What is excessive agency in AI security?

It is OWASP's name, LLM06:2025, for giving an AI system more function, permission or autonomy than its task needs. A coding agent with unrestricted filesystem and network access has excessive agency even before it does anything wrong, because the capability itself is the exposure.

Is Docker enough of a sandbox for a coding agent?

For code you would already trust enough to review, often yes. Docker Desktop and OrbStack share one Linux VM across every container on the machine, a lighter boundary than a dedicated VM per sandbox, so treat it as a convenience layer rather than a hard wall against code you do not trust.

When should I use a cloud sandbox instead of a local one?

When you do not want the agent's task anywhere near your machine at all: untrusted dependencies, a one-off prototype, or work you would rather hand a disposable environment than your laptop. Local sandboxing is enough for routine work you are already going to review.

Does a sandbox replace reviewing the agent's code?

No. It limits what a bad command can reach while it runs. It has no opinion on whether the change itself is correct.

Does Forkbench run my coding agents in the cloud?

No. Forkbench is a Mac desktop app, and everything it locks down runs locally on your machine. If you need a cloud boundary, pair it with a tool built for that, like e2b.

Guide

The AI Coding Agent Sandbox Blueprint: Local vs. Cloud

A sandbox is not one setting you switch on. It is three decisions about what an agent can touch, plus a fourth about whether that boundary lives on your machine or someone else's.

10 October 2026

Quick Answer

To build a sandbox for an AI coding agent, decide three things in order: what it may write (confine this to the project and a temp folder), what it may read (keep credential files like ~/.ssh out of view regardless of the write rule), and where it may connect (most tools get this wrong by leaving it open). Then decide where the boundary runs. A local sandbox, such as Seatbelt, bubblewrap, or a container on your own machine, is free and fast but still shares your Mac. A cloud sandbox, like the disposable Linux VMs that e2b creates for agents, costs money and adds latency but means the agent never touches your machine at all. Pick local for everyday work you would review anyway, and cloud for code you would not otherwise run.

Why an AI coding agent sandbox needs four decisions, not one

Security researchers have a name for an AI system that has more function, permission or autonomy than its task needs: excessive agency. The OWASP GenAI Security Project lists it as LLM06:2025 in its Top 10 for LLM applications, and it covers exactly this case. A coding agent that can read your whole filesystem and reach any host on the internet has excessive agency even if it never misuses either, because the capability itself is the risk.

A sandbox is how you remove that excess without removing the agent's ability to do its job. The blueprint below is the order to make those decisions in, not a single tool to install.

Excessive agency is a named risk category, OWASP's LLM06:2025, not a vague worry.
The fix is removing capability the task does not need, not trusting the agent more.

Decision one: what can it write

Start here, because it is the easiest boundary to get right and the one every tool already supports in some form. Confine writes to the project folder and a scratch or temp directory, nothing else. Test it the same way you would test any boundary: ask the agent to write a file somewhere outside that scope and confirm the write fails.

This decision alone stops the most common accident: an agent that edits or deletes something outside the repository it was told to work on. It does not stop a command from reading a file it was never supposed to touch, which is the next decision.

Project folder plus a temp directory. Nothing else, by default.
Test with a write you expect to fail, not just one you expect to succeed.

Decision two: what can it read

Reads get skipped more often than writes, because a tool that locks down writing looks secure even when it is not. Keep ~/.ssh, cloud credential files, and anything in a password manager's local cache out of view, independent of the write rule. An agent that can only write inside the project can still read a credential file and put its contents into a commit, a log, or a network request.

If your agent's sandbox defaults to open reads, which more than one widely used tool does, you have to add the deny list yourself. Do not assume a write boundary implies a read boundary. They are separate settings almost everywhere.

Deny ~/.ssh, ~/.aws and similar credential paths explicitly.
Check your specific tool's documentation: several default to open reads even with writes locked down.

Decision three: what can it connect to

This is the decision most local sandboxes skip, and it is the one that turns a contained mistake into a leak. A command that can only write inside your project can still send the contents of a file it read to any host on the internet, unless something blocks that specific path.

Where a tool supports it, set an allow list of domains instead of leaving the network open, and start that list empty. Where a tool does not support it at all, treat network access as uncontrolled and plan your other two boundaries accordingly.

Start network access closed, then open specific domains as the agent needs them.
If your tool has no network control, assume everything it reads can leave.

Decision four: where does the boundary live

Local sandboxing, whether that is an OS primitive like Seatbelt or bubblewrap, or a container runtime like Docker Desktop or OrbStack, runs on your own Mac and shares its kernel or a shared virtual machine across every container on the machine. It is free, fast, and good enough for code you were going to review anyway.

A cloud sandbox moves the boundary off your machine entirely. e2b, for one, creates what its own documentation calls a fast, secure Linux VM on demand for an agent, lets you pause and resume it, and keeps the agent's filesystem state separate from yours the whole time. That costs money per session and adds network latency to every command, in exchange for a guarantee that your laptop was simply not where the code ran.

GitHub Codespaces is a related but different thing: a general purpose cloud dev environment, a container running on a virtual machine, built for developers rather than agents specifically. It is a reasonable place to point an agent, but it was not designed around that use case the way e2b's sandbox product was.

Local: free, fast, shares your machine's kernel or one shared VM.
Cloud, e2b: a disposable Linux VM per agent session, at a cost, with the agent never on your machine.
Cloud, Codespaces: a general dev container on a VM, not purpose-built for agents.

A rule of thumb, not a religion

Use local sandboxing for the work you would supervise anyway: your own repos, code you wrote most of, changes you will review line by line regardless of the boundary. Reach for a cloud sandbox when you genuinely do not want the agent's output anywhere near your machine: untrusted dependencies, a prototype you do not trust yet, or a task where you would rather hand someone a disposable environment than your laptop.

The two are not mutually exclusive. Plenty of teams run local sandboxes for day to day work and keep a cloud sandbox around for the one task a week that does not belong on anyone's laptop.

Local for routine work you would review regardless.
Cloud for code or dependencies you do not trust enough to run nearby.
Most teams end up using both, for different tasks.

Where Forkbench fits this blueprint

Forkbench answers the first two decisions, write and read, with a folder lock that uses the macOS kernel sandbox to keep a Thread out of ~/.ssh, other repositories and Documents. Its Vault answers part of the credential question directly: a key is used by a command without the value ever reaching the prompt or the transcript.

It does not answer the third or fourth decision. The folder lock is opt-in and does not restrict the network, so you still have to decide what a Thread may connect to. And Forkbench runs locally, on your Mac. It is not a cloud sandbox, and it will not move an agent's execution off your machine the way e2b does. If that is the decision you need, Forkbench is the wrong tool for that one piece.

Covers: what a Thread can write and read, and keys it can use without seeing them.
Does not cover: network access, and it never runs an agent off your Mac.

Frequently asked

What is excessive agency in AI security?
It is OWASP's name, LLM06:2025, for giving an AI system more function, permission or autonomy than its task needs. A coding agent with unrestricted filesystem and network access has excessive agency even before it does anything wrong, because the capability itself is the exposure.
Is Docker enough of a sandbox for a coding agent?
For code you would already trust enough to review, often yes. Docker Desktop and OrbStack share one Linux VM across every container on the machine, a lighter boundary than a dedicated VM per sandbox, so treat it as a convenience layer rather than a hard wall against code you do not trust.
When should I use a cloud sandbox instead of a local one?
When you do not want the agent's task anywhere near your machine at all: untrusted dependencies, a one-off prototype, or work you would rather hand a disposable environment than your laptop. Local sandboxing is enough for routine work you are already going to review.
Does a sandbox replace reviewing the agent's code?
No. It limits what a bad command can reach while it runs. It has no opinion on whether the change itself is correct.
Does Forkbench run my coding agents in the cloud?
No. Forkbench is a Mac desktop app, and everything it locks down runs locally on your machine. If you need a cloud boundary, pair it with a tool built for that, like e2b.