Two attestation challenges for confidential AI inference
By Henk Birkholz, Chief Technologie Officer, XOR
Confidential AI inference is a remote-attestation problem that manifests in new challenges. This blog post covers two of these challenges your team will meet in a real deployment. In confidential computing, the workload, a model plus a stream of user inputs and outputs, has to be provably running inside a hardware-protected Trusted Execution Environment. Additionally, its computation has to be provably securely isolated in such a confidential-compute environment. The industry has composed a well-established guideline to address this challenge. The Confidential Computing Consortium states: confidential computing is "the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment" [CCC-TA]. Hardware-based TEEs and cryptographically-signed attestation documents (i.e., IETF RFC 9334 conceptual messages) enable such trust decisions. This guideline consensus comes with two unresolved design decisions inside it. Coding agents are already being asked to implement and defend around those decisions, which makes where they land a live question.
The first arises because a confidential-inference host is never a single chip. Its computation spans at least a CPU-side TEE and one or more AI accelerators, and the boundary between them is where the largest confidential asset, the model itself, has to be operated. The second arises because producing attestation Evidence about a confidential AI workload is itself a form of disclosure: measurements over a workload's contents are structural fingerprints of that workload, and the Verifier that appraises them is by construction outside the confidentiality boundary. Both of these challenges have been addressed piecewise by IETF, DMTF, PCI-SIG, and TCG specifications, and also by open-source confidential-computing implementations. This post is a start at assembling the pieces in a meaningful manner.
The RATS vocabulary
The Remote ATtestation procedureS architecture defined by [RFC9334] provides an established vocabulary. Figure 1 shows the roles and artifacts.
Original diagram source
flowchart LR
subgraph Providers["Reference inputs to the Verifier"]
E["Endorser"]
RVP["Reference Value Provider"]
VO["Verifier Owner"]
RPO["Relying Party Owner"]
end
A["Attester
(produces Evidence)"] -- "Evidence" --> V["Verifier
(appraises Evidence)"]
E -- "Endorsements" --> V
RVP -- "Reference Values" --> V
VO -- "Appraisal Policy
for Evidence" --> V
V -- "Attestation Result" --> RP["Relying Party
(appraises Result)"]
RPO -- "Appraisal Policy
for Attestation Results" --> RP
classDef producer fill:#eef,stroke:#446,stroke-width:1px;
classDef verifier fill:#efe,stroke:#464,stroke-width:1px;
classDef consumer fill:#fee,stroke:#644,stroke-width:1px;
class A,E,RVP producer;
class V,VO verifier;
class RP,RPO consumer;
Figure 1. Roles and artifacts of a remote attestation procedure, adapted from [RFC9334] Figure 1.
An Attester produces Evidence about itself. A Verifier consumes Evidence and appraises it against Endorsements (from Endorsers), Reference Values (from Reference Value Providers), and an Appraisal Policy for Evidence (from a Verifier Owner). The Verifier emits an Attestation Result, which a Relying Party consumes and appraises against its own policy. Two base-line topological patterns, Passport and Background-Check, govern how Evidence is routed. Additionally, two nested-Attester patterns govern how Evidence is built when the Attester is not a single flat entity: the Layered Attester ([RFC9334] §3.2) and the Composite Device ([RFC9334] §3.3). Both patterns matter because two design questions are the core of these two challenges.
For a real example: a bank wants to use coding agents to help maintain and secure its internal software. The agents call a confidential-inference service, so prompts, generated code, and any bank data they handle stay invisible to the model vendor. When those agents then talk to the bank's classical internal systems (payroll pipelines, secret vaults, deployment targets), remote attestation is not something those systems can be expected to understand. Some even run on hosts the bank does not fully control. They still make yes/no decisions in familiar terms: "is this certificate on the allowed list?", "can this caller access the KMS-wrapped key?". Remote attestation still provides significant value-add here, and nothing on the legacy side needs to change. In this example, the coding agent is the Attester. Its Evidence goes to a Verifier for appraisal, and the resulting Attestation Result is sent to a credential-issuing service (a Secret Vault or a Credential Authority) that takes on the role of the Relying Party. That service issues a classical credential the legacy system already knows: an X.509 certificate carrying a stable workload identity, a bearer token, or a KMS-wrapped key. The RATS-unaware relying party receives only the classical credential and returns the same yes/no decision it always has. This is the same pattern the IETF and the Confidential Computing Consortium have been converging on, currently under the name TACRA [TACRA].
Diagram source
flowchart TB
AGENT["Bank coding agent
(Attester)"] -- "protected prompts / bank data" --> INFERENCE["Confidential-inference service"]
INFERENCE -- "generated code" --> AGENT
AGENT -- "Evidence" --> VERIFIER["Verifier"]
VERIFIER -- "Attestation Result" --> ISSUER["Credential issuer
(RATS Relying Party)"]
ISSUER -- "issues" --> CREDENTIAL["Classical credential"]
CREDENTIAL -- "received by" --> LEGACY["Bank system
(RATS-unaware)"]
LEGACY -- "returns" --> DECISION["Yes / no decision"]
classDef producer fill:#eef,stroke:#446,stroke-width:1px;
classDef verifier fill:#efe,stroke:#464,stroke-width:1px;
classDef consumer fill:#fee,stroke:#644,stroke-width:1px;
class AGENT,INFERENCE producer;
class VERIFIER verifier;
class ISSUER,CREDENTIAL,LEGACY,DECISION consumer;
Bank example. A credential bridge lets classical systems use an attestation-backed decision without interpreting RATS Evidence.
In your confidential-inference deployment, a service-provider's workload paravisor as well as the AI accelerator jointly act as Attesters - together. The model owner and the data owner each take turns as Relying Party: the model owner when the KMS decides whether to release model decryption keys, the data owner when their client decides whether to send inputs. Silicon vendors are the Endorsers for the service-provider's platform. Reference Values can come from the silicon vendors, the firmware vendors for the platform layers, and from the model owners for the workload measurements the paravisor takes. As a result, a Verifier can be run by either party, all those parties, and by all independent 3rd party attestation services.
Confidential-computing writing frequently uses "attestation document" as a single term. The RATS architecture makes an important distinction that this phrase obscures. Evidence is produced by the Attester, describes internal state, and is meaningful only to a Verifier that will appraise it against Reference Values and Endorsements. An Attestation Result is produced by the Verifier after that appraisal, is a signed statement of whether the Evidence passed policy, and is meaningful to any Relying Party that trusts the Verifier. Evidence contains measurements; an Attestation Result provides a verdict. An AWS Nitro attestation document, produced by the Nitro Security Chip, is Evidence. A Microsoft Azure Attestation token, issued by the MAA service after appraising a confidential-VM quote, is an Attestation Result. Confusing the two obscures where trust is being placed and - most importantly - confuses who is intended to consume it and to create value from it.
Attesting the CPU-accelerator link
Confidential AI inference does not run on one chip. A modern host provides a CPU-side TEE (Intel TDX, AMD SEV-SNP, or an AWS Nitro Enclave) and delegates the heavy tensor arithmetic to one or more AI accelerators. Google Cloud's Confidential VMs run on the same TDX or SEV-SNP silicon. Meanwhile, the Google-specific components appear as a launcher and attestation service inside the guest. On the accelerator side, NVIDIA's Confidential Computing on H100 and later GPUs adds a device-level TEE. Those accelerators are GPUs, NPUs, or TPUs, physically separate from the CPU and sharing memory only across a PCIe fabric. Confidential inputs, model weights, and outputs must cross that fabric. The confidentiality boundary must cross it too. Consequently, the trust story has to be a composable one: the CPU-side TEE and the accelerator have to create Evidence (please note, not just any attestation document) jointly, so that no single piece of Evidence stands alone.
In a nutshell, this is the Composite Device as specified by [RFC9334] §3.3 terms. The CPU-side TEE is the lead Attester. Each accelerator is a sub-Attester whose device Evidence must be composed into the whole. Figure 2 lays out the specifications that govern the intra-host composition concept.
Original diagram source
flowchart TB
subgraph Host["Host / Confidential VM"]
subgraph CPU_TEE["CPU-side TEE (lead Attester)"]
LA["Attesting Environment
(Composite lead)"]
TE_CPU["Target Environment
(workload)"]
end
subgraph Link["Device-to-TEE link"]
SPDM["SPDM session
(DMTF DSP0274)"]
TDISP["TDISP context
(PCIe Base Spec, PCI-SIG)"]
end
subgraph ACC["AI accelerator (sub-Attester)"]
AE_ACC["Attesting Environment
(device root of trust)"]
TE_ACC["Target Environment
(weights, kv-cache, kernels)"]
end
end
V["Verifier
(external)"]
TE_CPU -. "measurements" .-> LA
TE_ACC -. "measurements" .-> AE_ACC
AE_ACC -- "Device Evidence
(EAT with detached CoRIM)" --> SPDM
SPDM --> TDISP
TDISP --> LA
LA -- "Composite Evidence" --> V
classDef link fill:#eef,stroke:#446,stroke-dasharray:3 3;
class Link,SPDM,TDISP link;
Figure 2. Composite Device from [RFC9334] §3.3. The link between the two Attesters is where SPDM, TDISP, EAT-DA, and CoRIM meet.
Two hardware-layer protocols govern the fabric. The Security Protocol and Data Model (SPDM, DMTF DSP0274 v1.3.2 [SPDM]) is a link-layer authentication and measurement protocol between a host and a device (no Internet Protocol involved!). SPDM can also run over an IP transport when the deployment requires it. The TEE Device Interface Security Protocol (TDISP) is folded into the [PCIe] Base Specification from Revision 6.x onward, and defines how a Trusted Virtual Machine and a device function establish a mutually attested trusted connection over PCIe. Neither of these, on its own, produces RATS Evidence. Only the composite is able to do so!
The IETF glue that turns those hardware-layer outputs into RATS Evidence is draft-poirier-rats-eat-da [EAT-DA], a profile of the Entity Attestation Token ([RFC9711]), the signed claim-set format the RATS working group standardised for conveying device-state Evidence. Section 3.1 of the draft carries SPDM claims; §3.1.4 carries a TDISP Device Interface Report. The Reference Values that a Verifier appraises this Evidence against are expressed as Concise Reference Integrity Manifests, draft-ietf-rats-corim [CoRIM]: CBOR-encoded records that a vendor uses to publish the expected measurements of a specific device or firmware. Put together: SPDM produces the device-side measurements, TDISP scopes the fabric that carries them, EAT-DA formats the Evidence, CoRIM tells the Verifier what to compare against (explains the Attester layout to the Verifier), and finally the composed Evidence is signed together with the lead Attester's key. Admittedly, this is more complex than a single "Attestation Document", but in all seriousness: this is how confidential computing is done, and this is a reality that has to be taken into account.
Some technical details: on the wire, the exchange looks like this. In its simplest form, SPDM is a challenge-response protocol: the device presents a certificate chain from one of eight slots, the requester issues a challenge with some challenge data (typically the nonce you are familiar with, but it can be extra data that is more than a "number used once"), and the device signs a measurement log of up to 239 entries covering categories such as ROM, mutable firmware, hardware and firmware configuration, and device mode. The signature covers a combined SPDM prefix, the hash algorithm, and the challenge data (again, this will typically be a nonce today), and binds the transcript to that exchange. TDISP then layers on top. Essentially, a device interface has a state machine with three positions (CONFIG_UNLOCKED, CONFIG_LOCK, RUN), and the accelerator's firmware freezes its configuration once that interface reaches CONFIG_LOCK or RUN. In either of those states, a Trusted Virtual Machine can request the TDISP Device Interface Report, which carries the interface state bitfields, MSI-X / LNR / TPH register values, and the MMIO (memory-mapped I/O) ranges the device has dedicated to the TVM out of its PCIe BARs (Base Address Registers). Confidentiality on the wire/fabric is provided by IDE (Integrity and Data Encryption), an encryption feature folded into the same [PCIe] Base Specification. The IDE keys derive from the SPDM session, so encrypted traffic on the bus is bound to the same handshake the Verifier will later appraise.
In conclusion, composite attestation for confidential AI inference already has a named pattern in [RFC9334] and a specific set of standards to populate it. In the case of [EAT-DA], those standards are actively converging on what is actually happening in your confidential TEE that contains your confidential model and processes your confidential data. That composite is also where security evaluations of confidential-inference stacks concentrate their efforts, because a broken composite invalidates every downstream attestation and delivers no trust value to the stack.
Shaping attestation Evidence for confidential AI
Remote attestation exists to convey information about a workload to a Verifier. Confidential inference exists to keep the workload's contents (model weights, model architecture, user inputs, user outputs) invisible to every party outside the TEE. These two purposes collide the moment attestation Evidence contains anything derived from those contents.
Three concrete cases demonstrate that collision. A measurement over model architecture is an approximate fingerprint of that model. Claims whose presence, size, or ordering vary with user input carry such input inferences in the form of measurements to any observer of the Evidence stream, which de facto could reside outside your confidential-computing context. Endorsements and Reference Values that describe a defensive posture are, unfortunately, also descriptions of that posture for anyone who can obtain them, potentially. Section 11 of [RFC9334] states this: "the conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device as well as potentially any users of the device"; and "if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attacker with insight into defensive mitigations."
Two architectural design choices can have an impact on this collision. The first is a Layered Attester ([RFC9334] §3.2) in which the workload is not its own Attesting Environment. A layer beneath the workload, but inside the confidentiality boundary, takes on that role. The second is an evidence-shaping policy at that layer: an auditable rule set that decides which measurements enter Evidence, which are held internally, and which appear as Reference-Value comparisons instead of raw claims.
Both of these design choices can land in the same place: a paravisor that is wrapped around your workload in a confidential computing domain. Microsoft's confidential-VM stack ships one under exactly that name: the OpenHCL paravisor, described in [OpenHCL] as "virtual firmware, running at a higher privilege level than the primary guest OS" and providing "virtualization services from within the guest partition itself". It runs the OpenVMM Rust codebase [OpenVMM] under an MIT licence and is developed in the open. The [TCG-DICE] Attestation Architecture supplies the layered-identity primitives such a wrapper builds on: it defines how a device derives a chain of identities from an immutable root of trust, so each stage attests to the next as the boot sequence unfolds.
Following all these design choices, an Agentic Paravisor is a natural progression of that pattern applied to an AI workload: an open-source layer with a reproducible build that measures the model-loader, key-management, and inference-runtime code, and that produces Evidence shaped for confidentiality. Figure 3 shows the paravisor positioned at the disclosure boundary.
Original diagram source
flowchart TB
subgraph Platform["CC platform (bottom layer)"]
HW["Hardware root of trust
(SEV-SNP / TDX / Nitro / etc.)"]
HW_AE["Platform Attesting Environment"]
HW --> HW_AE
end
subgraph Paravisor["Agentic Paravisor (open-source, reproducible)"]
PV_AE["Paravisor Attesting Environment
(measures the workload)"]
PV_POL["Evidence-shaping policy
(what is disclosed vs. minimised)"]
end
subgraph Workload["Confidential AI workload (Target Environment)"]
W_MODEL["Model weights + architecture"]
W_DATA["User data
(inputs, outputs, KV-cache)"]
end
HW_AE -- "Platform Evidence" --> PV_AE
Workload -. "measurements" .-> PV_AE
PV_AE -- "Composite / Layered Evidence
(shaped by policy)" --> V["Verifier
(external)"]
LEAK["Leakage-via-evidence
boundary
(RFC 9334 §11)"]
PV_AE -.-> LEAK
LEAK -.-> V
classDef paravisor fill:#efe,stroke:#464,stroke-width:1.5px;
classDef workload fill:#eef,stroke:#446,stroke-width:1px;
classDef leak fill:#fdd,stroke:#a44,stroke-dasharray:4 3;
class PV_AE,PV_POL paravisor;
class W_MODEL,W_DATA workload;
class LEAK leak;
Figure 3. Layered Attester ([RFC9334] §3.2) with the leakage-via-evidence boundary. The evidence-shaping policy is the paravisor's answer to §11.
Today, no two clouds ship the same layer here. Only Microsoft ships an in-guest, open-source paravisor tier at higher privilege than the guest OS: OpenHCL, running on OpenVMM. Google Cloud's nearest analogue in Confidential Space [ConfSpace] is the cs-launcher (Apache-2.0), which runs at user-space privilege inside the guest OS, so its privilege level is the guest OS's own. AWS has no paravisor at all: Nitro Enclaves [NitroEnclaves] are separately-isolated child VMs carved out of the parent instance by the (proprietary) Nitro Hypervisor, without an in-guest wrapper. An Agentic Paravisor design that wants to work across all three cloud types must decide whether to mandate the paravisor tier (Azure only), treat it as pluggable per cloud, or abstract it and map each cloud to such a pre-defined abstraction.
The shaping policy draws on four families of mitigation. Direct Anonymous Attestation ([RATS-DAA]), named by [RFC9334] §11, removes linkable identifiers from Evidence without removing appraisability. Selective disclosure primitives let the paravisor omit high-sensitivity claims: SD-JWT [RFC9901] lets an issuer sign a full claim-set once and then release only the subset a given Verifier needs, and its COSE-based (CBOR Object Signing and Encryption) counterpart SD-CWT ([SD-CWT], draft-ietf-spice-sd-cwt-08) carries the same construction for CBOR-encoded Evidence. Evidence shaping at the paravisor moves the disclosure decision from the workload into a transparent, auditable policy layer, in line with the [RATS-Privacy] framework, which catalogs the disclosure risks specific to RATS and pairs each with a mitigation pattern. SCITT-anchored appraisal-policy transparency [SCITT-Arch] records the Verifier's policy history in a public transparency service, so Endorsements and Reference Values gain the same provenance trail their Evidence does.
Getting the shaping policy right is a decision with significant impact on real security outcomes. A partial fix that closes the exploit path but leaves the confidentiality property broken is a critical failure mode. Coding agents are increasingly being asked to make this decision on this stack.
Attestation Evidence for a confidential AI workload has to be well-shaped, authentic, and appropriate for the Verifier's policy. All three properties are critical to enable real-world trust decisions. A transparent layer distinct from the workload, whose own trustworthiness is separately attested, delivers that shaping, and it also has to bind that Evidence to the channel in order to prevent replay attacks.
Toward a reference architecture
The CPU-to-accelerator link and the leakage-via-evidence boundary each have a pattern in [RFC9334]. The link aligns with the Composite Device pattern (§3.3), together with the specifications it depends on: SPDM, TDISP, EAT-DA, and CoRIM. The workload layout really starts to match the Layered Attester pattern (§3.2), with an Agentic Paravisor as its Attesting Environment and an evidence-shaping policy that addresses §11.
As a result (and probably not a big surprise): a companion reference-architecture whitepaper is in the making! It develops the Agentic Paravisor requirements against the three cloud hosts (OpenHCL, Confidential Space, Nitro Enclaves). The interesting nuance here is that it also wires in SCITT as the layer that provides supply-chain and policy transparency. The whitepaper also introduces a (quite concise) threat model for evidence disclosure adhering to the [RFC9124] idiom, which pairs each threat with the mitigations that address it in a structured register.
XOR uses the exact same reference architecture, as outlined in this post, as training material for coding agents. This is the basis for future steps, such as taking into account the three duties that always appear again and again in the exact same context: understanding the pattern, implementing it, and defending it! First results are published at [XOR-Unpatched]. Nine frontier coding systems met flaws XOR researchers had found in a confidential inference stack, before any public fix had been written or disclosed. Across the nine systems evaluated, agents looked better at attacking than at defending as long as partial progress counted, which is all a real world attacker, whether human or AI, needs. That imbalance is what training coding agents on this confidential inference reference architecture is meant to move for your team's coding agents.
Henk Birkholz, co-author of [RFC9334]; TCG Attestation WG co-chair; ITU-T FG-TIDA Attestation WG proponent; contact: henk@xor.tech