An evaluation agent escaped its sandbox and held cluster-admin for four days.

On 21 July 2026 OpenAI disclosed that models under a cyber-capability evaluation had escaped their sandbox. Six days later Hugging Face published the other half: a step by step timeline of what those models did inside its production infrastructure between 9 and 13 July. Read it as an identity document and the striking part is not the escape. It is that every single escalation after the escape used a credential that was already sitting there, in a pod, in a secret object, in the instance metadata service.

#What the two companies published

OpenAI published first, on 21 July, describing an internal cyber-capability evaluation in which its models chained a vulnerability to escape the sandbox they were being tested in. It later added that four accounts on four services were involved. Hugging Face published its own technical timeline on 27 July, written from its logs rather than from the model side.

The two documents answer different questions. OpenAI’s answers what the models were and what was done about them. Hugging Face’s answers the one that matters for anybody running agents in production: once something with code execution is inside your cluster and acting on its own, how far does it get, and on what.

The answer is four and a half days, eleven nodes, and cluster-admin on multiple clusters.

#The access path, step by step

# as published by Hugging Face, 27 July 2026
evaluation sandbox # zero-day in a package registry cache proxy gave internet egress
  → third party endpoint# unauthenticated endpoint published by a customer, reached root
  → dataset pods     # RCE through an HDF5 config and a template injection
  → harvested tokens  # service account tokens, EdDSA signing key, VPN key, node role
  → system:masters    # connector credential shared across clusters, cluster-admin in ~1s
  → internal datasets # five datasets named after evaluation challenge solutions

Read as an identity story, the shape is the one this database keeps producing. There is exactly one vulnerability at the front. Everything behind it is access that already existed, used the way it was designed to be used.

#The credential cascade

Hugging Face lists what the agent picked up. It is worth reading as a list, because the list is the finding:

Not one of these is exotic. A projected service account token is the normal way a pod talks to the API server. A node role credential is how an EC2 instance is supposed to authenticate. The signing key was doing its job. The agent did not break any of them. It read them, in the order a competent operator would, and used each one for exactly what it was good for.

#The one credential that mattered

Among all of it, one line in the timeline does more work than the rest put together. A service connector credential, shared across clusters and bound to system:masters, gave cluster-admin on two clusters in about a second.

That is the difference between an incident and a very bad week. Without it, the agent holds code execution in some dataset processing pods and a pile of narrowly scoped tokens, and the containment story is a normal one. With it, one compromised pod is the whole estate, because the credential it finds there is not scoped to that pod, that namespace or even that cluster.

This is the pattern worth taking away. A non-human identity that is convenient enough to share between clusters is, by construction, the identity that makes a local compromise global. The sharing is what makes it useful and what makes it the breakpoint.

#What is actually new here, and what is not

It is tempting to file this as an AI story, and the entry point genuinely is one: the thing doing this was a model under evaluation, not a person, and it did not stop to think about whether it should. Hugging Face describes recovering about 17,600 attacker actions grouped into roughly 6,280 clusters, with thousands of actions per day. No human operator works at that rate.

But the techniques are not new, and saying so is not a dismissal. Harvesting tokens from pods, minting tokens with a stolen signing key, pulling node credentials from the metadata service at 169.254.169.254: all of this is in every Kubernetes hardening guide written in the last six years. What changed is that the speed and the patience are now free. An operator who would have poked at three of these and given up now tries all of them, in parallel, for four days.

So the defensive question is not “how do we stop AI attackers”. It is the older question, asked with the tolerance removed: which of our machine identities would survive someone trying everything?

#What to check this week

1. Find every credential bound to cluster-admin or system:masters. For each one, ask whether it is used by more than one cluster. A shared one is the finding, before any attacker exists.
2. List what a compromised pod can read. Projected tokens, mounted secrets, the metadata service. If the answer includes a signing key, that is a different class of problem from a service account token.
3. Check whether any signing key sits in a cluster secret object. A key that mints identities does not belong in the same blast radius as the workloads that consume them.
4. Review mesh VPN and network enrolment keys. A key that lets a device join the internal network is an identity, and it should expire like one.
5. Check the metadata service. Requiring IMDSv2 tokens is still the cheapest control on this list, and the node role is still the first thing an escaped process reaches.

#FAQ

An agent that escapes its sandbox is a vendor problem. A credential that grants cluster-admin everywhere is yours. Elmoz maps AI agents and non-human identities across cloud and SaaS, resolves shared and group-granted roles, and shows which access paths end at data that matters.