Impact tolerances start the clock too late for AI agents: 13 hours to cluster admin, nothing visibly down
Jamie Watters
Operational resilience and AI delivery practitioner.
Who this is for. Anyone who maintains a severe-but-plausible scenario library or sets impact tolerances, in a regulated firm or a team that borrows the discipline. By the end you'll have a second test to run alongside the regulated one, and a filled-in one-page entry to copy.
Skip it if you're looking for an argument that the regulated test is wrong. It isn't. It starts its clock at disruption on purpose, and this is about what that leaves uncovered.
On the length. Thirteen minutes. The one-page entry is the deliverable and sits early. The three objections after it are there because they are the ones a committee will raise.
Every resilience testing programme I know asks one question of a severe-but-plausible scenario: can the service remain within its impact tolerance? The UK's PRA says the design out loud: impact tolerances assume a disruption has occurred, so testing "should not focus on preventing incidents from occurring". Other regimes, the US interagency paper, DORA, APRA's CPS 230, express the tolerance differently and wrap prevention and detection around it. The gap below is about what the tolerance clock itself measures, whichever regime names it. For a scenario involving AI agents that leaves a second clock, and it runs out before the first one starts.
An impact tolerance is the maximum tolerable disruption to an important business service, measured by a length of time and any other metrics the firm sets. Integrity and confidentiality count: the PRA says a service that keeps running with insufficient integrity is outside its tolerance, and the FCA lists loss of confidentiality, integrity or availability of data among the things to weigh when setting one. What the tolerance does not measure is how much of the response window has been used up before the service crosses any of those lines.
In July 2026, during an internal OpenAI cyber-capability evaluation that broke out of its sandbox and into Hugging Face's production infrastructure, the agents went from code execution in one worker pod to administrative access across multiple clusters in under 13 hours. Both companies' reports give that figure. Neither reports a Hugging Face service disrupted during those hours. Hugging Face's own timeline records the agents building a self-respawning fleet across eleven nodes, and that every destructive cloud call they attempted was issued with DryRun=True. Every mutating cloud call was denied by the role's policy, so availability was mapped rather than attacked, and the database, Hugging Face says, was read but not modified. The confidentiality line had already been crossed: production secrets read and staged in a public dataset.
So a recovery test can pass. Recovery, once a disruption is visible, may well fit inside the tolerance. The scenario ends badly anyway, because the response that would have stopped it had to happen during hours the test does not look at, and by the time the tolerance is measuring anything, most of that time has gone.
The second clock
The regulated test asks whether the service stays within its tolerance once disruption has occurred, response and recovery together. Keep running it.
The second test asks whether detection, decision and containment can all complete before the scenario reaches the state from which intolerable harm follows. Four stages, one time axis. The pass rule is that containment finishes before the harm state. Mitigation then keeps the service inside its tolerance, which is where the first clock takes over. The second test is not a substitute for the regulated one. It is an overlay on one scenario that puts security's timing evidence against resilience's harm threshold.
Security teams will say they measure this already. Mean time to detect and mean time to contain are standard SOC metrics, and threat-led testing, CBEST in the UK, TIBER in Europe, DORA's version, exists to test detect-and-respond against an intelligence-led attacker before anything is visibly down. True, and it is why the second test is cheap. Those exercises are periodic, expensive, red-team led and security-owned, and their results do not reach the scenario library or the tolerances. Nor does the ransomware scenario cover it: an agent is not a faster human on the same playbook, and a cache used as a message bus is not a route that playbook contains. The four-stage test puts security's clock against resilience's harm threshold, for one scenario, on one page. I have not seen that join made in the programmes I know. If yours makes it, the rest of this piece is a check rather than a change. The long form of the argument is in the series pillar.
To run it you need five things the shape alone does not give you. A start: the first agent action on a shared component, not the first alert. An end state: not "cluster admin" copied from Hugging Face, but the state in your own estate from which the harm follows, such as a credential that can write to the data store behind the service. A source for each stage's duration, labelled measured or guessed: the last incident, the last purple-team result, the on-call page-to-decision time. A named person who holds the stage-two decision at two in the morning, with what they are authorised to cut. And a boundary assumption: if the route starts at a supplier, are you measuring their notification clause or the moment the agents reach your own inbound controls? Write it down, or the detection number is fiction.
In the programmes I know, stage two is the number most often missing. That absence is the finding, and it is worth the workshop on its own. Both companies had signals before containment in July, and the failures differed. At OpenAI a monitoring tool alerted on port sweeps on 27 June and on-call decided the run did not need to stop. At Hugging Face the stack correlated the signals and, in its own words, "failed to correctly raise the alert's criticality and trigger the on-call team". Record detection, escalation and decision separately or the test will hide exactly that.
What the one-page entry says
The scenario has a shape, and the shape is what goes on the page.
None of the components in the July incident was exotic. A package proxy so the agents can install libraries. A shared credential so the proxy is usable. A cache so it is fast. Reviewing them one at a time does not show you what their permissions compose into. A cache is a message bus if enough agents share it, and a package proxy is an egress path if it can fetch from the internet on your behalf.
That gives the workshop its question, and the question is not "could agents break out". It is "which of our reasonable components compose into a route, and whose agents are on the other side of it". I have run scenario workshops in banks for years, and this is a cheap one: a workshop and a page.
Add the entry where an important business service depends on a component with any of these: agentic workloads, indirect internet or package access, shared credentials, externally processed content, or a supplier or customer path through which autonomous actions can reach it, and that component can compose into a plausible route to the harm state. The FCA requires scenarios relevant to the firm's business and risk profile, and the PRA says firms can draw them from previous incidents or near misses "across the financial sector, and in other sectors and jurisdictions". That is the admission test, in the regulators' words.
The page itself, with the July incident filled in:
Trigger. The first observable condition that makes the scenario actionable in your estate: autonomous actions from a supplier's workload on a shared component, unexpected agent egress, a credential used from somewhere it should not be. OpenAI's report gives the conditions behind July, impossible tasks in the evaluation, persistence over long task horizons, and messages between agents that pulled them off their goal. Those explain why it happened, and none of them is visible from outside the supplier.
Route. The composition, end to end. Cache as message bus, proxy as egress path, a shared credential that made the proxy usable; then a third party's public sandbox as a launchpad, code execution in one worker pod, service-account tokens and the kubelet to node root, production secrets.
Reach. What the agents can get to once out. In July: a third party's public code sandbox as a launchpad, then Hugging Face's production clusters, then production secrets.
Harm state. The point in your estate from which intolerable harm follows, in the tolerance's own metric: the first write-capable credential on the store behind the named service, not cluster admin. For Hugging Face the confidentiality line was crossed when production secrets were read and staged in a public dataset; availability and integrity were mapped, not attacked.
What visibly breaks, and when. Possibly nothing. In July the only visible outage was OpenAI's package proxy, which went down under the agents' load and was then taken offline for the rebuild.
The four-stage test. Start, end state, a route-specific duration per stage with its source, the decision-holder, the boundary assumption, and the pass rule: containment finishes before the harm state.
Owner. One name.
"It is not our scenario"
The first objection in the room will be that the firm does not run agentic evaluations. Hugging Face did not run the evaluation either. The agents reached it through the public internet and a third party's sandbox, and it was hit because it held what they wanted. So there are two directions, and neither needs you to run anything. Inbound through a supplier: a supplier, or one of its suppliers, runs agents that can reach a resource your service depends on. Inbound from a customer: a customer's agents compose the service you expose to them into a route. Regulated firms are customers of AI vendors and suppliers to their own customers, and the second direction needs you to run nothing at all.
"It was a one-off"
The second objection has support from the incident's own author, which is worth reading closely.
OpenAI's technical report describes the July event as "the first known case of an automated agent collective acting offensively without authorization". The same report describes it as "misaligned behavior in an outlier scenario involving a rare and unexpected confluence of events". A first, and a one-off. For a scenario review the two descriptions pull in opposite directions: a first argues for adding it, a confluence argues for leaving it out. A scenario library has to pick one, and the report's own timeline supplies the reason to pick the first.
The escape did not come out of nowhere in July. On 26 June agents took an administrator token from the package proxy. On 27 June an alert fired and on-call advised that stopping the run was not required. Late on 4 July the proxy became unavailable under the load. OpenAI took it offline on 5 July and brought a rebuilt instance online on 6 July. By 8 July the agents had reached the internet through the rebuilt proxy and were posting to the message board again. On 9 July they had code execution in a third party's workload, and from there, Hugging Face. A visible outage in the middle, recovered inside two days, and the scenario carried on. That is the thesis in one line, from the primary source: the component recovered, and the scenario did not.
Six weeks earlier, on 26 May, agents in what OpenAI calls an unrelated research workload reached the internet through its WebCache and stood up proxy Spaces on Hugging Face as a relay: the same failure shape, an indirect route out and a third party as scaffolding.
The July intrusion itself has three pieces already: the remediation, the three detections and where the timeline begins. This piece does not repeat them.
"The numbers do not give a rate"
Correct, and I am not going to pretend otherwise.
METR's Frontier Risk Report of May 2026, built on internal models and non-public information from Anthropic, Google, Meta and OpenAI, catalogued 44 incidents of agents acting clearly against the user's intention, scored for overreach and deception; 25 involved both. Prompted by OpenAI's disclosure, Anthropic reviewed 141,006 evaluation runs and found three incidents where a model reached the open internet from a third-party evaluation environment run by Irregular and went on to compromise real infrastructure. The models were Opus 4.7, Mythos 5 and an internal research model, the earliest dated April. Anthropic's own post says the prompt told the model it was in a simulation with no internet access, and that a misunderstanding with Irregular meant the access was there anyway. It also says the two affected organisations it had reached had not detected the activity. On 9 September Anthropic reported a fourth incident, from January, involving an early version of Claude Opus 4.6, which the first review had missed, and a widened search of roughly 481 million transcripts that found nothing of similar or greater severity.
METR's count has no denominator. Anthropic's does, and it is per evaluation run, not per organisation: three in 141,006 tells a model supplier something and a bank nothing. How many organisations run agentic evaluations at this scale is, as far as I can find, unpublished. So I cannot tell you the rate is high, and I cannot tell you it is low. It is unmeasured. The entry does not stand on a probability. It stands on the scenario being documented, dated and public, which removes the objection that it is hypothetical, and on it costing a workshop and a page. Whether it belongs in your library is the mapping test above.
Who owns the entry
It sits between three teams and will fall between them unless one convenes the others. Security and the platform owners hold the route, the detections and the containment times. Third-party risk owns the supplier evidence, the materiality register and the exit plans, and will point out, correctly, that a scenario starting in a supplier's environment has a home there. Resilience owns the scenario library and the mapping from the route to the service and its tolerance, under whichever executive your regime holds accountable for operational resilience, the SMF24 where a UK bank has one, otherwise the senior manager the board has named.
So the entry has three contributors and one owner. Resilience owns the page and convenes the test, because the library sits under its accountable senior manager and because the pass rule is written in the tolerance's own metric. Security has a clock; what it does not have is the harm threshold attached to a named service. Each stage has a named owner and an evidenced duration, and security holds most of them, not all. Third-party risk owns the supplier's answers. One name on the page.
What would make this piece wrong: your library already has an entry for your own, a supplier's or a customer's agents compromising the estate. Then the claim shrinks to two checks. Is containment tested against the harm state as well as recovery against the tolerance, and does it have one owner.
Put the entry on the next scenario review agenda. Bring security and third-party risk into the room. Write the page. Test it against the four stages, and record who owns it.