Origin Docs
Security

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

Request submission

The client submits an inference request to Gateway, explicitly specifying a TEE model ID (for example near_glm_4_7).

Secure execution

The request is forwarded to the model's TEE-backed execution environment.

Measurement and attestation

During execution, the hardware records cryptographic measurements of the environment, including code and configuration state.

Signature generation

These measurements are signed using hardware-backed keys rooted in the platform's trust anchor.

Response delivery

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.

On this page