The last two posts described Umbra, a system that locks AI coding agents inside confidential VMs, and aTLS, the protocol that proves those VMs are running the code you expect. Both lean entirely on trusted execution environments — Intel TDX in this case.

If you've read this blog before, that should raise an eyebrow. Most of what I've written here is about homomorphic encryption: protecting data with mathematics, so that nobody — not the cloud, not the operator, not the hardware vendor — has to be trusted with the plaintext. So why does a project I care about rest on hardware trust instead?

The short answer: because no cryptographic technique can run a developer's machine. The longer answer is this post, and I want to give it with the skepticism the topic deserves, because my honest position is that TEEs are less robust than the cryptographic alternatives — and that they are still the right tool for this job, provided you design around their fragility rather than pretending it away.

The Menu

When people say "privacy-enhancing technologies" for data in use, they usually mean some subset of the following. They don't line up on any single scale — each anchors its security somewhere different, so the honest comparison is anchor by anchor:

• Fully homomorphic encryption (FHE). Compute directly on ciphertexts; keys never leave the data owner. Security reduces to lattice problems — the same family of hardness assumptions NIST standardized for post-quantum cryptography — which have survived decades of open cryptanalysis. The price: performance overheads of several orders of magnitude, and a programming model of arithmetic circuits. No syscalls, no branching on encrypted values without paying for every branch, no network calls from "inside" the encryption. I've built toy schemes from scratch here before if you want to feel the constraints first-hand.
• Secure multi-party computation (MPC). Secret-share the data across several parties so no single one sees it; security holds as long as enough of them don't collude. The cryptography itself can be as strong as it gets — honest-majority protocols achieve information-theoretic security, no hardness assumption at all — so the thing you're really betting on is organizational: that the parties are genuinely independent. The cost is interactivity, bandwidth, and finding those parties.
• Zero-knowledge proofs. Prove that a computation happened correctly without revealing its inputs. Crucially, this is verifiability, not a way to host a live, interactive workload — it sits on a different axis than the rest of this list.
• TEEs. Run ordinary plaintext code at native speed inside a hardware-isolated, measured, attestable envelope. The data is only as safe as the CPU vendor's design, implementation, key management, and patch pipeline.

The one-sentence version of the whole landscape: cryptography moves trust into mathematics; TEEs move it into somebody's silicon.

TEEs Keep Getting Broken

Let's not sugarcoat the record. SGX, the previous generation of Intel's confidential computing, accumulated an entire literature of breaks: Foreshadow pulled enclave secrets — including attestation keys, meaning attackers could forge attestations — out through a speculative-execution hole; Plundervolt induced faults in enclave computations by undervolting the CPU from software; SGAxe extracted attestation keys again through a cache-based leak; ÆPIC Leak read enclave memory through an undocumented behavior of the interrupt controller — an architectural bug, not even a side channel. AMD's SEV had its own series: hypervisor memory-remapping attacks in the early versions, voltage-glitching of the security processor later. Physical attacks with memory interposers have been demonstrated repeatedly, from MEMBUSTER against SGX to the 2025 wave of DDR-interposer attacks (TEE.fail, Battering RAM) against the current generation, TDX and SEV-SNP included. TDX itself went through a joint Intel–Google security review before launch that found real issues — fixed before production, which is the system working, but also a reminder that this is a very large, very young trusted computing base.

I'm not a hardware person myself, but I've worked with people who break TEEs for a living, and when you hear their hacking stories the whole edifice sounds alarmingly fragile — a voltage rail nudged here, an undocumented register read there, one interposer on a memory bus, and the "confidential" machine quietly spills its guts.

Compare the failure mode on the math side. FHE deployments have bugs — parameter choices, implementation mistakes — but the underlying assumption has been attacked in public by cryptographers for decades and still stands; if lattices fell, it would be seismic, loud, and would take half of post-quantum cryptography down with it. Both anchors can fail, but they decay differently: math degrades slowly and publicly, silicon degrades in patch cycles. As trust anchors go, the mathematics is simply more robust. That's my stand, and nothing in the rest of this post walks it back.

But Breaking Them Isn't Free

Here is the part the "TEEs are broken, ignore them" take misses: read the fine print on those attacks. Most need physical access to the machine — soldered interposers, custom glitching rigs, control over voltage rails — or attacker-controlled hosts, specific unpatched microcode, and weeks of expert effort. These are research programs, not Metasploit modules. The economics matter: an attacker who can put hardware on your memory bus is a fundamentally different adversary than one who phished a developer.

And the software-visible part of this arms race is legible to defenders, because attestation carries it. When a class of attack gets patched, Intel bumps the platform's TCB version; verifiers that pin UpToDate — like the aTLS policies from the previous post — simply refuse quotes from unpatched machines, and grace periods give operators a bounded window to roll fleets. Living on the patch treadmill is uncomfortable, but the treadmill has instrumentation.

So the honest summary is: against a remote software attacker, a patched, attested TEE is a serious barrier. Against a well-funded adversary with physical access to the specific box, assume it will eventually fail. Which leads to two design consequences.

Consequence One: Placement Is Part of the Threat Model

If the scariest attacks need hands on the hardware, then where the TEE runs is not a detail — it's a security control. A CVM in a major cloud region sits behind badge readers, cameras, and audit trails; the physical-access attacks that shred TEEs in a lab have to get through a datacenter first. The same CVM on a bare-metal box rented from your adversary is a much weaker proposition: confidential computing's marketing says "you don't have to trust the host", and the engineering reality says "you get to trust the host less, not zero".

This composes with the vendor question (whose silicon, which generation, what patch posture) into something like a placement policy: TEE security is a product of the chip and the building it sits in. Pick both deliberately.

Consequence Two: Never Let the TEE Be the Only Wall

The more interesting consequence shows up in how Umbra is shaped. The design goal was never "TDX makes the sandbox impenetrable"; it was "no single layer's failure should be fatal" — including the TEE layer:

• Real credentials never enter the Dev CVM. The sandbox holds placeholders; secrets are injected into request headers at the egress proxy, per policy. An attacker who fully compromises a Dev CVM — TEE and all — harvests placeholder strings.
• Egress governance lives outside the sandbox's TEE. Even a popped sandbox still has exactly one network path, through a separate attested machine that enforces allow-lists, scans for secrets, and logs every request. Exfiltration has to walk past a second, independent checkpoint.
• Blast radius is per developer. One CVM per developer means a compromised sandbox is one developer's environment, not the fleet.
• Measurements come from a guarded pipeline. Attestation only proves you're running the expected code, so the expected code is built reproducibly and its golden measurements published by the release pipeline — trusting a TEE without trusting its supply chain would be theater.
• Verification is continuous. The control plane re-attests the security-critical CVM on every reconciliation pass, so drift and downgrades surface as alarms rather than silence.

None of this assumes the TEE is unbreakable. All of it assumes the opposite.

So When Are TEEs the Right Call?

My working heuristics, FHE bias and all:

• The workload is a whole interactive program — it needs native speed, syscalls, a network, arbitrary tools. That's a TEE or nothing. An AI coding agent that installs packages and talks to APIs is the textbook case: you cannot pip install inside a ciphertext.
• The workload is a fixed function over sensitive data — inference, scoring, private set intersection, analytics — and latency is negotiable. Reach for FHE or MPC first: the stronger anchor is affordable there, and stolen ciphertexts stay safe even against future quantum adversaries.
• You need to convince someone else what ran. Attestation does this cheaply inside a TEE trust model; ZK does it with cryptographic force at higher cost.
• The adversary plausibly gets physical access and the data is radioactive. Don't let a TEE be the only wall — and consider whether it should be a wall at all.
• And increasingly: combine them. TEEs make good armor for the plumbing around cryptographic systems — key management, orchestration, attested clients — while the math protects the payload. These technologies are colleagues, not competitors.

TEEs aren't that robust. They are, however, honest work: a real, measurable increase in attacker cost, an attestation story no other approach matches for live workloads, and native performance the cryptographic techniques won't reach for years. Use them where they're the only option or the pragmatic one, account for what you're actually trusting — vendor, patches, building — verify everything you can, and architect so their failure is a bad day instead of a headline.

And if the day comes when we can run a shell inside a ciphertext, I'll be the first to migrate Umbra onto it.