AI Attestation: How Hardware Proof Replaces Policy Promises at the Inference Layer

TL;DR

• Choosing ZDR over TEE model routing isn't a configuration preference; it's the decision that determines whether a cryptographic audit record exists for a given inference call, and that choice can't be retroactively undone for past workloads.
• CPU attestation alone leaves the GPU unverified, and since model weights and activations reside in GPU memory during inference, an audit trail built on CPU-only receipts leaves a gap that auditors examining composite attestation requirements will find.
• A TEE receipt proves an attested environment existed; message signature binding proves this specific output came from this specific input inside it; without that second layer, the receipt doesn't answer the question a regulator actually asks.
• Treating "failed" attestation status and "no attestation" as equivalent in audit workflows is a meaningful error: "failed" means a receipt arrived and didn't validate, which points to a fixable verification problem; "no attestation" means no hardware proof was produced at all, which points to an architectural one.
• The three TEE providers in ORGN Gateway (NEAR AI, Phala, Tinfoil) use different hardware roots of trust and different attestation classes, so compliance documentation that describes "TEE attestation" as uniform will contradict the attestation_type field in the actual request records, a discrepancy auditors check.
• Both attestation systems (per-request inference receipts at /request/:requestId and per-environment sandbox TDX at /sandboxes/:sandboxId) are publicly queryable without operator credentials, which means a third-party auditor can verify the full chain independently, but only if both were configured and captured before the audit, not after.

What Breaks When AI Runs Without Proof

NIST Cybersecurity Framework 2.0 now explicitly names data in use as a distinct protection category under PR.DS-10, alongside data at rest and data in transit. For AI inference workloads, that's the category that has been hardest to satisfy without hardware.

Encryption covers storage and transport. What it doesn't cover is computation: the brief window when model weights, user prompts, and inference outputs exist in plaintext in memory. Standard cloud architectures give hypervisors and infrastructure operators full access to that memory. The Anthropic/Pattern Labs Confidential Inference Systems whitepaper frames this as a three-party trust problem: model owners, data owners, and service providers each have confidentiality requirements that can't be satisfied through contracts alone. Contracts certify intent; they don't prove execution. AI attestation is the mechanism that closes that gap.

The failure mode is specific, i.e., a security team deploys AI into a regulated workflow, collects the vendor's SOC 2 report and data processing agreement, and files both with legal. Eighteen months later, a regulator asks for proof that a specific model inference produced a specific output in an isolated environment. The team has no chain of custody for that inference call. Log files and screenshots reconstruct narrative; they don't constitute cryptographic proof. Hardware-backed attestation exists to produce exactly the artifact that narrative cannot: a signed, independently verifiable record that a specific computation ran inside a genuine, hardware-isolated Trust Domain.

This article covers how that proof works at the hardware level, why inference receipts and sandbox attestation answer different questions, where the verification chain fails in regulated audit workflows, and what independent verification looks like without trusting the vendor's own UI.

What a Signed Inference Receipt Actually Contains

Inference receipts are per-request artifacts, not platform-level claims. Understanding what they contain, and what binds them to a specific computation, is the prerequisite for evaluating whether your attestation program satisfies an auditor.

The Gap Between CPU and GPU Attestation

CPU-only attestation is the most common starting point for confidential computing deployments, and it covers less of the AI workload than most teams realize. The CPU execution environment is verified; the GPU is not. During inference, model weights, input tokens, intermediate activations, and outputs all reside in GPU memory. CPU attestation says nothing about what happened there.

Composite attestation closes this gap by binding CPU and GPU evidence into a single chain of trust. The Intel TDX quote's REPORT_DATA field contains a cryptographic reference to the GPU's attested state, and the whole composite is verified before any workload proceeds. A session nonce links the two: it appears in the TDX quote's REPORT_DATA field and in each GPU SPDM evidence header simultaneously. A nonce mismatch between these fields automatically fails verification, preventing an attacker from combining a genuine TDX quote with GPU evidence harvested from a different machine. The failure mode for teams that skip composite attestation is discovering during an external audit that their GPU operations have no independently verifiable record. At this point, the audit trail is incomplete by definition.

How TEE Providers Produce the Receipt

When a request routes to a TEE model, the provider executes inference within a hardware-isolated Trust Domain and returns the model output along with an attestation receipt signed with a key embedded in the silicon at the time of manufacture. ORGN Gateway routes to three TEE providers with distinct attestation architectures: NEAR AI and Phala both use Intel TDX + NVIDIA GPU attestation; only Tinfoil differs, on AMD SEV-SNP + Sigstore. Only genuine hardware from each vendor can produce a valid, signed report, which distinguishes a hardware receipt from a software attestation claim.

The request itself isn't the most important part of this workflow. Follow the receipt after inference completes, because that's where hardware evidence is collected, verified, and prepared for independent validation.

Notice that receipt generation and receipt verification are separate stages. A receipt becomes an audit artifact only after the Intel and GPU evidence pass cryptographic verification.

The receipt lifecycle, as documented in ORGN Scanner, follows a deterministic sequence: the client submits the inference to the Gateway API, the Gateway routes to the TEE provider, inference executes inside the Trust Domain, the provider returns model output plus attestation artifacts, the Gateway stores the receipt and runs verification against Intel/NVIDIA PKI, and Scanner displays the outcome at /request/:requestId. The raw artifacts are accessible via the public Gateway explorer API without requiring user authentication:

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

The response contains both spend_log (request metadata) and attestation (the full receipt payload, including Intel quote, GPU evidence, and verification flags). No session credentials required. That public accessibility is intentional: it means a third-party auditor can run the same verification without needing access to the operator's account.

Message Signature Binding and What It Proves

Hardware evidence proves the environment was genuine. Message signature binding proves the attested environment produced a specific output for a specific input. These are not the same claim, and a receipt that provides only the former is incomplete for regulated audit purposes.

The message signature in an ORGN attestation receipt covers a hash of the inference request, a hash of the model output, and an ECDSA signature from the model's signing address. Confirming that signature against the message_signing_address field proves the attested environment generated that exact response to that exact prompt. Compliance narratives that stop at "we use TEEs" can't answer the question a regulator actually asks: "Was this output produced by this attested system for this input?" Message binding turns a platform-level attestation claim into a per-decision audit artifact.

Two Attestation Systems, Two Different Questions

ORGN Scanner surfaces two distinct attestation systems. Conflating them is the most common compliance mistake in confidential AI deployments.

Inference Receipts vs. Sandbox TDX Attestation

Sandbox TDX attestation proves an execution environment is running on genuine Intel TDX hardware. Inference receipts prove a specific model call ran inside that environment. A complete audit trail for regulated workloads needs both, because they answer orthogonal questions.

The two systems live on separate pages in Scanner for exactly that reason. Sandbox attestation lives at /sandboxes/:sandboxId and pulls from the Daytona attest-gateway, a separate upstream from the Gateway spend-log pipeline. Inference receipts are served at /request/:requestId and pulled from the NEAR AI, Phala, or Tinfoil provider pipeline. The relationship between them, as documented, is explicit:

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 / Tinfoil providers
Page:   /sandboxes/:sandboxId                      Page:   /request/:requestId

For regulated workloads, the standard practice is to capture both: sandbox attestation establishes the trusted compute boundary, and inference receipts prove individual model calls executed within it.

When ZDR Is Not the Same as Attestation

Zero data retention is a contractual commitment; hardware attestation is a cryptographic proof. They answer different questions and don't substitute for each other. ZDR commits the vendor to not storing or training on inference data. It says nothing about the isolation properties of the environment where that inference ran.

For requests routed through Vercel AI Gateway (the vercel_* prefix in ORGN Gateway), Scanner records the request for observability, but attestation fields read N/A, and no hardware receipt exists. If a compliance program requires cryptographic proof of execution environment, ZDR models don't satisfy that requirement regardless of what the vendor's data processing agreement states. That's not a criticism of ZDR as a control. It's a recognition that the control addresses a different question, and deploying ZDR models for workloads that auditors will verify at the hardware level creates a gap that no contract language can fill.

Reading Attestation Status Correctly

Four verification outcomes appear in ORGN Scanner, and misreading them creates compliance blind spots. Verified means all PKI checks passed and the request is safe to export for compliance records. Failed means a receipt arrived and didn't pass validation; the attestation.error field describes the specific failure (stale quote, nonce mismatch, invalid certificate chain). Pending means the inference is complete, but the TEE provider hasn't yet returned the receipt; this is a provider-side timing issue, not a system failure, and the request status field should be checked separately. N/A means a ZDR model handled the request and no hardware receipt path exists.

Read the transition arrows before looking at the individual status labels. The path taken into each state determines whether the issue is a verification failure or an architectural limitation.

The easiest mistake is treating Failed and N/A as equivalent outcomes. One indicates that verification was attempted but failed, while the other indicates that no hardware attestation was available for that request.

A failed status is not equivalent to an unattested request. It means verification was attempted and didn't pass, which is a different condition than a request for which attestation was never produced. Both require action before a request can be included in a compliance archive, but they point to different remediation paths.

Independent Verification Without Trusting the Vendor UI

The value of cryptographic attestation for regulated audits comes specifically from its verifiability outside the attestation provider's own toolchain. If verification requires trusting the vendor's UI, the proof isn't independent.

Independent verification begins only after observable workload activity is present. Focus on the waiting state first because it highlights that evidence is generated during execution rather than when an auditor requests it.

An empty monitoring screen doesn't indicate failed attestation. It simply means no trace, log, or metric has been produced yet, so nothing is available to verify or export to the audit trail.

Validating Against Intel and NVIDIA PKI

For TEE requests with verified status, ORGN Scanner makes the raw artifacts available publicly at /request/:requestId without requiring sign-in. The independent verification workflow covers four steps: decode the Intel TDX quote from the base64-encoded intel_quote field and verify the signature chain against Intel's DCAP root of trust; validate each NVIDIA GPU evidence certificate against NVIDIA's attestation PKI; confirm the nonce in the TDX REPORT_DATA matches the nonce in each GPU SPDM evidence header; verify the ECDSA message_signature binds the request and response hashes to the message_signing_address. All of these operations run against public PKI infrastructure that ORGN doesn't control.

For compliance archives, the artifacts to export for each verified request are: id (attestation record UUID), signing_address, intel_quote, gpu_evidence array, nonce, and attestation_timestamp. The attestation_timestamp is in RFC 3339 format. These fields, defined in the Attestation Reference, contain everything a third-party auditor needs to re-verify the receipt without accessing the operator's credentials.

What Attestation Does Not Cover

The shared responsibility boundary matters for regulated deployments precisely because attestation is often described in terms of what it proves rather than what it doesn't prove. Hardware attestation proves that the execution environment was genuine and unmodified at the time of the request. It doesn't cover compromised client environments or leaked API keys, malicious prompts or unsafe model outputs, data exposure before the request reaches the Gateway or after the response is delivered, or vulnerabilities in model weights or training data.

Source code security is an entirely separate system. ORGN Scanner's stated scope is Gateway inference attestation and confidential compute sandboxes; it's not a repository vulnerability scanner. Treating attestation as a complete security posture rather than a specific layer in a defense-in-depth architecture is where compliance programs tend to overstate their coverage, and where auditors find gaps.

Where AI Attestation Breaks in Regulated Audit Workflows

Getting attestation infrastructure in place is the first problem. Getting it to work correctly in production audit workflows is where implementation failures show up.

At this stage, the focus shifts from cryptographic proofs to the workload that ultimately generates them. Notice how the protected task executes within the confidential environment before any telemetry or attestation records are produced.

The execution interface itself doesn't establish trust. The evidence generated while that workload runs becomes verifiable later through attestation receipts and audit records.

Stale Quotes and Replay Attacks

A verified attestation quote is a snapshot of the execution state at a specific moment, not a continuous monitor. Unless freshness is enforced through nonce binding or timestamp validation, a valid-looking quote can be replayed from a different session. The nonce mechanism in ORGN Scanner's attestation model directly addresses replay: the session nonce is cryptographically bound to a specific inference session and appears in both the CPU and GPU evidence headers. Using nonce evidence from a different session produces a mismatch that automatically fails verification.

Teams consuming attestation receipts programmatically should check the attestation_timestamp field and reject receipts older than the freshness window required by their policy, not only receipts with failed PKI checks. A receipt that passes all PKI validation but carries a timestamp outside the acceptable window isn't unverified; it's a stale one. The distinction matters for audit trails: a stale receipt proves execution happened, but not that it happened when the audit log claims.

Provider Heterogeneity and Compliance Copy

Three TEE providers in ORGN Gateway use three different attestation architectures: Intel SGX enclaves (NEAR AI), Intel TDX with NVIDIA GPU SPDM (Phala), and AMD SEV-SNP with NVIDIA confidential-compute GPU (Tinfoil). The granularity, hardware root of trust, and verification process differ across all three. Compliance documentation that describes "TEE attestation" as a uniform property, without distinguishing attestation classes, creates a liability when auditors ask for specifics.

Scanner displays the provider's actual attestation class in the attestation_type field of each request. That field is the authoritative source for what class of attestation a request carries. External-facing compliance copy that describes a deployment's attestation posture should match the attestation_type values actually present in the audit log, because an auditor who checks Scanner against the policy document will catch any discrepancy.

Building the Audit Trail for a Single Regulated Workflow

A complete audit record for a regulated AI workflow combines both attestation systems. Sandbox attestation establishes the trusted compute boundary; per-request inference receipts prove individual model calls ran inside it. Neither alone constitutes a complete chain of custody.

Start with the two evidence paths feeding into the audit archive rather than the verification layer below. They represent two distinct types of proof that must coexist before an auditor can validate an AI workload.

The infographic shows why neither sandbox attestation nor inference receipts are sufficient on their own. Only when environment-level and request-level evidence converge into the same audit record can an independent auditor reconstruct the full chain of custody.

Before looking at the individual attestation records, it helps to understand where those trusted execution environments originate. Focus first on the TDX node pools on the right, because they define the hardware boundary that all subsequent sandbox attestations refer to.

One detail that's easy to misread is the utilization charts on the left. They describe cluster capacity, not whether a particular inference request is attested; hardware trust is established through sandbox and request receipts, not resource consumption metrics.

For archive export, the per-request artifacts to capture are: id, signing_address, intel_quote, gpu_evidence, nonce, attestation_timestamp, and attestation_type from each verified inference receipt, plus the sandbox TDX attestation from /sandboxes/:sandboxId for the environment those requests ran in. Both endpoints are public in ORGN Scanner and can be queried without user authentication. A third-party auditor can run the full verification independently against public Intel and NVIDIA PKI without ever accessing the operator's credentials or ORGN's own toolchain.

AI Attestation Is Infrastructure, Not a Compliance Checkbox

The choice between a TEE model prefix (near_*, phala_*, tinfoil_*) and a ZDR model prefix (vercel_*) in ORGN Gateway is an architecture decision with direct compliance consequences. TEE models produce hardware attestation receipts; ZDR models don't. That's not a configuration detail to sort out later. For regulated workloads where auditors will request cryptographic proof of the execution environment, the decision must be made before the workflow is deployed, not at the point of audit. Retrofitting an attestation layer onto a ZDR-routed architecture entails changing the routing configuration, rerunning historical requests through the attested infrastructure, and building a new audit archive. None of that is difficult, but none of it is retroactive.

This article covered how inference receipts and sandbox TDX attestation answer different questions and why both are required for a complete audit trail; how composite CPU and GPU attestation prevents the most common coverage gap; how message signature binding turns a platform-level TEE claim into a per-decision proof; where verification fails in practice through stale quotes, nonce mismatch, and provider-level attestation class differences; and how to export artifacts from ORGN Scanner for independent third-party verification against public Intel and NVIDIA PKI. The architectural decision that determines whether any of this is available to you is made at model prefix selection, not at deployment review.

FAQs

1. What is the difference between AI attestation and a SOC 2 report?

A SOC 2 report certifies an organization's security controls at a point in time through a third-party audit. AI attestation is a per-request cryptographic proof that a specific inference call ran in a genuine, hardware-isolated environment. SOC 2 indicates that the vendor had strong policies during the audit window. Attestation tells you what actually executed on Tuesday.

2. How do you verify TEE attestation independently without trusting the vendor?

Decode the Intel TDX quote from the intel_quote field and validate the signature chain against Intel's DCAP root of trust. Validate each NVIDIA GPU evidence certificate against NVIDIA's attestation PKI. Confirm the session nonce in the TDX REPORT_DATA matches each GPU SPDM evidence header. ORGN Scanner exposes all raw artifacts publicly at /request/:requestId without requiring a login, so a third-party auditor can run full verification against the public PKI infrastructure without accessing the operator's account.

3. Does GPU attestation work the same way as CPU attestation for AI workloads?

No. CPU attestation (Intel TDX, AMD SEV-SNP) verifies the compute environment on the CPU side. GPU attestation uses NVIDIA's SPDM-based evidence to verify the GPU hardware and firmware state. For AI workloads, both are needed: composite attestation binds them through a shared session nonce, so a valid composite receipt proves the full inference stack, CPU and GPU, ran in an attested state during the same session.

4. What happens to AI attestation when inference runs across multiple GPUs in a cluster?

Each GPU in the attestation set produces its own evidence entry in the gpu_evidence array, identified by ordinal. The session nonce binding extends across all GPUs in the set. A nonce mismatch on any single GPU causes composite verification to fail, preventing a partial-attestation scenario in which some GPUs in a multi-GPU inference run are verified while others aren't.