Sandboxing
How AI Workbench keeps agents apart from each other and from your machine, and when an agent runs in a sandbox.
Agents run code. AI Workbench limits what they can reach in layers: each agent works on its own branch, a policy caps what it may do, prompts are cleaned before they leave the machine, and on a Linux node each agent session can run in a sandbox of its own.
Worktrees keep agents apart
Each agent works in its own git worktree, on its own branch. Two agents never edit the same checkout, and their work only meets when it is merged on an integration branch you control. This is isolation of the work, not of the machine: an agent on your computer runs as you, with your user's access to files and the network.
Policy limits what agents may do
A policy decides which agent tools may start, the highest permission mode they may run in, actions that always ask, which network destinations they may reach, and which branches are protected. The workbench enforces it before an agent starts and on every request; no setting can loosen it.
What stays off the agent's hands
- Secrets. Keys and tokens are kept in the operating system's secure store, never in a repository. Agents do not inherit the workbench's own credentials, and an agent sees a secret only when it is allowed to. Hosted model providers are reached through the workbench's gateway, so the agent gets a stand-in key.
- What leaves the machine. Data-loss prevention redacts secrets (and, if you choose, personal data) from prompts before they leave, and an optional local classifier can block or ask.
Stronger containment
An agent on your own computer runs with your user's rights. When you need more than that:
- Dev containers run a repository's agents inside its container.
- SSH hosts and nodes run them on another machine.
- Sandboxed nodes run each agent session in its own sandbox.
Sandboxed sessions on a node
On a Linux node that can provide them, each agent session can run in its own NVIDIA OpenShell sandbox:
- The sandbox enforces your policy's network rules for that session, using Linux's seccomp and Landlock and a network proxy.
- Only the repository and the scripts the agent needs are mounted. The repository is mounted at its own path, so worktrees mean the same inside and out.
- API keys are held outside: inside, the agent sees a stand-in. A credential the sandbox cannot hold this way is left out, not passed in.
- Subscription sign-in files are copied in for that session only, and removed with it.
- When the agent stops, the sandbox and everything staged for it are deleted.
A desktop never sandboxes agents: sandboxes come with nodes. A repository's policy asks for them with agents.sandbox:
| Value | Means |
|---|---|
off (default) | Agents run as ordinary processes. |
preferred | Agents run in a node's sandbox when one is available, and as ordinary processes otherwise. |
required | Agents only ever run in a sandbox. On a machine that cannot provide one, including any desktop, no agent starts in that repository, and the workbench says why. |
Sandboxed nodes are new. Try them on a native Linux node before you rely on them. How to set one up is on Sandboxed nodes.