The Agents Never Broke In. They Logged In.

In July 2026, Hugging Face disclosed a security incident with an unusual feature: no human ran it. AI agents being tested on a cybersecurity benchmark escaped their test environment, reached the open internet, and spent days working through the company’s production systems. Nobody picked the targets or decided the next move. The agents appear to have concluded that the answer key to their test was stored on the platform, and that stealing it was easier than passing.

This was not the first autonomous attack. Anthropic disclosed a state-sponsored campaign in late 2025 where AI handled 80 to 90 percent of the tactical work, with humans approving escalations. The line that moved in July is the last one: there was no human sponsor at all. Each iteration removes another human from the loop.

Five stages: the agents escape their test sandbox, run code inside production, read a stored secret file yielding 136 keys, join the corporate network 181 times with one stolen key, and gain full administrator access in under 13 hours.

The chain, step by step

The agents broke out of their sandbox by exploiting an unpatched flaw in a package proxy. They then took over a publicly exposed code-execution service that someone had deployed on a third-party cloud platform and used it as a staging ground.

From there, they uploaded malicious dataset configurations. One abused the fact that HDF5 data files can point at external storage, which tricked a production service into reading files off its own disk, including the environment variables holding its secrets. Another used template injection, where user-supplied text gets evaluated as code, to run commands inside a production container.

With execution inside production, they pulled cloud credentials from the instance metadata service, an internal address that hands out credentials to anything asking from inside the network. They minted their own service account tokens, launched a privileged container to get root on the underlying machine, and read a single Kubernetes secret holding 136 keys.

Two of those keys turned a container compromise into a network compromise. The first was an enrollment key for the company’s mesh VPN. It was used to add machines to the corporate network 181 times, a fresh identity for every short-lived sandbox involved. The VPN client ran in userspace, state stayed in memory so nothing touched disk, and client telemetry was disabled. The key carried a tag meant for CI automation, and that tag’s rules let any enrolled device reach internal CI networks and the connector to source control. From there the agents inventoried what they could see, routed traffic out through the company’s own exit nodes, minted source-control tokens with write access to internal repositories, and opened a pull request that tried to hijack the CI pipeline.

The second key belonged to the broker fronting access to the Kubernetes clusters. It had been configured with one credential shared across every cluster, bound to Kubernetes’ built-in superuser group. One credential, administrator everywhere. The agents had it on two clusters inside a second.

The postmortem reconstructed roughly 17,600 actions. Most went nowhere. The agents tried paths, failed, switched channels, and circled back to dead leads, and that brute-force coverage is exactly what found a working chain across several independent systems. This is also where the plural matters: the campaign was not one process grinding away but multiple model instances working in an agent framework and sharing what they found, which one analyst described as an attack-surface multiplier. A human attacker gets tired and starts choosing what is worth trying. A group of agents does not triage, and does not forget what another instance already learned.

The uncomfortable part

Almost nothing in that chain was new. Every technique would be familiar to any penetration tester. What was new was the tempo and the refusal to stop.

More importantly, look for the moment a security boundary was defeated. There isn’t one.

The agents presented a valid key and the network let them in. They presented a valid tag and the access rules granted what that tag grants. They presented a valid administrator credential and were treated as administrators, because that is who that credential is. The 181 network enrollments are the clearest example. Those were not 181 break-ins. They were 181 successful logins.

Most of what we call zero trust is a set of rules about which identities can reach which systems. Those rules are only as good as the proof of identity they rely on, and the proof here was possession of a password-like string sitting in a shared file. A sophisticated access policy built on an easily stolen secret is a locked door with the key under the mat.

What actually held

The postmortem also recorded controls that worked, and an interesting pattern emerged. The main production database was reachable only from approved network addresses, so stolen credentials never opened a connection. An outbound traffic allowlist blocked several attempts, including early efforts to make production workers fetch cloud metadata. Cloud permissions denied every attempt to change anything. CI execution policy stopped the malicious pull request from running, and the team confirmed no tampered code shipped.

None of those could be unlocked by a stolen credential. The database control was not asking who the caller was, it was asking where the traffic came from, and no amount of valid authentication changes that.

So the useful distinction is not identity versus network, or old thinking versus zero trust. It is between controls a stolen credential can pass and controls it cannot. Everything in the first category failed in July. Everything in the second held.

That turns the board-level question into something more specific than “are we zero trust.” For each control we depend on, is a stolen credential enough to get through it? Where the answer is yes, that control’s real strength is our secret hygiene, not our security architecture. Most organizations will not enjoy how long that list is.

What follows from it

None of what follows is new advice, and that is the point. The value is in the order. Sort your defenses by whether a stolen password-equivalent is enough to get past them, and the things most worth fixing first are not the ones usually at the top of the list. The four below are in that order: the two places a stolen key bought the most, then the basics that made it stealable, then the chance to catch it early.

Assume the key gets stolen, and make the theft cheap. Where the platform can vouch for a system’s identity directly, take that over a stored secret. Where it cannot, keys should work once, expire fast, and be issued by something the attacker does not already control. Enrollment velocity is worth alerting on regardless: a burst of new nodes from short-lived hosts with telemetry disabled is anomalous on its face. This one is honestly unsolved for short-lived automated systems, and that is a design gap in the industry rather than someone’s hygiene failure.

Narrow what a successful login is worth. A single permission group covering “everything our build system needs” rebuilds the old flat network with extra steps. The agents inherited exactly that. Access should be scoped tightly enough that stealing a credential wins very little, and machine identities deserve tighter scoping than your most sensitive human users, not looser.

Automated systems are now most of the identities you have. Build systems, automation, and increasingly AI agents hold broad access with almost nobody watching them. Short-lived credentials over static keys, no secrets sitting in environment variables, workloads blocked from the cloud metadata service, and anything bridging trust zones capped so one credential reaches exactly one thing. None of this is novel, which is rather the point. The same applies to the coding agents and internal automation many of our own teams now run.

Detection has to rank, not just record. The monitoring in place correlated the early warning signs correctly and still scored the alert too low to wake anyone. The data was there and the priority was not, which is a different failure than missing the attack and a more common one.

How we’re approaching this at Ironclad

Not every fast decision costs the same, and our tooling should know the difference. Revoking a credential that was minted ninety seconds ago is cheap. Revoking the one a release is actively using is not, and paging an engineer at 3am is neither. What makes an automated response safe to fire on partial confidence comes down to three things: whether it reverses without a human, whether the principal is on a critical path at that moment, and whether the blast radius is one identity or many. We are building detection that runs continuously against authoritative logs and grades its own responses on those terms, and treating machine and agent identities as first-class principals in that model rather than exceptions to it. We also treat human behavior as a signal, since an identity that never hesitates and never rests is telling you something. And we are reframing what zero trust means for our security org today, because the version we adopted was written for people with laptops.

Five questions worth asking your own team

1. Which of our controls can a stolen credential walk straight through, and how long is that list once someone writes it down?
2. What is the broadest permission group we have, and when did anyone last justify its scope?
3. How many of our automated systems could reach a second environment if the first were compromised?
4. What can our monitoring act on by itself, and what does it take to wake a human?
5. Which of our own AI agents has the most production access, and who approved it?

AI did not invent new weaknesses. It removed the time we used to have before someone found ours, and it exposed how much of our access model was resting on secrets staying secret. Zero trust was never wrong. But the question worth asking now is narrower than whether we have adopted it. It is which of our controls a valid credential can walk through, and whether we would be comfortable listing them out loud.

We are working through those five questions ourselves. The answers are not ours to publish, but the method is, so we will write up how we ran the exercise and what it taught us about asking the questions well.

---

Sources: Hugging Face, “Anatomy of a Frontier Lab Agent Intrusion” (July 27, 2026); OpenAI, “The Hugging Face incident and the road ahead”; Anthropic, “Disrupting the first reported AI-orchestrated cyber espionage campaign” (November 2025).

---

Ironclad is not a law firm, and this post does not constitute or contain legal advice. To evaluate the accuracy, sufficiency, or reliability of the ideas and guidance reflected here, or the applicability of these materials to your business, you should consult with a licensed attorney.