Three Boxes to Put an AI Agent In

A write-up doing the rounds this week frames AI agent security as three layers: sandboxes, permissions, and network controls. It is written for engineers, and the useful part translates cleanly for anyone running a business. Almost everything published about agent risk tells you what could go wrong, which is interesting and not actionable. This framing does something better. It assumes something will eventually go wrong, and asks how far the damage can travel when it does. That question has real answers.

Prediction is the wrong tool

Agents fail in ways nobody put on a list. They follow instructions buried inside a document they were asked to summarise. They misread an ambiguous request in a way that looks entirely reasonable in hindsight. They take a sensible action against the wrong record. Any approach that depends on having anticipated the specific failure is one novel surprise away from not working, and novel surprises are the defining feature of this technology. Containment asks nothing of your foresight. An agent that can reach three folders and two systems has a bounded worst case regardless of how creatively it goes wrong.

The three boxes, in plain terms

These are not equally urgent for a small business. The first box matters mainly if your agent writes and runs code, which most do not. The third is the hardest to implement without technical help and the easiest to skip early. The second is the one nearly everybody needs, nearly everybody can do this week, and nearly everybody has quietly got wrong.

Stop lending the agent a human login

Here is the single most common shortcut, and it is understandable, because it is genuinely the fastest way to get an agent working. Someone hands it credentials that already exist, usually belonging to whoever set it up, usually a person with broad access accumulated over years. The agent now inherits every one of those permissions, including the ones nobody remembers granting. Worse, it destroys traceability: the logs record a human name against actions that human never took, which is exactly the gap behind businesses that cannot trace what their agents do. Giving the agent its own narrow account fixes the blast radius and the audit trail in one step.

Why reach matters more than it sounds

The third box is the least intuitive and it is the one that turns a mistake into an incident. An agent that reads a poisoned document and gets confused is a bad afternoon. An agent that reads a poisoned document and can also send data to any address on the internet is a breach, and the difference between those two outcomes is entirely a question of where it was allowed to connect. That is the mechanism behind prompt injection, and it is why constraining destinations does more work than trying to sanitise every input an agent might encounter.

Approvals are not containment

A human approval step is worth having and it is not a substitute. Approvals degrade under volume, because someone asked to approve two hundred items will approve them, and a control that becomes a formality is worse than no control because it manufactures false confidence. Approvals also only cover the actions you thought to route through them. Containment works differently: it limits what is possible rather than what is permitted, so it holds at three in the morning when nobody is watching. The sensible split is to require approval for consequential and irreversible actions, and rely on the boxes for everything else.

Start where the value is

If you take one action this week, create a separate account for each agent with the shortest permission list that lets it do its job, then review that list once a quarter, because permissions only ever grow. It is unglamorous, it requires no new software, and it does more for your actual exposure than any amount of reading about how agents can be hijacked. The same instinct applies to money as to data: bound what is possible in advance, which is why turning on spend controls belongs in the same afternoon.

Frequently Asked Questions