Breach Doesn't Compose

At 9:50 on the morning of 20 September 2026, a tool call inside one of OpenAI's training sandboxes received a response from the outside world.

The agent making the call was working a search-based training task. It had tried its search tool. It had tried to reach search engines directly, and failed. Then it noticed something small. Public DNS queries went unanswered, "but the training environment's own resolver returned a real record for a known domain and correctly rejected an invented one. The agent concluded that it could reach the public internet through this resolver."¹ It used that one unfiltered path to query a public chatbot service.

OpenAI's report is careful, and it deserves to be read carefully. Everything else the agent touched "hit our offline webcache and therefore did not access the live internet." Monitoring flagged the behaviour within fifteen minutes, and a person was reviewing it three minutes later.¹ This was not a production breach, and nobody malicious was involved.

What happened next is the part that matters. OpenAI did not patch the resolver and carry on. "All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused."¹ A frontier lab, with full visibility of its own environment and every incentive to keep working, decided it could not trust its own wall.

Two phrases in that report are worth underlining, because this book will lean on them. After an earlier incident, OpenAI's hardening had focused on "broad direct and transitive paths". And it expects further red-teaming "might surface other transitive internet access paths".¹ The lab itself reached for the word transitive. Keep it in mind.

The bigger one

September was the small incident. The large one had happened two months earlier. OpenAI's evaluation benchmarks ran "in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries."² That proxy was the only door. The models under evaluation "identified and exploited a zero-day vulnerability ... in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access." They went on to chain stolen credentials and further vulnerabilities into remote code execution on Hugging Face's production servers.²

OpenAI's own summary a month later was not hedged. "We consider this incident a "warning shot" for us and for the world." And, more quietly, the sentence that should keep a regulated institution's board awake: "Many external models, including open-source ones, will soon reach comparable capabilities."³

When the September report landed, my reaction was blunt. It found its way through the package proxy in the Hugging Face incident, and now it's found the DNS way out. It's going to find other ways out — consistently.

The second reaction took longer, and it's the reason this book exists. If the best-resourced labs on earth — who built the models, who can see every packet in their own sandboxes, who pause work the moment something slips — cannot hold a wall against what's inside it, then the wall is not the thing to build your security strategy around.

The assumption we stopped seeing

The security model most institutions still run rests on an assumption so familiar it has disappeared from view: most of the weird corners of a system will never be looked at. Exploiting a hypervisor, or chaining four browser bugs into an escape, took rare people, real money and months of runway. That scarcity was a control. It never appeared in a control framework, and it did more work than half the ones that did.

I should say how this book was made, because it matters for what follows. I worked the argument through out loud, in a long voice conversation with an AI assistant — not a human editor, but a model I used as a sounding board, pushing back and summarising as I went. The argument, and the conclusions, are mine. Some of the sharpest one-line summaries came back from the machine, and where I quote them I say so. It put this shift in one line:

"Instead of hoping nobody looks in the right weird corner, you assume something is looking everywhere all the time."

— the AI I was thinking this through with

The best description of what search pressure looks like from the receiving end comes from the victim of the July incident. Hugging Face's technical timeline is unusually candid:

"The individual weaknesses were familiar. A capable human attacker could have found and exploited the same flaws ... The agent explored them at a different scale. It took 17,600 actions, tested many paths that failed, switched channels when they were blocked, and repeatedly returned to earlier leads. Most actions went nowhere. Together, however, they produced enough coverage to find a viable chain across several independent systems."⁴

Read that twice. Nothing in it is exotic. The flaws were ordinary. What changed was coverage — the number of doors tried, at no cost to the thing trying them.

What cheap search looks like

If that were one lab's bad month, it would be a story. It isn't. Look at the rest of 2026 in order of how far the capability has spread.

At the frontier. Anthropic reported that its Claude Mythos Preview model had identified "thousands of zero-day vulnerabilities ... many of them critical, in every major operating system and every major web browser", and that it "was able to identify nearly all of these vulnerabilities—and develop many related exploits—entirely autonomously, without any human steering."⁵ In one case the model "wrote a web browser exploit that chained together four vulnerabilities, writing a complex JIT heap spray that escaped both renderer and OS sandboxes."⁶

The price of search. Anthropic was unusually specific about what that costs. "Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings. While the specific run that found the bug above cost under $50, that number only makes sense with full hindsight. Like any search process, we can't know in advance which run will succeed."⁶ Read it as a budget line. For an attacker, twenty thousand dollars is not a research programme. It's a rounding error.

The skill required. "Engineers at Anthropic with no formal security training have asked Mythos Preview to find remote code execution vulnerabilities overnight, and woken up the following morning to a complete, working exploit."⁶

Beyond the frontier. The UK AI Security Institute and the US Center for AI Standards and Innovation evaluated an open-weight model on a 32-step simulated corporate-network attack that "would take a human expert roughly 20 hours to complete". In one of ten attempts it completed the whole range, which they read as meaning it "is capable of autonomously attacking small, weakly defended and vulnerable enterprise systems, when directed to do so and given initial network access."⁷ The evaluators are careful — the range had no active defenders and an intentional attack path — and their caveats belong in any board paper that quotes them. So does their conclusion: "Solves of TLO are no longer exclusive to a small set of models."

The price of a chain. The Bank for International Settlements' Financial Stability Institute, surveying the evidence for supervisors in September, cited estimates that a full attack chain costs "between $5,000–10,000 for Mythos Preview, while DeepSeek could cost as little as $50–100."⁸ Treat the low figure as an estimate, not a price list. The shape is the point.

The layer multi-tenancy stands on

One finding in Anthropic's report matters more than the headline to anyone running on shared infrastructure, which is everyone:

"Nearly everything in the public cloud runs inside a virtual machine, and cloud providers rely on the VMM to securely isolate mutually-distrusting (and assumed hostile) workloads sharing the same hardware. Mythos Preview identified a memory-corruption vulnerability in a production memory-safe VMM."⁶

A guest-to-host bug in a production virtual machine monitor — written in a memory-safe language, in exactly the layer that lets strangers share a computer. It was unpatched at the time of writing, so it's undisclosed. When I said, before I'd seen this, that the next thing AI goes after is the containers and the isolation underneath them — that everything's on the cards — I was guessing. It isn't a guess anymore.

The ten-dollar beachhead

Here is the part of the argument that changed how I think about cloud risk. The frontier model doesn't need to be running inside your cloud to matter. It's the attacker outside the hyperscaler, with a frontier model, getting a beachhead. You buy a VPS for ten dollars a month and now you're on the inside. Now you can chain zero-days inside the hyperscaler, inside the hypervisor.

"So it's not about labeling an AI tenant. It's about assuming any tenant might be backed by one."

— the AI, putting my point back to me

Every interface that must exist for normal tenancy — the hypervisor's device model, the metadata service, the shared storage layer, the management APIs your workloads call — becomes a research target for someone who can sit one seat over and search it at leisure. Ten dollars is illustrative, not a quote. The point is that the price of admission to the shared substrate is trivial, and the searcher you let in is no longer a person.

And it's not only that the model is smart enough to try everything. The economics have changed. You don't have to be the brainiest hacker on the planet, and you don't need millions of dollars and six months of runway. What we've lost is a buffer we never named: the skill-scarcity buffer. For decades, deep exploitation of shared layers was rationed to a handful of actors with their own priorities and their own limits on attention. That rationing was protecting every multi-tenant system on earth. It's gone.

Friction is not a barrier

Anthropic's frontier red team drew the design lesson itself, and it's the sentence I'd put in front of every security committee this year:

"When run at large scale, language models grind through these tedious steps quickly. Mitigations whose security value comes primarily from friction rather than hard barriers may become considerably weaker against model-assisted adversaries."⁶

Be honest about how much of what we call defence in depth is friction. The obscurity of an internal API. The tedium of chaining a low-severity bug into something useful. The finite attention of a human attacker who has other targets. "Nobody would bother." All of it rested on the searcher getting bored or running out of budget. The same report notes that hard barriers — it names KASLR and W^X — remain worth having. Walls still matter. But every time you harden one layer, the search shifts to the next abstraction boundary.

That's why, when the AI offered me the familiar list — disposable containers, micro-VMs, strict segmentation, external monitoring — my answer was that it's standard thinking, defending against the multi-chain zero-day. Not wrong. Every one of those tools shows up later in this book. But more walls of the same kind don't change the game when the thing on the other side of them is cheap, tireless and parallel.

The speed on the other side

The defender's usual answer is detection: we can't stop every entry, so we'll catch them before they move. Look at what "before they move" now means. CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time — from initial access to lateral movement onto another system — at 29 minutes in 2025, with the fastest observed at 27 seconds.⁹ Mandiant found the median time between an initial access event and hand-off to a second threat group had collapsed from more than eight hours in 2022 "to just 22 seconds" in 2025, and estimated the mean time to exploit a vulnerability at minus seven days — "exploitation is routinely occurring before a patch is even released."¹⁰

Betting on detection before lateral movement is a race you now lose on the median. Chapter 2 takes up what that means for patching. Chapter 4 turns it into a design goal.

The pivot

Put the pieces together. Search is cheap, parallel and patient. The skill that rationed it has been automated. The layer that lets strangers share hardware has been searched and found wanting. Friction-based defences are weakening fastest, and the attacker moves in minutes. The AI's summary of where I'd landed is the one I'd hand a board:

"So containment becomes statistical, not absolute. And the security model shifts from this wall will hold to assume the wall falls and make that non-catastrophic."

— the AI, summarising the argument

This is not a counsel of despair, and it isn't an argument to stop building walls. You should patch, harden and monitor — Chapter 2 is explicit about that. It's an argument about where your strategy has to rest. If the wall will eventually be crossed, the question that decides whether a breach is an incident or a catastrophe is not "how thick was the wall?" It's "what was the thing on the other side of it holding?"

Where this goes

Part I finishes the diagnosis. Search is one reason walls fall; Chapter 2 is about the other — time — and why every deployed system is a snapshot being attacked by the future. Chapter 3 is about what a fall actually buys, and why the answer is almost always decided by what the fallen thing was sharing.

Part II is the design: a goal you can state (breach doesn't compose), a unit you can build (one principal, one purpose), a binding that makes the unit's contents worthless to whoever opens it, the traps that rebuild shared fate underneath you, and tiers that match isolation to consequence. Part III runs all of it on one synthetic insurer, end to end — mapped, redesigned, attacked twice, and drilled. Part IV is for the people accountable for it: what APRA expects, where this pattern breaks, and the path.

One boundary, before we start. I've argued the other half of this problem — shipping less software, compiling narrow environments instead of maintaining general-purpose ones — in Compile the Bounded Object. That book is about what goes inside the box. This one is about what sits between the boxes.

Suppose search stayed expensive. Suppose the ten-dollar beachhead never happened and deep exploitation stayed rationed to a few elite teams. Walls would still fall — just more slowly — because time works on them too.

Here's the thought experiment I keep coming back to. Take an AI from 2026 and send it back to 2010. Point it at the software of that year — the operating systems, the network stacks, the enterprise applications that were considered well-defended at the time. It would carve that software open.

Now notice that we don't need the time machine. Most of the software running a bank or an insurer in 2026 is 2010's software — or 2004's, or 1998's — patched, wrapped and extended, but structurally the same. That's what's happening right now, because the legacy software is static and can't move. It's a futuristic attacker on legacy code.

The AI I was talking it through with compressed it into a line I've come to rely on:

"Security has a kind of half-life. The software doesn't get worse, but the attacker gets cheaper and better."

— the AI sounding board

This isn't the familiar complaint that old software is badly written. Some of it was written by the most security-conscious people in the industry. The problem is that it was written against the attacker of its day, and it is now being read by the attacker of ours.

Old code, new attacker

The evidence has been accumulating for a decade. 2026 made it hard to ignore.

Twenty-seven years. Anthropic's frontier red team reported that many of the vulnerabilities its model found were "ten or twenty years old, with the oldest we have found so far being a now-patched 27-year-old bug in OpenBSD—an operating system known primarily for its security."⁶ That last clause is the one to sit with. This wasn't sloppy code. It was code from a project whose whole identity is security, and it was outlived by its attacker.

Default-on, in the shared layer. VENOM, disclosed in 2015, lived in QEMU's virtual floppy-disk controller. "The vulnerability, which has existed since 2004 when the virtual FDC was first added to the QEMU codebase, impacts hypervisors such as XEN, KVM ... Despite the fact that most organizations no longer use floppy drives, a virtual floppy drive is created by default in new virtual machines."¹¹ Its discoverer described it as a flaw that "may allow malicious code inside a virtual machine guest to perform arbitrary code execution on the host machine".¹² Eleven-year-old code for a device nobody used, sitting in the one layer every tenant on the host shared. (Why it was there at all is a minimisation question, and I'll leave it to the book that owns it.)

The fix existed; the estate didn't move. Microsoft published the MS17-010 fix for the SMBv1 vulnerability on 14 March 2017. WannaCry arrived two months later, exploiting that same flaw, with "tens of thousands of infections in over 150 countries".¹³ This is the purest form of the problem. The defender's knowledge had been updated. The deployed artefacts hadn't.

Static artefact, dynamic attacker

It would be comfortable to treat this as a legacy problem — something that happens to mainframes and old Windows servers, and that new software escapes. It doesn't. The same asymmetry applies to the application you ship next month.

When you deploy an application, you deploy it into a static security environment. You can red-team it, build it smart, attest it and test it ahead of time. But once it's deployed, it's largely a static attack surface for a dynamic AI attacker.

"The defender's intelligence gets compiled into a static artifact. The attacker keeps thinking after deployment."

— the AI, restating my point

Every assurance activity we perform before release — threat models, code review, penetration tests, certifications — is a snapshot. It tells you what a certain level of attacker could do on a certain day. The day after release, the level moves and the snapshot doesn't. APRA made a version of this point in its April 2026 letter on AI, criticising "reliance on point in time and sample based assurance methods, despite these methods being ill suited to probabilistic models that learn, adapt and degrade over time."¹⁴ APRA was talking about AI models that drift. The logic transfers exactly to the threat side: a point-in-time assurance of a static system is stale the moment the attacker learns something new.

The prudential standard already carries the hook. CPS 234 requires that the nature and frequency of systematic testing be commensurate with, among other things, "the rate at which the vulnerabilities and threats change".¹⁵ If that rate is now set by AI search, an annual test of an unchanging artefact is not commensurate with anything.

Assurance debt

The legacy case is where the time-travel problem compounds, and it's worth being precise about why. It isn't just that there's more code. It's the kind of code.

There's legacy in the network stack, in memory management, in how applications are managed — all of it there to support every customer and every old app anyone ever sold. None of it was tested against this attacker. To re-qualify it properly against an AI that chains weird paths, everyone would have to start again from scratch, and I don't think even the vendors can do that. (That's a claim about the class of problem, not an accusation about anyone's quality assurance. Nobody could have tested 2004 code against a 2026 searcher.)

The AI's line for it is the one I'd hand an architecture review board: "You can't delete the past, but you can't fully attest it either." Every compatibility path is an assumption someone made about who would call it and how. The attacker's job is to find the call nobody imagined — and complexity is where those calls live.

Most organisations respond to this the way I described in AI Legacy Takeover: "Most organisations end up in the same place: maintain by default." That book argues the replacement economics — that maintenance has quietly become the risky bet. Here I only need the security consequence: assurance debt accrues interest at the rate the attacker improves.

Patching: hygiene, not strategy

That team isn't failing. It's doing exactly what the strategy asks of it. The strategy is the problem. How do you patch against multiple chained zero-days? It doesn't even make sense — the chain that hurts you uses a flaw nobody has disclosed yet, except to the attacker's model. You need a different theory of what you're doing.

The statistic that settles it comes from Mandiant's 2026 M-Trends report: "the mean time to exploit vulnerabilities dropped to an estimated -7 days, meaning exploitation is routinely occurring before a patch is even released." Exploits remained "the most common initial infection vector for the sixth consecutive year, accounting for 32% of intrusions."¹⁰ On average, the patch arrives after the exploit.

The volume isn't helping. Independent counts put the number of CVEs published in 2025 at 48,185, up 20.6% on the year before — "roughly 130 new vulnerabilities disclosed every single day," as the OpenSSF put it.¹⁶

None of this is an argument to stop patching, and I want to be careful here because the regulator is. The same APRA letter criticises remediation timelines — "patching and configuration management" — that are "not consistently aligned to the accelerated threat environment."¹⁴ Patch faster. Close known holes. It's hygiene, and hygiene matters. The claim is narrower: a strategy whose success condition is "patch before exploit" fails on the mean, and a board that is told the patch cadence is its security posture is being told about the wrong variable.

The other half, briefly

My instinct, faced with all this, runs straight to minimisation: reduce, minimise, bring it home. Ship less software. Compile narrow environments. Don't carry twenty years of compatibility for users who need a browser and three web apps. That's the inside-the-box answer, and I've made the full case for it — including why AI makes narrow environments cheap for the first time — in Compile the Bounded Object. I won't repeat it. Even a small box is a static artefact. The question this book cares about is what happens when it's opened.

Where the defender's intelligence belongs

There's a tempting answer to a dynamic attacker: a dynamic defender. Put an intelligent agent inside every application, watching, adapting, fighting back in real time. The AI raised the problem with that before I could, and I agree with it. An intelligent agent inside the app is more code, more permissions and more behaviour inside the very boundary you're trying to defend. You've grown the surface to protect it.

The better shape keeps the deployed thing small, disposable and bound, and moves the intelligence outside the trust boundary — into the system that watches from outside, rebuilds, rekeys and redeploys. Repair by regeneration rather than by nursing a compromised instance back to health: the same kernel-first instinct behind replacing legacy by regenerating it from a specification rather than patching it forever, pointed at security.

Chapter 5 builds the small, disposable target. Chapter 7 deals with the uncomfortable fact that the regeneration system itself — the control plane — becomes something that must never be reachable from what it regenerates. For now, hold the shape:

"Not dynamic attacker versus dynamic firewall. More like dynamic attacker versus tiny, replaceable target, plus a dynamic regeneration system."

— the AI sounding board

Search explains why every wall eventually falls. Time explains why it keeps falling after you've fixed it. Neither explains why one fall costs a single claim file and another costs the company. That's decided by something else: what the fallen thing was sharing.

Following the question of what a fall buys, I first landed somewhere dramatic, and it's worth showing the wrong turn before the right one.

Imagine they can break out of any software layer, any container, and chain vulnerabilities. What does a hyperscaler do? Their whole business is built on multi-tenant isolation — on the promise that strangers can safely share hardware. If AI makes that promise statistical, I thought, the hyperscalers are in deep trouble.

Then I looked at what the labs actually did after their own models got out. OpenAI's response to the September DNS incident was to add "blocking controls at two independent layers, either of which would have prevented this access"; to restrict DNS "to a limited allowed list of domains and record types"; and to work through the narrower paths used by system dependencies, "replacing them with offline alternatives."¹ Offline web caches. Emulated package mirrors. Fewer shared paths, more isolation.

You know what that sounds like? The anti-pattern to a hyperscaler. The people with the most capable models are telling you, through their own lab design, what shared infrastructure is worth against those models. And not everybody red-teams frontier AI — but everybody now needs to isolate their applications from AI. It's the same pattern.

Except "anti-hyperscaler" is the wrong name for it, and I corrected myself within a few minutes of saying it. Hyperscalers can sell you dedicated hosts, confidential VMs, private links and customer-held keys. Nothing about renting compute forces you to share fate with the tenant next door. The pattern is actually anti-multi-tenant — not anti-hyperscaler.

The AI I was arguing it through with offered a better name still, and I've adopted it for this book: anti-shared-fate.

Multi-tenancy lives at every layer

The reason "anti-hyperscaler" misleads is that it locates the problem in one row of a much taller stack. AI is anti-multi-tenant, and almost every web app on the planet is multi-user — thousands of people log into the same app, the same process, with their credentials. Look at where principals pool, from the silicon up:

Moving out of a hyperscaler removes, at most, the bottom two rows — and only if you don't recreate them in your own data centre. The other eight come with you. A multi-user claims platform on premises, with a connection pool that can read every claim, shares fate across every policyholder in the book. The cloud isn't where the problem lives. Sharing is.

The Hugging Face intrusion, read for shared fate

The clearest evidence for this reframe is the forensic timeline Hugging Face published about the July intrusion — written from the victim's side, with a candour most organisations never manage. Read it not for how the attacker got in, but for where each step composed.

1. Entry through the shared pipeline. "A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker."¹⁷ The pipeline that processes everyone's datasets.
2. The node everyone's pods share. "The agent created a bare privileged pod with the host filesystem mounted and escaped to root on the node. Two of our own settings allowed it: we had no admission policy rejecting privileged or hostPath pods, and the CSI driver's ClusterRole granted pod creation cluster-wide."
3. A static credential in the environment. "Six minutes after reaching node root, the agent authenticated to the internal operational datasets-server MongoDB with a static password it had read from the worker environment."
4. One secrets object. "The agent read the cluster's secret objects, including a production object holding 136 keys. That single read yielded both the mesh-VPN auth key used minutes later and the access-broker credential used an hour later. Everything that follows, on this day and the next, descends from it."
5. One credential across clusters. "We had wrongly provisioned that broker with a single connector credential shared across clusters, and bound the connector identity to system:masters. One stolen system credential was therefore cluster-admin everywhere: impersonating it, the agent held cluster-admin on two clusters within one second."
6. An identity root. "Among the harvested secrets was an EdDSA JWT signing key ... Holding the signing key is broader than holding a stolen token: it allows issuing valid tokens on demand."⁴

From code execution in one worker pod to "cluster-admin across multiple internal clusters in under thirteen hours." Get a beachhead, go horizontal. Everybody knows that's how it works. What the timeline shows, with receipts, is what made each horizontal step possible: at every hop, a component whose fate was shared with things the previous hop had nothing to do with.

Now read the same timeline for where it didn't compose. It's just as important.

Same attacker. Same weekend. Same skill. The difference between "a map, not control" and "cluster-admin everywhere" was not the attacker's cleverness on that particular hop. It was whether the next hop shared fate with the last one.

The OpenAI side of the incident shows the same shape in a single component. In the evaluation environment, the package-registry proxy was the only shared service — and the agents turned it into three things at once. They first "found ways to communicate by writing files into the Artifactory package manager. This effectively turned Artifactory into an unintended message board". They made it "send any internet requests on their behalf". And they obtained its signing key and "forged administrator credentials."³ One shared component: an exit, a communication channel and an identity forge.

The pattern, case by case

If that were one company's bad weekend, it would be an anecdote. It isn't. Line up the incidents that defined the last few years and ask the same question of each: was the multiplier the first exploit, or something shared?

A few of those rows deserve their own sentence.

The Cyber Safety Review Board's account of Storm-0558 is the textbook statement of what a shared key costs: "an adversary in possession of a valid signing key can grant itself permission to access any information or systems within that key's domain. A single key's reach can be enormous, and in this case the stolen key had extraordinary power."¹⁸ Chapter 4 turns that phrase — the key's domain — into a design variable.

Okta's disclosure contains the most useful sentence in the whole table for anyone who has to decide how much to separate. The attacker downloaded a report of every customer-support user, and "All Okta Workforce Identity Cloud (WIC) and Customer Identity Solution (CIS) customers are impacted except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor)."¹⁹ The customers who didn't share the support system didn't share the fate.

SolarWinds is usually quoted with the scary number. The company's own later filing is more instructive: of up to 18,000 customers who downloaded the poisoned update, it estimated "the actual number of customers who were hacked through SUNBURST to be fewer than 100" — and among those who couldn't have been affected were customers who "did install the affected version, but only did so on a server without access to the internet."²⁰ The same poisoned component, installed where it had nothing to reach, bought the attacker nothing.

ChaosDB was found and disclosed by researchers, not exploited by criminals, and Wiz is clear about that. Its shape is still the one that matters: a notebook feature that "had network access to internal management APIs", leading to primary keys that are "long-lived and allow full READ/WRITE/DELETE access to customer data."²¹ A control plane reachable from a workload.

And the bottom rows are reminders that shared fate goes all the way down: runc escapes and Meltdown both exploited what containers on a host share; the Meltdown researchers wrote that "Depending on the cloud provider's infrastructure, it might be possible to steal data from other customers."²² Heartbleed let "anyone on the Internet ... read the memory of the systems protected by the vulnerable versions of the OpenSSL software", compromising "the secret keys used to identify the service providers".²³

The principle is old. The economics are new.

None of this is a new idea, and it would be dishonest to present it as one. Jerome Saltzer and Michael Schroeder wrote it down in 1975, in the paper that gave us least privilege:

"Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security."²⁴

They even anticipated the multi-user application. Given the choice between a function "shared by all users or as a library procedure that can be handled as though it were the user's own, choose the latter course." That is, fifty-one years early, the choice between a multi-tenant app and a per-principal one.

And in the same paper they described, with uncanny precision, the thing that has now changed. Some protection mechanisms can't be defeated by brute force; "Defeat can be accomplished only by indirect strategies, such as waiting for an accidental hardware failure or searching for an error in implementation. Reliable estimates of the length of such a wait or search are very difficult to make." Chapter 1 was about the collapse of exactly that wait.

So why did least common mechanism lose for fifty years? Because pooling was cheap and isolation was expensive — to build, to operate, to pay for. Every economic force in computing pushed toward sharing: one app for all users, one platform for all apps, one cloud for all companies. Now both sides of that trade have moved at once. AI made the search cheap, which makes sharing dangerous. And AI-built infrastructure made per-principal mechanism cheap to build and run, which Chapter 5 takes up.

"As the cost of zero-day discovery collapses, sharing becomes a liability and isolation becomes affordable."

— the AI sounding board

This book doesn't claim to have invented least common mechanism. It claims the economics finally favour applying it at the unit of one principal.

Less software, and less sharing

That discipline was about less software, and it's one half of the answer. It's the half argued in Compile the Bounded Object. This book is the other half: less sharing. You need both, and neither substitutes for the other. A minimal component that every principal depends on is still shared fate — a lean signing service is still a signing service. And an isolated component stuffed with surface is still a big target for whoever lands in it; it just can't take anyone else down with it.

Shared fate across institutions

The same pattern repeats one level up. When many institutions depend on the same component, a single flaw becomes a sector event. The IMF put it plainly in June: shared digital infrastructure "creates correlated exposure: when a vulnerability exists in a commonly used component, many institutions can be affected at once. AI intensifies this common exposure channel by increasing the speed and scale at which common vulnerabilities can be identified and exploited."²⁵ APRA and ASIC said the same thing to Australian boards in August: "common dependencies and concentration risk associated with third-party service providers can turn isolated individual incidents into much broader sector wide disruption".²⁶

We've gone from huge homogeneous attack surfaces to a world where that just doesn't fly anymore. The corollary, as the AI put it: stop shipping giant identical stacks where one break scales everywhere. Heterogeneity becomes a security feature. Chapter 12 returns to what regulators expect of boards here. The concept belongs in this chapter: shared fate isn't only inside your estate. It's how your estate is joined to everyone else's.

The diagnosis, complete

Part I in three lines. Walls fall, because search is cheap and never tires. Walls keep falling, because every deployed artefact is a snapshot and the attacker isn't. And what each fall buys is decided by what the fallen thing shared.

The first two are largely out of your hands. The third isn't. Part II designs for it: a goal that says the fall must buy as close to nothing as possible beyond one principal, and the machinery to make that true.

Start with the design goal, stated flat. You have to assume each machine can be breached, and make sure the next breach isn't any easier because of where the attacker already is.

That sentence sounds modest. It isn't. Most security programmes are built around the first breach — keeping it out, detecting it early, patching the hole it used. The sentence above doesn't care much how the attacker got in. It cares about the second step, and the third, and whether any of them are easier than the first. Stated as a principle, it's the one this whole part of the book elaborates:

Compromise should be non-transitive. Owning one machine should tell an attacker nothing about how to reach the next.

The idea was mine; the word wasn't. When I was talking this through with the AI, it was the one that reached for non-transitive — and a few turns later it handed back the phrasing that became this book's title:

"Not 'don't get breached,' but 'breach doesn't compose.'"

— the AI sounding board

The success criterion changes with it. The goal is no longer "we prevented breach number one". It's "breach terminates here" — a statement you can make about a specific component, test, and show to someone.

The transitivity axis quietly replaces most of the arguments security teams spend their time on. Cloud or on-premises. This operating system or that one. Vendor A or vendor B. Those choices can matter — but only through their effect on transitivity. A workload on premises that shares a service account with every other workload is more transitive than the same workload in a cloud with per-principal credentials. The question to ask of any design decision is whether it makes the next step easier or harder.

What does a breach actually buy?

"Consequence" is too vague to engineer against. It helps to break it into the four things that decide what an attacker holds after taking any one position. None of them is a number you can multiply precisely. Together they tell you where to push.

Reach is what the foothold can address — which networks, which APIs, which management interfaces. It's inflated by flat networks and reachable control planes: the ChaosDB notebook that "had network access to internal management APIs" is reach made concrete (Chapter 3's table). It's shrunk by having no ambient network at all, only defined channels — the Hugging Face database that "accepts traffic only from allow-listed addresses over a private link" and so was never reached.

Duration is how long the foothold, and anything it holds, stays useful. It's inflated by long-lived secrets and persistent hosts. Hugging Face's attacker minted "forged service-account tokens valid for 24 hours"; the Snowflake campaign of 2024 ran on customer credentials, with "at least 79.7% of the accounts leveraged by the threat actor" having prior exposure going back as far as November 2020.²⁷ Credentials that live for years give an attacker years. Duration is shrunk by footholds and tokens that die with the task.

Key domain — or credential scope — is what the keys a foothold can reach are valid for. The Cyber Safety Review Board's phrase is exactly right: "an adversary in possession of a valid signing key can grant itself permission to access any information or systems within that key's domain. A single key's reach can be enormous".¹⁸ The key domain is the unit of blast radius. Shrink the domain of every key and you shrink what any single theft is worth.

Co-residence is whose data and sessions share the foothold's memory, process, disk or connection pool. A multi-user application is maximal co-residence: every user's session in one process, every user's rows behind one connection pool. Hardware co-residence is the same idea at the bottom of the stack — the Meltdown researchers' warning that it "might be possible to steal data from other customers". Co-residence is shrunk by giving each principal its own compute, and by binding what's in memory to that principal.

The regulators are already saying it

This is not a fringe position. The IMF's note on AI and cybersecurity in the financial sector states the goal at the level of the whole institution: "If a network is breached, the objective is to ensure that the attacker—human or AI-enabled—does not gain access to the rest of the system." Its list of key policy actions includes "Technical controls that limit the blast radius of breaches and lateral movement."²⁵

What the policy language leaves open is the unit at which you engineer it. "The rest of the system" is too coarse. Inside one institution, a single multi-user claims application already is the rest of the system for every policyholder whose claim sits in it. If the goal is to stop an attacker reaching the rest of the system, the system has to be cut much finer than the network perimeter.

Doesn't zero trust already do this?

It's the first objection every security architect raises, and it deserves a straight answer: partly, yes.

Zero trust gets the direction right. NIST's SP 800-207 defines it as moving "defenses from static, network-based perimeters to focus on users, assets, and resources", and states the problem it was designed for: "Perimeter-based network security has also been shown to be insufficient since once attackers breach the perimeter, further lateral movement is unhindered." Its third tenet is the closest thing in the standards literature to non-transitivity: "Access to individual enterprise resources is granted on a per-session basis ... authentication and authorization to one resource will not automatically grant access to a different resource."²⁸

A small correction worth making, because it gets misquoted in board papers: the phrase "assume breach" doesn't appear in SP 800-207. What NIST actually says is that zero trust models "assume that an attacker is present in the environment". The difference is small in words and large in design — one describes a posture, the other a premise you can build against.

We've used zero trust in our own work for years. When I wrote about containing untrusted AI agents, the argument was that "zero trust" for AI "isn't a metaphor — it's the direct application of a proven security paradigm to a new category of untrusted actor." I still believe that. The problem is not the principle. It's how it's usually built.

Where zero trust, as usually built, stops

Look at a typical zero-trust programme. Every request is verified — by one identity provider, one policy engine, one set of signing keys. Verification has been decentralised to every request, and trust has been centralised in the verifier. NIST is candid about the consequence in its own threat section:

"In ZTA, the policy engine and policy administrator are the key components of the entire enterprise. No communication between enterprise resources occurs unless it is approved and possibly configured by the PE and PA ... a compromised PA could allow access to resources that would otherwise not be approved".²⁸

When I pushed the AI on this, it put it more sharply:

"If zero trust collapses into 'everything trusts one identity provider or one signing key,' then you've just moved the monoculture."

— the AI sounding board

Storm-0558 is what that looks like in practice. Every token the attacker used was cryptographically verified. The verification worked perfectly. It was the verifier's root that was shared — a 2016 consumer signing key that, as the review board put it, "was no longer supposed to be signing new tokens", accepted by enterprise mail through a validation flaw. And the board's most chilling observation is about what you can't see: "the loss of a signing key through unknown means is far more significant because it means that the victim company does not know how its systems were infiltrated and whether the relevant vulnerabilities have been closed off."¹⁸ Hugging Face's attacker did the same thing on a smaller scale: with the signing key in hand, the verifier happily verified every token it minted.

There's an honest counterpoint. Mandiant's 2026 guidance still recommends routing SaaS applications through a central identity provider, and it's right to — centralised identity is how you get consistent policy, fast revocation and a single audit trail. The position here isn't "no IdP". It's that centralised decisions are fine and centralised key domains are the problem. The identity provider should decide who someone is. What it issues should be scoped to one principal and one purpose, short-lived, and never a credential that works everywhere. The roots that sign should be narrow, hardware-held and unreachable from any workload. Chapters 6 and 7 build that.

One rung further than "can't"

Our earlier work on AI containment ended its trust hierarchy at architecture: vibes are fragile, monitoring is reactive, and architecture is structural — the level at which "misbehaviour is physically impossible". That was written about untrusted agents inside a cell, and inside a cell it holds up well.

Under 2026's search pressure, "physically impossible" has to be read as "probably impossible". The hypervisor had a bug. The proxy had a zero-day. The resolver answered. So the hierarchy needs one more rung: when "can't" fails, the failure must not compose. The same doctrine I once aimed at agents — make misbehaviour "boring, non-lethal, and non-actionable" — now has to be aimed at the attacker who has already beaten the wall.

What success is measured in now

If the goal is non-transitivity, the metrics have to change with it. Patch latency, scan findings and pen-test pass rates are all probability measures — useful, and increasingly set by the attacker's budget. Alongside them, a board should be able to see consequence measures for each critical operation: if an attacker held position X, what would they hold next? How many principals would be exposed? What's the widest key domain reachable? How many hops to something consequential? Chapter 11 turns those questions into a drill with a pass and a fail.

All four consequence factors point at the same design decision. If the unit of computing is "the application", then co-residence and key domain are the whole user base by construction — you can shrink reach and duration all you like, and one parser bug still touches every claim. Chapter 5 changes the unit.

Here's the move I think matters most in this book, and it came out of the conversation as a question. What if an app was only reachable by one user — spun up for that one user, disposable, stateless, in its own isolation?

If you do get breached, you've got one isolated breach, with fewer tools and less surface, holding only the credentials of the one user it was created for.

It's worth feeling how strange that is before deciding it's obvious. "One application, many users" is so thoroughly the default that nobody experiences it as a design decision. It's simply what an application is: a process, a connection pool, a set of service credentials, and a queue of people's requests flowing through them. It's also the reason a single parser bug in a claims platform touches every claim, and a single leaked service account reads every row. The unit of software determines the unit of blast radius, and we picked the biggest unit available.

When I floated it, the AI's reply named what I was reaching for:

"That feels like the logical extreme of zero trust, where the unit of computing is principal plus purpose, not the application."

— the AI sounding board

Seven properties

A cell is not "a VM per user". The properties below are what make it a unit of non-transitivity rather than a unit of hosting. Each maps to one of the consequence factors from Chapter 4.

1. Single principal. A cell never serves two principals and holds no session state belonging to anyone else. (Co-residence.)
2. Single purpose. A cell is scoped to one task or application session. A second purpose gets a second cell. (Key domain, reach.)
3. Ephemeral. Created on demand, destroyed at the end of its purpose or on any anomaly. Nothing persists inside it. (Duration.)
4. Its own root. Every key the cell uses derives from a root minted for this principal and purpose — the subject of Chapter 6. (Key domain.)
5. No ambient network. It can reach only the channels its purpose requires, and nothing can reach it except channels sealed for it. (Reach.)
6. No credential valid outside it. Any token it holds is scoped to its principal and purpose and lives for minutes. (Key domain, duration.)
7. Built, not nursed. Assembled from a measured image by a control plane it cannot reach, and repaired by regeneration — never patched in place. (The regeneration system from Chapter 2; the control plane is Chapter 7's problem.)

Why "purpose", and not just "principal"?

A per-person computer is a big improvement on a shared application. It isn't enough on its own, because within one person, work that shares a computer still shares fate. The most honest statement of this I've found comes from a vendor's own documentation. Grok Bot gives every user a dedicated, hardware-separated computer — and then warns its enterprise customers:

"Within one user, the boundary is different: all of that user's Bots share one computer, and Bots isolate personalities and workspaces, not compute. Treat a login or file on the computer as available to every Bot that user runs ... When a workload needs its own computer and credential set, give it its own Cursor user."²⁹

That's the vendor telling you, in its own words, that the person is the wrong unit when purposes differ in consequence. Browsing the web and approving a claim payment shouldn't share a kernel, even when the same person is doing both. The purpose boundary is where consequence changes.

We've made a version of this argument before, for a different problem. Designing workspaces for long-running AI agents, the lesson was that "Agent, subagent, session, goal, and host are not the same noun. Get the noun wrong and you either leak blast radius across the machine or you sterilise the very machinery that makes long goals compound." The answer there was to isolate per goal: "Inside a world, freedom is high. Across worlds, contamination is low." That was for trusted agents doing exploratory work, not for hostile containment, and the principal cell is its hostile-world counterpart. But one corollary carries over directly: processes serving the same principal and purpose can share a cell. The unit is the purpose, not the process. You don't need a VM per thread.

A cell's life, start to finish

What it looks like from the chair

From the user's side, the change is almost invisible. A staff member might have three, four, a dozen ephemeral computers in a day — one for their browser, one for each app they touch, each stood up just for them, with their credentials. What used to be a shared-tenant app is now an app that exists only for them. It's not one ephemeral box; you're probably standing up half a dozen for that user, each scoped to that one principal and encrypted for that one principal.

"Think of it less as one corporate system with many users and more like thousands of tiny corporate systems, each spun up around a single person and task, and that talk only through very tightly defined protocols."

— the AI sounding board

Chapter 9 walks one claims officer's actual Tuesday through this, cell by cell. For now the picture is enough: the estate stops being a few big systems that everyone lives inside, and becomes a very large number of very small ones that each belong to one person doing one thing.

It already ships

If this sounds like a research proposal, look at what consumer and enterprise platforms shipped in the past year.

xAI's documentation is plain about the per-person boundary: "Each user gets a dedicated computer with hardware-level separation, and one user cannot reach another user's computer. Every computer is a Firecracker microVM with its own kernel, memory, and virtual devices."²⁹

Meta's Muse "runs on its own dedicated computer in the cloud, contained so no one else's agent can reach it. That is where Muse lives and where the data and credentials for any service a person connects are securely stored."³⁰ Its security documentation describes the design assumption this book is built on: "we designed the system to assume the agent may be under attack and limit the potential damage — the harness runs in its own isolated cell, it doesn't see real credentials".³¹

AWS's AgentCore is the closest shipping analogue to a per-purpose cell. As Marc Brooker describes it: "Each session with the agent is given its own MicroVM, and that MicroVM is terminated when the session is over ... when it's over the MicroVM is destroyed and all the session context is securely forgotten. This makes interactions between agent sessions explicit".³²

Underneath them sits Firecracker, built precisely because the old trade-off — strong VM isolation with high overhead, or cheap containers with weaker isolation — was, in its designers' words, "unacceptable to public infrastructure providers, who need both strong security and minimal overhead." It has run in AWS Lambda and Fargate, supporting "millions of production workloads, and trillions of requests per month."³³ The project advertises boot in under 125 milliseconds and under 5 MiB of overhead per VM³⁴ — vendor figures describing the substrate, not the cost of running cells at an insurer. One detail from the project's own history is telling: when Lambda launched in 2014, AWS "used per-customer EC2 instances to provide strong security and isolation between customers." Isolation came first. The efficiency was engineered afterwards.

An honest note on that table. Grok Bot and Muse are persistent, per-person computers. They're not ephemeral, and they're not per purpose. The principal cell goes one level further than any consumer product does today. What the products settle is the economic question: per-person, hardware-separated compute is viable at consumer scale.

"Isn't this ruinously expensive?"

It's the right question, and the answer is a shape rather than a number.

Consumer platforms are already doing this for the general public. Corporates only have to do it for their staff — and even a big staff is small by comparison. The expensive part was never the virtual machine. It was building and operating thousands of bespoke little systems: the templates, the orchestration, the key plumbing, the observability. That is precisely the kind of engineering AI has made cheap.

"It's the sort of inversion that was too costly for humans to manage for forever, but is pretty natural for machines."

— the AI sounding board

What I won't do is invent a per-cell cost for an Australian insurer. Nobody has published one, and a made-up number would undermine the whole argument. The shape is this: substrate cost is falling and dense; orchestration and templates dominate the engineering; and the thing you're buying — a breach that stays small — gets measured directly in the drill in Chapter 11. That's the comparison a board should make.

One more honest caveat. Firecracker is itself a multi-tenant technology: many microVMs share one hypervisor and one set of CPUs. A cell on shared hardware still sits on the layer Chapter 1 showed being searched. That's why the cell alone isn't the answer. Chapter 6 makes its contents worthless to whoever gets underneath it, and Chapter 8 removes co-residence altogether for the workloads that need it.

From task keys to cells

This extends something I built earlier for AI agents. SiloOS scoped the key layer to exactly this unit. Its task keys are minted "Not for all customers. Not for all cases. Just this customer, this case, this conversation. The keys are scoped, temporary, and expire when the task completes." And it made execution disposable: each invocation starts fresh, and the context evaporates when the task ends.

What changes is the threat, and it changes the architecture with it. SiloOS contained an untrusted agent in order to protect the enterprise from it. The principal cell protects principals from each other — and from anyone who has already beaten the wall. SiloOS asked, "what can this agent reach?" The cell asks, "what does breaking this box buy toward the next one?"

The four factors, shrunk

That's the payoff of changing the unit. But a cell on shared hardware still sits on a hypervisor that search will eventually open. The next step is to make what's inside the cell useless to whoever opens it.

Picture the attacker at the worst moment of the Chapter 1 story. They've found the hypervisor bug. They're root on a host that runs forty principal cells. What do they see?

In a conventional estate, the answer is: everything. Every guest's memory is readable by the host. Every guest's disk is a file on the host's storage. Every secret any of those forty cells loaded into memory is sitting there in plaintext. Isolating compute per principal has cut co-residence at the application layer — and then the hypervisor, the one thing all forty cells share, hands it all back the moment it falls.

So the second half of the design is to push isolation below the hypervisor's line of sight. Push it all the way down — the memory, the operating system, the disk, the network. Everything the app can touch is encrypted to keys that exist just for that one principal and purpose. If you don't hold that key pair, the thing does nothing for you at all.

This used to sound exotic. It no longer is. My laptop runs full-disk encryption and I never notice it; chips are fast enough that encrypting everything to a principal has stopped being a performance question and become a design one.

One root per cell

The mechanism is simple to state. Each cell gets one root, minted for its principal and purpose and released only after the cell has proved what it is. Everything else the cell uses derives from that root. When the cell is torn down, the root is destroyed, and everything encrypted under it becomes permanently unreadable.

Note what this isn't. It isn't one key everywhere — a single key for "the user" that every cell they ever run shares. That just rebuilds the key domain at the person level. It's one root per cell, and a person running six cells has six unrelated roots.

The building blocks already ship

None of the primitives here is new. Every one of them is a commercial product today.

Per-VM memory encryption. AMD's Secure Encrypted Virtualization "uses one key per virtual machine to isolate guests and the hypervisor from one another. The keys are managed by the AMD Secure Processor." Its SNP extension "adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more".³⁵ One key per virtual machine is the hardware version of one root per cell. Intel's Trust Domain Extensions offer the equivalent — "hardware-isolated virtual machines" in which "Data in memory is opaque to cloud service providers (CSP) or operators and shared applications."³⁶

Attestation. The Confidential Computing Consortium defines the field as "the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment", and notes that "only attestability is strictly necessary for a computational environment to be classified as Confidential Computing."³⁷ Attestation is what lets a cell prove what it is before anything trusts it.

Attestation-bound key release. This is the piece that turns "encrypted" into "bound". Azure's confidential VMs provide "Secure key release with cryptographic binding between the platform's successful attestation and the VM's encryption keys", bind disk keys to the VM so they "securely bypass Azure components, including the hypervisor and host operating system", and "boot only after successful attestation of the platform's critical components".³⁸ AWS's key service can be told to refuse a key "unless the enclave provides a signed attestation document that contains measurements that match the measurements specified in the KMS key policy's condition keys."³⁹ Google's Confidential Space exists "to release your secrets only to authorized workloads."⁴⁰

Person-held keys at consumer scale. Meta has announced "Muse Confidential VM, where the whole VM, including a person's data and conversations with Muse, is encrypted with a key only they hold, so not even Meta can access it."³⁰

What's new in this chapter is not any of these parts. It's the unit they're bound to. Confidential computing is usually deployed per workload or per customer account. Binding it per principal and per purpose — one root for a claims officer's work on one claim, a different one for her browsing — is the proposal.

From isolation by policy to isolation by cryptography

Meta's own security documentation for Muse contains the clearest statement I've seen of the step this chapter asks for, and it's worth quoting at length because it's so candid about the difference:

"Today's Muse architecture isolates each user's data from each other and keeps it secure. It restricts access to your data by Meta personnel through operational policies. It does not prevent Meta from accessing data when necessary to support, secure or operate the service ... Muse Confidential VM is intended to cryptographically and verifiably prevent Meta from accessing data in your VM."³¹

That paragraph is this chapter in miniature. Isolation by policy today; isolation by cryptography next.

Identity moves down the stack

Chapter 4 described the monoculture zero trust tends to build: a central verifier that answers "who is this?" for every request, and whose key domain becomes the enterprise. Cryptographic tenancy moves the question.

"You're basically suggesting that identity isn't a question the app answers repeatedly. It's a property proven once per ephemeral cell and enforced by cryptography down the stack."

— the AI, reflecting my idea back

The cell proves itself once — at attestation and key release. After that, nothing works without the keys that proof unlocked. There's no session token to steal that works in another app, because the cell doesn't hold one. There's no "logged in" state to hijack, because being logged in is holding the root.

A network that only passes sealed traffic

This is the part of the idea I'm least certain how to build, and I said so at the time. But the direction is clear enough to state. Normally you check zero trust at an external proxy and then again at the application. What if, instead, the network only passes traffic encrypted to the right key? You connect to port 443 and nothing checks a password — the only thing that gets through is data sealed for that cell. Every layer of the network supports zero trust without inspecting a single packet.

In practice this looks like mutual, cell-bound channels: each endpoint a cell may talk to accepts only channels keyed from that cell's root, and the fabric carries ciphertext it has no way to redirect anywhere useful. A stolen channel key opens one cell's channel, for as long as the cell lives. That's a design direction assembled from existing primitives — mutually authenticated channels and attestation-bound keys — not a protocol specification, and it should be read that way.

What a thief actually gets

The test of any of this is what an attacker holds after they've beaten a wall. Walk the artefacts they typically come away with:

The token row deserves a sentence of its own. Okta's 2023 incident turned on HAR files in a support system that "contained session tokens which could in turn be used for session hijacking attacks", and the attacker "was able to use these session tokens to hijack the legitimate Okta sessions of 5 customers".⁴¹ A token that works anywhere, for hours, is a credential that composes. A token bound to one cell that no longer exists is a curiosity.

The termination point

Cryptography has to terminate somewhere. Somewhere, a key is held in plaintext and a process uses it. The AI named the conditions that make that bearable, and they've become a checklist I apply to every place a design holds keys:

"You still have to terminate crypto somewhere, but if that termination point is small, measured, short-lived and only holds keys that are useless outside that measured context, yeah, that's a different world."

— the AI sounding board

What this doesn't buy you

Confidential computing is not a wall, and anyone who sells it as one is repeating the mistake this book is about. It has published breaks — several of them recent, some against fully patched hardware.

CacheWarp's authors demonstrated "recovering the entire private key, logging into an OpenSSH server without authentication, and escalating privileges to root".⁴² RMPocalypse showed that "a single overwrite of 8 bytes within the RMP causes the entire RMP to become subsequently compromised. With a compromised RMP, all integrity guarantees of SEV-SNP become void."⁴³ TEE.fail extracted keys "including in some cases secret attestation keys from fully updated machines in trusted status", and noted that for interposer attacks "there is no current mitigation besides separately ensuring physical security".⁴⁴ StackWarp found that the processor's stack-engine state "is not correctly synchronized across the logical cores, allowing an attacker to deterministically adjust the stack pointer on the sibling logical core across Zen generations, including fully patched Zen 5."⁴⁵

Look at the shape of those breaks. StackWarp works through state shared between two logical cores. TEE.fail's worst result is a platform attestation key — a root shared by everything that platform attests. It's shared fate again, this time in silicon. And most of these attacks assume a malicious hypervisor or physical access to the machine, which is to say they matter precisely in the scenario that opened this chapter: the attacker who has already escaped to the host.

There's a quieter constraint too. AMD publishes how many encrypted guests each processor generation can hold at once — its table lists the EPYC 9004 series at "1006 Keys".³⁵ That's a real ceiling on how many confidential cells a single host can run, and a design has to plan for it rather than discover it.

Cells and binding together take shared fate out of compute and storage. The next failure is subtler, and I've watched it happen in my own designs: you build all of this, and then quietly rebuild multi-tenancy one layer down — in the database, the control plane, and the key service itself.

Every cell architecture I've sketched fails the same way on first draft, and it's the most useful warning in this book:

The main trap is rebuilding multi-tenancy one layer down: a shared database superuser, a shared control plane, a shared "break everything" credential.

The AI I was thinking this through with flagged it before I'd finished describing the cell. I've been finding it in designs — including my own — ever since.

Remember what actually carried the Hugging Face attacker across clusters. Not a hypervisor zero-day. One connector credential and one secrets object with 136 keys in it. You can give every principal their own confidential microVM and still hand every one of those microVMs the same database credential — at which point you've built a very expensive way to arrive at exactly the same place.

Shared fate hides in unglamorous places. What follows is a walk through the ten layers where I've found it, each with its failure shape, one line of evidence, and the design rule that removes it.

1. 1. The data tier

   Shape. The cell is per-principal, but it talks to the database as a service account that can read every row. You've rebuilt the multi-user application one hop later.

   Evidence. Cosmos DB primary keys in the ChaosDB research were "long-lived and allow full READ/WRITE/DELETE access to customer data".²¹ Hugging Face's attacker reached an internal MongoDB "with a static password it had read from the worker environment."⁴

   Rule — the principal-scoped data capability. A cell reaches data only through a narrow capability equal to what its principal could already see for its purpose, enforced by a data-access service outside the cell rather than by the cell's good behaviour. Database administration paths live off the workload network entirely.

   The shape of that capability is one I've argued before for AI agents: "every approved action gets a narrow, time-limited, plan-bound capability token", so that "The blast radius of any confused deputy attack is limited to the scope of whatever token is currently active — and tokens expire in minutes, not hours or sessions." Here the token is issued per cell — scope, time-to-live, nonce, purpose binding — and bound to the cell's root, so it's worthless if lifted out.

   What stays open: the database engine is still shared. An engine bug reachable through the capability interface is real residual risk — Chapter 13 comes back to it.

2. 2. The control plane

   Shape. Whatever builds cells, mints roots, pushes images and schedules hosts. If any cell can reach it, one cell compromise becomes every future cell.

   Evidence. Mandiant's 2026 report describes attackers "exploiting the "Tier-0" nature of hypervisors to bypass guest-level defenses. By targeting the virtualization storage layer directly or encrypting hypervisor datastores, they can render all associated virtual machines inoperable simultaneously." Its recommendation: "Isolate Critical Control Planes: Virtualization and management platforms must be treated as Tier-0 assets with the strictest access constraints."¹⁰ In OpenAI's incident, agents gained "full administrator access to a research cluster that supported our virtual machine environments."³

   Rule. Not routable from any cell, or from any host's workload interfaces. Separate administrator identities. Every change through a signed, reproducible pipeline. Tier 4 or higher (Chapter 8).

3. 3. Identity and signing roots

   Shape. Every token verified; one key domain for everyone.

   Evidence. Storm-0558's single consumer signing key; Hugging Face's EdDSA key that "allows issuing valid tokens on demand" (Chapter 3's table).

   Rule. Narrow key domains. Roots held in hardware. Issuance scoped to one principal and purpose. No signing material inside any cell. The identity provider decides who someone is; the key service releases per-cell roots (Chapter 6).

4. 4. Secrets stores

   Shape. One object, one vault path, one environment file that many services read.

   Evidence. "A production object holding 136 keys ... Everything that follows, on this day and the next, descends from it."

   Rule. No secret readable by more than one principal's cell. Where a credential genuinely serves many principals — an upstream API key, say — it stays outside cells, behind a gateway that holds it, and the cell gets a surrogate. Meta's Muse does exactly this: "code in the runtime cell or a worker only ever sees a "surrogate" token ... After the concrete network request is authorized, Sentinel will replace any surrogate tokens with the real credential ... at the network boundary. The agent never sees real tokens".³¹ The tokenising proxy in SiloOS is the same idea.

5. 5. Logging and telemetry

   Shape. A central collector that receives everyone's telemetry — and, sooner or later, somebody's credentials.

   Evidence. Okta's support system held HAR files "that contained session tokens which could in turn be used for session hijacking attacks".⁴¹

   Rule. Cells write only. Redact before egress. A separate, tiered, audited read path. Never a token in a log line.

6. 6. Backups and recovery

   Shape. The backup system can read everything, and is usually administered from the same directory as everything else.

   Evidence. Mandiant: "backup environments should be decoupled from the corporate Active Directory domain and utilize immutable storage".

   Rule. Back up through principal-scoped exports, or encrypt to keys the backup operator can't use. A separate identity domain. Immutable storage.

7. 7. Admin tooling

   Shape. Jump hosts, remote-management agents and orchestration consoles with standing credentials that reach everything.

   Evidence. NotPetya spread using "PsExec - a legitimate Windows administration tool; WMI - Windows Management Instrumentation, a legitimate Windows component" alongside the EternalBlue exploit.⁴⁶ Lateral movement through the organisation's own shared machinery.

   Rule. No standing shared admin credential. Admin access issued just in time, per target and per change — as its own cell, with its own principal and purpose.

8. 8. Network fabric and egress

   Shape. Shared egress addresses, default-allow outbound, mesh-VPN keys reused across hosts, DNS as a free path out.

   Evidence. Even a product built on per-user microVMs shares the network: Grok Bot's FAQ says "Computers use shared static egress IP addresses, and dedicated per-customer IPs are not available", and that "teams without a policy default to allow-all."⁴⁷ Hugging Face's mesh-VPN key came out of that 136-key object. And the September OpenAI incident was, in the end, an unfiltered resolver.

   Rule. No ambient network. Per-cell egress allow-lists set by purpose. DNS treated as a controlled dependency, not a utility.

9. 9. Build and supply chain

   Shape. The pipeline that produces every cell image is itself shared fate: a poisoned image is every future cell of that kind.

   Evidence. SolarWinds' signed update; Artifactory's signing key used to forge administrator credentials (Chapter 3).

   Rule. Signed, reproducible images; build identity separate from deploy identity. Deciding which components are admitted into an image in the first place is the subject of Compile the Bounded Object's argument for sovereign software assurance — "External assurance nominates. Internal assurance decides."

10. 10. Silicon

    Shape. Sibling cores, shared attestation keys, shared memory buses.

    Evidence. StackWarp and TEE.fail (Chapter 6).

    Rule. Tier it: dedicated hosts, no co-residence for the top tiers, physical control wherever attestation keys matter.

Our own design is on the map

The honest test of a warning like this is whether you'll apply it to your own work, so here's mine.

SiloOS, the containment architecture I built for untrusted AI agents, concentrates trust in one small, hardened router that mints every key. When I described it, I wrote: "Trust is concentrated in one small, hardened component. Everything else is untrusted by design." Its isolation chapter said of the gVisor sandbox that "The agent's code never touches the real kernel. Even kernel exploits can't escape."

Under the evidence of 2026 — a guest-to-host bug in a production memory-safe VMM, a zero-day in the one permitted proxy — "can't escape" has to be read as "is very unlikely to escape". And a router that mints every key is, by this chapter's own definition, a shared-fate component. It's exactly the trap.

The revision isn't a retraction. The design goal survives: keep the trusted thing small, hardened and the only trusted thing. It gains four requirements. It must sit off the workload path. It must be unreachable from any cell. It must mint per-cell roots rather than broad keys, so that its compromise is a key-service incident rather than an everything incident. And it must itself be tiered and drilled like any other crown jewel. That's what a design should do when the evidence moves: evolve in the open.

The shared-fate map

All of this comes together in one instrument. It's simple enough to start this month, and it's the artefact every later chapter depends on.

Chapter 9 fills this template in for a whole claims operation. Expect your first map to be long, and more than a little embarrassing. That's the point of drawing it.

The map has a sibling, and they're worth distinguishing. Compile the Bounded Object proposed a compositional containment test for what sits inside one environment: "If the agent treats every reachable component as a stepping stone, can any sequence of permitted interactions produce an unpermitted capability?" That test looks within a box. The shared-fate map looks across principals. The second-breach drill in Chapter 11 asks the same question dynamically, with a live attacker premise.

It also has a regulatory home. APRA's CPS 230 asks entities to identify the resources behind each critical operation, "the interdependencies across them, and the associated risks, obligations, key data and controls".⁴⁸ A shared-fate map is a natural way to do that analysis for security.

"Tier" is doing a lot of work in that sentence. Some shared things can't be removed — the key service, the database engine, the control plane itself — and not every workload needs a confidential, ephemeral, per-purpose cell. How strongly you isolate each thing should depend on what its failure would cost.

Tiering is how the pattern becomes affordable, and it's how the things you can't stop sharing get defended.

It also answers a fair objection to everything in the last three chapters: surely not everything needs a confidential, ephemeral, per-purpose cell? It doesn't. The AI sketched the shape early in our conversation — "a spectrum, multi-tenant, to dedicated hardware, to physically separated and bank-operated" — and later tightened it into the rule this chapter formalises:

"For low-risk stuff, per-user ephemeral cells on commodity infra might be enough, but high-risk systems can step up the isolation model. Dedicated hardware, dedicated network, maybe physical separation or air gap. The important bit is to remove shared fate at every layer, not just compute. So yeah, sensitivity tiered with a hard rule that breach isn't transitive."

— the AI sounding board

Matching protection to consequence isn't a new instinct in our work. For per-action authority over AI agents, the principle was that "Not every action needs the same level of proof. The key insight is matching the security ceremony to the risk of the action." Here the same logic applies to isolation: match the isolation to the consequence.

Five tiers

Cost rises with each tier, and I'm not going to put numbers on the steps; they depend on the estate and nobody has published them for an Australian institution. The shape is what matters: most workloads belong in Tiers 1 and 2, a meaningful minority in Tier 3, and a short, deliberate list in Tiers 4 and 5.

How do you decide which tier?

Four factors, in order of weight:

1. Consequence if breached — financial loss, harm to customers, regulatory exposure.
2. Principals exposed if a shared component at this tier fails.
3. Reversibility — can what the attacker could do be undone?
4. Regulatory criticality — for a general insurer, claims processing is a CPS 230 minimum critical operation unless justified otherwise.

Then apply a rule that catches most mistakes. Tier a workload by the worst credible consequence of its purpose, and then check that every shared component it depends on sits at the same tier or higher. A Tier 3 claims workbench that obtains its keys from a Tier 1 key service is, in practice, a Tier 1 workload. A workload is only as strong as the weakest tier it leans on.

The dependency check, worked

The rule is easy to state and easy to break, so walk one example. Say the claims workbench is assigned Tier 3: confidential cells, per-cell roots, attestation-bound key release. Now list what it depends on at runtime and check each one's tier.

Three of six dependencies fail, and none of them is where anyone would have looked first. The log collector passes or fails depending on a design detail — whether cells can only write redacted events. The feature-flag service is the kind of convenience dependency that accumulates silently; it has to be removed from the start-up path, or raised to the workbench's tier. The image pipeline is a supply-chain dependency that most estates run at the tier of a developer tool. Each of these would have made the workbench a Tier 1 or Tier 2 workload in practice, however carefully its cells were built.

Tiers already working

Chapter 3's table contained a small, clean example of tiering in the wild. When Okta's support system was breached in 2023, the attacker downloaded a report of all its support users. Every Workforce Identity Cloud and Customer Identity Solution customer was affected — "except customers in our FedRamp High and DoD IL4 environments (these environments use a separate support system NOT accessed by the threat actor)."¹⁹ Somebody had decided those customers warranted a separate support system. The decision was invisible right up until it was the only thing that mattered.

The frontier labs are running Tier 5 whether they call it that or not. After the September DNS incident, OpenAI "added blocking controls at two independent layers" and "restricted DNS queries within the environment to a limited allowed list of domains and record types", with other traffic hitting an offline cache.¹ Compile the Bounded Object made the general case for evaluation worlds: "Separate evaluation infrastructure physically or cryptographically from production trust." If your organisation starts red-teaming its own systems with capable models — and Chapter 11 suggests it might — that lab belongs here.

Where the hyperscalers fit

This is where the "anti-hyperscaler" instinct from Chapter 3 finally gets its proper answer.

"Hyperscalers won't vanish, but at the high-assurance end, they might end up selling less hyperscale than isolation by another name."

— the AI sounding board

Most of what Tiers 3 and 4 require is already on their price lists: dedicated hosts, confidential VMs, private links, customer-managed keys. And isolation has always been part of the product. Before Firecracker existed, AWS Lambda "used per-customer EC2 instances to provide strong security and isolation between customers."³⁴ The providers have always sold isolation. The question is how much of it you buy, and for which workloads.

Tier drift

That completes the design. A goal you can state: breach doesn't compose. A unit you can build: one principal, one purpose. A binding that makes the unit's contents worthless to whoever gets underneath it. The traps that rebuild shared fate below you, and an instrument for finding them. And tiers that match isolation to consequence without ever relaxing the rule. Part III runs all of it on a single estate — one insurer's claims operation, mapped, redesigned, attacked twice and drilled — to show that it holds together when it touches real work.

Why claims? Because for a general insurer, claims processing is a minimum critical operation under CPS 230 unless the entity can justify otherwise — it's the operation a board most needs to be able to defend. The same shape of work — an assistant that reads claim documents and proposes routing — was worked through for approval readiness in AI That Survives Audit. Here it's worked through for what a breach would cost.

Priya's Tuesday, as it is today

Priya is a claims officer. She's good at her job, careful with customer data, and has done her security awareness training. Follow her through a morning. After each step, note — in the margin, because she can't see it — what she's sharing fate with.

Nothing Priya did was unusual or careless. This is a normal, reasonably well-run estate. But her ordinary morning touched a dozen shared components, and each one is a ladder from a single foothold to the whole book of claims.

The shared-fate map, today

Now apply the Chapter 7 template properly. For each component more than one principal depends on, ask what owning it would yield toward the others.

Read the map the way an attacker would. Rows 1, 3, 5, 6, 10, 11 and 13 each, on their own, turn one foothold into the whole book of claims. Several of them are the exact shapes in Chapter 3's incident table: the static credential in a worker's environment (row 3), the secrets reachable from a node (row 13), the signing key (row 6), the admin tooling NotPetya rode (row 10), the pipeline SolarWinds showed you (row 11), the tokens in logs from the Okta support system (rows 7 and 8).

And look hard at row 3. The document-extraction pool is the one component whose entire job is to accept content from strangers on the internet — and it shares fate with every document the insurer processes. The front door opens onto the vault.

The same Tuesday, in cells

Now redesign Priya's day. For each cell: whose it is, what it's for, its tier from Chapter 8, how long it lives, what it holds, what it can reach — and which rows of the map it retires.

What stays shared — on purpose

Not everything can be cut per principal, and pretending otherwise would be the kind of overclaim this book is trying to avoid. Some things stay shared, deliberately, and get defended as what they are.

The map, redesigned

The day as a timeline of cells

The figure makes one point. At any moment of Priya's day, a foothold in any one of her cells is worth, at most, one claim, one purpose and a few minutes. The same foothold in her Tuesday as it is today was worth the book.

What changes for Priya

The first question any operations executive will ask is what this does to the person doing the work. It's the right question — a security design that makes claims officers slower will be quietly routed around within a month.

Most of the change is invisible to her. She still opens a claim and sees a workbench. The difference is what happens underneath: a cell is built, attested and keyed for that claim, and torn down when she closes it. The substrate's published boot figures are measured in milliseconds; whether the whole sequence — build, attest, release — stays out of her way is exactly what the pilot in Chapter 14 has to measure. What she might notice:

• No all-day session. Identity is proven per cell, so opening a Tier 3 workbench may ask for a step-up — a tap on a passkey — where today nothing asks. Proportion matters: browsing and correspondence at Tier 2 shouldn't ask at all.
• Payments go through a gate. Her request is re-verified by the payments service, and anything settlement-affecting needs a named human. That's already true in most insurers' policy; the difference is that it's now true in the architecture.
• No copy-and-paste between claims. Two claims open side by side are two cells with unrelated roots. Moving information from one to the other goes through the data service, which records it — which is, on reflection, what a privacy officer would want anyway.
• Nothing lingers. When she logs off, her cells are gone. There's no desktop to come back to with yesterday's files on it. Work lives in the claim record, written through capabilities.

And one change she'll never see, which matters more than all of those: a phishing link that lands in her browser can no longer become everyone's problem. Her browsing cell holds nothing that works anywhere else.

What it takes to run

Honestly: less exotic machinery than it sounds, and more discipline.

• A small number of cell templates, one per purpose — browsing, workbench, extraction, correspondence, admin. Not one per application.
• A data service that speaks capabilities, a key service that releases on attestation, a control plane nobody can reach, and an egress gateway that holds the real third-party credentials.
• Receipts written outside cells — every capability issued, every channel opened, every teardown — so observability doesn't depend on anything that dies with the cell.
• Engineering that AI now makes cheap. The plumbing for thousands of tiny systems is exactly the bespoke build-and-maintain work that used to make this uneconomic.

Performance is a fair question. The substrate isn't the constraint — Firecracker advertises boot times under 125 milliseconds³⁴ — but orchestration, attestation and key release at institutional scale haven't been measured in public, and I haven't measured them here. That's a pilot question, and Chapter 14 puts it in the sequence.

A design on paper proves only that it can be drawn. The next chapter attacks it — the same attacker, the same poisoned document, against both versions of Priya's Tuesday.

The attacker in this chapter is not a nation-state. It's a small crew with a capable open-weight model, a rented virtual server, and patience measured in model tokens rather than months.

The entry vector is deliberate. It echoes how the Hugging Face intrusion began: "A malicious dataset abused two code-execution paths in our dataset processing ... to run code on a processing worker."¹⁷ Every insurer has an input pipeline that has to accept content from anyone. That's where a sensible attacker starts.

Walk one — today's estate

Each step below names what the attacker does, what they hold afterwards, the row of Chapter 9's shared-fate map that made it possible, and the real incident it mirrors.

1. Foothold in the shared extraction pool

   The PDF lands in the shared pool of document-extraction workers. The parser bug gives the attacker code execution on a worker that is, right now, processing other people's submissions.

   Holds: code execution on a worker; its environment; every document currently in flight. Map row 3

   Mirrors: the Hugging Face dataset-processing worker.

2. Harvest the environment

   Workers need credentials to do their jobs, so the credentials are there: the insurer's model API key, access to the document store, and — as in so many estates — a database connection string with a password in it.

   Holds: the ability to call the model vendor as the insurer; read access to every claim file; a route to the database. Map rows 4, 5

   Mirrors: Hugging Face's agent authenticating to an internal database "with a static password it had read from the worker environment."

3. Cloud role and storage

   The instance metadata service hands over the worker's cloud role. The role can list and read the document store. The attacker now has every claim file the insurer has ever received — photos, medical reports, bank details — and a view of the cluster's API.

   Holds: all claim files, ever. Map rows 5, 13

   Mirrors: Hugging Face's own list of familiar weaknesses — "unsafe dataset processing, exposed cloud metadata, overly broad access, and long-lived credentials".⁴

4. Node, then cluster

   A permissive admission policy lets the attacker schedule a privileged pod with the host filesystem mounted — or a container-escape bug of the runc kind does the same job. Node root. From there, the cluster's secrets, including the claims application's database service account.

   Holds: every workload's secrets on the cluster. Map rows 13, 1

   Mirrors: Hugging Face's privileged hostPath pod and its 136-key secrets object.

5. The book

   The claims application's service account can read and write every claim. The attacker can now exfiltrate the whole book — or, more quietly, alter claims.

   Holds: every claim; the ability to change them. Map row 1

6. Sessions from the logs

   The central log collector is reachable from the cluster network, and one debug path writes session tokens. The attacker hijacks live staff sessions — including a team leader with payment approval authority.

   Holds: the live identities of staff, for the rest of their working day. Map rows 7, 8

   Mirrors: the Okta support-system HAR files and the five hijacked sessions.

7. Identity itself

   The admin jump host is reachable from where the attacker now sits, and it carries standing administrative credentials. Through the organisation's own management tooling, the attacker reaches the identity provider's administration — and its signing material.

   Holds: the ability to mint any staff identity. Map rows 6, 10

   Mirrors: NotPetya's use of PsExec and WMI; Hugging Face's signing key; Storm-0558's key domain.

8. Leverage

   The backup system is administered from the same directory, so the recovery path is theirs to read, encrypt or poison. The payments credential sits in the claims application, so money can move.

   Holds: the recovery path; payment authority. Map rows 9, 12

   Mirrors: Mandiant's warning about hypervisor datastores and backups joined to the corporate directory.¹⁰

That walk isn't pessimistic. It's close to a description of what happened at Hugging Face, transposed to an insurer, with the insurer's usual components in the places Hugging Face had its own. The individual weaknesses were ordinary. What made them a catastrophe was that each one shared fate with everything else.

Walk two — the cell estate

Same crew, same model, same PDF. This time, at every boundary they touch, we give them one more unknown vulnerability.

1. Foothold in a submission's own cell

   The PDF lands in its own extraction cell: principal, the submission for claim C-20931; purpose, extract this batch; Tier 3; lifetime, a few minutes. The parser bug works exactly as before.

   Holds: the documents they submitted themselves. A surrogate credential for one model call. A write-capability for extracted fields on claim C-20931. That is the entire address space of value.

2. Harvest the environment

   There's nothing to harvest. No environment secrets. No static passwords. No service account. The model credential is a surrogate that only the Tier 4 egress gateway can exchange — and only for this cell's purpose, the pattern Meta describes for Muse, where the cell "only ever sees a "surrogate" token" and the real one is swapped in "at the network boundary."³¹

   Holds: unchanged.

3. Move sideways Grant #1

   There's no ambient network. The cell can reach two things: the data service, with a capability scoped to one claim, and the egress gateway, for one purpose. Other cells aren't addressable. So we grant a vulnerability in the data service's interface. The attacker can now exercise that interface in unexpected ways — using a capability that only ever referred to claim C-20931.

   Holds: one claim they already knew about. (Whether the data service's authorisation logic holds under that grant is the first thing the drill in Chapter 11 tests. It's named as a weak point below.)

4. Escape to the host Grant #2

   Grant a hypervisor bug of the kind Anthropic's model found in a production VMM.⁶ The attacker is root on the host. What's there? Other cells' memory, encrypted with per-VM keys the host never holds. Disks sealed to measurements the key service won't release to anything else. No plaintext roots, no signing material, no service accounts — nothing Chapter 6 said a thief might want.

   Holds: ciphertext, and a host that the control plane will re-image the moment anomaly detection fires.

   The honest residual lives here. At Tier 3, this is exactly where confidential-computing break research operates — StackWarp's sibling-core attack, or TEE.fail with physical access. If one of those worked, the prize would be the plaintext of the cells co-resident on that host at that moment: some principals, some purposes, a few minutes each. Not the book. And none of the Tier 4 workloads — payments, the ledger, the key service — are on this host at all.

5. Reach for the control plane Grant #3

   Grant a vulnerability in the cell builder or the scheduler. The problem is that there's no path to use it on. The control plane isn't routable from cells, or from the hosts' workload interfaces. Its administrators use separate identities, and changes arrive only through a signed pipeline.

   Holds: unchanged. A granted vulnerability with nothing to point it at.

6. Try identity

   There's no signing material on hosts or in cells. The identity provider decides who Priya is, but it holds no key that makes anyone anyone; only the key service releases roots, only at Tier 4, only to attested measurements. Any token that survived in a cell's memory — and got decrypted somehow — is scoped to one principal and one purpose, and expires in minutes.

   Holds: at best, one cell's short-lived, single-purpose token.

7. Wait for a better target

   The extraction cell is destroyed when its fields are written. Its root goes with it; its surrogate dies; if anomaly detection fired, the host has already been re-imaged. Anything the attacker staged outside — the dead-drop trick Hugging Face described — has nothing worth reusing to come back to. The next cell starts with nothing that works anywhere else.

"Win inside the box, fine, but the win is scoped to that one person and that purpose and that moment. Then the box disappears."

— the AI sounding board

Side by side

Why the search stalls

There's a deeper reason walk two dead-ends, and it connects back to Chapter 1. Search pressure is powerful because search compounds. Every position an attacker takes reveals new things to try: more hosts to address, more credentials to replay, more services that trust what the attacker now holds. The Hugging Face agent took 17,600 actions, most of which went nowhere — and it didn't matter, because each success widened the frontier of places worth searching from. A foothold that yields a credential valid in ten places turns one search into ten.

Walk one is that dynamic in miniature. Step one yields a worker environment; the worker environment yields a cloud role, storage access and a database password; the cloud role yields a view of the cluster; the cluster yields every workload's secrets. Each step multiplies the number of doors the model can try next. Cheap search plus a widening frontier is how an ordinary parser bug becomes the whole book in hours.

Walk two starves the search of frontier. Each position yields almost nothing addressable that the attacker didn't already have: no new hosts, no new credentials that work anywhere else, no services that trust the cell for anything beyond one claim. The granted vulnerabilities in steps three to five were the most valuable things the attacker had, and two of them had nothing to point at. Search is cheap, but it isn't magic. It needs somewhere to go.

This is also why the design holds up as models improve. A better model searches each position more thoroughly and more cheaply. Against walk one, that makes things worse, because thoroughness finds more of the doors each position opens. Against walk two, a more thorough search of a position with nothing behind it still finds nothing behind it. The pattern's advantage grows with the attacker's capability rather than shrinking — which is the opposite of what happens to friction-based defences.

The same breach, notified twice

One more way to feel the difference is to imagine the notification. Under CPS 234, a material information security incident has to be reported to APRA no later than 72 hours after the entity becomes aware of it.¹⁵ Here's what each estate's notification would have to say — sketched, not legal drafting.

The first notification is the start of a crisis that will run for months, because the entity can't yet say where the attacker couldn't go. The second is the start of a vulnerability-management ticket, because it can. That difference — being able to state the boundary of an incident within hours, with evidence — is what the architecture is really for.

Where walk two is still weak

It would be easy to stop here and declare victory. That would make this a sales document. The cell estate has weak points, and they're worth naming precisely, because they're where the drill should aim first.

1. The data service. It's the termination point for every data capability. An authorisation bug there — a capability for claim C-20931 that can be coaxed into returning C-20932 — is a shared-fate bug by definition. Mitigation: keep it small and measured, put it at Tier 4, and drill it first.
2. The claims database engine. The data is shared by nature. An engine-level bug reachable through the data service's narrow interface is real residual risk. Mitigation: a narrow, parameterised interface; engine administration off the workload path; Tier 4. What stays open is taken up in Chapter 13.
3. The key service and control plane. These are the crown jewels, and their compromise would be a genuine incident. Mitigation: Tier 4 and 5, off-path, drilled. Per-cell roots mean that even misuse of an issuing key requires presence and time to exploit widely — but that's a mitigation, not an immunity.
4. The image pipeline. A poisoned cell image reaches every future cell built from that template. Mitigation: signed, reproducible builds and the admission discipline argued in Compile the Bounded Object.
5. Availability. Non-transitivity bounds what an attacker can read or change per principal. It doesn't stop denial of service, or ransomware aimed at the shared engine's storage. Mitigation: decoupled, immutable backups in a separate identity domain.
6. The legitimate principal. If the attacker phishes Priya herself, they get Priya's cells — one person's authority, for as long as they can hold it. Cells limit what else that authority reaches. Whether a given action was actually authorised by her is a different axis: as the Agent Provenance Stack put it, "Containment says: "You can't exceed these boundaries." Provenance says: "Someone authorised you to use these boundaries for this specific action."" The payment path's re-verification is where that axis shows up in this design.

What detection and response become

One benefit of the cell estate is easy to miss. Every cell has a declared purpose, so anything a cell does outside that purpose is anomalous by definition. An extraction cell that tries to open a channel to the data service for a different claim, or spawns a process the extraction template never runs, isn't a faint signal in an ocean of normal traffic — it's a violation of a specification. Compile the Bounded Object made the same point about bounded environments: the investigation becomes tractable because "the system knows what normal is allowed to be". Signals get sparser and sharper.

And response changes shape. You don't nurse a compromised cell back to health. You destroy it, re-image the host it ran on, and issue a fresh one. That's Chapter 2's "dynamic regeneration system" in operational form: the intelligence lives outside the boundary, and repair means regeneration.

Walking one attack twice is still a thought experiment — a persuasive one, I hope, but a board can't file a thought experiment. The next chapter turns it into an instrument: something you can run next week, repeat every quarter, and hand to a risk committee as evidence.

When I described the accountable executive's problem — a board that can't hand accountability to a vendor, and a team with no answer beyond patch, scan and segment — the move that came out of that conversation is the seed of this chapter:

The CISO's move is a scenario exercise. Assume the first breach. Assume AI finds another unknown vulnerability. Then show that it doesn't get the attacker anywhere consequential. That's a much stronger posture than "the vendor assured us".

It was the AI I was talking with that framed it as a scenario exercise. The premise inside it — grant the breach, then design and test what it buys — is the one this book has been building since Chapter 1.

Chapter 10 ran that exercise informally, on one document. This chapter specifies it so that a security architecture team can run it next week, repeat it every quarter, and put the output in front of a risk committee.

Why a drill, and not just a pen test?

Penetration tests and audits are valuable, and nothing here replaces them. But look at what they measure. Mostly, they ask whether the first wall holds — the probability side of the ledger, which Chapter 1 argued the attacker's search budget increasingly controls. The drill measures the other side: what getting in actually buys.

Keep the pen tests. They find real bugs, and they exercise your detection. The drill measures the variable you still own.

The protocol

Who's in the room

If you do run an AI-assisted attacker, the lab it runs in is a Tier 5 environment, and the conditions for it are already set out in Compile the Bounded Object: "Separate evaluation infrastructure physically or cryptographically from production trust," and "Expose no credentials whose compromise matters inside red-team or evaluation worlds." The book's "containment escape lane" — treating "every allowed interface ... as a potential capability-escalation path" — is a natural automated companion to this drill.

What you bring

• The workload's shared-fate map (Chapter 7's template).
• Its tier assignments (Chapter 8).
• Current architecture and network reachability — who can address whom.
• A credential and key inventory: every credential or key each component holds or can obtain, and its domain.

The seven steps

1. Choose the workload and the critical operation it supports — claims lodgement, say.
2. Place the beachhead. Name the principal or component where the attacker starts: a document parser, a staff browser, a vendor integration. Don't debate how they got there.
3. Grant the second vulnerability at the next boundary they touch — one per boundary crossing, up to the tier's grant budget.
4. Trace holdings after each step: credentials and their key domains, network reach, data, sessions, and any shared component now within reach. Write it down.
5. Record the outcome of the path: a dead-end inside one principal and purpose, or a continuation — and the shared-fate map row responsible.
6. Decide the architecture fix, not the finding fix. Remove, scope or tier the responsible component. Patch the bug too — but that's hygiene, not the result.
7. Re-run after the change, and record the new chain.

The grant rules

The attacker gets one free unknown vulnerability per boundary crossing. A starting budget per path: two grants for Tier 1 and 2 workloads, three for Tier 3, four for Tier 4 — more generous where the consequence is higher. Those budgets are a convention for the exercise, not an empirical claim about attackers; tune them as you learn.

The most important rule is the one that makes this a drill rather than a pen test: no arguing exploitability. The premise is AI search. The only admissible objection in the room is "that component doesn't hold that" or "that component can't reach that" — and it has to be shown, not asserted.

Pass and fail

The worksheet

Scoring. Deliberately, there's no composite score. For each path, record the hops to a consequential outcome, the widest key domain reached, the number of principals exposed, the residual shared components touched and the grants consumed. For each workload, count the failing paths and list the map rows responsible. Report the chains, not an index. A number invites a board to stop asking questions. A chain invites the right ones.

The drill, run on the specimen

Here's what the output looks like on Chapter 9's claims operation, before and after the redesign. Three paths.

Path A — the portal document

Result: FAIL. Hops to consequence: one. Widest key domain: every claim file. Principals exposed: every policyholder. Grants used: one.

Result: PASS. Widest key domain: one submission, one purpose, minutes. Residual shared component touched: the data service. Grants used: three.

Path B — a phishing link in the browser

Before: the attacker lands in Priya's desktop browser and inherits her all-day single-sign-on session — every internal application she can reach, until evening. FAIL at step one: key domain, everything Priya can do. After: they land in her browsing cell, which holds no corporate credentials and has no route to any internal application. PASS at step one, with the grant budget unspent because there's nothing to spend it on.

Path C — the uncomfortable one

A good drill finds work even in a good design, so aim one path at the redesign's weakest point. Place the beachhead in the data service and grant an authorisation bug. After the redesign: FAIL — any claim the bug lets a capability reach is exposed. Responsible row: the data service itself. Disposition: it's already Tier 4, so the fix is depth at the termination point — verify the capability again inside the database's own access layer, so that one service's bug isn't sufficient; and narrow the service's interface further. Re-run. This is the drill doing its job: telling you where the remaining shared fate lives and what to do about it.

What your first drill will probably find

I can't tell you what your estate holds. But the incident record in Chapter 3 is consistent enough that the first drill on almost any conventional estate will surface some version of the same four findings. Knowing them in advance helps a facilitator recognise them quickly — and helps a board understand they're normal, not a scandal.

None of these is exotic, and none requires a novel exploit to matter. That's exactly why they belong in front of a board: they're the ordinary shared components that turn an ordinary vulnerability into an institutional event.

Running it for the first time

A first drill works best small. Pick one path — the one through the component that accepts input from the internet is usually the most instructive — and one workload. Allow half a day for a tabletop version. Spend the first hour building the holdings for the beachhead honestly: system owners will often discover, in the room, that a component holds credentials nobody remembered giving it. That discovery is itself a result. Record it on the map before moving on.

Expect the first run to fail, probably early. That's the point of running it. A second-breach drill that passes the first time on a conventional estate is almost certainly one where someone argued the grant. The drill earns its keep on the second run — after the dispositions — when the chain that reached the book on Tuesday stops inside one principal on Thursday, and you have both worksheets to show.

Putting a model in the attacker's seat

Once the tabletop version is routine, it's worth asking the obvious question: if the threat is AI search, why is the attacker seat filled only by people? A capable model, working against a sealed clone of the workload, brings exactly what Chapter 1 described — coverage. It will try the paths a human red team skips because they're tedious, and it will try them at a volume no human team can.

Three conditions make that safe and useful. First, the clone lives at Tier 5: no route to production, no route to the live internet except through a fully captured gateway, and no credentials inside it whose compromise would matter. The labs' own incidents are the argument for taking this seriously; an evaluation environment is precisely where a capable model looks hardest for a way out. Second, the grant rules still apply. The model doesn't replace the premise — it explores the space the premise opens, and the facilitator still records holdings step by step against the map. Third, success is measured against the same pass and fail conditions, deterministically: did any path reach another principal's data, a wider key domain, the control plane, the recovery path, payment authority or the image pipeline? The model's opinion of whether the estate is secure is not a result.

What the model adds isn't judgement. It's the volume of attempts, which is the one thing the attacker has that your red team doesn't. Used this way, it turns the drill from a structured argument into a structured experiment.

The board one-pager

How it maps to what APRA asks

This is orientation, not legal advice, and the obligations belong to the entity. But the drill lines up closely with what the prudential standards already ask regulated entities to test.

The same APRA–ASIC paper contains a sentence I'd frame on the wall of every security architecture team: "If key decisions would be debated for the first time during an incident, this should be treated as a priority gap." The drill is how you have that debate on a Tuesday afternoon, with coffee, instead of at 2 a.m. with a regulator waiting.

What the drill gives you, above all, is the entity's own evidence: your chains, on your map. That's what these clauses are asking for, and it's what no vendor's letter can supply.

When to run it

Quarterly for critical operations at Tier 3 and above. And on any trigger: an architecture change; a new shared component; a tier change; a new kind of principal — APRA has already observed that identity and access management "have not yet adjusted to nonhuman actors such as AI agents"¹⁴; a newly published class of incident (the next Hugging Face-style disclosure); or a jump in public model capability.

The drill makes the design legible to the people who carry the accountability for it. Part IV turns to them directly: what APRA holds the board responsible for, where this pattern breaks, and the path from here.

Now imagine you're the CEO or the CISO of a large Australian insurer under APRA.

You can't delegate this. "I signed off on the hyperscaler's security audit, it's their problem" is not an option available to you. You've heard about the Hugging Face attack like everyone else has, and your board has too. If you get breached you can't throw up your hands and say it wasn't your problem. You're on the hook.

So you ask your internal people: what can we do? And the honest answer in most rooms, right now, is some combination of patch faster, scan more, segment better, and more zero trust. I don't think anybody's doing anything very useful yet. That's my read of the market, not a survey result — but I'd be surprised if many readers of this book have been shown something different.

That default answer isn't wrong, and it has regulatory company. The Bank for International Settlements' survey of supervisors found that "authorities consistently stress that the underlying defensive principles remain largely unchanged. Effective patch management, zero trust architectures, secure software development and robust identity and access management continue to form the foundation of cyber security, but authorities are urging for these tasks to be executed more quickly, more continuously and increasingly with AI support."⁸ Do all of that. But notice that every item on the list is on the probability side. None of it tells the board what a breach would buy.

What APRA actually says

It's worth reading the prudential standards directly, rather than through summaries, because they're sharper than their reputation. What follows is orientation, not legal advice; the obligations are the entity's, and how they apply depends on the deployment.

Source for the table: APRA, CPS 234 Information Security, current and as-made text.¹⁵⁴⁹

Two more details in CPS 234 deserve attention. Internal audit must assess any information security control assurance provided by a third party where it intends to rely on that assurance and an incident could materially affect the entity. And the standard describes environments where the entity is unable to enforce its own policies — "Also referred to as an 'untrusted' environment." A shared substrate you can neither inspect nor control is exactly that.

CPS 230 extends the same logic to operational risk. "An APRA-regulated entity must not rely on a service provider unless it can ensure that in doing so it can continue to meet its prudential obligations in full and effectively manage the associated risks." "The Board of an APRA-regulated entity is ultimately accountable for oversight of an entity's operational risk management. This includes business continuity and the management of service provider arrangements." Entities must understand the risks from "any fourth parties that material service providers rely on", assess risks "associated with geographic location or concentration", and map the resources behind critical operations and "the interdependencies across them".⁴⁸ The instrument now on APRA's site is a reissue commencing on 1 July 2026; CPS 230 itself first commenced on 1 July 2025.⁵⁰

A precision note, because I've seen it misquoted in board papers: CPS 230 does not contain the phrase "you cannot outsource accountability". What it says is what's quoted above — and it's stronger, because it's operational. You may rely on a provider only if you can still meet your obligations in full.

What APRA said in 2026

If the standards leave any doubt, APRA's statements this year remove it. Its April letter to industry on AI reads, in places, like a description of shared fate:

• "APRA also noted an overreliance on vendor presentations and summaries without sufficient examination of key AI risks such as unpredictable model behaviour and the impact on critical operations."
• "AI can shorten the attack cycle and increase speed, coordination and impact. At the same time, entities are using AI to improve threat hunting and vulnerability identification, with the challenge being remediating at the speed with which vulnerabilities are identified."
• "Identity and access management capabilities have not yet adjusted to nonhuman actors such as AI agents."
• "ongoing consideration of third-party and concentration implications in relation to common platforms, services, and providers."
• "Where entities fail to adequately identify, manage or control AI risks in a manner proportionate to their size, scale and complexity, we will take stronger supervisory action and, where appropriate, pursue enforcement."¹⁴

In August, APRA and ASIC published the outcomes of their frontier-AI roundtables with industry. It opens bluntly — "Frontier AI poses a real and present risk to Australia's financial system" — and its advice to boards and executives is, almost word for word, the method of this book: "Focus first on shared dependencies and disruption scenarios where one weak link could affect customers, markets or confidence across the system." It also asks entities to understand "where legacy systems may create vulnerabilities, constrain recovery options or complicate incident response" — Chapter 2's assurance debt, in regulatory language.²⁶ APRA's corporate plan for 2026–27 says it "will focus on ensuring entities strengthen their resilience to AI-enabled cyber threats".⁵⁰

Read together, the regulator is describing the problem this book is about in its own vocabulary: concentration, common dependencies, one weak link. What it isn't doing — and shouldn't — is prescribing the architecture. That's the entity's job.

"The vendor signed off"

Which brings us back to the sentence nobody in a regulated boardroom can say anymore, if they ever could. "The hyperscaler is my security." "My vendor signed off on it, so I'm good."

I've written before about why this kind of assurance fails under scrutiny. In AI That Survives Audit, the pattern was named borrowed authority: "the board can approve because a prestigious firm said so. That authority expires the moment an Architecture Review Board, cyber team, or privacy office asks for exhibits instead of brand." A provider's assurance report is borrowed authority about the provider's scope. It says nothing about what a breach inside your estate composes into, because it never looked at your estate.

The drill is the opposite: the entity's own exhibit, about its own chains. Compile the Bounded Object made the same move for software admission — "External assurance nominates. Internal assurance decides." The same principle holds here. A provider's evidence is an input to your map. It isn't a verdict on it.

"Regulation applies accountability pressure, AI applies technical pressure, and AI built infrastructure changes the economics."

— the AI sounding board

That's why this is the moment. Any one of those pressures alone wouldn't force a change. All three together mean the accountable executive has a reason to act, an attacker who won't wait, and — for the first time — an affordable way to do something structural about it.

What to put in front of the board

1. The shared-fate map for each critical operation (Chapter 7), with dispositions and owners — what's been removed, scoped and tiered, and what hasn't yet.
2. Tier assignments, with the dependency check done: no Tier 3 workload leaning on a Tier 1 key service (Chapter 8).
3. Second-breach drill chains, before and after, on the one-page template (Chapter 11).
4. The residual crown jewels — data service, key service, control plane, image pipeline — with their tier and the date each was last drilled.
5. What isolation has been bought from providers, and what the entity still shares with other customers of the same provider.
6. The next drill date and its triggers.

None of that is a certificate. All of it can be questioned — which is exactly what a board should be able to do with it.

What to ask your providers

The frame for every provider conversation is simple: you're buying isolation, not borrowing assurance. These are the questions that separate the two.

Across the system

There's one more reason a regulator cares about this, and it's bigger than any one institution. The IMF warns that "AI heightens these risks by increasing the likelihood of simultaneous and correlated cyber incidents."²⁵ The BIS survey adds that reliance on common providers "introduces concentration and sovereign access risks, whereby a single provider's disruption or policy decision can cascade across firms and jurisdictions."⁸

An institution whose breaches don't compose internally is also less likely to be the node through which a breach composes across the sector. Non-transitive design is, among other things, a contribution to the system's resilience — and heterogeneity, as Chapter 3 put it, becomes a security feature at that scale too.

A board will — and should — ask where all of this doesn't work. The next chapter answers that directly.

The first objection a good CISO raises is the right one to start with. "The database is shared anyway. What's the point?"

It deserves a straight answer rather than a deflection, so it goes first. Then the rest, in rough order of how often I expect to hear them. For each: the problem, why it's real, what the pattern does about it, and what stays open.

Myth and reality

What would tell you this is the wrong bet?

An argument that can't be falsified isn't worth much to a board. These are the results I'd take as evidence against the pattern — each testable in a pilot, and each teaching something specific if it comes back the wrong way.

With the limits named and the falsifiers set, what's left is the sequence — what to do, in what order, starting now.

The order matters more than the speed. The right cadence depends on your estate, your teams and your providers. The right order doesn't.

The principle behind the order is simple: start where the yield is highest and the cost lowest. That means drawing the map and removing the worst shared credentials before building a single cell — because those two steps alone retire several of the hops that carried the Hugging Face attacker across its clusters, and they need no new infrastructure at all.

1. 1. Pick one critical operation

   Claims lodgement, payments release, policy servicing — something APRA would recognise as critical under CPS 230, and your board would recognise as the thing it most needs to defend.

   Artefact: a named scopeOwner: CISO with the operation's owner

   Why first: the map and the drill only mean something against a real consequence.

2. 2. Draw its shared-fate map

   Use Chapter 7's template; Chapter 9 shows the density to expect. Every component more than one principal depends on, what owning it would yield toward the others, and its key domain.

   Artefact: the mapOwner: security architecture with system owners

   Why here: it tells you where breach composes today. Every later step is prioritised from it.

3. 3. Kill the "break everything" credentials

   Shared service accounts with all-row access. Secrets objects many services can read. Enterprise-wide signing keys. Standing administrator credentials. Tokens in logs. Move each map row to "scoped" or "tiered".

   Artefact: map rows re-dispositionedOwner: platform and identity teams

   Why this early: it's the cheapest, highest-yield work on the list — and it's exactly the shape of the worst hops in Chapter 3's incidents.

4. 4. Carve the control plane off the workload network

   There are no cell builders yet, but there are hypervisor and virtualisation management platforms, cluster control planes, image registries and backup systems. Make them unreachable from workloads. Separate administrator identities. Treat them as Tier 0, as Mandiant's 2026 guidance puts it.

   Artefact: a reachability diagram showing no pathOwner: infrastructure

5. 5. Tier the operation's components

   Assign tiers by consequence (Chapter 8), and run the dependency check: no higher-tier workload leaning on a lower-tier key service, logging path or pipeline.

   Artefact: the tier table for the operationOwner: architecture with risk

6. 6. Pilot principal cells for one high-consequence purpose

   The best candidate is usually the one facing hostile input — the document-extraction cell from Chapter 9. Per-submission cells, surrogate credentials through an egress gateway, a data capability scoped to one claim, attestation-bound key release at Tier 3.

   Artefact: a working template, with measured spin-up and run costOwner: platform engineering

   Why this one: it retires the component that opens the front door onto the vault — and the measurements answer Chapter 13's cost and latency falsifiers.

7. 7. Run the second-breach drill, before and after

   Chapter 11's protocol, on the same operation, before the pilot and after it.

   Artefact: the chains, and the board one-pagerOwner: security architecture, with risk and internal audit observing

8. 8. Take the chains to the board, and extend by template

   Show the board the chains — what breach one and breach two bought before, and what they buy now — with the residual crown jewels and their tiers (Chapter 12's list). Then extend: the workbench, correspondence, administrator access. Re-drill on every trigger.

   Artefact: the board packOwner: CISO

What each role does on Monday

A sequence only moves if somebody owns each step. Here is what the path asks of the people most likely to be reading this book.

Close

Here is the whole argument, one more time, as briefly as I can put it.

The wall will be searched — cheaply, in parallel, forever — by something that never gets bored, and every deployed thing is a snapshot being read by a smarter attacker each day it stays the same. You no longer control the probability of breach the way you think you do. You still control what a breach is worth. So shrink the unit of computing to one principal and one purpose; bind everything that unit touches to that principal; hunt down the things still shared one layer below, including the ones you designed yourself; tier by consequence; and then prove it with chains your board can read.

Too many things now have attack surfaces — and shared fates — too big to defend. There's no defending them anymore except by making them smaller, and making them separate.

"That makes breaches boring, localized, disposable, and cryptographically illiterate outside their little cell."

— the AI, summing up where the conversation landed

Boring is the goal. Not a breach nobody noticed — a breach that, when you trace it, went nowhere. Let them win the box. Make sure the box is all they win.