The safest thing to give an agent is nothing

TL;DR: The best containment we found for a second machine cost nothing and nobody designed it. Every rule and hook we had built depended on the agent reading it or our own tooling running it. The one wall that held was a credential that had never been handed over.

The insight

The strongest boundary around an autonomous agent is not a guard you build. It is a capability you never give it. A guard can be skipped, misconfigured or left uninstalled on a fresh machine, and it can be fooled the day its assumptions move. A credential that was never minted cannot be any of those things, because there is nothing there to get past.

This matters most at the moment you add a second agent, a second vendor or a second machine. Every rule written for the first agent, every hook in its harness and every wrapper around its tools depends on that agent’s cooperation or that harness’s presence. A new vendor’s agent reads none of your rules and runs none of your hooks, so the whole apparatus stops applying the moment the new agent starts. Mik Kersten argues in Output to Outcome that control over autonomous agents should live in the shape of the organisation, with each autonomous stream a leaf that reports up to a human, rather than in the agent’s instructions. We took that frame, that control belongs below the agent, and pushed it one step further down, from the org chart to the credential.

In practice

When we audited what would contain a second vendor’s agent on the Mac mini we are adding as a build machine, the one hard wall in the whole system turned out to be an accident of provisioning. The task database accepts an empty password from the machine it runs on and refuses the same login from any other machine. Nobody designed that, and yet the mini was fully contained before anyone drew a diagram.

The guard we had built to catch a rogue task write was not on the path at all. It lives in a wrapper we put round the command-line tool our agents use to read and write tasks, and that wrapper had been installed under a different name. Even in place, it identifies an agent by an environment marker that only our own vendor’s tooling sets, so a foreign agent would have been classified as Peter himself and waved through with a warning. That is what a built guard does when its assumptions move, and it is what an unminted credential never does.

What we’ll try next

Before the second machine runs anything, we will write down what it has been given and what it has not, and treat the second list as the design. It gets no identity for the services that hold our secrets, no grant on the task database and no ambient git credential in the agent’s shell. Block’s nanoclaw project puts the same idea in one line of its security notes, “the attack surface is limited by what’s mounted”, and that sentence is the one we now measure each machine against. Guards still get built, but as the second line, and our own agents will sit inside the same box as the foreign one.

One honest number

A process on the laptop could read 3,344 rows from the task database with no password at all, and the same login from the second machine could read none. The first figure says that on one machine there is no boundary worth the name, since anything running there can read or rewrite every task for every business the factory runs without going near the task tool. The second says that across machines the boundary is total, and that it was free.

Both are true at once, and the lesson is that a single database grant or tunnel would spend the second figure to buy nothing. Ask of every new agent not what wall to build around it, but what you have handed it that you did not need to.