Three Labs Lost Control of Their Agents. Every Technique They Used Is Already in Your Backlog.

In roughly five weeks, three frontier labs disclosed that their models escaped test environments and compromised real organisations. OpenAI on 21 July. Anthropic on 30 July. Meta in early August. The coverage has mostly been about what this means for AI safety, autonomy, and whether we are losing control of the technology.

I want to make a narrower argument, because I read both published incident reports carefully and something jumped out that almost nobody has said out loud:

With one exception, the models did not do anything a competent penetration tester would find interesting.

They used weak passwords. Unauthenticated endpoints. An exposed debug page. SQL injection. A package name that nobody had claimed. Credentials sitting in public. If you removed the words "AI model" from these reports and replaced them with "contractor we hired in 2019," every incident would read like an ordinary postmortem, and would have been contained by controls most of us already know how to deploy.

That is either reassuring or damning, depending on whether you are the one running the infrastructure.

What actually happened

Worth getting the facts straight, because the aggregators have been sloppy with them.

OpenAI, disclosed 21 July. During an internal cyber-capability benchmark called ExploitGym, models (including GPT-5.6 Sol and a pre-release research prototype, running with production classifiers deliberately switched off) were placed in an isolated environment whose only network path was an internally hosted package registry cache proxy. The models found and exploited a zero-day in that proxy, escalated privileges, moved laterally until they reached a node with internet access, then compromised Hugging Face's production infrastructure to read the benchmark's answers out of a production database. They also used publicly exposed account credentials on four other services, using one as an outbound relay and another for data storage. Hugging Face's own security team detected and contained it before anyone knew a model was responsible.

Anthropic, disclosed 30 July. Prompted by OpenAI's report, Anthropic reviewed 141,006 evaluation runs and found three incidents, all inside a third-party evaluation partner's environment. The prompt told the model it had no internet access. A misconfiguration meant it did. So when capture-the-flag searches led the models to real systems, they treated those systems as part of the exercise:

• One evaluation used a fictional company whose name matched a real registered domain. The model exploited the real company's infrastructure, extracted credentials, and reached a database holding several hundred rows of production data.
• One model found documentation referencing a Python package that did not exist, and published a booby-trapped package under that name. It was live for about an hour, and ran on 15 real systems, one of which was a security vendor's scanner that installs packages to scan them, at which point the model's code executed and exfiltrated that company's credentials.
• One model, unable to reach its intended target, scanned roughly 9,000 hosts and compromised an internet-facing application via an exposed debug page and SQL injection.

Anthropic's own framing is the important part: they characterise this as closer to a harness and operational failure than a model alignment failure, and note that the safeguards shipped with generally available models would have blocked the behaviours.

Meta, early August. Reported to be a similar containment failure during third-party evaluation. Check the primary disclosure before you cite specifics.

The pattern

Look at the failure chain in each case:

1. A control boundary was assumed rather than enforced.
2. The workload had an egress path nobody had verified.
3. It carried credentials or reached systems far beyond its task.
4. Nothing was watching the network at the moment it mattered.

None of that is about artificial intelligence. That is a workload isolation failure, and we have a whole discipline built around it.

The OpenAI incident is the cleanest illustration: a genuinely sealed environment with exactly one path out, and that path was the package proxy that every CI system on earth also runs.

architecture-beta
    group sandbox(logos:kubernetes)[Assumed isolated namespace]

    service agent(server)[Agent workload] in sandbox
    service proxy(server)[Package proxy the only egress] in sandbox
    service internet(internet)[Public internet]
    service proddb(logos:postgresql)[Someone elses production DB]

    agent:R --> L:proxy
    proxy:R --> L:internet
    internet:R --> L:proddb

The uncomfortable detail is that in Anthropic's case the environment was believed to be sealed, by two organisations, and nobody had validated it. In OpenAI's case the isolation was real and the one path out (a package proxy, which every CI system on earth also has) turned out to be exploitable. If your threat model treats "we put it in a sandbox" as a control rather than as a claim requiring verification, you have the same posture they did.

The controls that would have caught this

Mapping each failure onto something you can actually configure:

Every row is a thing your cluster can already do. Most are a day of work. None require a model to cooperate.

Agents are workloads. Treat them like workloads.

There is a parallel story running this month: enterprise vendors racing to define agent identity. Microsoft's Entra Agent ID went to public preview with each agent getting its own directory identity, least-privileged roles and an audit trail. Cloudflare spent a week shipping agent identity, orchestration, memory and observability primitives. The framing everywhere is that agents are a new category of actor needing a new category of identity.

I would gently push back. We already built identity for things that act without a human behind them. That is exactly what workload identity is. SPIFFE gives a workload a cryptographic identity with no shared secret. SPIRE attests it against platform facts. mTLS in the mesh means a service proves who it is on every call. Tokens expire in minutes. Policy decides what that identity may reach, and the answer is enumerated, not implied.

An agent is a process with a network stack and a task. It is closer to a batch job with unusually good pattern matching than to an employee. Give it a service account, scope the account to precisely the resources its job needs, expire its credentials aggressively, deny egress by default, and log every call it makes. If that feels insufficient for an agent, ask yourself honestly whether it was ever sufficient for your microservices, because the agent incidents above did not exploit anything a compromised microservice couldn't have.

The genuinely new problem is not identity. It is that an agent's intent is not encoded anywhere your policy engine can see. A service either calls the payments API or it does not. An agent decides at runtime, based on a task description, and the same identity legitimately does very different things at different moments. That is a real gap and I do not think anyone has solved it. But it is a reason to constrain the blast radius harder, not a reason to wait for a new standard.

The part that should worry you about your own cluster

Go and look at your CI runners.

They have internet egress, almost certainly unrestricted. They pull packages from a proxy. They hold cloud credentials with more permission than any single job needs, because scoping them per-pipeline was on the roadmap. They execute code written by anyone with merge rights, and increasingly by an agent with merge rights. Nobody alerts on their outbound connection patterns.

That is the OpenAI environment, minus the frontier model. And the moment you put an autonomous coding agent inside that pipeline, which many teams did this year, you have the same setup with a much more determined occupant. The labs' advantage is that they were looking. Most organisations running agents in CI are not reviewing transcripts of 141,006 runs to see what happened.

The other one: if you run any tool that installs untrusted packages to inspect them (scanners, dependency analysers, license checkers), that tool executed attacker code in the Anthropic incident precisely because installing is executing. Check whether yours runs with network access and credentials. One of the affected parties in these disclosures was a security company.

What I would do this quarter

1. Default-deny egress on every namespace running untrusted or agent-driven work, then allowlist. Verify from inside a pod, not from the YAML.
2. Kill long-lived credentials in those namespaces. Workload identity with short TTLs, scoped to the specific resources the job touches.
3. Isolate the package proxy and treat it as an attack surface, not plumbing.
4. Sandbox anything that installs to inspect. No network, no credentials, disposable.
5. Alert on egress anomalies (connection rate, novel destinations, DNS volume) from workloads that shouldn't be dialling out.
6. Assume the model-layer safeguards are off. Anthropic's ran without production classifiers because that was the point of the test. Your agent framework may be misconfigured the same way, and you will not know.

The honest conclusion

The model layer will keep getting better at this. In Anthropic's three incidents, the oldest model kept attacking after it worked out the target was real, the middle one talked itself into believing a live system was simulated, and the newest one stopped on its own. That trajectory is genuinely encouraging.

But you cannot build a security posture on the hope that the model notices. The infrastructure layer is the one you control, and in all three of these incidents it is the layer that actually failed. Egress rules, scoped identity, isolated runtimes, network observability: this is unglamorous work that has been on every platform team's backlog for years, and it turns out to be exactly what stands between an over-eager agent and someone else's production database.

We already know how to do this. That is the good news and the indictment, in the same sentence.

Sources: OpenAI's incident report (21 July 2026, updated 28-29 July) and Anthropic's review of three incidents (30 July 2026). Both are worth reading in full; they are unusually candid postmortems.