Pick an attack on a wire transfer and watch execution refuse. The digests are computed in your own browser. Then take the record it hands you and check the second signature against a published key, again in your own browser.
What the demo does not do. It proves the instruction did not change in custody. It does not prove the answer was right or that any model was honest. The second signer is a separate key, a separate clock and a separate log operated by Hive, so it is not an outside party and the service reports that itself. It signs Ed25519, which is not post quantum. The operator side signs ML-DSA-65 under NIST FIPS 204. The second signer's log does not survive a redeploy today, and it says so too. Patent pending.
AmpliHive is the customer-side trust layer for AI Gateway, Workers AI, and any model traffic passing through Cloudflare. Each response is stamped with an ML-DSA-65 certificate binding prompt_hash, response_sha256, tenant_did, and partner_id=cloudflare. That's unforgeable attribution. You ship the “provable AI” checkbox enterprise CIOs already ask for. We take $0.06 per 1M signed calls. You take a negotiated cut. The ledger is the signed payload, so there's no reconciliation theater.
Today AI Gateway gives caching, rate-limiting, and analytics. AmpliHive adds the missing layer: cryptographic provenance under FIPS 204 (ML-DSA-65). The same gateway, now defensible in a banking, healthcare, or gov procurement.
Bind every Workers AI response to a signed cert with partner_id=cloudflare inside the payload. Competitors can’t copy this in a quarter. PQ signing infra plus tenant DID plus corpus writeback is a year of work.
AmpliHive does not see the customer’s prompt body unless they opt in. We see hashes. The cert is signed against hashes. Drop it next to AI Gateway on the customer’s account, and the customer’s data path stays at the edge.
Cloudflare’s edge wins on TTFT and reach. We don’t sit in that path. AmpliHive is a sidecar: the customer’s app calls AI Gateway, then calls hive.sign({prompt, response}). Total round-trip overhead is ~6ms p95 plus ~60ms ML-DSA-65 sign, off your critical path. AI Gateway’s latency story stays clean. Cloudflare’s compliance story becomes the best in the AI infra market.
partner_id=cloudflare. Revenue share is provable, not promised.Customer keeps their Cloudflare AI Gateway URL. Customer keeps their data path. AmpliHive returns a cert. The cert says “signed for tenant X, attributed to Cloudflare.”
import OpenAI from "openai"; import { AmpliHive } from "@hivery/amplihive"; // Cloudflare AI Gateway in front of any provider const ai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY, baseURL: "https://gateway.ai.cloudflare.com/v1/<account>/<gateway>/openai", }); const hive = new AmpliHive({ tenantDid: "did:hive:acme", apiKey: process.env.AMPLIHIVE_API_KEY, partnerId: "cloudflare", // bound into the signed cert }); const llm = await ai.chat.completions.create({ model: "gpt-4o-mini", messages: [{ role: "user", content: prompt }], }); const text = llm.choices[0].message.content; const cert = await hive.sign({ prompt, response: text }); console.log(cert.certificate.payload.partner_id); // "cloudflare" console.log(cert.certificate.alg); // "ML-DSA-65"
Sign a real (prompt, response) pair against production. The cert payload will carry partner_id: "cloudflare". Try the “Tamper partner_id” button, and the signature breaks. That’s the unforgeable attribution.
partner_id=cloudflare is bound inside the signed payload, so attribution is a query against signed records rather than a quarterly reconciliation call. Price and split are set in the pilot, once we both know what the workload actually looks like.Each link opens that entry in the canon implementation explorer, where its schema, mint route, open verify route, auth requirement and implementation state are stated. The state shown here is read from the same registry file the explorer renders from, so the two cannot drift apart. Nothing here implies a customer, a deployment or an endorsement.