Confidential AI's two threat models
What hardware-rooted trust buys an enterprise AI customer in 2026
On May 1, the Pentagon agreed to deploy commercial AI from eight technology firms on its IL6 and IL7 classified networks. The architectural decision sitting underneath that procurement is the same one Yma Health signed in October when it began running clinical AI on patient data through NVIDIA Confidential Computing, and the same one Fortanix's March 18 launch put into ElevenLabs' government, healthcare, and finance deployments. The contract clause is that customer data is never decrypted outside a hardware-attested trusted execution environment.
That means the cloud operator, the model vendor, and the infrastructure provider cannot see plaintext data while inference runs. But what do the underlying primitives say?
The architectural endpoint
Fortanix's Confidential AI launch states that third-party model weights and customer prompts both stay encrypted in GPU memory, decrypted only inside a hardware-attested NVIDIA H100 or H200 confidential computing environment. The architecture's claim is that mutual trust is established by cryptographic attestation rather than by contract.
Fortanix is not alone. Microsoft's Azure AI Confidential Inferencing encrypts prompts under hybrid public-key encryption decryptable only inside an attested TEE; client identity is hidden from Azure AI itself by an OHTTP proxy outside the Azure perimeter. Red Hat's office of the CTO is building an open-source cloud-native version through the upstream Tinfoil project on Confidential VMs and Kata Containers. Phala Cloud's dstack ships a developer SDK on the same substrate. DataKrypto's FHEnom for AI combines TEEs with fully homomorphic encryption so ciphertexts stay encrypted in GPU memory even when the TEE holds.
Every one of these architectures shares a substrate: an Intel TDX or AMD SEV-SNP confidential virtual machine on a recent Xeon or EPYC processor, an NVIDIA Hopper or Blackwell GPU in confidential computing mode, and an attestation chain that begins at a per-CPU key signed by the silicon vendor and ends at a customer-controlled verifier.
The substrate has a threat model. Intel and AMD have been very specific about what it does and does not promise.
The silicon's threat model
Intel TDX and AMD SEV-SNP are virtual-machine-scoped trusted execution environments. A confidential virtual machine on either platform runs with its memory encrypted under a key the hypervisor cannot observe; its register state is shielded; and the silicon refuses to allow privileged software outside the VM — including the cloud operator's own hypervisor — to read or modify its memory. The technologies are not the same in their internals, but they share an architectural intention that a customer can rent compute from a cloud operator without trusting the operator with the data being computed.
What the threat model defends against is consistent across both vendors. AMD's January 2020 SEV-SNP white paper classifies the host BIOS, the hypervisor, device drivers, peer VMs, and the cloud operator's privileged software as fully untrusted, assumed to be malicious and potentially conspiring. Intel's TDX threat model, as documented in the ACM Computing Surveys treatment co-authored by IBM and Intel researchers, takes the same position. In both, the silicon's job is to defeat software-level adversaries no matter how privileged: the rogue insider with root, the compromised hypervisor, the malicious DMA from a peer device.
However, AMD's white paper specifies that on-line attacks against the DDR bus while a VM is actively running are out of scope, on the stated rationale that such attacks require significant local access and resources. The TDX literature parallels this: physical bus probing is outside what the hardware claims to stop. Attestation attacks themselves are within scope; the physical means by which an attacker might extract an attestation key are not.
This boundary has been documented since 2020 and has not changed. AMD's October 2025 response to the TEE.fail disclosure invokes Table 1 of the same 2020 white paper. Intel's October 28, 2025 security announcement states that TEE.fail does not change Intel's prior out-of-scope statement on physical attacks. The threat model is what it has always been.
The disclosure record
A more useful way to read the maturation curve of confidential computing may be the public disclosure cadence on hyperscaler infrastructure. Google Cloud's Confidential VM security bulletins page documents five disclosures in twenty-four months: GCP-2024-009 and GCP-2024-046 covering five AMD SEV-SNP firmware vulnerabilities on Milan and Genoa platforms; GCP-2025-007 on a separate AMD-side compromise; GCP-2025-058 on a Zen 5 RDSEED flaw that can silently fail in 16- and 32-bit modes; and GCP-2026-008 in February of this year, bundling six Intel TDX firmware CVEs ranging from race conditions to a transient-execution information disclosure. In each case, fixes were applied to Google's fleet before publication and the bulletins note no customer action required.
AMD's security bulletin sequence covers the same period at six SEV-SNP-specific bulletins in roughly the same two years. AMD-SB-3015 in December 2024 disclosed a physical-memory-aliasing path that allowed SPD metadata manipulation to overwrite encrypted guest memory; AMD-SB-3024 in September 2025 disclosed a second; AMD-SB-3040 in October 2025 was the formal acknowledgment of TEE.fail.
The silicon design is not what the disclosure record is indicting; the maturation work is happening above the silicon. A separate Google–Intel security assessment of TDX 1.5, published this year, found one VMM-to-TD full compromise vulnerability and four memory-leak paths in the TDX module itself.
This is what a young primitive layer looks like under disclosure pressure. These are operational issues that don't rise to vulnerability disclosure, but Google's October 2025 firmware update breaking attestation parsers, and the June 2025 incident where SEV-SNP and TDX remote attestation simply stopped working on certain guest OS images are the other side of the same maturation story.
TEE.fail and the inheritance chain
TEE.fail is the most recent in a research arc that started with WireTap and BatteringRAM on DDR4 systems in early 2025; the same Georgia Tech and Purdue group, joined by independent researcher Stephan van Schaik, extended the technique to DDR5 server platforms current confidential AI deployment use, and published the result in October 2025.
The attack is a passive memory-bus interposition. A custom DDR5 interposer, built by hand from off-the-shelf parts at a cost the researchers document at under one thousand US dollars, sits between the CPU and the DIMMs and observes encrypted memory traffic. The deterministic encryption scheme both Intel and AMD use for confidential VMs means the same ciphertext at the same address always corresponds to the same plaintext. Over enough observations, the researchers reconstruct sensitive in-memory values without ever decrypting anything.
What this lets them do: extract Intel's per-CPU Provisioning Certification Key from a fully trusted Xeon server in a single signing operation; forge TDX attestation quotes that Intel's own DCAP Quote Verification Library validates at the highest trust level; extract ECDSA signing keys from OpenSSL's constant-time implementation running inside an AMD SEV-SNP guest with Ciphertext Hiding enabled; and run a public Twitter/BlueSky bot that issues forged attestation quotes on demand.
The implication for confidential AI is the inheritance chain. NVIDIA's Confidential Computing on H100 and H200 GPUs, the substrate underlying every product named earlier, attests through the CPU TEE, a confidential VM proves its identity, and the GPU's attestation rides on that trust. The TEE.fail authors note that NVIDIA CC attestation reports are not bound to the identity of the specific CVM that requested them. An attacker with a forged CPU-side attestation can present an NVIDIA attestation quote borrowed from a different machine they do not own, and the verifying party cannot tell the difference. The paper demonstrates this against Phala's dstack SDK and Ethereum's BuilderNet, treated until then as a hardened confidential-computing deployment.
The substrate did what its threat model said it would do.
The gap
The cryptographic guarantee remains intact: data and model weights, while inside an attested CVM that has not been physically compromised, are not visible to the cloud operator or to anyone else operating only software-side. Within the threat model the silicon vendors have documented since 2020, the substrate behaves correctly. A confidential AI deployment in a tier-3 hyperscaler datacenter, where physical access is escorted, supply chains are attested, and DIMMs are sealed in tamper-evident enclosures, inherits a residual risk that is small and narrowly bounded.
The deployment Fortanix has been built to enable looks different. The named market is on-premises AI factories: government, healthcare, finance customers running third-party model weights on infrastructure they control.
What does the deployment's physical security posture actually look like, and which party's threat model governs in which physical location? When an attestation report verifies, what does the verification establish about the location of the machine that produced it? If composite attestation is what the next architectural diagram will lean on, what does that composite actually compose if the underlying primitives inherit the same threat-model exclusion? And how does that residual risk get reconciled with regulatory frameworks about to assume confidential AI works the way the architecture diagrams suggest?
The compliance layer
The regulatory regimes that govern AI deployments in the customer industries Fortanix is selling into, like California's SB 243 on AI companions, in force since January 1; HIPAA's evolving stance on AI-mediated PHI; the EU AI Act's high-risk-system audit requirements; GDPR's Article 22 right to contest automated decisions, increasingly assume privacy guarantees that the substrate is still maturing toward. SB 243 in particular pairs disclosure and content-detection obligations with a private right of action; first enforcement actions are expected in the second half of this year.
