Confidential computing attestation is the cryptographic handshake that lets a key service decide whether the code requesting your model weights or customer data is the exact workload you built. AWS Nitro Enclaves issue signed attestation documents from the Nitro Hypervisor that carry the enclave’s platform configuration registers, while Google Cloud Confidential VMs return equivalent evidence from a virtual TPM or a hardware trust module. For inference workloads that handle regulated prompts or proprietary weights, attestation — not network policy — is the control that makes memory encryption actionable.
Why attestation gates key release
The design pattern is key-release encryption: plaintext never ships with the deployment. Model weights, API credentials and customer secrets are encrypted before upload, and the ciphertext only becomes usable inside a trusted execution environment whose measurements match your policy. Decryption runs through an attestation check, so a tampered image, an unexpected host or a debug build never obtains the key.
This matters for inference in particular. An endpoint that already handles connection-level concerns — see the trade-offs in streaming tokens over SSE versus WebSocket — still holds plaintext prompts and responses in memory during generation. Attestation extends protection to that window instead of covering only data at rest and in transit. Teams hardening agent tool access, like the Linux privilege-escalation research traced in the OpenAI agent pipeline exploit analysis, gain a complementary guarantee: the code allowed to hold secrets is pinned to a measured digest.
AWS Nitro Enclaves PCR workflow
Each enclave carries its measurements in platform configuration registers. PCR0 hashes the enclave image file, PCR1 the Linux kernel and bootstrap, PCR2 the user applications, PCR3 the IAM role of the parent instance, PCR4 the parent instance ID, and PCR8 the certificate used to sign the image. The values are SHA384 digests, so an access policy compares exact strings rather than trusting metadata supplied by the workload.
The workflow in practice: build the enclave image, record the PCR values printed by the build command, then write a condition key into your KMS key policy that pins Decrypt and GenerateDataKey to those digests. At runtime the enclave requests its document through the Nitro Enclaves SDK and attaches it to the KMS call, and KMS verifies the signature before releasing anything. Debug flags destroy this guarantee: enclaves booted in debug mode produce attestation documents whose PCR values are entirely zeroes, and AWS documents that such documents cannot be used for cryptographic attestation, so a correct policy fails closed on all-zero registers.
Treat the signing certificate as a supply-chain control. Because PCR8 measures the certificate attached to the image, a policy that pins PCR8 refuses keys to images rebuilt by anyone outside your release process, even when the rest of the build matches.
Google Confidential VM report paths
Google differs in what performs the signing. Attestation reports on Confidential VM instances are signed either by a software-based vTPM or by a dedicated hardware-based Trusted Security Module — the AMD Secure Processor for SEV-SNP instances or the Intel TDX module. The vTPM report covers bootloader activity and kernel integrity; the hardware-backed report covers firmware and the hardware environment, the stronger claim when your threat model includes the host.
To consume the evidence yourself, Google publishes go-tpm-tools, and version 0.4.4 or later is required for AMD SEV-SNP and Intel TDX support. If you prefer not to run your own verifier, Google Cloud Attestation checks a retrieved quote and returns a token carrying VM claims that you compare against your policy. GPU deployments add a second layer: NVIDIA GPU device attestation verifies the Video BIOS running on the GPU and identifies NVIDIA software versions, while driver attestation depends on Secure Boot, because only distribution-signed NVIDIA drivers establish the SPDM session that roots device evidence. Google also documents an operational caveat: a mismatched measurement record can require a full stop and restart of the VM, since an in-guest reboot does not clear it.
Comparing the two attestation models
The platforms make different trust bets. AWS roots trust in the Nitro Hypervisor and gives KMS native enforcement, which keeps the verifier out of your code but ties the design to AWS services. Google offers both a software vTPM path and hardware-rooted reports, plus verification as a service, which takes more integration work but spans multiple confidential technologies. Choose by threat model: if the host itself is in scope, prefer hardware-rooted reports; if you need turnkey enforcement on decryption, the KMS condition-key path is shorter.
| Dimension | AWS Nitro Enclaves | Google Confidential VM |
|---|---|---|
| Signer | Nitro Hypervisor, AWS PKI | vTPM, AMD Secure Processor or Intel TDX module |
| Measured | Image, kernel, apps, IAM role, instance ID, signing certificate | Bootloader, kernel, firmware, hardware, GPU VBIOS |
| Enforcement | KMS condition keys on PCR values | Google Cloud Attestation tokens compared to policy |
| Failure guard | Reject all-zero PCRs from debug builds | Stop and restart the VM on measurement mismatch |
A key-release policy checklist
- Encrypt weights and secrets before deployment and store ciphertext outside the trusted environment.
- Pin policy to full measurement sets, never to a single register.
- Reject debug evidence and fail closed on zeroed registers.
- Bind a fresh nonce to every attestation request so reports cannot be replayed.
- Verify the certificate chain back to the provider root before comparing measurements.
- Log the accepted digest rather than the raw document, keeping customer data out of audit trails.