---
title: "AI coding agent sandbox: one jail per session"
description: "La Boétie runs this AI coding agent sandbox in house: one jail per session, credentials on the host and a default 120 turns per caller per minute."
canonical: "https://laboetie.io/products/agent-runtime"
language: en
---
# Agent Runtime: AI coding agent sandbox

Agent Runtime is the AI coding agent sandbox La Boétie runs in house. Each session gets its own isolated environment. The host keeps model credentials behind a relay and opens draft pull requests itself. The service sits beneath PRbot and has no public access.

Status: Live. Access: In house. One folder per session and no real credentials inside it.

## Capabilities

- Each session runs in its own jail with a private home and folder.
- Model credentials stay on the host behind a relay.
- Draft pull requests open from the host, which rejects empty diffs and credential shaped content.
- One forge interface covers GitHub and GitLab.
- Admission is controlled per caller and per client address.

## How the sandbox isolates each session

Each session runs in its own isolated environment with a private folder. It reaches only what its work needs, and other services on the machine stay out of reach.

## Where model credentials live

Model credentials stay on the host behind a relay. Because a jailed agent calls the model through that relay, the session holds no real credential. The host scans each diff before it opens a draft pull request and refuses anything shaped like a credential.

## Draft pull requests from the host

The host opens draft pull requests on GitHub and GitLab through one forge interface. Before it opens one, it refuses empty diffs, paths out of scope and anything shaped like a credential. The jailed agent edits files in its folder and leaves the push to the host.

## Rate limits and session ownership

The default limit is 120 turns per caller per minute, and a second limit allows 20 failed authentications per client address per minute. A session folder belongs to the profile and caller that created it. A caller key without that profile gets refused. File access stays confined to the session folder once links are followed.

## How La Boétie uses Agent Runtime

La Boétie runs its coding agents on this service, and PRbot is built on it. The codebase holds 204 test declarations in 26 files. The repository is private, and the service offers no signup and no public endpoint. Teams that want agents working on their own code can send a brief, and the studio will start from PRbot.


## Why a coding agent needs a 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.

## What can go wrong without one

| Risk | Example | Control in Agent Runtime |
|---|---|---|
| Credential theft | The agent reads an API key and posts it to a URL | The key stays on the host, behind a relay |
| Data exfiltration | The agent uploads source code | A private network with an allow list |
| Cross project access | One session reads another client's folder | One isolated environment per session |
| Internal service access | The agent calls a database on the same machine | Nothing else that listens on the host is reachable |
| Secret in a commit | The agent writes a token into a file | The host scans the diff and refuses it |
| Runaway use | A loop burns the model budget | Admission limits per caller |

## Sandbox technologies compared

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

| Method | Isolation boundary | Start time | Good fit |
|---|---|---|---|
| Permission prompts | A person approving commands | None | A developer at the keyboard |
| Containers | Namespaces, with a shared kernel | Fast | Most server workloads |
| Operating system jail | Namespaces, with a shared kernel and no daemon | Fastest | One process tree under a plain user |
| MicroVMs | A separate kernel per session | Slower | Hostile multi tenant code |
| Hosted sandbox service | Depends on the vendor | Network dependent | Teams that want no servers |

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.

## Network rules

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.

## How the model credential stays on the host

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.

## Draft pull requests opened by the host

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.

## Build or buy a sandbox

| Your situation | Sensible choice |
|---|---|
| One developer, trusted repository | Permission prompts or a local sandbox |
| A team running agents on its own server | A jail like this one, or containers |
| Code from unknown users | MicroVMs or a hosted sandbox |
| Agents working from tickets | [PRbot](https://laboetie.io/products/prbot), built on this engine |

## What to check in any agent sandbox

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?

## Common mistakes

| Mistake | Better |
|---|---|
| Passing the API key as an environment variable | Keep it on the host, behind a relay |
| Giving the agent a personal forge token | Let the host push, under its own account |
| Running as your own user | Use a dedicated account |
| Leaving the network open | Allow only the destinations a session needs |
| Testing isolation once | Run a probe on each machine after each change |

## Who needs what level of isolation

| Team | Typical risk | Reasonable starting point |
|---|---|---|
| Solo developer | A bad command on a personal laptop | Approval prompts and a separate project folder |
| Product team | A leaked key, or a change to the wrong service | A dedicated environment per task |
| Agency with client code | One client's code reaching another | Separate environments and separate credentials |
| Platform running user code | Hostile code by design | A separate kernel per session |
| Regulated company | Proof of who did what | Isolation, logs and human approval |

## Prompt injection in coding agents

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

| Source | Example |
|---|---|
| Issue text | A hidden comment in a ticket |
| Dependencies | A README or a post install script |
| Web pages | Documentation the agent looks up |
| Test output | Error text printed by a tool |
| Pull request comments | A note left by an outsider |

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.

## What to log

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.

## Rolling out agents in a team

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.

## Costs to plan for

| Cost | Driver |
|---|---|
| Model usage | Context size and number of turns |
| Compute | Parallel sessions and test suites |
| Reviews | Human time on each draft |
| Failed runs | Tokens spent on work you throw away |

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.

## Local, self hosted or hosted sandbox

| Question | On a laptop | On your own server | Hosted service |
|---|---|---|---|
| Setup effort | Low | Medium | Low |
| Where code runs | Your machine | Your machine | The vendor's cloud |
| Parallel sessions | Few | As many as the server allows | Scales with spend |
| Access to private systems | Direct | Controlled | Needs a tunnel or a key |
| Best for | One developer | A team with private code | Bursty workloads |

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

## Signs your setup is too open

- 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.

## Glossary

| Term | Meaning |
|---|---|
| Sandbox | An environment that limits what a program can reach |
| Prompt injection | Text that steers a model away from its instructions |
| Exfiltration | Sending data out without permission |
| MicroVM | A small virtual machine with its own kernel |
| Allow list | The only destinations a session may reach |

## Writing tasks an agent can finish

| Weak task | Stronger task |
|---|---|
| "Fix the tests" | "Fix the failing date test in the invoice module" |
| "Improve the page" | "Add a loading state to the orders table" |
| "Clean up the code" | "Remove the unused helpers in one named folder" |

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

## Next step

Teams that want this engine usually want [PRbot](https://laboetie.io/products/prbot), which packages it. [Send a brief](https://laboetie.io/brief) that names your stack, your forge and the paths agents may touch. The studio can also build a runtime around your own constraints.


## Frequently asked questions

### What is an AI coding agent sandbox?

An AI coding agent sandbox is an isolated environment that limits the files, network and credentials an agent reaches while it runs commands. Agent Runtime builds one for each session with bubblewrap: an empty root, a private home, a private folder and a private network. A jailed agent reaches the model relay and the MCP servers its request names.

### Can a sandboxed agent read the model API key?

No. Agent Runtime keeps model credentials on the host. A jailed agent reaches the model through a relay on that host. The session holds no real credential. The host scans each diff before it opens a draft pull request and refuses anything shaped like a credential. The relay and that scan both run on the host outside the jail.

### Does a sandboxed coding agent have internet access?

Public web access depends on the tools a session holds. A session reaches the public web only when it holds the WebFetch tool. Each session has a private network limited to the model relay and the MCP servers named in its request. A probe script checks the jail and the network of each kind of session on the machine.

### How many agent turns does Agent Runtime allow?

The default limit is 120 turns per caller per minute. A second limit allows 20 failed authentications per client address per minute, and turns running at once default to the number of session slots. A refused turn returns HTTP 429, the status every runtime client treats as a capacity signal. These limits bound what one credential can start.

### How is Agent Runtime related to PRbot?

PRbot is built on Agent Runtime. PRbot uses it for the clone, the forges and the broker that opens each draft, then adds issue intake, a twelve phase run and a console. Teams that want agents working through their issues should read the PRbot page, because PRbot is the version of this engine available by request.

### Can my company use Agent Runtime?

Agent Runtime has no public access. The service binds to a loopback address on a studio machine, and its repository is private with no license file. La Boétie uses it to run its own coding agents. To put sandboxed agents on your code, send a brief from this page. The studio replies with a setup based on PRbot.