TEE Attestation Evidence as a Procurement Requirement for Operator-Access Lockout

TEE-backed AI assistants use trusted execution environments to keep inference-time data out of the hands of the provider’s operators. For buyers requiring operator-access lockout, TEE attestation evidence turns a contractual promise into a cryptographically verifiable claim about the system handling their data. That proof is bounded, however, by what the hardware measures, which software the buyer approves, and how changes are governed.

Why contractual promises about operator access are no longer sufficient

A procurement officer asks an AI vendor for proof that its operators cannot access data during inference. The vendor produces a contract clause prohibiting that access. The answer establishes an obligation. Without a TEE, the provider’s operators remain technically capable of accessing plaintext during processing, regardless of what the agreement permits. How can a buyer establish operator exclusion when the evidence describes only operator conduct?

DORA, applied from 17 January 2025, requires financial entities to maintain a Register of Information covering ICT contractual arrangements and conduct risk-proportionate due diligence. Its most thorough written risk assessments cover providers that support critical or important functions. A missing account of vendor governance leaves the buyer with an evidentiary gap it cannot close alone.

California Executive Order N-5-26, signed 30 March 2026, tells agencies to set vendor certification requirements and procurement standards that require vendors to attest to and explain their policies and safeguards. The requirement reinforces the distinction between making an assurance and supplying evidence for it. Neither regulatory framework makes a contract clause proof that privileged access is technically impossible.

How a TEE enforces operator lockout at the hardware level

A TEE creates an isolated execution boundary around code and data. The protection applies while inference is running. The host operating system, hypervisor, and privileged accounts cannot read or modify the enclave’s protected CPU state and encrypted memory. For a buyer asking how to keep prompts private from the company hosting an assistant, this is the architectural distinction from conventional hosting with administrative access controls.

OpenPcc, an academic implementation from 2026, illustrates how the surrounding software must support that boundary. Its image strips SSH, shell access, privileged accounts, and package managers, exposing only a gRPC inference and attestation port. The CPU TEE also denies the host access to CVM CPU state and encrypted guest memory. Reaching through the host therefore fails as well. Removing administrative interfaces removes capabilities rather than merely withdrawing permission to use them.

Apple’s Private Cloud Compute makes the same principle explicit. PCC must not contain privileged interfaces that let site reliability staff bypass its privacy guarantees, even to resolve an outage. It must also keep the privileged access envelope from growing at runtime, including when software is added. An outage does not create an exception.

Sealed storage keeps this protection in place across restarts by binding secrets to approved measured states. If the software stack changes, it cannot access material that was already sealed. Confidential inference on current GPU hardware nevertheless has a real but modest latency overhead, dominated by memory-encryption cost on HBM access, which buyers should treat as an engineering trade-off.

What attestation evidence actually is and how the verification chain works

Hardware isolation is a local property of a machine. A remote buyer still needs evidence of it. Remote attestation supplies that evidence through a signed measurement of the TEE’s state, including loaded code, measured configuration, and platform firmware. The signature is rooted in hardware keys controlled by the chip manufacturer, rather than in a statement written by the service provider.

A verifier then checks the signed evidence against a known-good policy. That verifier can be an attestation service or the buyer’s own tooling. Matching an approved software release establishes that the measured environment satisfies the policy. But who decided that the release was acceptable? The cryptographic check establishes correspondence with an approved state, while the approval process establishes which states deserve trust.

PCC connects this verification to the point of key handoff. Data does not reach a node that cannot prove its software state. Apple also maintains a cryptographically verifiable, append-only ledger of all Google Cloud hardware in the PCC fleet, supporting inspection of authorised software versions and detection of unauthorised versions. The log makes authorisation visible beyond the operator’s assertion.

The word “attestation” needs care in procurement documents. BSI runs no C5 certification procedure and states that an auditor’s attestation report is currently the only evidence reaching the minimum required level for public authorities, an audit standard. For operator-lockout verification, the relevant artefact is a hardware-signed measurement checked against an approval policy, supported by a transparency log, rather than a vendor-authored assurance or an auditor’s report alone.

What a complete attestation evidence package must contain for procurement purposes

The hardware platform measurement must show that confidential-compute operation is genuine. Signed evidence from the CPU or GPU must be rooted in the chip manufacturer’s attestation keys and cover firmware and platform configuration. The software image measurement must identify the exact stack loaded in the enclave or CVM through a cryptographic hash. Reproducibility gives that hash an independently testable meaning. An independent party must be able to establish that it matches the published build.

The policy binding record must connect that measured image to operator exclusion. It must document the absence of privileged runtime interfaces, dynamic code loading, and mechanisms that enlarge the access envelope during execution. A hash alone cannot explain those properties. The transparency log entry must place the approved version in a publicly verifiable, append-only record, with unlisted versions failing attestation. The log must be independently readable and hosted beyond the vendor’s infrastructure.

Deployments that need high assurance also need the multi-root evidence that applies to them. Apple’s 2026 Google Cloud expansion requires software attestation for any component that could exfiltrate user data to be rooted in at least two separate roots of trust from independent vendors. This prevents a single vendor compromise from being sufficient to break the chain. Freshness and revocation complete the temporal boundary. Evidence must be time-bounded, with a specified maximum age and notification when a previously attested version is withdrawn.

Runtime-writable configuration requires separate assurance where measurements exclude it. Research on PCC in 2026 found that writable data-volume files driving daemon behaviour were outside the verification process, leaving a poisoned node indistinguishable from a clean one in the attestation-relevant fields examined. A procurement package must therefore state what falls inside and outside the measurement perimeter. For excluded runtime-writable configuration, it must identify the separate assurance mechanism.

Where the attestation evidence chain is genuinely fragile

Removing the cloud operator from the plaintext-access path concentrates reliance on the chip manufacturer, which designs the silicon, writes firmware, anchors attestation keys, and ships microcode updates. Due diligence must therefore name the hardware root of trust on which the system relies. “Hardware-backed” is too broad to name the dependency a buyer is accepting.

Attestation proves that a particular image is running, with bugs, backdoors, or logic errors still possible in that image. A malicious but consistently attested image can pass an identity check while undermining operator exclusion. Reproducible builds and transparency logs provide a basis for scrutiny of the approved software. They do not, by themselves, prove its correctness.

Does the approval policy cover the state that actually determines runtime behaviour, or only part of it? Governance determines how the allow-list is maintained, how updates enter it, and how compromised releases leave it. Procurement requirements should surround the cryptographic proof with hardware-root specificity, reproducibility, runtime-configuration assurance, revocation procedures, and audit rights over that governance process.

How to write procurement language that references TEE attestation evidence correctly

A requirement merely to “use a TEE” leaves the verification obligation undefined. Using PCC as the reference model, the contract should require a current attestation report at or before data handoff, containing hardware platform measurements, software image hashes, and a policy binding record. It should name the hardware roots on which verification depends.

Independent verification must be an express contractual requirement. The buyer or a named third-party verifier must be able to check the report without relying on the vendor’s own infrastructure. Any transparency log must be independently readable. The contract should also define the measurement perimeter and require a specified assurance mechanism for runtime-writable configuration outside it, so that an excluded file cannot disappear into a general claim of confidential computing.

Following the PCC model, the buyer’s systems should automatically enforce verification by releasing encrypted inputs only to nodes whose attested measurements match an approved version in a named transparency log. The agreement should set a maximum attestation age, require re-attestation after software updates, and define the notification window for revoked or compromised versions. No single freshness interval can be inferred from the technology label.

Audit rights should cover how the decisions behind the evidence are made. The vendor should make records available on request showing how authorised versions are selected, updates reviewed, and revocations propagated. Buyers should ask vendors to explain the lockout architecture before they assess its attestation output. Otherwise, procurement may evaluate a convincing proof of an architecture that still permits privileged access.

These requirements also need careful regulatory positioning. Under DORA, financial-sector third-party risk assessment takes account of the provider’s security arrangements, data governance, and change management, so detailed TEE evidence can help with those parts while the wider assessment is still needed. The proposed GSAR 552.239-7001 language requires attestations from individuals representing the LLM’s Developer(s), System Operator(s), System Integrator(s), and Service Provider(s). Procurement teams should layer hardware evidence on top of that proposed human-attestation baseline. The California order likewise concerns vendor explanations and safeguards.

What buyers should verify before signing and how the evidence chain holds across contract tiers

A deployer can discharge its obligations only if the provider’s commitments survive handoffs through the supply chain. A hardware signature still depends on the root vendor’s governance of keys and firmware updates. Before signing, buyers should establish which parties control those dependencies and whether their obligations flow down to the buyer’s benefit.

PCC on Google Cloud in 2026 provides a concrete multi-tier example. Apple extended PCC privacy commitments to third-party data centres using NVIDIA Confidential Computing with NVIDIA GPUs, Intel TDX, and Google’s Titan chip. Apple maintains the fleet ledger independently of Google to mitigate supply-chain risks. The multi-root requirement protects components that could exfiltrate user data if a single vendor is compromised. Stateless computation, no privileged runtime access, and verifiable transparency remain identical across Apple’s own silicon and Google’s infrastructure.

For a buyer, the signing review should trace that chain explicitly. The vendor should list every hardware and firmware component used and name each root-of-trust vendor. If a separate infrastructure provider is involved, equivalent attestation obligations must bind it. The buyer should also establish that the transparency log is not hosted exclusively on vendor-controlled infrastructure and that documented update and revocation processes include buyer notification rights.

Procurement teams should require TEE attestation evidence along with rights to audit governance and obligations that flow down through the supply chain. The agreement should define incident response for attestation failures or revocations. When an approved state changes or a root of trust comes into question, the buyer needs enforceable access to the responsible parties and their decisions.