Remote Attestation for Confidential AI Inference: Release Model Keys Only to Approved Execution Environments

Deploying inference to a “confidential VM” does not by itself prove that the current node has the correct TEE enabled, that the GPU is in the required mode, that the boot image is unchanged, or that the attestation result was not captured yesterday. The real control point is this: only fresh attestation that satisfies the release policy may obtain the model DEK, tenant-input DEK, or short-lived data access token. Secrets Management protects the keys; this article defines the execution-environment facts that must be verified before key release.

Separate Trust by RATS Role

RFC 9334 divides remote attestation into the Attester, Verifier, and Relying Party roles. The inference instance acts as the Attester and produces Evidence; an independent Verifier evaluates it against reference values and endorsements to generate an Attestation Result; the key release service acts as the Relying Party and consumes only authenticated results. Do not let an instance submit trusted=true itself, and do not let the KMS parse each vendor's raw binary reports directly, or every hardware upgrade will spread vendor-specific details into key policies.

Freeze ai.attestation.policy.v1 so that it binds at least the environment, workload image digest, boot-parameter digest, allowed CPU TCB, GPU attestation state, debug-disabled flag, Verifier version, and latest acceptable update time. EAT (RFC 9711) can serve as a standard claims container, but the existence of a claim name does not make it trustworthy. The Verifier must state which claims come from hardware and which come from the orchestration layer, and it must reject any result missing a mandatory measurement.

{
  "policy": "ai.attestation.policy.v1",
  "nonce": "base64url(random-256-bit)",
  "ephemeralPublicKeyHash": "sha256:...",
  "releaseId": "release_42",
  "tenant": "t_42",
  "workloadDigest": "sha256:...",
  "cpuTcb": "accepted-set-2026-07",
  "gpu": {"required": true, "debug": false},
  "purpose": "tenant-input-dek",
  "expiresInSeconds": 300
}

Freshness and Composite Attestation Must Both Hold

The instance generates a non-exportable ephemeral private key inside the attested execution environment and exposes only its public key to the attestation path. Hardware-bound Evidence must cover nonce + ephemeralPublicKeyHash + releaseId + tenant + purpose. Merely placing these fields beside a normal request cannot prevent an attacker from forwarding valid Evidence to the attacker's own public key in a cuckoo relay. The specific TEE must carry this canonical binding in its protected report or user data; if hardware binding is unavailable, no key may be released.

The key service stores a single-use challenge. After the Verifier validates the certificate chain and Evidence, the Relying Party must still confirm that the Attestation Result's audience is the current key broker, that the result has not expired, that the TCB is not currently revoked, that the policy and reference digests match the requested release, and that the binding above recomputes correctly. The RP first wraps the DEK for the attested public key, then uses CAS in the release store to atomically change the nonce from PENDING to CONSUMED, storing the binding and wrapped result in the same transaction. Only the winner may return the result. If the response is lost, the same result may be read again; a retry with a different binding is rejected immediately.

GPU inference often depends simultaneously on a CPU TEE, device firmware, drivers, and the workload. Validating only the VM report misses a replaced GPU path, while validating only the GPU cannot prove who requested the device. The platform must combine Evidence from every layer, validate certificate chains, TCB states, device binding, and image measurements, and then produce one overall result from a single policy. The layering of the Attestation Agent and Key Broker Service in Confidential Containers can help explain this boundary, but production systems must still freeze the claims and versions they accept.

Remote attestation also does not prove that a model has no backdoor or that its answers are correct. Inference Reproducibility Across Hardware must still validate output equivalence, and AI Supply Chain Security must still govern artifact provenance. Attestation answers only whether the current execution environment belongs to an allowed set.

Put Fault Injection into the Release Gate

Pre-release exercises must include at least replaying old Evidence, consuming a nonce concurrently, replacing the ephemeral public key, mismatching the release, tenant, or purpose, relaying A's Evidence to B, using an incorrect result audience, presenting an expired result, using an unapproved image, enabling debug, using an old TCB, omitting GPU attestation, and timing out the Verifier. The expected outcome is that no key is released or that the old data lease becomes invalid. Availability concerns must never turn this into “allow access when verification fails.”

Acceptance records include summaries of the Evidence and binding, the nonce, result audience, reference-value and policy digests, TCB state, certificate chain, ephemeral public-key fingerprint, key version, data lease, and expiration time. Raw data and keys must not enter ordinary logs. Observability can integrate with AI Agent Observability, but attestation logs belong in a separate security domain.

The hard requirements are: zero key releases across the noncompliance matrix; every decryption is associated with unexpired attestation and a valid data lease; reference-value updates reach every Verifier; and when the KMS or Verifier is unavailable, zero new jobs receive plaintext. Only registered enclaves with unexpired leases may finish in-flight requests during the short window permitted by policy; they may not obtain new tenant keys.

Preserve Reversibility When Updating Reference Values

For an upgrade, first add the new image and TCB to a candidate policy and replay Evidence through a shadow Verifier that has no access to plaintext. Once the results agree, enable a small number of instances before expanding. To roll back, first stop new key releases and task admission for the candidate generation, terminate candidate instances, revoke their data leases, broker tokens, and ephemeral certificates, and verify that they have reached zero across the instance inventory, active leases, and decryption audit. Then shift traffic back to the previous digest that remains secure.

Revoking an ephemeral certificate prevents only future authentication; it cannot recover a DEK that has already been released. If an instance may have exported plaintext, private-key protection has failed, or memory erasure on termination cannot be proven, treat the relevant DEK or KEK as compromised, rotate it, and rewrap the data. Rotation may be skipped only when it is proven that the key never left the non-exportable boundary and the instance has been destroyed. During the observation period, the old policy may serve only the old release; it must not accept every version indefinitely.

If a vendor marks an old TCB as revoked, rollback must not accept it again. Secure degradation means queuing work, moving it to another attested region, or rejecting sensitive tasks. Cloud Disaster Recovery must establish in advance that the backup region has an independent Verifier, reference values, and KMS authorization, rather than copying a permissive policy during an incident.

Confidential computing becomes an auditable production security control rather than a hardware selling point only when fresh Evidence, explicit reference values, and purpose-restricted key release form a closed loop.

Further Reading

• Secrets Management
• Inference Reproducibility Across Hardware
• AI Supply Chain Security
• Cloud Disaster Recovery