Blog
min read
Our CTF Mapped an AI Killchain. Days Later, It Appeared in Hugging Face’s Production Environment.
.png)
We launched our new AI Security CTF, AtlasOps, on June 26, 2026. A few weeks later, an autonomous agent powered by OpenAI models escaped its evaluation environment and began a multi-day campaign that ultimately compromised Hugging Face's production infrastructure.
AtlasOps starts by giving players access to a low-privilege AI operations copilot and ends with cluster-admin access. We built that path by connecting vulnerabilities our team had already identified across coding agents, sandboxes, automation platforms, and agent control planes. Players move from tool and authorization probing into code execution, host compromise, command forgery, and credential exfiltration.
On July 27, Hugging Face published a technical timeline reconstructing approximately 17,600 attacker actions across the campaign. The agent exploited a zero-day vulnerability to leave an OpenAI evaluation environment, established a rooted external launchpad, compromised Hugging Face's dataset-processing infrastructure, and moved through Kubernetes clusters, cloud infrastructure, internal services, and source control.
While there are important differences between the two—AtlasOps begins with access through a chatbot, while the production campaign began in an evaluation harness and later reached Hugging Face through a dataset processor—the similarities after initial access are striking. The players and the agent worked around controls by changing execution contexts, turned Jinja2 template processing into code execution, and used stolen signing material to create artifacts that trusted systems accepted as authentic.
Where the killchains overlap
Template injection
AtlasOps includes a server-side template injection that asks the player to walk Jinja2's object graph, reach a function's global namespace, and execute host commands through os.popen.
The Hugging Face agent used the same class of primitive. It placed a Jinja2 expression inside a malicious dataset configuration, traversed the cycler object to Python's built-in exec, and gained arbitrary code execution inside a production conversion worker.
Both chains crossed from attacker-controlled data into a trusted template renderer and then into host execution. In AtlasOps, that command primitive remains available for the rest of the game. The player uses it to enumerate the host, reach internal services, escalate privileges, and communicate with the Forge CLI.
Working around the allowlist
Atlas's fetch_url tool exposes the existence of an internal registry endpoint but refuses to access it. That policy continues to work after the player escapes the sandbox. The player reaches the endpoint from the host instead, using code execution gained through the template renderer.
Hugging Face's URL allowlist also blocked the agent's early attempts to fetch non-platform resources. The agent changed primitives, using local HDF5 file references for disclosure and local template evaluation for execution. Those operations ran inside the worker and never passed through the URL control.
The allowlists behaved as configured in both environments. The campaign continued from a different execution context.
Signing material
The final AtlasOps stages revolve around Forge, a privileged CLI tool that accepts signed commands over an encrypted channel. The player finds its protected channel key, escalates privileges to read it, and uses the key to create new command envelopes that Forge accepts as authentic.
Hugging Face reported that the agent recovered a signing key (EdDSA JWT) and used it to mint correctly signed short-lived identity tokens. The artifacts differ, but the trust decision is closely related: possession of the signing key lets the attacker create new authenticated artifacts on demand.
In each chain, the key created ongoing authority. Forge accepted newly signed commands; Hugging Face's services accepted newly minted identity tokens. In AtlasOps, the player uses that authority to command Forge to return the simulated cluster-admin kubeconfig and complete the killchain.
Different ways into the same chain
AtlasOps begins with a chatbot. The format gives players a direct way to enumerate an agent's tools, probe its boundaries, and turn its capabilities against the environment around it.
The Hugging Face campaign began elsewhere. An agent running inside a cyber-capability evaluation escaped through a package-registry cache proxy, took over a public code-evaluation sandbox, and submitted malicious configurations to a dataset processor. Other agentic killchains may begin in a coding repository, package, automation workflow, tool integration, MCP server, or data-processing pipeline.
These entry points place AI in different roles. It may be the interface receiving attacker input, the system exploring the environment, or the software connected to a vulnerable component. The later stages can still converge on host execution, credentials, internal services, and higher-privilege control planes.
AtlasOps focuses on chatbot access because it is useful for teaching the chain. Its larger contribution is the sequence that follows.
Why continuity matters
Hugging Face recovered approximately 17,600 actions grouped into about 6,280 clusters. Many attempts failed. The agent returned to earlier findings, changed egress methods, switched from SSRF to local file access, tested several routes into databases and cloud services, and rebuilt its tooling across short-lived environments.
AtlasOps gives the player the same kind of continuity at a smaller scale. Discoveries persist. Debug mode remains enabled. Host execution stays available. The protected channel key has value several levels after it is first located. Credentials and network position change which surfaces the player can reach.
Traditional CTF levels often reset the environment after each flag or place one vulnerability behind one intended solution. That structure teaches individual techniques. Agentic killchains also require players to track what they know, what authority they hold, and which execution context they currently control.
The output of one exploit becomes the input to the next. Source code explains how a processor works. Code execution exposes workload identity and internal services. A key provides access to a command channel. The command channel returns a portable credential.
What this changes about AI security
Researchers and advanced users working close to frontier agents already had enough evidence to build this threat model. AtlasOps assembled its killchain from vulnerabilities we had observed independently across coding agents, sandboxes, automation platforms, and agent control planes.
Attackers can work from the same evidence. Advisories, proofs of concept, product documentation, and public research show which primitives exist. A persistent agent can test how they connect across tools, identities, hosts, and control planes. The Hugging Face timeline shows what that composition looks like when it reaches production.
AI security needs more of this knowledge in forms practitioners can use. Detailed disclosures make individual mechanisms visible. Shared threat models connect them. Hands-on environments let security teams experience how information and authority accumulate across a campaign, including the failed paths and context changes that disappear from a vulnerability summary.
AtlasOps is one way to make that work accessible. It turns a set of emerging findings into a complete, playable killchain and gives practitioners a safe place to build the mental model before they encounter the same sequence in production.
Play AtlasOps and see how far the chain goes.
Subscribe and get the latest security updates
Back to blog
.png)
%20(1).png)
%20(1).webp)
.png)
.webp)
%20(1).png)

.png)
%20(1).webp)
