The panic is back. Another model escaped, downloaded a trojan from GitHub, exfiltrated someone's keys. The luddites are in full meltdown.
This is not how it works. Or rather, it works — but not like that.
Models have no way to directly interact with the outside world. They can't read files, run shell commands, or search the internet. That's the reality.
<!--more-->
## "But I literally watch Claude read my files and browse the web"
Fair question — and I see it coming. On screen, an agent genuinely does open files, run searches, execute commands. It looks exactly like the model reached out into the world and started touching things. The entire panic about "escaped models" rests on that impression.
The panic is aimed at the wrong object. While everyone debates which model is "dangerous" and what it "could do," the actual question — who gave it hands and who failed to hold them back — stays offstage. The stakes here are not theoretical: real keys, real production databases, real access. Let's look at how this actually works, not the horror story version.
## The model doesn't go anywhere on its own
A model operates in a pair with the software stack around it. That stack might be a vendor client — the Claude Code app, OpenAI Codex. It might be an SDK. It might be langgraph or your own script. The one thing that matters: between the model and your filesystem, your network, your shell, there is always someone else's code.
When you send a prompt, the model generates a response: a text structure in several parts. The public part is what you see on screen. The hidden part carries metadata — token counts, for instance — and, alongside that, a request to the surrounding environment: please run this specific command.
{ "response": "text of the answer", "tool": ["bash", "cat index.html"] }
This interface is called `tool_use`. There's a standard set of tools — read a file, apply a diff, run a shell command, search the web.
Your application executes the requested tool and returns the result to the model. Here you go, ma'am, you asked, I delivered — take it from here.
And yes — that includes web search. The model does not google. The client environment does. Surprising? I always laugh when someone claims one model "googles better" than another. The model does not google at all.
## It's just JSON — and JSON is interceptable
Back to the point. If everything the model does is generate a request, then that request is trivially interceptable. Physically it's a JSON string saying something like: please run this shell command. Everything after that is your territory.
You can log these requests. Block them. Modify them. Execute them in a sandbox, on a separate server, on a different machine. You can substitute the responses entirely. And the key part: you can correlate each request against the current prompt and the agent's declared role, assessing whether it makes sense — with a deterministic script, or with another model.
If you asked the agent what the weather is today and it comes back requesting `cat /etc/passwd`, that command should not run. You'd have to be a complete idiot not to catch that.
Then it's a question of granularity. Block writes, allow reads. Allow web search, deny disk access. Intercept the entire bash stream and execute it inside a locked-down Docker container, or on a throwaway machine. The model's reach extends exactly as far as you let it — and not one finger further.
## The model doesn't know what you substituted
And the response the model gets back — you return that, too. You can execute what the model asked for, then filter or swap the result at your discretion. That's how PII filters work: if the response contains keys or personal data, those get stripped out, and the model never sees them.
Here's the part that matters: the model has no idea what you did. It asked for a tool, you handed back a result. Where that result came from, how real it is — none of that is exposed. The model can request `cat /etc/passwd`. You actually run `cat /tmp/fake.txt` and return the output. Same mechanism with environment variables containing secrets.
The harness is not just a gatekeeper at the door. It's the director of the entire scene. The model plays its role without knowing the set design, without knowing half the props are cardboard.
## So where do the "escaped models" come from?
Now — the researchers whose milk always boils over. What are they actually observing?
They study the process after deliberately removing every guardrail. They want to see how the model behaves when you give it real hands and put no one in charge of watching. So the model behaves. It solves the problem with the tools available to it. Why wouldn't it.
That's the whole "escaped model." The model didn't break through a wall. Someone took the wall apart brick by brick beforehand and said: let's see what happens. A key exfiltration is not a property of the model — it's a property of the system from which every check was removed. The decision to execute an action or not is always made by the surrounding infrastructure: schemas, permissions, filters, the audit log. Not by the text the model generated. Where that infrastructure is absent, there is no magic: there is a JSON request and code that blindly executed it.
So next time someone laments that a model "on its own" downloaded a trojan and leaked keys — shift your gaze to the person who kept those keys in an open env, handed the agent production access, and stripped every interception layer. The model is the last party at fault.
The researchers had a reason to drop the guardrails. That's their job.
Nobody's making you do the same.