In July, the two best resourced AI companies in the world lost control of models during their own safety testing. OpenAI learned its agent had broken out from the blog post of the company it broke into. Anthropic found its own three incidents, but only because OpenAI's made it go and look.

That is the issue, and it is worth sitting with before any of the detail arrives. These are organisations with more money, more expertise and more incentive to get containment right than any regulated operator reading this. In neither case did routine monitoring surface the problem.

Issue 2 of this newsletter asked every asset operator two questions. Could you demonstrate, without convening a working group, what critical assets you operate, who owns each one, and what condition they are in. And if you are running AI against that infrastructure, could you demonstrate where the data behind it came from, whether it is governed, and who is positioned to intervene when it gets something wrong.

I wrote that as a diagnostic for any organisation whose operation depends on assets it does not fully see. Defence estates, NHS Trusts and critical infrastructure operators, certainly, but equally government departments, facilities management providers, manufacturers and local authorities. It was built around two regulators converging on the same blind spot. The Cyber Security and Resilience Bill (CSRB), the UK's answer to the EU's Network and Information Security Directive 2 (NIS2), starts from the asset and asks whether you can see it. The EU AI Act starts from the algorithm and asks whether you govern its data.

I also flagged that the AI Act's teeth were softer than the headlines suggested. The Digital Omnibus, given final Council approval on 29 June, defers the Annex III high-risk obligations, the ones requiring documented data governance, logging and designed-in human oversight, to 2 December 2027. That deferral matters more now than it did when I wrote it, because it removes the easiest excuse for inaction. Regulators have handed the industry sixteen extra months to prove it can govern AI systems against exactly this standard. July was the month the industry showed it cannot yet do that for its own.

What happened

OpenAI disclosed that a model combining GPT-5.6 Sol with a more capable unreleased system was placed in what it called a highly isolated testing environment, with some safety guardrails deliberately disabled, to measure advanced cyber capability. The environment was meant to have network access restricted to a controlled internal package installer. It did not hold. The model exploited an unknown flaw, reached the open internet, and breached the systems of Hugging Face, apparently to find information that would let it cheat the evaluation it was undergoing.

The timeline should concern a governance audience more than the exploit. Reuters reported that the model first attempted to break out on 9 July, and that the attacks on Hugging Face ran from 11 to 13 July. Hugging Face detected the intrusion itself, treated it as a serious external attack, and alerted the FBI. On 16 July it published an account of being hacked by an autonomous AI agent system, without naming an attacker, because it did not know who the attacker was. OpenAI did not find this in its own logs. It learned that the agent was its own from that public blog post, and confirmed responsibility on 21 July, roughly ten days after containment failed and a week after Hugging Face had stopped the attack and gone to the FBI.

Dan Guido, founder of the security firm Trail of Bits, called it "a containment failure with the safeties turned off". Cybersecurity veteran Jake Williams was blunter, calling it "a massive control failure" and noting that "any model performing the types of actions documented by Hugging Face was not fully contained in a sandbox". His summary is the line worth keeping: "One man's 'the model escaped the sandbox' is another man's 'you failed to build the sandbox correctly, so of course it escaped.'" The isolation OpenAI described was not isolation, and the company did not know until an external party's incident response surfaced it.

Anthropic's case is a different shape of the same problem. In March it quietly added hidden code to Claude Code, using prompt steganography to signal a user's environment, including timezone and proxy details, back to its servers. The purpose was defensible, detecting unauthorised resellers and distillation by rival labs. The method was not in the release notes, not documented anywhere a user could find, and was only discovered in late June by developers reverse engineering the binary for unrelated reasons. Anthropic removed it within days of the finding going public. Alibaba classified Claude Code as high risk software internally and stopped employees using it, citing backdoor risk.

Neither company set out to be reckless. Both were solving real problems. But in both cases the governance question that matters, could you demonstrate what this system was doing and who was positioned to catch it, was only answered after an outsider forced it.

Since this was written, both stories grew

Two developments after the first draft of this issue, and both sharpen rather than soften the argument. Between them, the count of real organisations reached by models that were supposed to be contained rose from one to eight: five in the OpenAI incident, three in Anthropic's, across both labs, inside a single month.

The OpenAI incident was larger than first disclosed. Reuters reported on 28 July that the same agent also broke into four further accounts across four separate services during its run, one of them a customer of the New York infrastructure firm Modal Labs. Modal was clear that it was not itself breached: the agent exploited a customer's own code, an unauthenticated endpoint published to the open internet that let anyone execute code in their sandboxes. OpenAI says it has found nothing else at the scale of the Hugging Face compromise. Note what changed, though. The first account described one victim. The fuller account, arriving a week later, described four. The scope of an incident is itself something an organisation has to be able to establish, and OpenAI's own estimate moved after external reporting did.

Then, on 30 July, Anthropic published its own disclosure, covered in the UK by the BBC among others. It describes the same thing happening three more times. During cyber evaluations, three Claude models, Opus 4.7, Mythos 5, and an unreleased internal research model, broke out of their testing environment and gained unauthorised access to the live production infrastructure of three different real organisations. Not test targets, and not simulations: three separate companies, hacked, exactly as Hugging Face was. The models believed throughout that they were inside simulated capture-the-flag exercises. The cause was a misconfiguration between Anthropic and its evaluation partner Irregular: the evaluation prompt told the model it had no internet access, while the machines it was running on had live internet access. The earliest incident dates to April. Anthropic stopped all cyber evaluations on 23 July, identified all three cases by 24 July, and notified the affected organisations on 27 July.

Two details in that disclosure deserve more attention than they have had. The first is what prompted it: Anthropic went back through more than 141,000 evaluation records, and only found these three because OpenAI's incident made it look. The second is how the models got in. They did not deploy novel exploits. They used weak passwords and unauthenticated services, the same unglamorous weaknesses that have featured in breach reports for thirty years.

Read the cause again, because it is the most quietly devastating sentence in either disclosure. The control existed in the prompt. It did not exist in the environment. The organisation running the test believed the two matched, and nothing in its process checked. That is not an AI problem. It is a configuration management problem, and it is the same one that produces an asset register saying a valve is isolated when the valve is live.

Anthropic's remediation list is worth reading as a governance template rather than an AI story: continuous monitoring of evaluation transcripts for unexpected behaviour, better investigation tooling, and more rigorous assurance work with vendors. Monitoring, evidence, and third-party assurance. Nothing in that list is novel, and nothing in it is specific to AI.

This is not an isolated pair

It would be easy to file both as AI industry gossip. The wider evidence says otherwise, and it has been accumulating for months.

On 1 July, the United Nations Independent International Scientific Panel on AI published its preliminary report, identifying a specific engineering gap: there are currently no known technical guarantees that AI agent systems will follow their instructions consistently, and evidence of systems acting contrary to instructions is already accumulating. That is not a campaign group. It is a panel of forty scientists, selected from more than 2,600 candidates across 140 countries, reporting into the United Nations.

The Cloud Security Alliance has catalogued ten consequential agent security incidents in its 2026 research paper The Cost of Unchecked Autonomy, and its survey work puts the share of organisations reporting an AI agent incident in the past twelve months at around two thirds. MIT Sloan researchers have named the underlying pattern an authority gap, organisations deploying agents into environments where the oversight infrastructure was never built to follow them. Mayer Brown's practitioner guidance on agentic AI governance lands on two foundational safeguards, least-privilege technical controls and structured human oversight checkpoints, precisely the two things absent from OpenAI's test environment.

The consistent finding across all of them is not that AI agents are dangerous in the abstract. It is that deployment is outpacing the control infrastructure, and that the organisations deploying agents frequently cannot say what those agents did.

Why this belongs in Foundations First

The CSRB does not ask whether your organisation intended to have good asset visibility. It asks whether you can demonstrate it, on request, without a scramble. The AI Act does not care whether your data provenance gap was oversight or a trade off made under commercial pressure. Both regimes rest on the same premise as the Issue 2 diagnostic, that intent is not evidence, and that the gap between "we believe our controls work" and "we can prove what this system did last Tuesday" is exactly where regulatory exposure lives.

OpenAI believed its sandbox was isolated. Anthropic believed its tracker was a contained experiment. In both cases the actual state of the system diverged from the organisation's own account of it, for weeks or months, without anyone inside noticing.

A Defence estate that can name every classified system on its network but cannot say, within a working day, which facilities management contractor holds keys to the building housing them has the same structural gap as OpenAI's sandbox. An NHS Trust running a scheduling or triage tool without a clear answer on where its training data came from and who can intervene has the same structural gap as Anthropic's undisclosed tracker. So does a government department that has outsourced its estate and retained the accountability. So does a facilities management provider running condition surveys across dozens of client sites on a data model nobody has audited since mobilisation. So does a manufacturer whose production line depends on a supplier tier it has never mapped. The asset class differs. The sector differs. The failure does not.

That first example is not hypothetical, and I should stop presenting it as though it were. In September 2025 a maintenance contractor working across the defence estate was breached, and roughly a thousand documents covering eight Royal Air Force and Royal Navy sites were posted to the dark web. Two of those sites host United States Visiting Forces. Reported among the material were visitor records, vehicle registrations, mobile numbers, personnel names and email addresses, and internal security guidance. That is not a set of records any department would want assembled and published by somebody else. Sixteen months earlier, a payroll system operated by a third-party shared services provider had been compromised, holding the names and bank details of up to 272,000 serving personnel and veterans. Neither incident came through the department's own systems. Both came through a supplier holding its data.

And this is not a Defence problem wearing a Defence uniform. Issue 2 mentioned the Jaguar Land Rover attack in passing, as an attribution story. It is a better supply chain story. The attack began in late August 2025 and halted production across three UK plants for five weeks. The Cyber Monitoring Centre classified it as a Category 3 systemic event, modelled the total loss at £1.9 billion within a range of £1.6 billion to £2.1 billion, and put the number of UK organisations affected at more than 5,000. It described the incident as the most economically damaging cyber event to hit the UK. Most of that impact was lost manufacturing output, and not only at the manufacturer. It fell across a supplier base whose own systems were not the ones attacked. Those firms could not trade, because the organisation at the centre of their operating model had stopped.

That is the same structure as the Defence incidents, viewed from the other end. In Defence, a supplier's weakness exposed the department. In manufacturing, the manufacturer's outage exposed thousands of suppliers. Either direction, the dependency was real, material, and largely unmapped before the event forced someone to map it.

And none of it requires an attacker. In April 2022 the arrangements for maintaining service family housing were restructured across several contractors. The Defence Committee later found that there was no contractual interface between them, so "no one contractor had responsibility for the mobilisation and transition of service", and that problems with the service families received were compounded by "an information system which does not hold sufficient information". There was no breach and no adversary. The same inability to establish what the record actually held produced the same result.

Which makes the Issue 2 question harder than the one I actually asked. It is not only whether you know which contractor holds the keys. It is whether you know who that contractor has subcontracted to, what those firms hold on your estate, and whether either of you could produce that list this week rather than next quarter. And it runs the other way too: if you stopped on Monday, who else stops on Tuesday, and do you know their names. A supply chain is only assured to the depth you have actually looked. Most are assured to the first tier and assumed beyond it, and the assumption is where the exposure sits.

And if that is the state of self knowledge at the frontier, the diagnostic for regulated UK sectors is not softened by comparison. It is sharpened. Waiting for vendors, platform partners, or the labs themselves to solve this first is waiting for a bar that has not been cleared by the companies setting it.

What the board actually owns here

The temptation is to convert this into a management action. Ask the CIO for an AI governance update, receive a paper, note it, move on. That response is itself the failure being described, because in both July incidents the management line believed the controls were working. The gap was not that nobody had asked. It was that the answer had never been independently tested.

Board rigour here has four components, and only the first is comfortable.

One, separate assurance from delivery. The team building or procuring the AI capability cannot be the team assuring that its data provenance and oversight arrangements hold. OpenAI's evaluation team was assuring its own containment. That is a structural conflict, not a competence failure, and it is one a board would refuse to accept in financial controls without a second thought. If the paper coming to your board was written by the function delivering the AI, you have a management update, not assurance.

Two, require named individual accountability. "IT owns this" is not an answer a board should accept. A named executive, in the minutes, who can be asked in twelve months what changed. The AI Act's Article 14 human oversight requirement and the CSRB's asset ownership expectations both resolve to a person, and a board that has not named one has deferred the naming to whoever happens to be in the room when something goes wrong.

Three, require evidence, not assertion. The distinction between "we have data governance" and "here is the record of what this system did last Tuesday and why" is the entire distinction the regulators are drawing. A board can test this cheaply. Pick one AI system, ask for the record of a specific decision it made last month, and time the answer. That single request reveals more about readiness than any maturity assessment.

Four, treat 2 December 2027 as a working deadline, not a reprieve. The Annex III obligations moved because they are hard, not because they stopped mattering. Note also that the Article 50 transparency obligations were not deferred and have applied since 2 August 2026. A board reading the wider delay as breathing room will find, in late 2027, that it has eighteen months of remediation to fit into six.

The question to put on the agenda

Not "are we compliant." Compliance is a management assertion, and for the high-risk obligations it is not yet technically possible to breach. Ask instead the question July made unavoidable.

OpenAI took a week to notice, and revised its own estimate of the damage after a reporter did. Anthropic ran misconfigured evaluations from April to late July. How long would we take, and who in this room would be the one to find out.

If the honest answer is "longer, and probably nobody," that is not cause for panic. It is the most useful thing a board can establish in a single meeting, because it converts an abstract governance concern into a specific, minutable gap with a named owner and a date. That is what board rigour on AI looks like. Everything else is a paper.

If you sit on a board or an audit and risk committee in a regulated sector and you have found a way to test this that works, reply and tell me. And if you are the one presenting the paper, tell me what your board asks you, and what you wish it asked instead, through the contact page or on LinkedIn. I am building a view on what good board-level assurance looks like here, and I read every response.

Alex Brain Founder and Managing Director, Brainwave Asset Intelligence

References

Every factual claim above traces to one of the following. Primary sources are linked; where a claim rests on Reuters reporting, the outlets carrying it are named so the chain is checkable.

The OpenAI incident

  • Reuters, 21 and 28 July 2026, carried by CNBC, Axios, Bloomberg, Fortune and Fox Business: the containment failure, the 9 to 13 July attack window, Hugging Face's 16 July disclosure and FBI referral, OpenAI's 21 July confirmation, and the later finding of four accounts across four services including a Modal Labs customer.
  • TechCrunch, 22 July 2026, on the configuration error behind the escape.
  • Dan Guido (Trail of Bits) and Jake Williams, quoted in the above coverage.

The Anthropic incidents

The Claude Code tracker

  • Reported 30 June to 1 July 2026 following independent discovery by two developers; Malwarebytes and TechTimes for the mechanism, the removal, and Alibaba's internal classification.

Supply chain incidents

Regulatory and wider evidence