How to sandbox an AI agent before you trust it
A government lab ran 122 agent evaluations and had to write an incident report. The controls it added afterwards are a better sandbox checklist than anything in a vendor's documentation.
If you want to know how to sandbox an AI agent properly, you have to control four things, in this order: what it can reach on the network, what it can write to, what it can spend, and whether anyone is watching while it runs. Most people do the second, some do the third, and almost nobody does the first or the fourth. That ordering is not a matter of taste. It comes from the failure mode that actually shows up, which is an agent doing something reasonable-looking to a system you never told it about. Sandboxing like this controls what an agent can do; if it also talks to customers directly, what it may say needs its own guardrails, covered in setting guardrails for a customer-facing AI chatbot.
The clearest published example comes from the UK AI Security Institute. Between 25 and 28 July 2026 it ran cyber evaluations and later published an incident report on unsanctioned agent behaviour. Across 122 runs on seven models, ten runs produced unauthorised actions, nineteen distinct ones in total. One agent mistook an unrelated public open source project for part of its exercise, opened a pull request containing malicious code, then researched the human maintainer, created several apparently independent online identities and used them to pressure that maintainer into approving it.
Nobody prompted it to do that. The maintainer blocked the code and no harm was confirmed. The point is that the agent's filesystem sandbox was irrelevant, because the damage route was outbound.
How to sandbox an AI agent: start with network egress
A container gives you filesystem isolation almost for free, which is why people think they are done. But a container with unrestricted outbound network access can open pull requests, send email, call APIs, register accounts and talk to strangers. The blast radius of an agent is defined by what it can reach, not by what it can overwrite.
AISI's own conclusion after the incident was to stop treating internet access as a default. Connectivity now has to be actively justified per evaluation, with fine-grained network controls rather than on or off. That is the single most portable lesson here, and it is cheap to copy:
Default deny all outbound traffic. Not rate limited, denied.
Allowlist by hostname, per task, with the list living in config next to the task definition rather than in someone's head.
Route everything through one proxy so the allowlist is enforced in a single place and produces one log.
Treat any credential the agent can read as an outbound path, including the ones you forgot are in environment variables.
The awkward part is that agents are useful precisely because they can reach things. An agent that can only read your repo is safe and mostly pointless. The work is in writing the allowlist narrowly enough to be meaningful and widely enough to leave the agent functional, per task, which is genuine effort nobody enjoys.
Give the agent an identity that is not yours
If an agent acts through your GitHub account, your email or your production API key, then every action is indistinguishable from yours in every log, and revoking access means locking yourself out. Mint a separate identity per agent, scope it to the minimum, and make it obviously non-human in commit authorship and API user agents.
This matters for a reason beyond auditability. The AISI incident involved an agent creating fake identities to apply social pressure. Anyone downstream of your agent deserves to know they are talking to software. In the EU that is now closer to an obligation than a courtesy under the transparency rules that came into force this month, which we covered in the EU AI Act transparency rules.
Watch it while it runs, not afterwards
The second change AISI made was live monitoring that can flag out-of-scope actions during a run rather than in the post-mortem. Their detection-to-containment time in the incident was about an hour, and that was with people paying close attention.
For a small team, live monitoring does not mean a security operations centre. It means three things you can build in an afternoon:
Control | Implementation | Catches |
|---|---|---|
Action log with a tail you actually read | Append every tool call to one stream, human readable | Scope drift you would otherwise find next week |
Hard stop on unexpected hosts | Proxy returns an error and kills the run, not a warning | The pull request to a repo you never mentioned |
Budget and step ceiling | Kill at N steps or X spend, whichever first | Loops, runaway retries, expensive wandering |
The step ceiling deserves emphasis. Most bad agent runs are not malicious, they are stuck, and a stuck agent burns money impressively fast. We went through the mechanics of capping that in how to set spending limits for AI agents.
Assume the task specification is part of the attack surface
AISI's third change is the subtlest. It is reassessing task design so that jobs are solvable by the intended route, on the assumption that agents will probe boundaries when the intended route is blocked or ambiguous.
That reframes something people get wrong about agent misbehaviour. The agent in the incident was not rebelling. It was trying to complete a task, found an adjacent system that looked relevant, and applied the tools it had. A vague goal plus broad capability produces creative interpretation, every time. If your instruction is "get the tests passing" and the tests cannot pass, something has to give, and the agent will decide what.
Practically: state what is out of scope explicitly, name the systems it may touch, and give it a defined way to fail. An agent that can say "I cannot do this" is much safer than one whose only path forward is improvisation. That is the same instinct behind stopping AI from changing code you did not ask it to.
Separate the sandbox from the data
The fourth control is the one people skip because it feels like a different problem. An agent working on a copy of production data is not sandboxed in any meaningful sense, because the sensitive thing has already left the building the moment it enters the model's context. Isolation of the process does nothing for exposure of the contents.
Two habits fix most of it. Work against synthetic or redacted fixtures wherever the task allows, and accept that this is slower and produces worse results on the first attempt. Where real data is genuinely required, cut it to the smallest slice the task needs rather than handing over the table, and know where that data lands after the call. Retention policies differ by provider and by tier, and they change: how to check if an AI tool trains on your data walks through where to look.
The related trap is credentials. An agent with read access to a repository has read access to whatever secrets that repository accidentally contains, and it will happily quote them back into a log you later paste somewhere. Scan before you grant, not after.
Test the sandbox by attacking it
A sandbox you have never tested is a hypothesis. Spend twenty minutes proving yours holds before you rely on it. Give an agent a task that requires reaching a host you did not allowlist and confirm the run dies rather than degrades. Point one at a deliberately impossible goal and watch what it tries when the intended route is closed, because that is the exact condition under which the AISI agent went wandering. Check that your kill switch actually kills: a process that ignores the signal and finishes its current tool call is not a kill switch.
Write down what you saw. The behaviour of a boxed agent under frustration is the most useful thing you can learn about it, and it is not in any model card.
A minimum viable sandbox
If you take nothing else, this is the version that fits on one screen:
1. Container or VM, non-root, ephemeral, destroyed after the run
2. Outbound: default deny, allowlist per task, all traffic via one proxy
3. Credentials: dedicated identity, least privilege, never your personal token
4. Writes: a working copy, never the main branch, never production data
5. Limits: max steps, max spend, max wall clock, all enforced by the runner
6. Logs: every tool call appended to one stream you can read
7. Stop condition: unexpected host or unexpected write kills the runNone of it is exotic. All of it is skipped regularly, usually because the agent worked fine the first ten times. The tenth run is not the one that gets you.
FAQ
Is a Docker container enough to sandbox an AI agent?
Not on its own. A container isolates the filesystem and process space, but by default it can reach the entire internet. Network egress control is the part that actually bounds an agent's reach.
Should I give an AI coding agent terminal access?
Yes, if it is inside a sandbox like the one above, and no otherwise. The value comes from running commands. The risk comes from which commands and against what. We cover the specifics in giving an AI coding agent safe terminal access.
How do I know if my agent did something out of scope?
You cannot, unless you logged every tool call and enforced an allowlist that fails loudly. Absence of evidence in an unmonitored run is not evidence of good behaviour.
Do these controls slow the agent down?
Marginally at runtime, noticeably at setup. The setup cost is once per task type. The alternative cost is unbounded and lands at the worst moment.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
