Verifiable Privacy and Attestation
How ORGN Gateway provides cryptographic proof of execution integrity for TEE model requests using Intel TDX and NVIDIA GPU hardware attestation — and what ZDR routes do not prove.
Cryptographic attestation and hardware verification apply to TEE models only (near_*, phala_*). ZDR models (vercel_*) provide zero data retention guarantees through provider agreements but do not generate attestation receipts or support independent hardware verification.
Verifiable inference explained
Verifiable inference is the core security guarantee for TEE models on ORGN Gateway. For those requests, privacy is not based on policy alone — it can be backed by cryptographic proof tied to each individual request.
What "verifiable privacy per request" means (TEE)
For every TEE inference request:
- The model executes inside a hardware-backed Trust Domain
- The execution environment produces cryptographic evidence of how and where the request was processed
- That evidence can be independently verified in ORGN Scanner
Privacy guarantees are request-scoped on the TEE path. Each response can carry its own proof.
What is proven cryptographically (TEE)
Using hardware attestation, you can verify that:
- The inference ran inside a genuine Trust Domain
- The execution environment was not tampered with
- The environment matched expected security measurements
- The response was generated within that trusted boundary
These proofs are anchored in hardware root-of-trust mechanisms, not software assertions.
What TEE routes guarantee
For TEE model requests, Gateway ensures:
- Prompts and responses are processed inside Trust Domains during inference
- Data is encrypted while in use inside the TEE
- Execution integrity can be verified per request in Scanner
- Gateway does not access plaintext inference data outside secure Trust Domains
What is out of scope
Gateway does not claim to guarantee:
- Compromised client environments or API key leakage
- Malicious prompts or unsafe model behavior
- Data exposure before requests are sent or after responses are received
- Vulnerabilities inside model weights or training data
- Hardware proof on ZDR routes (policy retention only)
- Non-attested execution paths outside supported TEEs
For the full threat model, see the Security model.
Attestation flow (TEE)
Attestation is the mechanism by which TEE execution produces verifiable evidence you can inspect in Scanner.
Request lifecycle and attestation timing
The client submits an inference request to Gateway, explicitly specifying a TEE model ID (for example near_glm_4_7).
The request is forwarded to the model's TEE-backed execution environment.
During execution, the hardware records cryptographic measurements of the environment, including code and configuration state.
These measurements are signed using hardware-backed keys rooted in the platform's trust anchor.
The model output is returned along with attestation artifacts tied to that specific request.
Hashes, measurements, and signatures
Attestation artifacts typically include:
- Cryptographic hashes of the execution environment
- Signed measurements attesting to environment integrity
- Metadata linking the attestation to the specific inference request
These artifacts are tamper-evident and can be validated independently.
For a detailed breakdown of the attestation receipt structure, including Intel TDX quote fields, NVIDIA GPU evidence, message signatures, and external trust anchors, see the Attestation data reference.
What you can independently verify
Using the attestation data, you can verify that:
- The inference ran inside a genuine Trust Domain
- The hardware platform is authentic
- The execution environment matches expected security properties
- The response was produced within that verified environment
This enables auditable, defensible trust without relying on Gateway or model providers as intermediaries for the proof itself.
Supported attestation technologies (TEE)
Gateway TEE routes use a unified architecture combining CPU and GPU isolation.
Intel TDX + NVIDIA GPU
Every TEE inference request runs inside a Trust Domain that combines CPU and GPU isolation in one session.
Intel TDX (Trust Domain Extensions) provides the secure virtual machine:
- Hardware-enforced isolation from the host OS and hypervisor
- Memory encryption and integrity for all VM contents
- Verifiable measurements of VM state (code identity, runtime configuration)
NVIDIA GPU attestation extends the trust boundary to GPU compute within that VM:
- Verified GPU firmware and execution environment
- Cryptographic proof of trusted GPU execution
- Protection against unauthorized access during inference
How CPU and GPU evidence bind together
The TDX quote and GPU evidence are cryptographically linked by a shared session nonce. The nonce appears in both the TDX REPORT_DATA and each GPU's SPDM evidence header, proving that all attestations were generated in the same session.
By combining hardware-backed execution, cryptographic attestation, and per-request verification, Gateway enables a posture where TEE privacy and integrity are provable, inspectable, and auditable in regulated or adversarial environments.
Related
- Gateway quickstart — send a TEE request and inspect Scanner
- ORGN Scanner — verify receipts independently
Gateway Security Model and Threat Boundaries
How ORGN Gateway enforces privacy through TEE (hardware-isolated, cryptographically verifiable) and ZDR (policy-enforced zero data retention via Vercel). Threat model, key management, and data handling.
Gateway Attestation Data Reference
Technical reference for the cryptographic attestation receipt returned with TEE inference requests through ORGN Gateway. Intel TDX quotes, NVIDIA GPU evidence, message signatures, and external trust anchors.