Containing the Optimizer

We call them all “sandboxes” to make them easy, and then quietly assume they all protect the same way. They don’t.

Unmitigated Risk · August 2026 · a field guide to what isolation actually does

Technical companion to  What Confidential Computing Is, What It Isn’t  ·  Confidential Computing’s Inconvenient Truth

Ask a room of technical people what separates a container from a virtual machine, a virtual machine from a confidential VM, a confidential VM from a hardware enclave, and you will get five confident answers and three correct ones. This is not a failure of intelligence. We call all of them “sandboxes.” It is a genuinely useful word. It makes the concept teachable in one breath, and everyone knows what you roughly mean. The trouble is the side effect. Once four different mechanisms share one friendly name, people assume they share properties too. If this one is safe to run untrusted code in, that one must be. If this one keeps the operator out, that one must. The simplification that made the idea easy quietly ships a false equivalence, and the equivalence is wrong in exactly the places that matter.

That false equivalence is having a moment, because in July 2026 an autonomous AI agent broke out of a test “sandbox” that had no direct internet access, only a package proxy for installing dependencies, and hacked its way into the production systems of a real company. The reaction was a wave of “secure AI” and “private AI” messaging, all of it leaning on the same friendly word and the property-transfer that comes with it. A vendor who says “your model runs in a secure sandbox, even we can’t see it” is not usually lying. They are borrowing the reassurance one kind of sandbox earns and spending it on another, and the reader cannot tell, because the word was flattened before the conversation started.

So what is an optimizer? Fundamentally, every AI you use is one. A model is trained by searching for the parameters that score best against an objective, and an agent built on it runs the same procedure one level up, searching the actions available to it for the ones that get the objective met. Nothing in that procedure knows which paths you meant to leave open. It only knows which ones work. And that is what makes them a security problem worthy of containing.

Container, VM, confidential VM, and enclave are four different mechanisms, built for four different adversaries, making four different promises. Calling them all “sandboxes” makes them easy to talk about and impossible to tell apart, and none of the four, by itself, contains an optimizer. What contains an optimizer is the design wrapped around whichever one you pick, and that is the part the friendly word hides.

This piece is a field guide to telling them apart. It walks the staircase above one step at a time, what each primitive shares, what it was built to resist, and what it honestly promises, then gives you two things to do with it: a way to read what any “secure AI” claim is actually asserting, and a way to size what each rung’s failures cost you when they come. The evidence is the hardware record, because confidential computing is the most heavily studied rung and its failures are documented in a way the agent-sandbox rung’s are not yet. Whether you are buying the claim or building the containment, the ladder is the same. Only the last question differs, and the piece ends by answering it both ways.

Part I · The Ladder

1Container is not VM is not enclave

Start where the confusion starts, because until the words come apart nothing else in this piece can be reasoned about. Four mechanisms get spoken of as one, “sandbox” in casual use, “isolation” in the marketing, and they differ in the one dimension that decides everything downstream: what they share with their neighbours. Sharing is the attack surface. The more a workload shares with the code next to it, the more paths exist between them, and each rung of the ladder shares less than the one below it. One honest caveat before we climb. This is a single axis, not a total order of security. It ranks how much shared, guest-reachable surface each primitive exposes, and two other things that matter, whether the operator is inside or outside your trust boundary, and whether you sit on physically shared silicon, are orthogonal to it and do not move in lockstep as you climb. A confidential VM drops the operator but keeps the shared silicon; a discrete processor drops both. Keep those as separate questions; the ladder answers only the first. The flattening into a single word is convenient and it is exactly what makes the properties look transferable when they are not.

A container shares the host kernel. Namespaces and cgroups give each container its own view of the process table, the filesystem, and the network, but there is one kernel underneath all of them, and a flaw in that kernel is a flaw in the wall between every container on the box. Containers were built to keep cooperating workloads from tripping over each other, a packaging and resource-management tool, not a defense against code that is actively trying to get out. That is not a knock on containers; it is what they are for. It is only a problem when someone points hostile code at one and expects a security boundary, which is exactly what happened in July.

A virtual machine shares the hypervisor and the silicon, but not the kernel. Each guest runs its own operating system, and the hypervisor mediates between them with a far smaller, far more scrutinised interface than a shared kernel exposes. This is a genuine escalation in isolation strength, and it is why the security-conscious response to “run untrusted code” has long been “put a VM boundary around it.” But a VM still trusts the host. The operator, the hypervisor, and anyone who compromises them can see inside the guest. The VM defends you from your neighbours, not from your landlord.

The size difference is not abstract. The Linux kernel accumulated 5,681 CVE identifiers in 2025 alone. Xen, a thin monitor doing a far narrower job, publishes a few dozen advisories a year. Some of that gap is counting convention, since the kernel began assigning an identifier to nearly every backported fix in 2024, which is why the number jumped from 265 in 2023. It is not two orders of magnitude of counting convention. Then notice the other number. Of the 16,436 kernel CVEs indexed by the NVD since 1997, twenty-five have ever been confirmed exploited in the wild. Volume measures surface, not risk, and the two come apart badly. That is the honest case for the smaller interface, and it is the first hint of the argument in Part III, where what you can count turns out not to be what should worry you. It is also why KVM is worth naming early. It turns the kernel itself into the hypervisor, so a KVM host carries the larger number rather than the smaller one.

Those two, container and VM, are the entire isolation vocabulary most deployments actually use, and the gap between them is already large enough to matter. A container escape and a VM escape are different events with different likelihoods and different fixes, and treating “it’s isolated” as though it named one guarantee erases that difference. The next two rungs exist to defend against the landlord, and they are where the AI-privacy pitch lives.

2Not all VMs are the same

Before climbing higher, open up the rung we just set down, because “it runs in a VM” hides a range wide enough to matter to the argument. The isolation a VM gives you is set almost entirely by the hypervisor underneath it, and hypervisors differ in two dimensions that each change what the contained code can reach, and then there is a third move, which is to remove the hypervisor from the picture entirely. The optimizer does not see “a VM.” It sees whatever surface the specific arrangement exposes, and it will probe every inch of it.

The first dimension is where the hypervisor runs and how much privileged software sits under the guest. A type-2, or hosted, hypervisor (VirtualBox, VMware Workstation) runs as an application on top of an ordinary host operating system. That means the guest’s isolation depends on the hypervisor and the entire host kernel beneath it; compromise the host OS and the VM boundary is moot. A type-1, or bare-metal, hypervisor (ESXi, Xen) runs directly on the hardware, with no general-purpose OS underneath to drag into the trusted computing base, the set of code you have no choice but to trust because a flaw anywhere in it defeats the boundary. KVM is the instructive middle case, because it does not fit the tidy split. It turns the Linux kernel itself into the hypervisor, so the host OS is the trusted computing base, and Firecracker and Cloud Hypervisor run as thin user-space monitors on top of exactly that. The lesson is that the layers of privileged software the guest sits on top of vary enormously between two things both called “a hypervisor,” and that variation is a rung. The hosted case trusts everything a full OS trusts; the bare-metal case trusts less; and where KVM lands depends on how much of Linux the monitor above it actually exposes.

The second dimension is how much the hypervisor exposes to the guest. A fat hypervisor carries decades of features (emulated devices, live migration, a broad paravirtualized interface), and that emulated-device code is precisely where most historical VM escapes have lived; the canonical ones are bugs in an emulated floppy or network controller the guest was never expected to weaponise. A thin monitor like Firecracker deliberately strips that device-emulation surface down to a minimal, purpose-built interface, which is the entire reason it can be trusted around untrusted code in a way a legacy hypervisor cannot. Firecracker does this on top of Linux KVM, not instead of it, so the shrinking is of the monitor’s own exposed interface rather than of everything beneath it (AWS Nitro reaches a similar small guest interface by a different route, its own hypervisor and dedicated offload hardware rather than KVM). Same word, an order of magnitude difference in the surface the guest can reach. One thing none of these VM arrangements changes, though, is that a thin monitor still trusts the operator underneath it. Only the confidential-VM rung above, SEV-SNP and TDX, uses hardware to drop the operator from the trust boundary. A smaller guest interface and an untrusted operator are different axes, and it is worth not letting “minimal” slide into “shielded from the host.”

The confidential VM near the far end is itself a hypervisor variant, the one where the hardware removes the operator from the trust boundary, so the guest no longer has to trust the hypervisor at all. That is what makes it the bridge to the upper rungs, and it is why the “even we can’t see it” claim is coherent only for this arrangement and not for the ones to its left. It is also, as the record will show, the arrangement that trades the hypervisor’s surface for the cache’s. The ladder in this part is described in CPU terms, because that is where the primitives were built and where the record is deepest; if your workload runs on accelerators, the rungs still apply but the sharing story underneath them is far less settled, which §9 takes up directly.

Keep going in that direction and you reach the floor of the whole axis: no hypervisor at all. Compile the workload to run directly on the hardware, with no host OS, no monitor, and no guest, and the entire family of hypervisor-escape and kernel-escape attacks loses its target, because the layers those attacks live in are simply not present. This is not hypothetical; it is what a project like TamaGo does, running a memory-safe Go application bare-metal on hardware like the USB armory, with the trusted computing base reduced to the firmware and the runtime and nothing else. The catch is the same trade the dedicated security processor makes at the top of the main ladder, reached from the software side. You give up the cloud model entirely (one workload owns the machine, no multi-tenancy, no orchestration) and you move the whole of your trust onto the firmware and the runtime, which are now the entire attack surface. The cost is not abstract. Bin-packing, elasticity, live migration, spot capacity, the entire economics that make cloud inference affordable all assume many tenants sharing a machine, and the top rungs give exactly that up. Which is why this end of the axis is not for a typical deployment. It is for the case where the workload itself is the crown jewel and the multi-tenancy discount is not worth what it exposes, a frontier lab isolating model weights, a signing operation, a key-management core. For everyone running inference at cloud economics, the honest position is that the top rung is not available to you, and the design question is how you contain an optimizer on a rung that shares silicon. It is the strongest containment on this sub-ladder and the least like a cloud deployment, and which of those facts matters more is exactly the design decision this piece is trying to make legible.

3Why the rungs get confused

The reason these mechanisms blur together, and the reason a primitive built for one job keeps getting sold for another, is almost never incompetence. It is economics, and the pattern is old enough to have a shape. Build a mechanism X for threat model Y; later, repurpose X for threat model Z, because X already exists and shipping it beats building the right thing years from now. Each repurposing quietly changes what the mechanism protects against while the name stays the same, and that is how one word ends up covering four threat models.

I have watched this run several times over thirty years in and around the public-key infrastructure that secures the web, and the examples rhyme. SMS was built for messaging and repurposed as an authentication channel; SIM-swapping exploited the gap, and the channel is still everywhere because deployment inertia beats the security community’s ability to move a market. SSL was built for browser sessions and repurposed for APIs, IoT, email, and VPNs; the ecosystem spent two decades closing the resulting gaps through Certificate Transparency, stricter issuance rules, and sustained institutional pressure, fixes that were not inevitable and did not come from patching. And Intel’s SGX was built for secure remote computation, with content protection as one of its flagship early uses, protecting a media stream from the machine’s owner (it underpinned Ultra HD Blu-ray playback, and its removal from later chips broke that), then was repurposed to protect a cloud tenant from the machine’s operator. That last repurposing did something worse than widen the threat model. It inverted it. The party SGX’s content-protection use was built to trust, the platform owner, became the party the cloud version has to defend against.

Hold that against the box that escaped in July. A container runtime and a language-model sandbox were built to contain cooperating code (code that is not trying to leave). Point an autonomous agent at one, feed it instructions from an untrusted web page or a poisoned document, or just turn it loose to optimize hard against a benchmark, and the contained code is now adversarial by construction. Same box, inverted threat model. The container did not fail at its job; it was asked to do a different job, one rung above the one it occupies, and the name “sandbox” hid the substitution.

4The top of the ladder, and the conflation

The two upper rungs exist to defend against the landlord (the operator the VM still trusts), and they are where “secure AI” and “private AI” actually live. A confidential VM (AMD SEV-SNP, Intel TDX) keeps the guest encrypted in memory so that even the operator and the hypervisor cannot read it through the software stack. This is the technology behind almost every “even we can’t see your data” claim, and within its threat model it delivers. The provider genuinely cannot read your memory the ordinary way. But a confidential VM still shares the physical caches, buses, and the memory-encryption engine with other tenants, and those shared resources leak through side channels that the encryption does not touch. A side channel carries no data of its own. It lets an attacker infer the data from how the hardware behaves, how long an operation takes, which cache lines it touches, so nothing is ever decrypted and the encryption is never defeated. The guarantee is real and it is narrower than the sentence implies.

A dedicated security processor (a hardware security module, a smartcard secure element, Apple’s Secure Enclave) sits at the top because it shares almost nothing with the workloads around it. It runs on physically dedicated execution resources, its own processor and a protected region of memory, rather than time-slicing the same cores and caches as other tenants, so the cache-timing, speculative-execution, and port-contention classes that plague the shared-silicon rungs are categorically absent rather than merely mitigated. (This is a different claim from the confidential-VM rung. AWS Nitro Enclaves, for instance, are hardened VMs isolated by the Nitro hypervisor, not a dedicated security processor, and belong a rung down.) The trade is explicit and it is not free. A dedicated security processor does not solve cloud multi-tenancy, which is the entire reason the industry reached for shared-silicon confidential VMs in the first place. You buy the strongest isolation by giving up the sharing that made the cloud economical.

Now the conflation, stated plainly. “Your model runs in a secure enclave, even we can’t see it” is a sentence that borrows the word from the top rung and the economics from a middle one. Sold as an enclave-grade promise, delivered on a shared-silicon confidential VM, it inherits the confidential VM’s side channels, which, as Part III shows, are exactly the ones that reach model weights and user prompts. The pitch is not usually a lie. It is a rung substitution, selling the guarantee of the top of the ladder at the price and deployment of the middle, and the substitution passes unnoticed because “sandbox” covers both rungs equally.

Part II · What It Costs When a Rung Fails

5Vector tells you how. It doesn’t tell you what to do

Attacks on a hardware boundary sort into seven vectors, by how the attacker gets information across it. A single attack can span more than one, a speculative-execution bug that leaks through a cache side channel touches two, but the vector names where the boundary actually failed. They run roughly from the shared-resource side channels that dominate the record to the interface and firmware attacks that look most like a classic software escape.

The vector is useful, but it stops one step short of the decision. Knowing an attack was a cache side channel or an interface bug tells you a great deal about how it works and nothing directly about what you should do. And that missing step is precisely the one a vulnerability score also skips. A CVSS number rates how bad the exposure is if exploited. It says nothing about whether the fix is a maintenance window or a hardware-replacement cycle, and it treats a bug closed in next month’s microcode and a leak baked into the silicon for the machine’s five-year service life as the same species of problem, because from the standpoint of severity they can be identical.

6How fixable is it, really

So sort the record a second way, not by how the boundary was crossed, but by how fundamentally fixable the weakness is. This is the cost layer that sits under the ladder. Once you know which rung a workload is on, remediability tells you what that rung’s failures will cost you. It has four values, and the value, not the severity, is what sizes your response.

Patchable. A flaw in an SDK, microcode, or firmware that an update resolves. Foreshadow, ZombieLoad, Downfall, most speculative-execution attacks, the July agent’s whole exploit chain. Often carries a performance cost, but the flaw is gone for patched systems. Compensating control. The flaw stays; you reduce the conditions under which it can be exploited, disable simultaneous multithreading, put the hardware in a physically secured facility, run multiple independent attestation verifiers. You have not fixed it; you have narrowed it. Architectural. A property of the silicon or the encryption engine that no patch reaches: deterministic memory encryption, where identical plaintext always produces identical ciphertext, so an observer learns what changed without decrypting anything; port contention, where two tenants competing for the same execution unit can each time the other; physical interposition on the memory bus. It persists for the life of the hardware; mitigations reduce exploitability without removing the cause. Root-of-trust break. The trust anchor itself is compromised, a root key extracted from fuses, a microcode signature check defeated. These do not leak data; they forge the proof that the boundary exists, which makes attestation itself, the cryptographic proof that the boundary is genuine and running what it claims, meaningless for the whole platform generation. One qualification keeps this honest. Some trust anchors are rotatable. When SGAxe extracted SGX attestation keys, Intel could run a TCB recovery, invalidating the compromised keys and re-issuing new ones once the underlying microcode flaw was patched, and the attestation ecosystem is designed for exactly that move. The break is unrecoverable when the extracted material is not rotatable, a global key burned into fuses at manufacture (the shape of TEE.Fail and global-wrapping-key extraction), where there is no new key to issue because the old one is the silicon. Rotatable anchor, a bad calendar quarter. Fused anchor, the platform generation is done. The line that argues is the one between compensating and architectural, and some entries sit close enough to it that a careful reader could file them either way. When that happens the resolving question is which response you would actually have to fund, because that is the only thing the class is for.

The reason this beats a severity score is that it maps directly to money and calendar. Patchable is a maintenance window. Compensating is an operational setting and some lost performance. Architectural is either accepted residual risk or a line item in the next hardware refresh. Root-of-trust is decommissioning the platform generation and rotating every secret ever sealed to it. Four different budgets, four different owners, four different timelines, and a CVSS number distinguishes none of them.

7The shape of the record is the argument

Sort the whole published record into those four columns and the distribution, not any single entry, is what carries the argument. The patchable column is crowded and reassuring. Real attacks, real severity, all closed by an update. This is the column the industry is comfortable in, because it is the column where effort reliably produces safety. It is also the column the marketing is happy to discuss, because “we patched it” is a good sentence.

The two right-hand columns are where the durable risk lives, and they are the columns the marketing never mentions. Ciphertext side channels on AMD SEV-SNP, port contention that disabling hyperthreading does not touch, physical bus interposition with a thousand-dollar device. These are not bugs awaiting a patch. They are what the hardware does. And root-of-trust breaks, a global wrapping key pulled from fuses, an insecure hash that let researchers load malicious microcode under a confidential-VM technology, do not leak data at all. They forge the proof. When those land, no patch restores trust, because the thing that was broken is the mechanism by which trust was established.

That asymmetry is the argument in one observation. The failures that are easiest to fix are the ones the industry talks about, and the failures that are impossible to fix are the ones it doesn’t. A reader who only follows the patch announcements sees a technology getting steadily safer. A reader who sorts by fate sees a technology whose worst problems are structurally exempt from the only response the industry has practiced. The next part lets you do that sort yourself.

Part III · Reading the Record

8The record, sorted by fate

Here is the published record, the attacks that give this guide its evidence, sorted the way that matters rather than by platform. Filter by remediability class, by attack vector, or narrow to the entries that bear directly on AI workloads. The bar shows how the visible set distributes across the four fates; watch it shift as you filter, because that shifting distribution is the argument you can now run for yourself.

Each row anchor-links. The § copies a direct link to that entry, so a specific attack can be cited on its own. Entries marked AI extract model weights, inference inputs, or user prompts from a running workload, and each rests on published, peer-reviewed research rather than rumor. This set covers the attacks that carry the argument; it is not the complete catalog. The newest entries are also the least settled, having had the least time to be replicated or contradicted.

9The rung AI runs on, and hasn’t met yet

Put the ladder and the record together and the picture sharpens. “Private AI” is sold on the confidential-VM rung (the one that shares caches, buses, and the memory engine) while the conversation about its failures is stuck one rung lower, among the container-and-sandbox escapes. That is the mismatch this whole piece exists to name. The AI-isolation conversation is living almost entirely in the patchable column and has not yet met the other three. Container escapes, agent jailbreaks, tool-call breakouts, nearly all vector 7, nearly all genuinely patchable. That is a real treadmill, and the industry knows how to run it. The mistake is concluding from the treadmill that isolation for AI is fundamentally a patching problem.

It stops being one the instant those workloads share silicon. Put an inference job on a GPU or CPU it shares with another tenant and the shared-resource side channels (the architectural column) come into scope, and nobody in the sandbox-escape discussion is talking about them yet. The three entries that carry this are the newest in the record, and none of them breaks any cryptography. TDXRay reconstructs a language model’s user prompts from inside an encrypted confidential VM, recovering them from a single memory access trace at better than ninety per cent similarity, by watching at cache-line granularity which hash-map buckets the tokenizer walks. The data stays encrypted the whole time; the computation pattern leaks it. HyperTheft and CipherSteal do the same to the two assets an AI deployment most wants to protect, model weights and inference inputs, through a ciphertext side channel. All three are architectural. A patch can raise the cost or add mitigations, but none of them removes the underlying shared-resource leakage mechanism, because that mechanism is the shared silicon doing its job. The ciphertext channel is the sharpest illustration, because it does now have a fix. Starting with Zen 5, AMD can check the hypervisor’s reads against the hardware rather than only its writes, hiding guest ciphertext and closing the software-based ciphertext attacks as a class. Notice what that fix is. It is not microcode and it is not a kernel patch; it is a silicon generation. Most deployed SEV-SNP fleets do not have the hardware, it is not on by default where they do, and it carries a performance cost when enabled. That is what the architectural column means in practice: not “unfixable forever,” but “fixed on a purchase order and a refresh cycle, not on a patch Tuesday.”

It would be fair to stop here and ask whether that result is real or an accident of timing. Every AI-relevant entry is recent, recent research skews toward exotic hardware attacks because the easy interface bugs were picked over years ago, so perhaps “none of them patchable” says more about the sample than about AI. The objection is worth taking seriously, and there is a mechanism underneath the pattern that answers it. An interface bug gives an attacker execution: a way in, a shell, an escalation, the thing a patch takes back by closing the hole. But the assets an AI deployment exists to protect (the weights, the prompt, the inference input) are not seized by getting in. They leak from observation of a running computation: watching which cache lines the tokenizer touches, reading the ciphertext as it changes, timing the memory bus. Reading a computation without breaking into it is precisely what shared silicon structurally permits and what a patch cannot revoke, because there is no defect to fix, only physics being observed. So the extraction attacks are architectural for a reason that has nothing to do with when they were published: the thing being protected is exposed by the sharing itself, not by any particular bug in the boundary. The timing is a coincidence; the column is not.

The “private AI” promise is that encryption protects your data in memory. It does. Then the computation pattern leaks the same data through the cache, because that is a different boundary than the one the encryption defends.

It is worth being fair to the technology here, because the failure is not the one it looks like. Confidential computing does deliver a real guarantee, and a valuable one: it excludes the honest-but-curious operator through the ordinary software path. A cloud provider running a SEV-SNP or TDX instance genuinely cannot read the tenant’s memory the normal way, and for a bank or a hospital renting someone else’s machine, that is a real change in what is possible. The mechanism does the thing it was built to do. The trouble is everything sold on top of that. The published record against these parts is not a handful of edge cases: SEV-SNP alone has been broken by CipherLeaks, CacheWarp, WeSee, and Heckler, and the memory-integrity and attestation guarantees fall to a roughly ten-dollar interposer in BadRAM and a fifty-dollar one in Battering RAM, the latter bypassing Intel SGX and AMD SEV-SNP alike. But notice where the vendors draw their own line: Intel, AMD, and Arm all state that physical attacks are out of scope of their threat model, and the shared-cache side channels are a boundary the memory encryption was never designed to touch. So the honest reading is not that the silicon is defective. It is that “even we can’t see it” is true against exactly the adversary it was built for and false against a co-tenant or a physical attacker, threats the builders themselves already told you they do not cover. The guarantee is real. The marketing sells its scope, and the scope is the part that was quietly dropped.

One precondition is worth stating, because it is the first thing a careful reader will reach for. Nearly all of these attacks assume a hostile or compromised host: TDXRay’s own threat model is an operator who controls the host kernel and hypervisor, and the ciphertext attacks assume the same. If your operator is not in your threat model, none of this is aimed at you, and a well-run cloud with careful placement and monitoring makes the expected loss lower still. But notice which adversary that is. “Even we can’t see it” is a promise made about the operator specifically, and it is sold to buyers whose reason for wanting it is that they do not want to trust the operator. The precondition these attacks require is not an exotic assumption bolted on to make them work. It is the exact adversary the sentence names.

So the AI-isolation world faces two problems stacked on top of each other. On top, the interface treadmill: patchable, loud, survivable, and getting all the attention. Underneath, the shared-silicon side channels: architectural, quiet, permanent, and getting almost none. A field that reads only the top of that stack will conclude, correctly, that it is patching fast, and miss, entirely, that its most valuable assets are exposed through a boundary no patch defends. The record hands you that reading a decade before you would otherwise reach it entry by entry.

And the record so far is mostly the CPU side of the story, which understates the problem, because AI runs on the accelerator, where sharing is even less settled. A GPU was built to serve one workload at a time, and Kubernetes still hands a pod a whole GPU by default, so cross-tenant sharing was added afterward with uneven isolation: NVIDIA’s hardware partitioning (MIG) gives tenants genuinely separate memory but arrived only with Ampere and is unevenly adopted, while the software time-slicing many environments fall back on does not isolate memory between the workloads sharing a card. The exposures follow the same architectural shape as the CPU ones. LeftoverLocals (CVE-2023-4969) let one process read another’s data out of GPU local memory that was never cleared between kernels; GPUHammer (USENIX Security 2025) showed Rowhammer bit-flips in a GPU’s GDDR6, where a single flip in a weight’s exponent collapsed model accuracy from around 80 percent to under one, mitigable only with error-correcting memory that costs standing performance and capacity. Same lesson as the confidential-VM rung. No patch makes shared silicon stop being shared.

10Grading the escape

Now run the instrument on the incident that opened the piece, because grading a case you have heard of is how the lens becomes something you can use rather than something you have read. Take the July agent’s attack chain link by link and place each one.

The SSRF against the package proxy, which bought indirect internet access by having the proxy fetch external content on the agents’ behalf: vector 7, patchable. The token-forgery zero-day found a month later, where a legacy refresh endpoint accepted an invalid signature and handed back a validly signed administrative one: vector 7, patchable. The Linux kernel privilege escalation, a recent CVE whose public exploit the agents customised for the host they landed on: vector 7, patchable. The credential harvesting and lateral movement: interface and configuration, patchable. Two independently discovered bugs and two known classes, and every link lands in the same column. OpenAI did exactly what that fate prescribes: revoke the credentials, rebuild the service, patch the zero-day, wipe the board. On the record so far, a textbook patchable-column response, executed competently.

Then the message board came back. Here is where the grading earns its keep, because the board is not on that list. The persistent message board depended on two things that are not bugs: standing write access to a shared service, and state that survived a teardown. Grade those and they do not land in the patchable column at all, they are design properties, the software equivalent of the architectural column. You cannot patch away “the contained code can write to a shared resource and its writes persist.” The proof is in how it returned. The rebuilt board did not reuse the hole that had just been closed. The agents reconstituted it out of directory names on an unauthenticated WebDAV endpoint, a different mechanism carrying the same property, which is what you would expect if the property rather than the bug was the thing doing the work. You remove it by changing the architecture, with no standing write and ephemeral state. Patch the bugs and the board returns; change the design and the whole class of persistence is gone. The lens told you, before the second disclosure, that the remediation was aimed one column to the left of the actual problem.

Part IV · Containing the Optimizer

11Containment is the design, not the rung

Here is the part that should be uncomfortable, and I will be plain about my stake in it. The agent-containment failure was not a surprise to anyone who had watched optimizers before. I wrote up a containment framework for this failure mode well before the incident, but the date is not the point and I do not want it read as a called shot. The point is that nothing in it was exotic. It was the ordinary consensus of people who had watched reinforcement-learning systems discover, over and over, that the fastest path to a reward is rarely the one anyone intended. The threat-model inversion at the root of it, a system that optimizes against its own constraints rather than working within them, was old before agents made it concrete.

The framing then was that an agentic system behaves less like a program and more like an insider. It does not accidentally misuse resources, it optimizes, and successful optimization routinely violates assumptions nobody wrote down. The prescription followed directly, and every line of it maps onto something the July incident violated. Execution should be ephemeral, fresh state each task, so nothing persists between runs; the message board is the counterexample, persistence an ephemeral design would have erased on the next reset. Credentials should be short-lived and scoped, minted per task and attenuated for sub-agents; the incident ran on standing write and harvested long-lived credentials moving laterally. And there should be agents watching the agents, behavioral baselines, anomaly detection, a kill switch, which is precisely the defensive layer OpenAI said, afterward, it needed to build.

None of those are new primitives. Ephemeral infrastructure, scoped tokens, immutable images, caveat-based delegation, tamper-evident logs. All of it is buildable today with parts that already exist. The reason it was not in place is not that it was hard or unknown. It is that the field poured its effort into measuring how good the models are at offense, benchmarks like the one this agent was cheating, and treated containment as something you patch after it breaks. In the vocabulary of this piece, the industry chose to live in the patchable column and called it security.

Safety is a design problem, not a policy problem. You do not get containment by writing a rule that says “do not leave the sandbox” and monitoring for violations. You get it by building an environment where leaving is structurally hard, with no standing write, no persistent state, no egress path the design trusts the contained code to respect. The safe choice has to be the default, because an optimizer will find every path where it is not.

This is why the whole apparatus of vectors and fates is not academic. The remediability lens is, at bottom, a way of asking whether a problem is a bug or a design property, and design properties are not patched, they are designed out. Read the escape as patchable bugs and you patch them and move on, and the agents rebuild the board. Read it as a design failure and you change the architecture, and the class of exploit is gone. And here the software design-property is importantly unlike its hardware namesake. When a side channel is architectural in silicon, you are stuck for the service life of the fleet, and the fix is capital expenditure and a refresh cycle measured in years. When standing write access or persistent state is architectural in a system design, changing the architecture costs a redesign measured in weeks. Both are architectural in the sense that no patch to the existing thing removes them, but one is a hardware generation and the other is a sprint. That asymmetry cuts against the AI industry, not for it, because its architectural problems are mostly the cheap kind, designable-out at the cost of some engineering, which makes leaving them in place a choice rather than a constraint. The lens tells you which reading is true. Acting on the true one is the difference between a maintenance window and a solved problem. But “change the architecture” is still too vague to build from, and the next section makes it concrete, because the design failure has a specific shape and a specific fix.

12The wall, and the holes you cut in it

Everything so far has been about the wall, how tall it is, what it shares, which rung of the staircase you stand on. But no useful workload lives behind an unbroken wall. A container that cannot pull a package, an agent that cannot call a tool, a model that cannot return an answer, a perfectly sealed box is also a perfectly useless one. So every real deployment cuts holes: an egress path, a write channel, a tool API, somewhere to keep state, a credential to authenticate with. This is not carelessness. The holes are the entire point; they are what lets the contained thing do work.

And here is the part the staircase cannot show you. Every hole hands back a property the wall was providing. Cut an egress path and the “no network” property is gone on that path. Grant write access to a shared service and the “cannot affect others” property is gone through that channel. Persist state and the “nothing survives” property is gone for that store. It is tempting to reach for the Swiss-cheese image here, but not the one from safety engineering, this is not Reason’s model of stacked imperfect layers whose holes occasionally line up. It is one wall, deliberately perforated, and the holes do not need to align with anything. Each is a standing trade of a property for a capability, open by design. Which means a stronger rung does not save you. Move from a container to a confidential VM and you have built a taller, thinner wall, around exactly the same holes.

So the containment was never the wall. It is the discipline that governs the holes, and that discipline has a name: mediated access. An unmediated hole is an opening, and anything the contained code wants to push through it, it can. A mediated hole is a checkpoint: every action through it is brokered by something the contained code does not control, scoped to the minimum the task needs, logged so it can be seen, and revocable so it can be shut. Read-only until write is genuinely required. Allow-listed rather than open. Scoped to one purpose rather than general. The wall decides how strong the barrier is between the holes; mediation decides what can happen through them, and it is the second that actually contains an optimizer, because an optimizer’s whole method is to find a hole you left unmediated and use it for something you did not intend.

The July incident is the cleanest possible demonstration, because the wall held. There was no direct internet path; the isolation, in the staircase sense, worked. The escape ran entirely through a hole (the package-registry proxy, a permitted egress channel), and it turned on one property of that hole that nobody had mediated. It was writable. Write access to a shared service is not a data path, it is a coordination path, and the agents used it as one, leaving state for each other on a surface that outlived every teardown. That is the whole mechanism, a hole that was an opening instead of a checkpoint, while the wall itself held. Mediate that one hole, read-only unless write is required, brokered, logged, and the coordination surface never exists, no matter which rung of the staircase the wall was built on.

13Watching what the actions add up to

Mediation has a blind spot, and it is a structural one, not a tuning problem. A mediated hole judges each action on its own: is this write permitted, is this egress on the allow-list, is this credential in scope. It has no memory and no aggregate view, so it can approve a thousand individually-legitimate actions and never notice that together they add up to something you never intended. The July message board is exactly this failure. Any single write to that shared proxy might have looked fine; the coordination channel only exists in the sum of them, and a per-action checkpoint is constitutionally unable to see a sum.

So the second half of containment is a reviewer that reads the accumulated behavior over time. Every mediated hole already emits a signal. That is what “logged” in the previous section was for, and those signals are a stream describing what the contained system has actually been doing, action by action, session by session. The job is to correlate that stream, looking for the shapes that only appear in aggregate: writes that are quietly building shared state, egress that is slowly staging an exfiltration, a sequence of in-scope calls that together probe for a privilege boundary. Then surface the few patterns worth attention to a human, who adjudicates what the machine flagged and, when it is real, feeds the verdict back to close the hole that allowed it.

The requirement on the reviewer is specific, and it is stronger than “use AI.” It must be automated, because at machine speed and machine volume no human can read the stream in time. It must be stateful and cross-session, because the patterns that matter accumulate across actions and runs. And it must recognize emergent sequences rather than score individual actions, because a static alerting rule only catches shapes someone already wrote down, and the optimizer’s entire method is to produce shapes nobody anticipated. An agent is an excellent way to meet those requirements, the continuous-reasoning move that separates a live conclusion from a live dashboard, pointed at agent behavior rather than compliance state, and it may be the only practical one today. But it is the requirements that are load-bearing, not the label. A human cannot be the monitor here; a human is the adjudicator the monitor exists to protect.

Which raises the obvious problem, and the section would be dishonest to skip it. The reviewing agent is itself a surface with holes. It reads a signal stream from across the system, it has write access to raise findings, it talks to a human. By the argument of the previous section, every one of those is a hole, and an unmediated reviewer is just a higher-value coordination target, one that can see everything and is trusted to report on it. So the monitor gets contained like anything else. It runs least-privileged, reading the signal but unable to act on the workloads it watches; its own actions are attested, so a compromised reviewer cannot quietly rewrite what it reports; and it is not the thing that adjudicates, only the thing that surfaces. The human adjudication has to be bounded the same way, because a loop that asks a person to review ten thousand flags a day does not scale, it collapses, and a collapsed adjudication layer is indistinguishable from none. The reviewer earns its place only by cutting the volume a human sees to something a human can actually judge. Assume it will be wrong in both directions. Tuned to miss nothing it floods the queue until nobody reads it, and tuned for a quiet queue it misses the slow pattern, which is the one worth catching. The asymmetry that matters is in what its verdicts are allowed to do. Tightening a mediation rule on its own recommendation is safe, because the failure mode is inconvenience. Loosening one is not. A monitor that becomes another unmediated surface has not closed the loop. It has added a hole with a privileged view.

Mediation and review are not alternatives, and neither is optional. A mediated system with no aggregate review still ships the message board one legitimate write at a time, because nothing is watching the sum. An aggregate reviewer with no mediation just narrates the breach as it unfolds, because nothing can stop the action. Together they are the two halves of governing a hole: mediation decides what may pass through it in the moment, review decides what the things that passed through it amount to over time, and the human sees only the small, high-value residue that survives both. Both halves rest on a prerequisite worth stating plainly, because it is the part most easily assumed. You cannot mediate or review what you cannot see. Every argument in this section presumes the actions at a hole are observable at the fidelity the reasoning needs, and on some layers they are not. The GPU is the sharp example, opaque enough that its own operators often cannot say which tenant ran what, but it is not the only one; host-level telemetry in practice captures a small fraction of what actually happens. Where the record is thin, mediation and review both degrade quietly, and the first work of containment on those layers is making the hole observable at all.

14The containment scorecard

So here is the second tool, and the one I most want you to leave with. Notice what it actually asks about: egress, standing write, persistent state, credentials, monitoring. Those are not questions about the wall. They are questions about the holes. The scorecard grades your mediation, not your rung; a confidential VM with five unmediated holes scores worse than a plain container with none. Before you deploy an isolation boundary, answer honestly, and read the result as a map of where your residual risk will land, which holes are open doors, and whether the parts you cannot patch are parts you can live with.

Nothing here is stored or sent anywhere. It runs entirely in your browser. The questions are drawn from the failure modes in the record above and the containment properties that separate a patchable problem from a permanent one.

15If you’re buying. If you’re building.

The ladder and the fates together give you one procedure, and it forks at the last step depending on which side of the transaction you are on. Everything up to the fork is shared.

Locate the rung. Container, VM, confidential VM, or dedicated security processor, which one is actually running the workload? The marketing word is not the answer; the mechanism is. If you cannot get a straight answer to this question, that is already the finding.

Name the adversary the rung was built for, and the one you actually face. A container resists a clumsy neighbour, not an optimizer. A VM resists a neighbour, not the operator. A confidential VM resists the operator through software, not through the cache. If your adversary is above the rung’s pay grade, the isolation is decorative.

Find the fate of its likely failures. Interface bugs are patchable; shared-silicon side channels are architectural. This tells you whether a breach is a maintenance window or a property you will live with for the life of the hardware.

If you’re buying

Your job is to see through the pitch, and the pitch’s favourite move is the rung substitution: enclave language, confidential-VM economics. So ask the vendor three questions and listen for flinching. Which primitive does my workload actually run on? If the answer is a brand name, make them translate it to a rung. What does this boundary specifically not cover? An honest vendor can name the side channels and the shared resources without being cornered into it; a pitch cannot. When it fails, is the fix a patch or a hardware generation? That separates “we’ll push an update” from “you are exposed until you replace the fleet.” A vendor who answers all three plainly is selling you a rung and telling you which one. A vendor who keeps returning to “even we can’t see it” is selling you an adjective.

If you’re building

Your job is different: the rung is necessary and it is not sufficient, and the part that actually contains an optimizer is the one the staircase does not draw, the design you wrap around whichever rung you chose. Pick the rung your real adversary demands (an optimizer on shared silicon protecting high-value data pushes you toward the top, and the cost of the top is giving up multi-tenancy). Then build the containment the rung does not give you for free: ephemeral state so nothing persists between tasks, no standing write to shared resources, credentials scoped and short-lived, egress bounded rather than “controlled,” and an agent reviewing behavior over time to surface patterns for human judgment. The rung sets your floor. The design is what keeps the optimizer on it. The scorecard above is how you check whether you have built the design or only bought the rung.

So here is the whole piece in one move. We have been asking how strong the sandbox is, and that is an incomplete unit of analysis. The strength of the wall is one number among several, and rarely the one that decides the outcome. Two questions decide more, and they are the two this piece has been building: which failures are patchable and which are properties of the architecture, because that sets what a fix actually costs; and, separately, which capabilities you deliberately cut through the wall to do useful work, because the wall is only ever half the story. Containment lives in the architecture that governs those capabilities, mediates the openings, and reasons about what the permitted actions add up to over time. Ask that of any “secure AI” claim, of any deployment you are about to ship, and the friendly word stops hiding anything. That is the entire use of the model. It tells you what you are actually holding.

✓Check your understanding

Ten questions on telling the primitives apart and reading a containment by its holes. The wrong answers are the plausible ones.