How to Sandbox Your AI Coding Agent on Your Own Machine

Before you start

In September 2026, someone posing as a project director contacted a Binance engineer on a real job platform. After two rounds of interviews, the engineer downloaded the take-home assignment repository to a work computer. Code in its setup step replaced the engineer's pyenv with malware that the endpoint tools did not detect. By 20 October the attackers had used an internal AI tool to take control of two more engineers' computers, and on one of them they found a container deployment token. On 29 October they used it to deploy a container that reached Binance's wallet signing service. Binance's initial incident report puts the affected assets at $6.34 billion, with $2.85 billion frozen or intercepted.

Two steps in that chain are what a sandbox takes away. The assignment's setup code ran with everything the engineer's account could reach, and a deployment token sat on a laptop where any process could read it. Sandboxing a coding agent, or any code you don't trust yet, means shrinking that reach to one project and the few credentials the task needs.

This guide uses brig, the open-source sandbox NOFire AI builds, because it runs on a developer's own machine. The same steps apply to any sandbox that gives you control over files, credentials and network. You need an Apple silicon Mac on macOS 15 or newer, or a Linux machine, and a project folder.

What changes when the agent runs inside a sandbox:

What AI agent sandboxing is compares containers, gVisor and microVMs if you want the detail behind the last two rows.

The steps

1. Install brig and check the machine

On macOS:

brew tap brig-sh/brig
brew trust brig-sh/brig
brew install --cask brig
brig doctor

On Linux, follow the install page. brig doctor reports whether the host can run a sandbox.

2. Run the agent on one project

brig run claude-code ~/code/my-app

The agent works in /work/my-app and in its own guest home. It does not see your other folders, your keychain or your SSH agent. Name one project per run, and not your home directory. For code you don't trust, such as a take-home coding assignment, mount no project at all: run with --no-project and clone the repository inside the sandbox, so brig rm deletes everything it touched. A writable checkout can carry malicious hooks back to your machine. How Brig could have interrupted the Binance attack walks through that setup command by command.

3. Keep production tokens out of that project

Everything inside the folder you name is in reach, including .env files and old scripts. Move production credentials out of the project and into brig's store, where the agent can reach them only through a route (steps 4 and 5). In the Binance attack, the deployment token was sitting on an engineer's laptop, where the attackers found it.

4. Keep credentials on the host with the broker

Since v0.5.0, brig has a credential broker. The agent sends its API requests to a route, and the broker adds the real credential on the host and forwards the request upstream. The agent holds only a session token for that route, and brig stop or brig rm revokes it. Import your Claude Code login into brig's store once. brig stores it as claude-credentials, the secret the policy in step 5 names:

brig secret import claude-code

5. Write one policy for credentials and network

A policy names the routes and denies every other outbound connection. Save this as ~/.config/brig/policies/claude-routed.yaml:

apiVersion: brig.sh/v1alpha1
kind: Policy
metadata:
  name: claude-routed
  description: Claude Code through the broker, no other egress
spec:
  egress:
    default: deny
  routes:
    - name: anthropic
      preset: claude-code
      credential:
        secretRef: { name: claude-credentials }

Attach it, check it, and run the agent:

brig policy attach claude-routed claude-code
brig policy check claude-code
brig run claude-code ~/code/my-app

brig policy check refuses a route the run could not enforce. Add allow rules under egress for anything else the task needs, such as your package registry. The same route form works for other HTTPS APIs: you set the upstream, how the credential is added, and which methods and paths request.allow lets through. The github-token preset also takes a list of repositories. Routes run on macOS with the hvi backend, which the claude-code profile already uses, and on Linux with nerdctl and urunc, and brig refuses a routed run anywhere else. The policy docs list every field.

6. Scope tokens at the provider and keep backups elsewhere

Create tokens per environment and per job wherever your provider allows it, so a staging token cannot touch production. Keep backups in a different place from the data: push code to a remote, and store database backups outside the account or volume they protect.

Verify it worked

Run brig info claude-code. The isolation row should name a microVM, and the BROKER row should list your route and say which secrets are kept on the host. Any credential brig info lists outside that row is still delivered into the sandbox.

Inside the sandbox, ANTHROPIC_BASE_URL should point at brig.internal, and there should be no ~/.claude/.credentials.json.

Ask the agent to list your home directory on the host or read ~/.ssh. It should find neither. Then ask it to fetch a page from a host the policy does not allow. The name should not resolve.

Where it breaks

The project folder. The agent can change or delete any file in it. Commit and push often.

What a route allows. The agent never holds a routed credential, but it can send any request the route's rules allow while the sandbox runs. Path rules cannot tell apart operations that share one endpoint, such as GraphQL mutations, so a broad token behind a route is still broad.

Credentials delivered the old way. A secret a profile delivers as a file or variable sits inside the sandbox, and the agent can use it the way a person holding it could.

No egress policy. Without default: deny, the sandbox still reaches the internet, and anything the agent can read it can also send out.

Allowed hosts. If the task needs your cloud provider's API, a host allow list cannot tell a staging call from a production one. That is the token's job, which is why step 6 matters.

Agents that act on infrastructure. Once an agent needs write access to production, isolation is not enough on its own. Sandboxing agents with production write access covers the policy gate and staged access that go with it, and the sandboxing manifesto explains why the agent is treated as untrusted by default.