Practical guide · Coding-agent security
How to sandbox AI coding agents safely
A coding-agent sandbox should make the safe path easy and deny everything the task does not need. Bound the files, network destinations, credentials, commands, resources, and side effects before the agent reads untrusted repository content. Then run denial tests. A policy that looks strict but cannot stop a real command is documentation, not isolation.
Published October 17, 2026 · Reviewed October 17, 2026 · 11 minute read
The short answer
Start each coding agent in a disposable workspace with one repository, no production access, no personal home-directory access, blocked network access by default, and short-lived credentials for the smallest required action. Require approval for dependency installation, external communication, sensitive files, and irreversible writes. Keep logs outside the workspace, test forbidden actions, and delete the environment when the task ends.
Begin with the task, not the tool's default
Write down what the agent must read, change, execute, and contact. Include repository files, package registries, test databases, issue text, web pages, MCP servers, and any command that can publish or deploy. Treat external text and repository instructions as untrusted input. OWASP's secure coding with AI guidance identifies issue bodies, pull requests, README files, tool responses, changelogs, and fetched pages as prompt-injection surfaces.
Now list the damage possible if hostile text controls the next tool call. Can the process read an SSH key, send source code to an arbitrary host, alter CI, delete a database, or push a protected branch? Remove those capabilities instead of asking the model not to use them.
Set seven boundaries
1. Filesystem
Mount only the task repository. Make unrelated directories unavailable, keep secrets outside the mount, and grant write access only where the change requires it. A Git ignore file does not prevent a process from reading a file. Use operating-system, container, or virtual-machine controls.
2. Network
Block outbound and local network access unless the task requires it. Add exact hosts for package registries or documentation, rather than open internet access. GitHub's sandbox documentation describes separate controls for outbound internet, local networks, filesystem paths, credentials, and subprocesses. Its local sandbox uses lighter operating-system containment, while cloud sessions use isolated ephemeral environments.
3. Credentials
Issue a short-lived token for one repository or service and one action. Keep production, cloud-admin, personal Git, password-manager, and signing credentials out of the environment. Prefer a proxy that attaches credentials after checking the destination and operation, so the agent never receives the secret value.
4. Commands and tools
Allow the compiler, test runner, formatter, and bounded file tools needed for the task. Require approval for package installation, shell escapes, MCP additions, generated scripts, CI changes, and sandbox bypass. Review tool descriptions because a connected server can supply instructions as well as actions.
5. Side effects and approvals
Separate editing from publishing. Let the agent prepare a patch, but ask a person or independent policy to approve pushes, pull requests, database writes, deployments, messages, purchases, and destructive operations. Anthropic's Claude Code security guide distinguishes permission prompts from operating-system sandboxing and warns that an approved shell command can otherwise act with the user's permissions.
6. Resources and time
Limit CPU, memory, disk, process count, runtime, and spend. Stop recursive agent spawning and retry loops with explicit ceilings. Resource limits reduce denial-of-service risk and make failed tasks easier to reproduce.
7. Logs and cleanup
Send command, network, credential, approval, and file-change records to storage the agent cannot edit. Preserve the commit and policy used for review. Revoke credentials and destroy the workspace after the task, rather than reusing a contaminated environment.
Worked example: fixing a parser bug from a public issue
The task needs source and test access, the project's existing dependency cache, and no external service. Clone the repository into a disposable workspace. Mount that directory read-write and mount the language package cache read-only. Block the home directory, credential stores, Docker socket, local network, and outbound network. Provide no Git push token.
Before starting, a person reads the public issue for hidden or unrelated instructions. The agent may edit code and run focused tests. Adding a dependency, changing CI, or accessing another path requires approval. Afterward, export the patch and test log, review them with Learnetto's six-pass AI code review, then destroy the workspace. A separate trusted process can push the approved commit.
Choose isolation by risk
| Approach | Good fit | Trade-off |
|---|---|---|
| Permission prompts | Trusted repository, supervised exploration, no sensitive credentials | A tired reviewer may approve a harmful command, which can expose everything the user account can reach. |
| Local OS sandbox or container | Routine development with narrow file and network needs | Strength varies by platform, configuration, mounts, sockets, and in-process tools. |
| Ephemeral VM or cloud workspace | Untrusted repositories, autonomous runs, parallel tasks, stronger separation | More setup, cost, image maintenance, and data-governance work. |
| No agent execution | Production-only access, regulated secrets, or tasks whose safe boundary cannot be enforced | A person performs the work with established controls. |
Test the sandbox before trusting it
- Attempt to read a file outside the repository and a known credential path. Both should fail.
- Attempt outbound access to an unapproved host and a service on the local network. Both should fail.
- Attempt to install a package, start a privileged subprocess, use the Docker socket, and write CI configuration without approval.
- Attempt a push, branch deletion, production request, and database write with the task credential. Each unneeded action should be denied.
- Exceed a small process, disk, and runtime limit in a test environment and confirm the session stops without affecting the host.
- Verify that logs survive workspace deletion and that revoking the credential prevents later reuse.
Limits and common mistakes
- A sandbox limits reach. It does not prove that the generated code, test, or requested action is correct.
- An allowed host can still receive sensitive data, and an allowed command can combine harmless-looking steps into a harmful result.
- Remote MCP servers run outside a local process sandbox. Review their identity, tools, data handling, and authorization separately.
- Mounted sockets and broad cloud credentials can erase container or VM boundaries.
- Multiple agents multiply credentials, contexts, logs, cost, and failure paths. Give every worker its own scope and expiration.
Pre-run checklist
- □ The task, expected patch, and acceptance checks are explicit.
- □ Untrusted content and possible damage are listed.
- □ File, network, command, and resource policies deny unneeded access.
- □ Credentials are short-lived, task-scoped, and non-production.
- □ Sensitive or irreversible effects require independent approval.
- □ Denial tests pass and the session fails closed when isolation is unavailable.
- □ Logs are outside the agent's control.
- □ Cleanup revokes credentials and destroys disposable state.