Every response can prove itself
Until today, a TrustedRouter response proved nothing on its own. Everything we publish about the gateway — the attested enclave, the RFC 9266 channel binding, the measured image digests — is evidence about the connection and the binary. The moment a response left that connection, it was just bytes. Anyone could edit them, misattribute them, or claim a different model wrote them, and nothing in the bytes could argue back.
Now any request can opt into a signed receipt. Add one header — x-inference-receipt with a fresh nonce — and the response carries a compact proof signed inside the enclave: the SHA-256 of the exact request you sent, the SHA-256 of the exact bytes you received, the model and provider that actually served it, how that upstream was verified, and the signing time, with your nonce echoed inside the signature. Streaming responses get the same proof as the final chunk before [DONE], with the enclave's hardware attestation embedded so the whole thing verifies offline, from a file, with no call back to us. Signed-receipt requests are priced separately: managed prepaid inference uses a 12% total TrustedRouter service fee instead of the standard 5.5%; BYOK token pricing is unchanged.
curl https://api.trustedrouter.com/v1/chat/completions -H "Authorization: Bearer $TRUSTEDROUTER_API_KEY" -H "x-inference-receipt: $(openssl rand -hex 16)" -d '{"model":"trustedrouter/auto","messages":[{"role":"user","content":"Hello"}]}'The chain goes all the way down. Each enclave instance mints a fresh Ed25519 key at boot and commits a hash of it into its Confidential Space attestation — the same Google-signed evidence our trust page pins, with debug disabled and the image digest measured. A verifier checks the receipt's signature, recomputes both hashes from the bytes it holds, then checks that the signing key's commitment sits inside that attestation. If any byte of the request or response changed, the hash check fails. If the key didn't come from a measured enclave, the commitment check fails. We ran exactly this against production while writing this post; so can you, with the open reference verifier or any of the six SDKs — Python, JavaScript, Go, Rust, Swift, and Java all verify receipts against the same frozen test vectors, byte for byte.
The receipt is honest about the upstream, too. When your request rode a verified TEE route — a Tinfoil enclave, a Chutes TDX worker — the receipt says tee-verified and names the exact policy and the window in which that verification held. When it rode ordinary TLS to a provider like DeepSeek, the receipt says tls-webpki and claims nothing more. A failed verified candidate never lends its tier to the fallback that actually answered; the tier describes the connection your bytes used, and we pinned that property with a test before we shipped it.
Two things a receipt deliberately does not prove, because saying so is the difference between a proof and a vibe. It is not a confidentiality proof: a relay that forwarded your request holds a valid receipt and read everything, so session privacy remains the attested-TLS flow on the trust page, not the receipt. And it names no requester: receipts carry nothing about who asked, so you can hand one to an auditor without handing them your identity.
Keys are per-boot and per-instance, which is a feature with a consequence. The feature: no long-lived signing key exists anywhere, so there is nothing to exfiltrate and rotate. The consequence: a receipt must outlive the instance that signed it, so every observed key lands in an append-only public key log with its attestation, verified before it is recorded, alarmed if a key id ever reappears with different material. Your receipt from today still verifies after that instance is gone.
The wire format is deliberately provider-neutral — plain JWS, plain SHA-256, a documented commitment scheme — and the spec, the reference verifier, and the cross-implementation test vectors are public. Any OpenAI-compatible gateway that runs in a TEE could sign the same shape, and we would rather compete on routing than on whether a response can be trusted at all. The full guide, with the claims table and verification walkthroughs, is at docs/receipts. Get a receipt for your next request →