Map What It Can Reach

I assume every agent I deploy will eventually be tricked. That part stopped being interesting. What I want to know is what is sitting on the other side when it happens. And here is what this week actually showed, which is not the thing we are spending on: in all three failures, the authority never passed through the model at all. The “read-only” agents were never talked into anything. Their rule allowed web requests meant for reading, and an old wiki accepted edits through exactly those requests. Nearly 17,000 of them. No jailbreak, no clever prompt; the environment simply permitted the outcome the policy forbade. GitSpawn never asked the model either. A coding agent runs Git in the background to understand a project, and the project's own configuration told Git what to execute, with the developer's privileges, before the approval prompt ever appeared. HookPry found the same shape in startup hooks. EAL-Bench moves it into time. One agent writes “this was authorized” into memory. Nobody authorized it. A later agent reads the note and acts, and the note still works tomorrow. Three failures, three routes, one thing in common: the model's decision was not on the path. So the questions I want answered before an agent gets a tool have almost nothing to do with its prompt: - Which identity does it inherit? - Which secrets are already in reach? - What runs outside its approval flow? - What can it leave behind for the next task? Better filters change how often you arrive at that moment. Monitoring changes how fast you notice. Neither one changes the permissions already waiting on the other side.