ZDR is a vague promise. Attestation is precise proof
Every AI router says it protects your data. Of course it does. Nobody puts "our employees can read your prompts" on the homepage. The useful question is what the running machine can do with your prompt right now, and a privacy policy cannot answer it.
A normal gateway terminates TLS in an ordinary application process. That process reads your prompt, chooses a provider, and sends it along. The company may keep logging turned off. You still have to trust every administrator, every configuration change, every analytics library, and every deploy. Zero retention limits what the company promises to keep. It gives the machine full access first.
Open source helps, but there is an obvious hole. You can read a repository while the hosted service runs a different binary. How do you prove that the code on GitHub is the code holding the TLS key? Usually, you cannot.
I built TrustedRouter to close that hole. Public TLS for api.trustedrouter.com terminates inside a measured GCP Confidential Space workload. The private key stays inside that workload. The separate control plane handles accounts, credits, and request metadata. It never receives prompt or output bodies, and the gateway has no prompt storage path.
Google describes Confidential Space as a trusted execution environment that keeps data from the workload operator and produces attestation evidence identifying the workload. The product name is boring. The evidence is useful. It lets your computer check the issuer, audience, image digest, and certificate binding before it sends a prompt.
The live TrustedRouter trust page publishes the gateway repository, source commit, image reference, image digest, attestation issuer, and audience. A client can request fresh evidence, bind it to the TLS certificate with a nonce, and compare the measured image with the published release. If any of those values fail, the client should stop. There is no ordinary server waiting behind it as a convenient privacy downgrade.
But the model provider still gets the prompt, right? Yes. The router and the model provider are two separate trust boundaries, and pretending otherwise would make the attestation worthless. The provider directory publishes the upstream posture for every route and leaves unknown providers marked unknown. trustedrouter/zdr requires a tracked zero-retention provider. trustedrouter/e2e requires eligible confidential provider compute and provider-side encryption. Both fail closed when a qualifying route is unavailable.
Could another router add this? Yes, after moving certificate custody and plaintext request handling into a trusted execution environment, separating billing from the prompt path, removing content from telemetry, publishing source-to-image evidence, verifying fresh attestation, and giving up the ordinary fallback server. That is a rebuild, which is why a checkbox saying "ZDR" proves so little.
A privacy policy tells you what a company says. Attestation tells your computer which code has your prompt.