The cloud should not be able to read your prompts

The cloud administrator should not be able to read your prompts. Disk encryption and HTTPS do not get you there. They protect data while it is stored and while it crosses the network. A normal server decrypts the request before the application uses it, which leaves plaintext in memory where a privileged operator, debugger, compromised hypervisor, or host bug may reach it.

Red Hat describes confidential computing as protection for data in use. The code runs inside a hardware-backed Trusted Execution Environment, usually shortened to TEE. The host can give that workload CPU and memory, send it network packets, restart it, or kill it. The processor blocks the host from inspecting the workload's protected memory. The prompt becomes plaintext only inside that boundary.

A TEE does not make bad code good. Code running inside the protected memory can still leak a prompt. Bugs still matter. The cloud hardware and its attestation service remain part of the trust base. Confidential computing removes a very large class of operator and host access, but you still need to know which code entered the protected memory.

That is what remote attestation is for. Before an agent sends a prompt, it sends fresh random data called a nonce. The confidential workload asks the platform for a signed attestation token containing that nonce and measurements of the running environment. A verifier checks the platform signature, the intended audience, the production debug state, and the container image digest. Replaying an old token fails because its nonce is wrong.

Apple made this verification model unusually clear in its Private Cloud Compute design. Traditional cloud controls are hard for a user to inspect from the outside. Apple therefore treats verifiable software transparency, stateless processing, and the absence of privileged runtime access as product requirements. TrustedRouter applies the same basic demand to a public-source AI gateway: identify the code that will receive the prompt before trusting it with the prompt.

Here is what happens on a normal request to api.trustedrouter.com:

1. The client opens TLS directly to a regional TrustedRouter gateway. The TLS private key and HTTP request terminate inside GCP Confidential Space.
2. The gateway asks the control plane to authorize the API key and choose eligible routes. That exchange contains billing and routing metadata, not the prompt body.
3. The gateway calls the selected model provider, streams the answer back, and settles integer token costs against the authorization.
4. The control plane records metadata such as model, provider, token counts, latency, status, and cost. The prompt and answer stay out of that database and its logs.

GCP Confidential Space runs the gateway container on a Confidential VM with hardware isolation and remote attestation. TrustedRouter uses the production image. The public verifier rejects a debug image because Google's debug variant enables operator access that is unacceptable for sensitive production prompts.

TrustedRouter also binds the attestation to the live TLS connection. The signed token covers the certificate presented on that connection and an RFC 9266 TLS exporter derived from that exact session. This matters because a valid token fetched through one connection should not be reusable to bless a different proxy connection. The verifier keeps the socket open and confirms that the follow-up request stays on the attested session.

You can have an agent verify the live service now. This uses the public release record, checks out the source commit named by that release, and runs the strict verifier from the same commit. It does not pipe downloaded code straight into a shell, so the agent can inspect the verifier first.

release="$(mktemp)"
curl -fsS https://trust.trustedrouter.com/gcp-release.json -o "$release"
commit="$(jq -r '.source_commit' "$release")"
digest="$(jq -r '.image_digest' "$release")"

git clone https://github.com/Lore-Hex/quill-cloud-proxy.git
cd quill-cloud-proxy
git checkout "$commit"

# Read tools/verify-attestation.py, then run it.
uv run --script tools/verify-attestation.py   --api-host api.trustedrouter.com   --expect-digest "$digest"   --samples 4

A passing run confirms a Google-signed Confidential Space token, a fresh nonce, the expected audience and image digest, production debug state, the TLS leaf certificate, the TLS session exporter, and repeated requests on the same attested socket. The release record names the source commit and deployed image. The repository also includes a full rebuild verifier for an engineer who wants to compare the published binary with a local build.

What does that prove? It proves that the gateway at the other end of the verified TLS session is running the measured production image and that the connection is bound to that workload. The source and verifier are public, so an engineer can inspect the code paths that handle prompts, logging, settlement, and provider calls. It does not prove the code has no bugs, that your own machine is clean, or that every downstream model provider uses confidential computing.

The provider boundary is the part people skip. The selected model provider normally receives the prompt. provider.min_privacy = "zdr" requires a route with a zero-data-retention posture. The stronger provider.min_privacy = "confidential" requires provider-side confidential compute and end-to-end encryption, and fails closed when no eligible route exists. The model aliases trustedrouter/e2e and trustedrouter/confidential select that same stronger pool.

The distinction is useful. Attestation proves the TrustedRouter gateway. A confidential provider route extends the protected path through model execution. A ZDR contract governs retention after a provider receives the data. Those are three different properties, and the security page and provider directory expose them separately.

A privacy policy asks you to believe whoever runs the server. Make the server identify itself before your agent sends the prompt.

---