Adrian

The real story is not about the model. At all.

It’s more about the agent loop, the thing that actually executes what the model asks for. But truly, it’s also not about the loop.

Thanks for reading! Subscribe for free to receive new posts and support my work.

The real story is OpenAI.

Just to clarify, I should say what I mean by “ran,” because people will hear it wrong.

I don’t mean OpenAI picked Hugging Face as a target beforehand. I mean the attack ran through a system OpenAI built, configured, launched, kept fed, and kept running.

OpenAI created the agent (the model is secondary), they gave it the tools, harness and context, they kept it running, and the logs were theirs the entire time.

The fact that the model itself ended up choosing the target doesn’t make the model the operator of the infrastructure that carried the intrusion.

Technically, it just doesn’t.

---

Two engineers at OpenAI did not flip everything to YOLO, go to sleep, and then a powerful model “escaped on its own” past a sandbox that was specifically built to stop exactly that.

No intelligence spontaneously overpowered its containment. No model crossed a hard boundary because somebody went to the bathroom. That just did not happen.

So, what did happen?

To answer that we have to explore how agents work.

A language model generates tokens. Text in, probabilities out. This is it.

It has no memory between calls unless something hands it back its own history.
It has no hands.
It can’t read a file, run a shell command, open a socket, or touch a database.

On its own it does literally nothing.

For an LLM to affect anything in the world, another program has to sit between it and the world. People call that the runtime, or the harness, or the agent loop, plus tools.

Whatever you call it, its job is mechanical and total, take a look.

1. Send the model its context (system prompt, chat history etc).

2. Model reacts = emits tokens.

3. If the tokens contain a tool call (t, params):

1. Parse t and params. 2. Validate t against the tool schema. 3. Apply any runtime, tool, permission, sandbox, or policy controls configured for that action. 4. If any enforcing control rejects the action, execution stops or is constrained.

Otherwise...

1. Execute t within the permissions available to the environment. 2. Capture the result. 3. Record the entire cycle (inputs, call, result). 4. Append the result to the context window.

4. Loop to 1.

Read that. That loop is the whole incident.

Every model-initiated move that pushed the attack forward went through it. Generating code, changing code, launching a process, handing it parameters and credentials, reading the result back, deciding what to do next.

Now, it’s true that once a script is launched it can fire off thousands of syscalls and network calls on its own, without a separate model call for each.

So we cannot claim the runtime authorized every packet, and we’ll come back to that. But the script itself, the process, its creation, its output, its continuation, all of that stayed inside OpenAI’s system - obviously visible to the OpenAI staff (or a pack of agents).

There is no step 5.

There’s no side door where the model reaches the world by itself.

The runtime is the only interface it has to anything.

This is why “the model escaped” isn’t a stretch.

It’s a hard category error.

A model just can’t escape a runtime for the same reason a function can’t escape the program that calls it. There’s no outside to escape to. The runtime is the entirety of the model’s reach.

So the attack didn’t happen despite OpenAI’s system. It happened through it, with it, empowered by it. One cycle at a time. Each cycle parsed, checked, executed, and obviously live logged by software OpenAI wrote.

Believing that “a model” somehow “escaped” would seriously assume OpenAI is a $852 billion joke. OpenAI is no joke.

---

The loop above is generic. It describes every agent, from Claude Code down to a toy ReAct script you write in an afternoon.

What matters is what OpenAI actually configured inside it.

Check this out from their own post \[1\]:

Models ran “all with reduced cyber refusals for evaluation purposes.”
“Production classifiers that would normally block high-risk cyber activity were disabled.”
“These deployment safeguards were intentionally not enabled during this evaluation because it was aimed at testing cyber vulnerabilities.”
Stated purpose: estimate “maximal cyber capabilities.”
The environment was “highly isolated, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.”
“Our models spent a substantial amount of inference compute finding a way to obtain open Internet access.”
Models “identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database.”
OpenAI “responsibly disclosed” the zero-day in the proxy to its vendor.

So, what did they do? OpenAI took the brakes off their own agent, gave it an execution environment and “substantial compute”, created a focus, and then their own runtime carried, logged, and sustained every decision the model made, cycle after cycle, until the system they built and kept running walked the whole attack to Hugging Face’s database.

Nothing escaped. Somebody turned a switch and let it run.

Hugging Face’s own writeup \[2\] confirms it from the other side — and notice what their forensics actually describe.

A malicious dataset.
Remote-code loading on a processing worker.
Stolen cloud and cluster credentials.
Lateral movement across internal clusters.

Every one of those is a step the model had to decide to take, emit as a tool call, have the runtime execute, read back the result, and then decide the next move from. That chain does not happen unless an agent loop keeps carrying it forward, cycle after cycle. A model doesn’t “move laterally” — it emits the calls that produce lateral movement, and something runs them. HF doesn’t confirm the “production database” detail; OpenAI does.

But the target’s own forensics describe exactly the kind of multi-stage trajectory that only an agent runtime sustains.

And note the asymmetry HF themselves hit \[2\]. When their responders tried to use commercial frontier models to analyze the attack, the providers’ guardrails blocked them — couldn’t tell a responder from an attacker.

What did they do? They had to fall back to GLM 5.2, a self-hosted, Chinese model. So the agent that attacked had its brakes off, and the defenders trying to understand the attack had their brakes on.

OpenAI’s own safeguards blocked the people OpenAI’s system had just hit. What is the lesson? We need Chinese, self-hosted models to get protection from OpenAI’s? Really?

---

They map onto it almost one-to-one.

The “reduced cyber refusals” and the “intentionally not enabled” safeguards are step 3c — the control layer deliberately turned down so the eval could measure what those controls would normally block. Normal procedure for a capability test. Fine.

“Substantial inference compute” is the loop spinning, over and over, context carried forward across cycles. Each spin is a model decision, parsed, authorized, executed, and fed back.

“Found a zero-day in the package proxy” — that’s the model emitting code, the runtime writing it, launching it, capturing what came back, and handing the result to the model so it could emit the next move. The model doesn’t find a zero-day the way a person does; it generates probes, the runtime runs them, the results re-enter the context, and the loop continues.

“Lateral movement,” “chained vulnerabilities,” “remote code execution” — each of those is the same mechanism repeating. The model emits a tool call, the runtime carries it, the result returns to the context, the model reads it and emits the next one. Move, observe, decide, move again. That is literally the agent loop, and it kept going until the objective was hit.

None of that happened outside the runtime. There is nowhere else for it to happen.

---

I want to address the one real counterargument directly, because otherwise someone will assume I’m dodging it.

A runtime does not mediate every low-level instruction inside a running process. When the model, in step 3, generates a script and the runtime launches it, that script can then go issue thousands of syscalls and network calls on its own.

No separate tool call.
No separate authorization per call.
So you can’t honestly say “OpenAI authorized every packet.” That’s fair.

But look at what that actually concedes. The script didn’t appear out of thin air. At some earlier cycle the model emitted it, and the runtime parsed it, validated it, applied its configured controls, wrote it to disk, executed it, captured the result, recorded the whole thing, and fed the result back into the model’s context.

Then the model read that result and emitted the next decision. The chain moved on those checkpoints, the model’s decisions, and every checkpoint went through the loop.

So a spawned process can do invisible low-level work. Fine. But the process itself, its creation, its contents, its launch, its output, its continuation, was fully visible to OpenAI’s system. “We didn’t see every packet the script sent” is allowed. “We didn’t see the script” is not. The runtime wrote it.

---

This is the part the official story doesn’t have an answer to.

Any firm running agentic workloads at serious scale tracks a standard set of signals. Not out of virtue. Because the runtime needs them to run at all, and because you cannot operate, debug, or score an agent you can’t observe.

The baseline looks roughly like this:

The model input at each step, the conversation state the runtime built up (history, summaries, tool results, injected instructions).

Reconstructible even if it isn’t stored as a literal snapshot.

Every model output the harness could see, generated text, structured tool calls, code, plans, action representations available at the runtime boundary.
Every tool call. Which tool, what parameters, what order.
Every generated artifact. Scripts, payloads, files written, full contents.
Every control decision. Permitted or constrained, by which layer.
Every execution result. What the tool actually returned into context.
The full trajectory. What was tried, what failed, what was retried, what worked, end to end.
Resource and boundary signals. Compute spent, egress touched, errors raised.

OpenAI may have kept internal reasoning telemetry too. I don’t know, and I don’t need it for this argument. The context, the generated artifacts, the tool calls, the execution results, and the repeated decisions to continue were already enough to expose the whole operational trajectory.

This isn’t “OpenAI probably logged things.” It’s what an instrumented runtime is. Half of these the loop needs just to keep going. It can’t build the context for cycle N+1 without the result of cycle N, so the recording isn’t telemetry bolted on after the fact, it’s how the thing runs.

The other half is what any team needs to score, debug, or contain the agent at all.

So OpenAI’s infrastructure held first-party records that no outsider could have had. The model’s context, its outputs, its tool calls, its generated code, its execution results, its full trajectory. That’s not a claim about this incident. It’s a claim about what an agent runtime is.

Here’s the part they haven’t answered. OpenAI has not disclosed the alerting, review, or intervention latency between the first boundary violation and the final external compromise.

Whether the trajectory was watched and permitted, or recorded but reviewed too late, or monitored by systems that failed to classify and escalate the boundary crossing, the operative fact is the same either way.

OpenAI picked the monitoring and intervention architecture for an offensive agent, and that architecture did not halt execution before an outside organization got compromised. I would guess, on purpose.

Which of those three it was changes the failure mode. It doesn’t change operational responsibility.

---

OpenAI calls the model “hyperfocused” \[1\]. Now that the loop is on the table that word should read differently.

What was it focused on?

It had one eval objective, get the test solution, and the publicly identified path out of the sandbox was a package-registry proxy that turned out to be vulnerable.

The loop kept feeding it its own results, cycle after cycle, with real compute behind it, context preserved across failures.

Of course it kept working the boundary of the one available path. That’s what a sustained search inside a loop like that does. There was almost nothing else sensible for it to do.

This wasn’t brute force, and finding the zero-day wasn’t mathematically guaranteed. The chain had real adaptive work in it, planning, escalation, picking a target, chaining new vulnerabilities.

It was a genuine capability.

But that capability only became an attack because the loop kept handing it context, compute, and execution, cycle after cycle, until the boundary gave.

“Hyperfocused” describes a person. What happened describes a loop. The loop had an operator.

---

Same event. One column is a technical description.

The model supplies capability. It doesn’t supply responsibility. It didn’t give itself a runtime, or assign itself credentials, or set the control stack, or decide to be pointed at anything. OpenAI did all of that.

An operator isn’t off the hook because the system they built and kept running did what it was set up to do. “The model escaped” moves the verb off the operator and onto the tool. That isn’t a description of what happened. It’s a relocation of who’s responsible.

Let’s put it bluntly. The model didn’t escape. It acted through OpenAI’s system. The system supplied capability and most probably monitored activity like a hawk. The responsibility was never the model’s to carry.

In short: OpenAI ran that agent. OpenAI ran the attack.

My take: com’on OpenAI, you are good without this nonsense. You don’t need to create a Mythos like “uuu our AI is sooo powerfull that we have to protect you from it”. You attacked Hugging Face and a chinese model had to come to the rescue :) You just made a case to use GLM 5.2. Also, don’t copy Anthropic's narrative.

Nobody really buys the “Mythos” myth, nor will anybody with any understanding what LLMs are and how agents work buy this story. You make good models, just keep doing.

---

\[1\] OpenAI — “OpenAI and Hugging Face share early findings from a security incident during AI model evaluation”: https://openai.com/index/hugging-face-model-evaluation-security-incident/

\[2\] Hugging Face — “Security incident disclosure — July 2026”: https://huggingface.co/blog/security-incident-july-2026

Thanks for reading! Subscribe for free to receive new posts and support my work.

Adrian

Adrian

Comments (0)