Coding Agent Sandbox Permissions: How to Layer File, Network, and Command Execution

As soon as a coding agent can execute a shell, it is no longer just a text generator. It can read environment variables, overwrite the working directory, download unknown dependencies, trigger deployment commands, and even write outside the repository through a bad symlink. The security boundary cannot rely on "the prompt says don't do this"; it must be enforced by the runtime environment.

The first principle is to split capabilities apart: reading the repository, writing the workspace, executing builds, accessing the network, reading secrets, publishing artifacts, and modifying production resources should be different permissions. An agent fixing a unit test doesn't need a cloud platform token; an agent generating a patch shouldn't by default have git push or deploy permissions. The finer the capabilities, the more meaningful approval and audit become.

Expose only the file-system regions the task needs

Put the agent in a temporary worktree or copy, rather than directly using the main working directory. When mounting paths, use an explicit allowlist — for example a read-only dependency cache, a writable source-code directory, and an invisible SSH config and host sensitive directories. Set a size cap on output directories to prevent the model or commands from generating large amounts of logs that fill the disk.

Path validation must be done on the actually resolved path, not just by checking string prefixes. src/../.env, symlinks, case differences, and mount points can all bypass naive rules. The executor should resolve the real path, reject targets that escape the repository root, and log each write operation as a relative path, a content digest, and the call source.

Command execution should have a visible policy layer

Don't expose an unrestricted shell as a general-purpose tool. Wrap common actions into parameterized commands: install dependencies, run lint, run a specified test, build, view git diff. For rm, network downloads, process management, container operations, and publish commands, apply a higher risk level and require explicit confirmation.

Command policy can be graded into three classes: read-only, writable, and irreversible. Read-only commands like git status are allowed by default; formatters or code generation that write to the working tree require task-scope validation; irreversible commands or external side effects must go through an approval gate. Recording the actual argv, working directory, exit code, a stdout digest, and resource usage is far more trustworthy than only saving the model's "I already ran the tests."

Network and credentials must be short-lived and minimal

Turn off the network by default, or only allow limited domains such as the package registry and documentation mirrors. When the build needs to download dependencies, use a controlled proxy and cache, and don't let the agent arbitrarily access intranet addresses or metadata services. If you must call a third-party API, issue a task-level short-lived token, scoped to a specific project and operation; never write long-term secrets into the environment, chat context, or logs.

Credential rotation is bound to the task lifecycle. After a task ends, a user cancels, or an approval expires, the token should immediately become invalid. The audit system records "which operations a certain capability token authorized during a certain time window," but it never records token plaintext. This way, when something abnormal happens, you can revoke a whole class of capabilities rather than urgently replacing all developer credentials.

Use offensive tests to prove the sandbox actually works

Before going live, prepare several negative tests: ask the agent to read a file outside the repository, write out of the workspace through a symlink, access an unapproved domain, execute a delete command, and print environment variables. The correct behavior is not the model politely refusing, but the runtime returning a deterministic denial and recording the reason. You should also test the normal paths, such as an allowed lint and a write to a restricted directory, to ensure the security policy doesn't block all everyday engineering work.

Least privilege adds a bit of configuration cost, but it limits the impact of an agent mistake to a single task, rather than an entire dev machine or a production account.

Treat the isolated environment as a disposable artifact

After each task ends, destroy the worktree, container, temporary volume, and capability tokens; keep only the redacted audit summary and the diff to commit. Don't, to save a few seconds of startup time, reuse an environment that carries the previous cache, processes, or credentials; this kind of reuse blurs the data boundary between tasks. When you genuinely need to cache dependencies, mount the cache read-only and partition it by project and lockfile hash.

When recovering a failed task, recreate the isolated environment, then restore the necessary checkpoints from controlled artifacts. The verification steps include checking that the container user is not root, that host sensitive paths are not visible, that the network policy still takes effect after a restart, and that the token is already unusable after the task ends. This way, even if the agent or its dependencies are compromised, the attack surface is limited to a single short-lived execution.

Bring these checks into the image release gate, to prevent a new base image from quietly loosening the isolation conditions.

Also keep a failing example, to prove that the policy actually rejected the out-of-scope command rather than only printing a warning.

Further reading

• AI Supply Chain Security
• Secrets Management
• MCP Security Audit