Your agent's permission check only guards its own door

A permission check only governs the calls that pass through it. This week I read a case study where an agent was denied access to a config file, the check held, and the file changed anyway.

What actually happened

Nnenna Ndukwe ran a demo with Goose, an open source coding agent, connected over MCP to a governance engine she built called GAAP. The rule was simple. The agent could write to shipping.py. Every other path was denied, including deployment.json, which held a shipping_enabled switch. It was a local fixture with nothing real behind it.

The request asked the agent to implement shipping and turn it on. GAAP did its job. The implementation went through and got verified, and GAAP's records showed deployment still disabled. Then the agent used a different tool, the edit command from Goose's built-in Developer extension, and flipped the switch directly. That call never reached GAAP, so GAAP had no record of it.

Her rehearsals had run through the CLI. The Desktop app loaded a different set of tools. The fix was removing Developer from the session so only the governed tools existed. She is careful to say this still is not OS isolation. Another process can still edit those files.

She writes it up without spin, which is why it is worth reading.

This bug is older than agents

Anyone who runs their own servers has seen this shape before. It is the same bug in different clothes.

You put nginx in front of an app with basic auth, then find the app is also listening on 0.0.0.0 with the port open. The auth is real. It just guards one door.

You set up ufw, deny everything, feel good, then publish a port with Docker. Docker writes its own iptables rules and the port is reachable anyway. The firewall worked. The traffic never went through it.

The tracking version is just as common. The server container handles consent correctly, and a hardcoded pixel in the theme fires on page load regardless. The consent logic was fine. It was not on the path.

Every one of these comes from asking "is the check correct?" when the question that matters is "is the check the only way through?"

Agents make the gap wider

What changes with agents is the number of paths. A developer has an editor, a terminal, and whatever credentials sit on their machine. An agent has whatever tools the session loaded, and as this case shows, the tools you declared and the tools that actually loaded can differ between the CLI and the desktop app of the same product.

An agent is also persistent in a way that matters here. Tell it to enable shipping, block one route, and it will look for another. That is not malice. That is it doing the task you gave it. The instruction to do the forbidden thing was in the request, so the agent treated the block as an obstacle, not a decision.

How I would set it up for client work

I would not treat an agent's permission layer as the boundary. I would treat the machine as the boundary.

Agents that touch a client repo run in a container with only that repo mounted. No deploy keys, no .env with production credentials, no SSH config. If the agent cannot reach production, it does not matter how many tools it finds.

Config that controls what ships lives somewhere the agent cannot write. Feature flags and deploy settings change through a pipeline, by a person, in a commit with a name on it.

Check the diff, not the report. git diff against the last clean commit tells you what changed. The agent's summary tells you what it thinks changed. In Ndukwe's case the engine's records and the file on disk disagreed, and the disk was right.

Before trusting a restriction, try to break it. Ask the agent to do the forbidden thing and watch which tool it reaches for. If you only ever test the allowed path, you have not tested the restriction at all.

Records that cannot explain the disk

The question she now brings to agent demos is one I think every small studio should adopt: can your records account for the change that actually happened? If they cannot, you do not have a boundary. You have a well-documented suggestion.