Agent Runtime: AI coding agent sandbox

A coding agent reads files, runs shell commands and calls tools in a loop. Its instructions come partly from outside: a ticket, a web page, a README in a dependency. Any of those can contain text that tells the agent to do something harmful. This attack is called prompt injection, and no model is fully immune to it.

A sandbox reduces what a successful attack can reach. The operator sets what an agent can reach before it starts. If a malicious instruction succeeds, the agent still finds no credentials to steal, no neighbouring project to read and no open route to send data away.

The rule to apply: treat the code an agent runs the way you treat code from an unknown contributor.

Agents can be isolated in several ways, and stronger methods start more slowly.

Agent Runtime isolates each session at the operating system level, around the whole agent process. If you run code from anonymous users, choose a microVM.

A session reaches only what it needs: the model, the tools named for it, and the public web when its work calls for it. Everything else on the machine stays out of reach, including databases and other internal services. An agent with a stolen secret and no route out cannot send that secret anywhere.

Agents need a model key to work, and a key inside the sandbox is a key an attacker can read. Agent Runtime keeps real keys on the host, so an agent that prints its whole environment finds nothing of value.

The agent edits files in its folder and holds no forge token. A forge is the service that hosts your code, such as GitHub or GitLab. After the work ends, the host reads what changed and decides. An empty change, a file outside the assigned area or anything shaped like a credential is refused. Everything else becomes a draft for a person to review.

1. Can the agent read the model key from inside?
2. Can it reach internal services on the same machine?
3. What happens when the sandbox tool is missing: refusal or silent fallback?
4. Who pushes the code, the agent or the host?
5. Is the diff scanned for secrets before it leaves?
6. Can one session read another?
7. Can you test the isolation on the real server?

A coding agent reads far more outside text than a chatbot does. Each of these sources can carry an instruction.

Filtering text helps a little, and it will miss new phrasing. Limiting what the agent can reach holds up better, since it works whatever the wording.

An agent that works alone needs a record. Keep these for each session.

• Who started it, with which permissions
• The tools it used and the commands it ran
• The files it changed
• The outbound connections it opened or tried to open
• The model and the cost

Store secrets outside these logs, and mask anything shaped like a credential. A refused network call is worth an alert, since a healthy agent rarely tries one.

1. Start with read only tasks, such as explaining code.
2. Move to draft changes on low risk repositories.
3. Require a human review on every change.
4. Protect the main branch at the forge.
5. Give agents their own accounts, so history shows who did what.
6. Review refused actions each week.
7. Widen access one step at a time.

Set a budget per task, and stop runs that reach it. A task described clearly costs less than a vague one, because the agent spends fewer turns searching.

Check your client contracts first, because they may limit where your code can run.

• Agents run under a developer's personal account.
• A .env file with production keys sits in the working folder.
• An agent can push straight to the main branch.
• Sessions share one folder.
• Nobody can say what an agent did last Tuesday.
• A failed sandbox start lets the agent run anyway.

Any one of these is worth fixing before you give an agent more work.

Name the place, the expected result and how to check it. Clear tasks use fewer turns, and they need less access.