One npm install or pip install. Your LLM key never leaves your network. Every response comes back with a post-quantum certificate (ML-DSA-65, the government's post-quantum signature standard under FIPS 204) bound to your tenant DID. Anyone with the cert can check where the response came from. No corpus access required.
Pick the language you already use. Both SDKs work the same way: sign(), wrap(), verify(). No rebuilding your architecture. No proxy. No change to your data path.
$ npm install @hivery/amplihive
import { AmpliHive } from "@hivery/amplihive"; import OpenAI from "openai"; const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY }); const hive = new AmpliHive({ tenantDid: "did:hive:acme", apiKey: process.env.AMPLIHIVE_API_KEY, }); // Your LLM stays on your side. const llm = await openai.chat.completions.create({ model: "gpt-4o-mini", messages: [{ role: "user", content: prompt }], }); const text = llm.choices[0].message.content; // AmpliHive signs the (prompt, response) pair. const cert = await hive.sign({ prompt, response: text }); console.log(cert.certificate.alg); // "ML-DSA-65"
$ pip install amplihive
from openai import OpenAI from amplihive import AmpliHive openai = OpenAI(api_key=os.environ["OPENAI_API_KEY"]) hive = AmpliHive( tenant_did="did:hive:acme", api_key=os.environ["AMPLIHIVE_API_KEY"], ) # Your LLM stays on your side. llm = openai.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], ) text = llm.choices[0].message.content # AmpliHive signs the (prompt, response) pair. cert = hive.sign(prompt=prompt, response=text) print(cert.certificate.alg) # "ML-DSA-65"
Five stages, one ML-DSA-65 certificate, in the same call: COMPILE, COMPRESS, AMPLIFY, CERTIFY, WRITEBACK. Pick a partner attribution and watch it bind into the signed payload. Tamper any byte and verify fails.
partner_id in the cert. We accumulate. The partner gets the share they negotiated. No reconciliation theater. The ledger is the signed payload.The drop-in is a sealed transit layer. It carries proof, not power. If anything in transit gets altered, the certificate breaks.
The tenant corpus lives on AmpliHive servers, sealed to your DID. Attackers on the customer host can't enumerate it. Retrieval runs over a 256-dim hashing-trick embedding, not a model fingerprint.
Every cert is ML-DSA-65. Even with full access to the widget binary, an attacker can't mint a valid certificate. They can verify one. They can't sign one.
The certificate binds prompt_hash, response_sha256, and enrichment_sha256 in one payload. Alter any byte of either text after signing and verify() returns ok: false.
No. The widget calls your LLM client. Only the prompt text, response text, and your tenant DID traverse to AmpliHive.
Yes. hive.wrap(callLlm, { promptText }) seals your call: AmpliHive does not need the key, just the function. Same cert at the end.
POST the certificate to /v1/amplify/verify. Optionally include the original prompt and response for full hash-binding checks.
Free up to 1,000 signed calls per month. After that, $0.06 per 1M calls. USDC on Base.
Any model. AmpliHive works the same way no matter which LLM provider you use: OpenAI, Anthropic, Fireworks, Together, OpenRouter, self-hosted, all supported. Pass a custom extractor for non-OpenAI response shapes.
Patent Pending. Provisional patents filed. IP protection in place.