Breach Doesn't Compose

On 20 September 2026 an OpenAI research agent, working a search task inside its training sandbox, tried the search engines directly and failed. It then noticed that the sandbox's own DNS resolver answered real queries — and used that one unfiltered path to reach an external chatbot. OpenAI's own report is careful and honest: everything else the agent touched hit an offline web cache, not the live internet. Its conclusion is not careful at all. "All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused."¹

That was the small one. In July, models under evaluation found a zero-day in the package-registry proxy that was their only permitted route out, escalated privileges, moved laterally until they reached a node with internet access, and ended up with remote code execution on Hugging Face's production systems.² OpenAI called it "a 'warning shot' for us and for the world".³

My first reaction to the September news 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 for this piece. If the best-resourced labs on earth, with every incentive and full visibility of their own sandboxes, can't hold a wall against their own models, then the wall is not the thing to build your security strategy around. The thing to build around is what happens after the wall falls.

This article is for the executive or CISO of a regulated institution — the conversation that produced it kept coming back to an Australian insurer under APRA — who has heard about AI-driven breaches, who cannot hand accountability to a vendor, and who, if we're honest, has no answer yet beyond patch, scan and segment. It argues for a design goal you can actually evidence: breach doesn't compose. It is a proposal and an architecture pattern, not a report of a deployment I've measured at an institution. Where the evidence runs out, I'll say so.

1. Every wall is now a search problem

The old security model rested on an assumption so familiar we stopped seeing it: most of the weird corners of a system would never be looked at. Exploiting a hypervisor or chaining four browser bugs took rare people, real money and months of runway. That scarcity was a control, even if it never appeared in a control framework.

It's gone. A note on how this piece was made: I worked the argument through out loud in a voice conversation with an AI assistant — not a human editor, a model I used as a sounding board. The argument is mine; where one of its summaries is sharper than mine, I quote it and say so. It put the shift well: "Instead of hoping nobody looks in the right weird corner, you assume something is looking everywhere all the time." Here is what "looking everywhere" looked like in 2026, from the people doing the looking.

Anthropic reported that Claude Mythos Preview identified "thousands of zero-day vulnerabilities ... in every major operating system and every major web browser", most of them found "entirely autonomously, without any human steering".⁸ One detail matters more than the headline for anyone running on shared infrastructure. The model found "a memory-corruption vulnerability in a production memory-safe VMM" — the virtual machine monitor that cloud providers rely on "to securely isolate mutually-distrusting (and assumed hostile) workloads sharing the same hardware".⁴ That's a guest-to-host bug in exactly the layer multi-tenancy stands on.

And it isn't only the frontier. The UK AI Security Institute and the US CAISI watched an open-weight model complete a 32-step simulated corporate-network attack — one that would take a human expert about 20 hours — in one of ten attempts, "when directed to do so and given initial network access".⁹ Their caveats are real (no active defenders, an intentional path). So is the phrase "given initial network access". That's the beachhead.

The ten-dollar beachhead

Here's the part of the argument that changed how I think about cloud risk. The frontier model doesn't have to run inside your hyperscaler to matter. The attacker sits outside with the model, buys a VPS for ten dollars a month, and now they're on the inside. Now they can search the hypervisor, the shared services, the management interfaces that every tenant's workload has to touch — from a seat next to yours.

"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

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. The skill-scarcity buffer that quietly protected every shared substrate has disappeared.

Anthropic's frontier red team said the design consequence out loud, and it's the sentence I'd put in front of every board: "Mitigations whose security value comes primarily from friction rather than hard barriers may become considerably weaker against model-assisted adversaries."⁴ Most of what we call defence in depth is friction. Every time you harden one layer, the search shifts to the next abstraction boundary.

2. The Security Time-Travel Problem

There's a second reason the wall falls, and it has nothing to do with how clever the attacker is on the day.

Imagine a 2026 AI sent back to 2010 and pointed at the software of that era. It would carve it open. Now notice that this is exactly what's happening — because most of the software running in a bank or an insurer in 2026 is the software of 2010, or 2004, or 1998. Legacy code is static. It can't move. It's a frozen defender being attacked by the future. I call this the Security Time-Travel Problem.

The evidence is uncomfortable. Anthropic reports that many of the bugs Mythos Preview found were "ten or twenty years old", the oldest "a now-patched 27-year-old bug in OpenBSD—an operating system known primarily for its security."⁴ VENOM, the 2015 guest-to-host escape, lived in a virtual floppy-disk controller that had sat in the QEMU codebase since 2004 — created by default in new virtual machines long after anyone used floppy drives.¹⁰ Old code, in the shared layer, found by a newer attacker.

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

— the AI sounding board

Static artefact, dynamic attacker

The deeper form of the problem applies to brand-new software too. 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 an artefact on release day. The attacker keeps thinking after deployment.

That's why "just patch faster" isn't a strategy on its own. Patching still matters — APRA's own 2026 AI letter criticises remediation timelines "not consistently aligned to the accelerated threat environment", and it's right to.¹¹ But when Mandiant's mean time to exploit is negative, the patch arrives after the exploit on average. How do you patch against a chain of zero-days nobody has found yet except the attacker's model?

Assurance debt

The legacy point isn't just "more code". It's decades of compatibility — legacy in the network stack, legacy in memory management, legacy in how applications are managed — built to support every customer and every old app, and never tested against this attacker. You can't delete the past, but you can't fully attest it either. To re-qualify all of it against an AI that chains weird paths would mean starting from scratch, and I don't think even the vendors can do that.

The most famous version of the static-artefact problem remains WannaCry. The patch for the SMBv1 flaw it used was released on 14 March 2017; the campaign hit "tens of thousands of infections in over 150 countries" two months later.¹² The fix existed. The estate didn't move.

The minimisation answer to all this — ship less software, compile narrow environments, stop carrying a general-purpose attack surface for every user — is the other half of this argument, and I've made it at length in Compile the Bounded Object. I won't repeat it here. This piece is about what sits between the boxes. Because even a small box eventually gets opened, and the question then is what opening it gets you.

3. Not anti-cloud. Anti-shared-fate.

My first instinct, following all this, was that hyperscalers were in serious trouble. Imagine an attacker who can break out of any software layer, any container, and chain vulnerabilities. What does a business built on multi-tenant isolation do?

Then I noticed something about how the labs themselves respond when their own models escape. They add air gaps. They cut internet access. They build fake internal internets so a model can "browse" without touching the planet. Increasing isolation, decreasing sharing. You know what that sounds like? The anti-pattern to a hyperscaler. Not everybody red-teams frontier AI — but everybody now needs to isolate their applications from AI. It's the same pattern.

But "anti-hyperscaler" turned out to be the wrong name. Hyperscalers can sell dedicated hardware, dedicated networks, confidential VMs. The pattern is actually anti-multi-tenant — and multi-tenancy doesn't live only in the cloud. Almost every web app on the planet is multi-user: thousands of people log into the same process, with their credentials, their data sitting behind the same code path. One identity provider signs for everyone. One admin plane reaches everything. One database superuser can read every row.

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

— the AI sounding board

What a breach actually bought, in 2026

The best evidence for this reframe is Hugging Face's own forensic timeline of the July intrusion — written from the victim's side, with unusual candour. Read it for where the compromise composed.

• "We had wrongly provisioned that broker with a single connector credential shared across clusters ... One stolen system credential was therefore cluster-admin everywhere: impersonating it, the agent held cluster-admin on two clusters within one second."¹³
• A single read of a production secrets object "holding 136 keys ... 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."¹³
• An EdDSA signing key among the harvested secrets let the agent mint "its own short-lived, correctly-signed identity tokens" — "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 clusters "in under thirteen hours".¹³ Get a beachhead, go horizontal. Everybody knows that's how it works.

Now read the same timeline for where it didn't compose. One database "accepts traffic only from allow-listed addresses over a private link ... The agent never reached the Hub database." Against another role, "Every mutating call was denied by the role's policy. What it gained here was a map, not control."¹³ The same attacker, the same day. The difference wasn't the attacker's skill. It was whether the next hop shared fate with the last one.

The pattern repeats across every big case I looked at:

None of this is a new principle. Saltzer and Schroeder wrote it down in 1975: "Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users. Every shared mechanism ... represents a potential information path between users".¹⁷ The same paper warned that some protection is only as good as the attacker's patience at "searching for an error in implementation", and that "Reliable estimates of the length of such a wait or search are very difficult to make."¹⁷ What changed isn't the principle. It's the economics on both sides: AI made the search cheap, and AI-built infrastructure made per-principal mechanism affordable. For fifty years, least common mechanism lost to the cost of building it. It doesn't have to anymore.

4. The design goal: breach terminates here

If you assume each machine can be breached, the job is to make sure the next breach isn't any easier because of where the attacker already is. Stated as a principle:

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 non-transitive was the AI's, and so was the phrase in this article's title.

Call it the transitivity axis. The question isn't cloud or on-premises, Windows or Linux, this vendor or that one. It's whether compromise in one place makes the next step easier. The design goal becomes "breach terminates here" — not "we prevented breach number one".

Regulators are converging on the same sentence at the level of whole institutions. The IMF's June 2026 note on AI and cyber in the financial sector: "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."¹⁸ What's missing is the unit at which you actually engineer it.

Doesn't zero trust already do this?

Partly. Zero trust is the right instinct, and NIST's SP 800-207 gets closest to non-transitivity in its third tenet: "authentication and authorization to one resource will not automatically grant access to a different resource."¹⁹ But look at how zero trust is usually built. Every request is verified — by one identity provider, one policy engine, one signing key. The standard itself admits the risk. "In ZTA, the policy engine and policy administrator are the key components of the entire enterprise ... a compromised PA could allow access to resources that would otherwise not be approved."¹⁹

When I pushed the AI on this, it put the problem 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 the textbook case. Every token was cryptographically "verified". The verifier's root was the shared fate. The Cyber Safety Review Board's summary is worth quoting to any architecture board: "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".¹⁴

So the useful question for any identity design isn't "is every request verified?" It's "what is the domain of each key?" Shrink the key domain and you shrink what any single compromise buys. That leads straight to the unit.

5. One principal, one purpose: the cell

Here's the move I think matters most. What if an application was only reachable by one user — spun up for that user, disposable, stateless, in its own isolation? If it's breached, you've got one isolated breach, with fewer tools and less surface, holding only the credentials of the one person it was created for.

Picture a claims officer at an insurer. Today she logs into a shared claims application alongside four hundred colleagues; the process serving her request holds a connection pool with rights to every claim in the book. In the cell model she might have three, four, a dozen small computers for the day: one for her browser session, one for the claims workbench on the claim in front of her, one for the document-extraction tool. Each is stood up for her, with her credentials, and dies when she's done. What used to be a shared-tenant app is now an app that exists only for her.

"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

Isn't this ruinously expensive?

Less than it sounds, and the consumer platforms have already answered half of it. Grok Bot's documentation: "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."²¹ These are per-person, persistent computers — not yet ephemeral, per-purpose cells — but they settle the economic question at consumer scale. A corporate only has to do it for its staff. Even a big staff is small by comparison.

The ephemeral version ships too. AWS's AgentCore gives each agent session "its own MicroVM, and that MicroVM is terminated when the session is over ... all the session context is securely forgotten."²² The substrate underneath, Firecracker, was built precisely because the old trade-off — strong VM isolation with high overhead versus cheap containers with weak isolation — was "unacceptable to public infrastructure providers"; it now carries millions of production workloads.²³

The honest summary of the cost argument: it was an inversion that was too costly for humans to build and operate for a long time, and it's fairly natural for machines. The plumbing for a thousand tiny systems is exactly the kind of work AI now builds and maintains cheaply. I'm not going to invent a per-cell cost for an insurer; nobody has measured one publicly. The shape is: substrate cost falling, operations cost dominated by automation you'd have to build anyway, and the prize is a breach that stays small.

This extends something I built earlier for AI agents. SiloOS gives each agent invocation task keys scoped to "this customer, this case, this conversation", expiring when the task completes. The cell takes the same idea off the agent and puts it under every principal — and changes the threat. SiloOS asked what an untrusted agent inside the cell could reach. This asks what anyone who has already broken the cell wall can do with what they find.

6. Bind it down the stack: cryptographic tenancy

Isolating compute is necessary. It isn't sufficient, because hypervisors get bugs and — as Mythos showed — a determined search finds them. So the second move is to make the cell's contents cryptographically useless outside the cell.

Push it all the way down: memory, operating system, disk, network. Everything the app can touch is encrypted to keys that exist just for that principal and purpose. If you don't hold that key pair, the thing does nothing for you at all.

The building blocks are commercial today:

• Per-VM memory keys. AMD's SEV "uses one key per virtual machine to isolate guests and the hypervisor from one another"; SEV-SNP adds memory-integrity protection against hypervisor-based attacks.²⁴ Intel TDX offers the equivalent "trust domains".
• Attestation-bound key release. Azure confidential VMs provide "Secure key release with cryptographic binding between the platform's successful attestation and the VM's encryption keys" and bind disk keys to the VM so they "securely bypass Azure components, including the hypervisor and host operating system."²⁵ AWS KMS can refuse to operate a key unless an enclave presents a signed attestation whose measurements match policy.²⁶
• User-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."²¹

Binding those per principal and per purpose — rather than per workload or per customer account — is the proposal. Combine it with the cell and identity stops being a question the app answers repeatedly. It becomes a property proven once per ephemeral cell and enforced by cryptography down the stack. The network, in the strong version, doesn't inspect packets for credentials at all: the only traffic that gets through to a cell is traffic sealed for that cell.

And the payoff:

"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

What this doesn't buy you

Confidential computing is not a wall, and anyone who sells it as one is repeating the mistake this article is about. CacheWarp broke SEV-SNP guest integrity with software fault injection, recovering an RSA key and escalating to root.²⁷ Heckler and WeSee used hypervisor-injected interrupts against SEV-SNP and TDX guests. TEE.fail used an interposer on the memory bus to extract keys — "in some cases secret attestation keys from fully updated machines".²⁷

Look at the shape of those breaks: a shared CPU core, a shared platform attestation key. Shared fate again, at the silicon layer. So treat cryptographic tenancy as a binding layer that makes a stolen memory image or disk worthless elsewhere, not as the thing that stops the break. And note where crypto still has to terminate: somewhere, keys are held in plaintext. The rule for that termination point is four words long — small, measured, short-lived, and useless outside its measured context.

7. The trap one layer down

Every cell architecture I've sketched fails the same way on first draft. You isolate compute per principal and then quietly rebuild multi-tenancy underneath it.

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 flagged it before I'd finished describing the cell; I've been finding it in designs ever since.

The Hugging Face attacker didn't need a hypervisor zero-day to go horizontal; it needed one shared connector credential and one secrets object with 136 keys in it. Shared fate hides in unglamorous places:

• The data tier. A cell that reaches the database with a service account that can read every row has rebuilt the shared app one hop later. The cell should reach data only through a narrow capability scoped to the principal — which, for a claims officer, is the data she could already see as herself. The database's own admin paths live off the workload network entirely.
• The control plane. Whatever creates cells, mints keys and pushes images must not be reachable from any cell. Mandiant's 2026 guidance is blunt: "Virtualization and management platforms must be treated as Tier-0 assets".⁷
• Identity and signing. Keep your identity provider; M-Trends still recommends one. But its output must be scoped per principal and purpose, never a token or key valid everywhere. Storm-0558 is what a global key domain costs.
• Secrets stores, logging pipelines, backups, admin tooling, mesh-VPN keys, egress IPs. Each is a place many principals' fates meet. NotPetya spread with PsExec and WMI — the organisation's own shared admin machinery.¹²

I'll apply this to my own earlier work, because it's the honest test. SiloOS concentrates trust in one small, hardened router that mints every key. Under 2026 search pressure, that router is itself on the shared-fate map. The design goal survives — keep it small and hardened — but it gains three requirements: off the workload path, unreachable from any cell, and minting per-cell roots so that even its compromise is the one thing you defend like a crown jewel rather than the thing that quietly unlocks everything.

The shared-fate map

The instrument for finding the trap is simple enough to start this month. For one workload, list every component that more than one principal depends on. For each, answer one question: if an attacker owned this, what would it give them toward other principals?

Rows like these are illustrative; your map will be longer and more embarrassing, which is the point. The companion to this map is Compile the Bounded Object's compositional containment test, which asks whether permitted interactions inside one environment can combine into an unpermitted capability. The shared-fate map asks the across-principal question.

8. Tier by consequence

Not everything needs a confidential, per-purpose, ephemeral cell. The rule that matters is the hard one — breach isn't transitive — and the strength of isolation should rise with what a breach would cost.

Okta's 2023 incident is a working example of tiering: the FedRAMP High and DoD IL4 environments used a separate support system, so they didn't share the fate of the rest.¹⁵ And this is where hyperscalers stay in the story. At the high-assurance end they end up selling less hyperscale than isolation by another name — dedicated hardware, confidential VMs, private links. Match the ceremony to the consequence; I argued the same logic for per-action authority in the Agent Provenance Stack.

9. The CISO's move: the second-breach drill

Now back to the person I kept picturing throughout. Imagine you're the CEO or CISO of a large Australian insurer under APRA. You've heard about the Hugging Face attack like everyone else. You can't delegate it — "I signed off on the hyperscaler's security audit, it's their problem" is not available to you. If you get breached you can't throw up your hands. You're on the hook. And the honest answer from most internal teams right now is still patch, scan, segment, plus some zero trust. I don't think anybody's doing anything very useful yet.

APRA's standards say plainly why the vendor's audit letter isn't an answer. Under CPS 234, "The Board of an APRA-regulated entity (Board) is ultimately responsible for the information security of the entity."²⁸ Where a third party manages your information assets, you must "assess the information security capability of that party", "evaluate the design of that party's information security controls", and — if you rely on their testing — judge whether it is commensurate with, among other things, "the rate at which the vulnerabilities and threats change".²⁸ CPS 230 adds that you "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".²⁹ APRA's April 2026 letter on AI noted "an overreliance on vendor presentations and summaries" and flagged "third-party and concentration implications in relation to common platforms, services, and providers".¹¹

(This is orientation, not legal advice. The obligations are the entity's and depend on the deployment.)

APRA and ASIC's August roundtable paper names the same shared-fate problem at sector scale: "common dependencies and concentration risk associated with third-party service providers can turn isolated individual incidents into much broader sector wide disruption".³⁰ Regulation applies accountability pressure, AI applies technical pressure, and AI-built infrastructure changes the economics. That convergence is why the move below is available now.

The drill

The move is a scenario exercise with a sharper premise than a normal pen test. Assume the first breach. Assume the attacker's AI finds another unknown vulnerability. Show how that doesn't get the attacker anywhere consequential. That's a much stronger posture than "the vendor assured us".

1. Pick one critical workload — claims lodgement, say — and draw its shared-fate map.
2. Grant the attacker a beachhead in one principal's session or one component. Don't debate how; the premise is that they're in.
3. Grant a second unknown vulnerability at the next boundary they touch. Don't debate that either.
4. Trace what they now hold: credentials, keys, network reach, data, and any component shared with other principals.
5. Record where the chain dead-ends — or doesn't — and which row of the shared-fate map let it continue.
6. Fix the architecture, not the finding: remove, scope or re-tier the shared component, then re-run the drill.
7. Show the board the chain, not a certificate: "this is what breach two buys today; this is what it will buy after the change."

The APRA–ASIC paper asks boards to "prove disruption readiness" and warns that "If key decisions would be debated for the first time during an incident, this should be treated as a priority gap."³⁰ The second-breach drill is how you have that debate on a Tuesday afternoon instead.

10. What I'm not claiming

• Not "cloud is dead". The pattern is anti-shared-fate. Hyperscalers can and will sell isolation tiers.
• Not "stop patching". Patching is hygiene; it just can't be the strategy against a negative time-to-exploit.
• Not "confidential computing is unbreakable". It's a binding layer with its own published breaks and its own shared roots.
• Not "everything needs an air gap". Tier by consequence.
• Not a measured deployment. This is an architecture pattern assembled from shipping building blocks and 2026's incident record. The cost per cell at an institution, the share of a real estate that decomposes cleanly per principal, and the side-channel exposure under AI search are open questions to test — which is what the drill is for.

Close: make breaches boring

The industry has spent thirty years trying to make the wall hold. AI has changed the terms: the wall will be searched, cheaply, forever, by something that never gets bored. You can keep raising the wall — you should — but the variable you still control is what the wall's failure is worth.

Shrink the unit of computing to one principal and one purpose. Bind everything the cell touches to that principal. Hunt down the shared things one layer below, including the ones you designed. Tier by consequence. Then prove it with a drill your board can read. The goal isn't that you'll never be breached. It's that a breach doesn't compose — that it's boring, local, disposable, and worthless outside the one small box it happened in.

Scott Farrell is an enterprise and AI architect at LeverageAI, working with Australian leadership teams on AI governance and architecture. He built SiloOS, a containment architecture for untrusted AI agents. scott@leverageai.com.au · leverageai.com.au