Plaintext stays inside TEE memory
TLS ends inside the gateway TEE. Each request is sealed to the provider enclave’s key, so the router carries only ciphertext and never holds the key.
Independent verification
Why this is private
Why 0G can’t read your Private Compute prompts—and how to verify it yourself.
This is the short version. The procedure is verifying-the-gateway.md; the design is under design/.
The short answer
The operator cannot read enclave memory
Keys are created and kept inside enclave memory. Neither the cloud host nor 0G operators can inspect the keys, prompts, or decrypted responses.
Both TEEs are checkable
Gateway and provider TEEs publish hardware-signed measurements and release builds, allowing anyone to verify exactly which code is running.
Where your prompt goes
The router forwards and bills every request, but it never receives the key needed to open the sealed body.
Ciphertext · TLS
Your browser
A standard HTTPS session terminating inside the gateway TEE.
Plaintext · memory
Gateway TEE
The request is sealed to the verified provider enclave's key.
Ciphertext · HPKE
0G router
Forwards the sealed body opaquely and never holds the decryption key.
Plaintext · memory
Provider TEE
The model runs inside the same attested enclave that decrypts the request.
Ciphertext · signed
Response
Returns sealed with an enclave signature the router cannot forge.
After the response, the gateway fetches the provider’s signature—without prompt content. Prompts are never stored in logs, backups, or on disk.
Why “inside a TEE” is checkable
The TLS key is born inside
The ingress creates its private key inside the confidential VM and commits the served certificate into an Intel TDX attestation quote. Matching them proves that TLS terminated inside the enclave.
Intel signs the running build hash
The quote commits to the deployment manifest, which pins every container by digest. Any code change produces a different hardware-signed measurement that anyone can compare with a published release.
The provider is verified first
The gateway DCAP-verifies the provider quote and reads its encryption key from that verified evidence, never from the router. Unverified providers and unsigned responses are rejected.
Check it yourself
Build the verifier and run one command against a gateway domain. It validates Intel's quote, the certificate served to your connection, the code hash, and its published release.
$cd 0g-pc-e2ee/client && go build -o pcverify ./cmd/pcverify
$./pcverify -gateway <gateway-domain>
What we can still see
Encrypting the body does not hide all surrounding metadata. The router can read and bill these fields, but the enclave signature prevents it from altering them.
- The model you requested, because the router must route it.
- Your exact token usage, because the router bills on it.
- Message sizes; ciphertext preserves plaintext length plus a constant.
- Request and response timing, including streamed chunk timing.
What this does not prove
- Detection, not prevention. A dishonest deployment becomes publicly detectable only when someone runs the verification.
- A pass covers the connection that was checked, not automatically every enclave behind the same domain.
- This is verifiable relay, not verifiable computation. It proves which enclave produced a response, not the model's quality or behavior.
- Availability is not attested; a deployment can still be taken offline.
- The hosted gateway adds a second enclave that sees plaintext. Client-side sealing is not yet a supported entry point.
Going deeper
Verifying the gatewayEvery check, exit code, manual step, and current limitation.Trust chainEvery hop and which links are enforced versus observed.Cloud gateway designWhy the gateway exists and why its quote comes from ingress.Protocol specificationThe wire format for sealing requests and proving responses.