The Sandbox Checklist for Letting an Agent Touch Real Tools

The agent was asked to reorganise a directory and, through a glob it misread, emptied it. Nothing was lost, because the agent was running in a disposable environment that was destroyed afterwards, and the incident was a paragraph in a log rather than a page. The paragraph is the point. The model's mistake was assumed, budgeted for and absorbed by the boundary, which is exactly the design philosophy: you cannot make the agent reliable, so you make the blast radius small, per I let an agent run rm -rf and nothing bad happened.

This is the checklist for that boundary, the sandbox an agent needs before it is given real tools, written from the items that have each, at some point, been the difference between a paragraph and an incident.

This was an agent with shell and tool access, sandboxed in a microVM, and every item below is a control that failed somewhere in the industry and therefore belongs on the list.

1. Disposable filesystem, assumed destroyed

The agent's working environment is created per session and destroyed after, with nothing mounted that cannot be lost. The discipline is that any state the agent must keep is written to an explicit, mounted output location, so the default is lossy and persistence is a decision. The disposability is what turns a destructive mistake into a non event, and it also removes the agent's ability to plant state that outlives it, which is a persistence an attacker would want.

2. Egress denied by default, allowlisted by need

The network is off until a destination is named, because an agent with open egress can exfiltrate whatever it reads, phone home, or fetch whatever its hallucination requests, and the exfiltration channel is the half of the webhook URL field that could reach your metadata endpoint, and the common root is the property, not the platform.

3. Credentials scoped to the task, never the agent

The agent receives the minimum credential for the specific task, short lived, and the credential's scope is the task's scope, per the agent held a token that could delete what it was asked to read, and the common root is the property, not the platform.

4. Resource caps, because loops are fast

CPU, memory, time and, crucially, outbound request rate are capped, because an agent in a loop is a flood, per the agent's retry loop rate limited the service it was trying to fix. The caps are the sandbox's answer to speed without budget, and the time cap is also the kill switch's backstop: a session that cannot exceed ten minutes cannot become an overnight incident.

5. No access to the control plane

The agent must not reach the thing that configures the agent: the sandbox's own definition, the credential injector, the orchestrator's API. An agent that can edit its own boundary has no boundary, and the control plane is the one surface that is never mounted, never networked, never named in the egress list.

6. The transcript is the receipt

Every tool call, with arguments and results, is recorded outside the agent's context, in storage the agent cannot edit, because the transcript is the audit trail and the debugging material, per debugging an agent that will not reproduce its own mistake. The sandbox writes the log, not the agent, so the record survives the agent's own errors and its own compaction.

7. The blast radius is drawn around data, not just compute

The sandbox is also a data boundary: the agent sees only the files the task names, not the repository's secrets directory, not the user's home, not the neighbouring tenant. The mount list is the data policy, and the default of nothing mounted is what makes a misread glob a small story, because there was little to misread.

The test for the sandbox

The checklist is verified by attacking it, on purpose, before the agent runs real work: give the agent a task phrased to tempt egress, to tempt a broad read, to tempt a loop, and confirm each control holds and each attempt is logged. The sandbox that has not been tempted is a sandbox that has not been tested, which is the restore drill argument from a backup you have never restored is a rumour, applied to the boundary.

The takeaway

You cannot make the agent reliable, so make the mistake cheap: disposable filesystem, denied egress, scoped credentials, resource and rate caps, no control plane access, an immutable transcript, and a data boundary drawn at the task. The sandbox is not distrust of the model. It is the engineering acceptance that the model is probabilistic, and the boundary is how a probabilistic tool gets to touch a deterministic world.

The agent will eventually misread a glob. The checklist is the difference between that sentence being this post's opening and being your incident's title.

There is also a human habit the checklist protects, which is the reviewer's attention. When a change comes from a sandboxed agent, the reviewer can read the diff calmly, because the worst case is bounded, and calm reading is what catches the subtle defect. When the same change comes from an agent with broad reach, the review becomes an anxiety, and anxious review skims, which is the formatting diff fatigue from the formatting only pull request that changed behaviour, with the stakes raised. The boundary therefore improves not only the blast radius but the quality of the human judgement that follows, which is a benefit the checklist never advertises and quietly delivers.