Attestation Reference

Field definitions for inference attestation receipts and sandbox TDX attestation in ORGN Scanner.

ORGN Scanner is not Studio Code Security (Shannon). Scanner audits Gateway inference attestation and confidential compute sandboxes — it does not scan your repository for CWE vulnerabilities. For code security assessments, see Code Security.

ORGN Scanner surfaces two distinct attestation systems. They answer different questions and live on different pages. Conflating them is a common compliance mistake.

System	Question answered	Scanner page	Scope
Inference attestation receipts	Did this specific Gateway inference call run in a verified TEE?	`/request/:requestId`	Per-request
Sandbox TDX attestation	Is this confidential compute environment running on genuine Intel TDX hardware?	`/sandboxes/:sandboxId`	Per-environment

Both are public — no sign-in required to inspect artifacts.

System 1: Inference attestation receipts

When you send a request to a TEE model (near_* or phala_*), the Gateway records the call in spend logs and attaches an attestation receipt from the TEE provider. Scanner displays the receipt on the request detail page.

ZDR models (vercel_*) do not produce hardware receipts. Their attestation fields read N/A.

Receipt lifecycle

Client submits inference to the Gateway API
Gateway routes to the TEE provider (NEAR AI or Phala)
Inference executes inside a hardware-isolated Trust Domain
Provider returns model output + attestation artifacts
Gateway stores the receipt and runs verification against Intel/NVIDIA PKI
Scanner displays the outcome at /request/:requestId

Core fields

Field	Type	Description
`id`	string	Attestation record UUID
`attestation_type`	string	Provider class — e.g. NEAR SGX, Phala TDX+GPU
`verified`	boolean	Whether Gateway verification passed
`signing_address`	string	Address that signed the attestation receipt
`message_signing_address`	string	Address that signed the request/response hash binding
`message_signature`	string	ECDSA signature over request and response hashes
`attestation_timestamp`	string	Receipt generation time (RFC 3339)
`model`	string	Model ID at time of attestation
`nonce`	string	Session binding value for CPU + GPU evidence
`error`	string	Verification failure reason (null when verified)

Hardware evidence flags

Field	Type	Description
`has_intel`	boolean	Intel TDX quote is present
`has_nvidia`	boolean	NVIDIA GPU SPDM evidence is present
`nvidia_arch`	string	GPU architecture identifier
`intel_quote`	string	Base64-encoded Intel TDX attestation report
`gpu_evidence`	array	NVIDIA certificate + evidence pairs per GPU

GPU evidence entries

Each element in gpu_evidence:

Field	Description
`ordinal`	GPU index in the attestation set
`arch`	GPU architecture string
`certificate`	NVIDIA attestation certificate chain
`evidence`	SPDM evidence blob

Session nonce binding

The nonce is the cryptographic link between CPU and GPU attestations. It appears in:

The TDX quote REPORT_DATA field
Each GPU SPDM evidence header

A mismatch between these nonces indicates mixed-environment attestation and causes verification to fail. This binding prevents an attacker from combining a genuine TDX quote with GPU evidence from a different machine.

Message signature binding

Beyond hardware evidence, the receipt includes a message signature that binds:

request_hash — hash of the inference request
response_hash — hash of the model output
ecdsa_signature — signature from the model signing address

This proves the attested environment produced the specific output for the specific input — not just that a TEE existed at some point.

Verification status values

Status	Meaning
`verified`	All PKI checks passed
`failed`	Receipt present but validation failed — see `error`
`pending`	Inference complete; receipt not yet received
`n/a`	ZDR model — no hardware attestation path

For the independent verification workflow, see Verify a request.

API access

curl -s "https://api.gateway.orgn.com/internal/console/explorer/request/<request-id>" \
  | jq '.attestation'

System 2: Sandbox TDX attestation (Daytona)

Confidential compute sandboxes are isolated execution environments provisioned for Studio projects and Gateway workloads. Unlike inference receipts (per-request), sandbox attestation proves the environment itself is running on genuine Intel TDX hardware.

Scanner loads sandbox attestation from the Daytona attest-gateway — a separate upstream from the Gateway spend-log pipeline.

Where to inspect

Page	URL	Content
Sandbox list	`/sandboxes`	Running sandboxes, resource usage, TDX node pools
Sandbox detail	`/sandboxes/:sandboxId`	Per-sandbox metadata + live TDX attestation panel

Sandbox attestation is public. The attest-gateway serves evidence to anyone — the same primitive that powers Scanner's sandbox panel.

What sandbox attestation proves

The sandbox VM is running inside an Intel TDX Trust Domain
The TDX quote reflects the current VM measurement state
The environment matches expected confidential-compute configuration

Sandbox attestation does not prove that a specific inference call ran inside the sandbox. For per-request proof, use inference attestation receipts at /request/:requestId.

Relationship to inference receipts

Sandbox TDX attestation          Inference attestation receipt
─────────────────────────        ─────────────────────────────
Proves: environment is genuine   Proves: specific call ran in TEE
Scope:  per sandbox              Scope:  per request
Source: Daytona attest-gateway   Source: NEAR AI / Phala providers
Page:   /sandboxes/:sandboxId    Page:   /request/:requestId

A compliant audit trail for regulated workloads typically includes both: sandbox attestation establishes the trusted compute boundary; inference receipts prove individual model calls executed within it.

API access

Scanner proxies sandbox attestation through:

GET /api/sandboxes/:sandboxId/attestation

This calls the Daytona attest-gateway directly — no user session required.

Provider attestation types

Provider	Prefix	Hardware	Attestation class
NEAR AI	`near_*`	Intel SGX	SGX enclave attestation
Phala	`phala_*`	Intel TDX + NVIDIA GPU	Unified TDX + GPU SPDM
Vercel AI Gateway	`vercel_*`	Standard cloud	ZDR — no hardware receipt

NEAR AI uses SGX enclaves — a different granularity than Intel TDX Trust Domains. Do not conflate SGX "enclave" language with TDX "Trust Domain" language in external-facing compliance copy. Scanner displays the provider's actual attestation class.

What attestation does not cover

Explicit boundaries — shared responsibility model:

Compromised client environments or leaked API keys
Malicious prompts or unsafe model behavior
Data exposure before the request reaches the Gateway or after the response is delivered
Vulnerabilities inside model weights or training data
Source code security (that is Studio Code Security)

Next steps

Verify a request — step-by-step independent validation
Request details — full metadata field reference
Sandboxes — sandbox inventory and TDX panel
Verifiable privacy — end-to-end attestation flow
Platform trust model — TEE vs ZDR framing

Attestation Reference

On this page