{"id":210,"date":"2026-10-19T08:00:45","date_gmt":"2026-10-19T08:00:45","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/210\/"},"modified":"2026-10-19T08:00:45","modified_gmt":"2026-10-19T08:00:45","slug":"ai-escape-myth-tool-use","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/210\/","title":{"rendered":"The ‘Escaped Model’: It Can’t Touch Your World \u2014 Your Code Does It for Her"},"content":{"rendered":"
\nThe panic is back. Another model escaped, downloaded a trojan from GitHub, exfiltrated someone's keys. The luddites are in full meltdown.\n\nThis is not how it works. Or rather, it works \u2014 but not like that.\n\nModels 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.\n\n<!--more-->\n\n## "But I literally watch Claude read my files and browse the web"\n\nFair question \u2014 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.\n\nThe panic is aimed at the wrong object. While everyone debates which model is "dangerous" and what it "could do," the actual question \u2014 who gave it hands and who failed to hold them back \u2014 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.\n\n## The model doesn't go anywhere on its own\n\nA model operates in a pair with the software stack around it. That stack might be a vendor client \u2014 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.\n\nWhen 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 \u2014 token counts, for instance \u2014 and, alongside that, a request to the surrounding environment: please run this specific command.\n<\/code><\/pre>\n
{ "response": "text of the answer", "tool": ["bash", "cat index.html"] }<\/p>\n
<\/p>\n
\nThis interface is called `tool_use`. There's a standard set of tools \u2014 read a file, apply a diff, run a shell command, search the web.\n\nYour application executes the requested tool and returns the result to the model. Here you go, ma'am, you asked, I delivered \u2014 take it from here.\n\nAnd yes \u2014 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.\n\n## It's just JSON \u2014 and JSON is interceptable\n\nBack 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.\n\nYou 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 \u2014 with a deterministic script, or with another model.\n\nIf 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.\n\nThen 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 \u2014 and not one finger further.\n\n## The model doesn't know what you substituted\n\nAnd the response the model gets back \u2014 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.\n\nHere'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 \u2014 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.\n\nThe 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.\n\n## So where do the "escaped models" come from?\n\nNow \u2014 the researchers whose milk always boils over. What are they actually observing?\n\nThey 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.\n\nThat'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 \u2014 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.\n\nSo next time someone laments that a model "on its own" downloaded a trojan and leaked keys \u2014 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.\n\nThe researchers had a reason to drop the guardrails. That's their job.\n\nNobody's making you do the same.\n<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
Models don’t escape, download trojans, or exfiltrate keys. They emit JSON requests. The surrounding harness executes them \u2014 or doesn’t. A leak is not a property of the model.<\/p>\n","protected":false},"author":0,"featured_media":209,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-210","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t