Zero Data Retention Is a Promise. Attestation Is Proof: Verifying Confidential AI in 2026

1. August 2026: two retention policies, zero verifiability

On 19 and 20 August 2026, OpenAI previewed Private Safety Processing, a zero-data-retention mode with safety scanning that, they say, no human ever sees. A whitepaper is promised for September. The same week, The Register framed it as a direct move on Anthropic, which has required 30-day retention on its frontier models since 9 June.

We run a confidential GPU cloud, so we read both announcements the way a compliance officer would. The question is not which policy is nicer. The question is what a customer can actually check. Today the answer, for both vendors, is: the contract, a third-party audit report, and nothing else. No customer can produce evidence that a given request was processed the way the policy says.

2. Three assurance levels

It helps to name the levels, because vendors blur them on purpose.

• Level 1, policy. "We keep nothing." A sentence in a DPA. Real, enforceable, and unverifiable from your seat.
• Level 2, vendor-declared architecture. Apple Private Cloud Compute on Google Cloud and Google Confidential Space with Intel Trust Authority are serious engineering. They are also architectures where the verifier is chosen by the vendor. You trust the vendor to have wired it correctly, and you trust the verifier.
• Level 3, proof you generate. You are root inside a Trust Domain, you write your own challenge into the attestation device, you read a hardware-signed quote, and you verify it against the silicon vendor on your own machine. The provider is not in the chain. This is what our Confidential VM tier does, and it is the only level where "do not trust us" is an instruction rather than a slogan.

3. Hands-on: a quote you generated, verified against Intel

The full walkthrough lives in our tenant TDX attestation guide. The short version is three filesystem operations, because Linux 6.7+ ships a vendor-neutral TSM report interface in configfs.

# On a VoltageGPU Confidential VM (Ubuntu 24.04, kernel 6.8), as the tenant
ls -l /dev/tdx_guest
lsmod | grep -E "tdx_guest|tsm"

# 1. A report entry, through the kernel's configfs TSM interface
sudo mkdir /sys/kernel/config/tsm/report/r1

# 2. Your own 64-byte challenge (here: sha512 of a fresh nonce)
NONCE=$(openssl rand -hex 16)
printf '%s' "audit-$(date -I)-$NONCE" | sha512sum | cut -d' ' -f1 | xxd -r -p > report_data.bin
sudo dd if=report_data.bin of=/sys/kernel/config/tsm/report/r1/inblob bs=64 count=1

# 3. The signed quote (5247 bytes, TDX quote v4, header 04 00 02 00 81 00)
sudo cat /sys/kernel/config/tsm/report/r1/outblob > quote.bin
xxd -l 6 quote.bin

The header bytes matter: 04 00 is quote format v4, 02 00 is ECDSA-P256, 81 00 is the TEE type for Intel TDX. Then leave the VM and verify somewhere we do not control.

# On YOUR machine. Intel DCAP, Intel collateral, Intel root CA. We are not in the loop.
scp ubuntu@<your-vm-ip>:quote.bin .

# QuoteVerification sample from intel/SGXDataCenterAttestationPrimitives:
# checks the ECDSA signature, walks the PCK chain to the Intel SGX Root CA,
# and returns a TCB status you must read (UpToDate, SWHardeningNeeded, OutOfDate...).

# Pin what you expect, or the quote proves nothing you care about:
#   MRTD   = the measured TD firmware/boot
#   RTMRs  = runtime measurements (kernel, initrd, your image)
#   report_data = the 64 bytes YOU wrote in step 2

Pinning is where most teams stop short. A valid signature on a quote with unknown measurements proves that some Trust Domain exists. Pinning MRTD and the RTMRs to values you computed from the image you deployed proves it is your Trust Domain, running your code, answering your nonce.

4. Attestation is not a one-off. Two reasons from this summer

TCB Recovery 22. On 11 August 2026 Intel disclosed a TCB recovery that touches TDX: new module versions (v1.5.34 on Sapphire and Emerald Rapids, v2.0.18 on Granite Rapids), new PCK certificates, "early" DCAP collateral from 11 August and "standard" collateral only in August 2027. The Intel guidance is explicit: verifiers that keep old collateral will see quotes flagged OutOfDate. A platform that verified clean on 10 August can fail on 11 August without a single byte changing on the machine. If your verification pipeline is a screenshot from onboarding day, it is already stale.

CVE-2026-33697. In July, researchers showed a relay attack against attested TLS performed inside the handshake, CVSS 7.5, affecting several "private processing" designs, with no general fix. Read The Register or the IETF 126 slides. The design lesson is the one we already follow: generate the quote inside the VM, bind your own nonce into report_data, and verify out of band. A relay cannot invent the 64 bytes you created a second ago.

5. Eight questions for any "confidential" provider, and our own answers

1. Who generates the attestation quote, you or the provider?
2. Can you choose the report_data (a nonce you just created), or is it fixed?
3. Can you verify offline, against the silicon vendor root CA, with no provider verifier or API in the path?
4. Which measurements are you expected to pin (MRTD, RTMRs, kernel, image), and does the provider publish reference values?
5. What happens after a TCB recovery: who refreshes the collateral, and will your verifier flag OutOfDate?
6. Is the attestation bound out of band, or inside a TLS handshake that a relay could sit in?
7. What does the quote NOT cover (GPU memory, PCIe link, the model vendor side)?
8. Where is the "zero data retention" promise written, and what evidence exists beyond the contract?

Our answers, plainly. The tenant generates the quote. You choose report_data. Verification is offline against Intel, with no VoltageGPU verifier. We publish the walkthrough and the evidence pack rather than reference values for every image, so pin your own. After a TCB recovery, re-verification is your job, we do not run a verification service. Binding is out of band. And the limits: the quote proves the identity and state of the VM on the CPU side (memory encryption, measured boot, MRTD and RTMRs). It does not cover GPU HBM memory or the PCIe link, because GPU confidential-computing mode is off on our infrastructure. It proves what code booted, not what a model vendor does with outputs. The VM tier has no persistent volumes and no self-serve deploy UI yet. Zero data retention remains a promise we make in writing; attestation is the part you no longer have to take on faith.

Related reading

• Generate your own Intel TDX quote as a tenant: hands-on guide
• Confidential VM tier: pricing, limits, provisioning
• Intel TDX vs AMD SEV-SNP for confidential AI
• GDPR and AI: why a DPA is not enough

FAQ