The Sandbox Is a Policy, Not a Perimeter

The Sandbox Is a Policy, Not a Perimeter

6 min read

A local coding agent does not inherit a smaller identity when you turn on approvals. It inherits your account until the execution boundary says otherwise.

That distinction is the important part of GitHub’s general availability announcement for local Copilot sandboxing. The feature covers Copilot CLI, the Copilot app, and VS Code sessions using Agent Host. It restricts filesystem, network, credentials, and other capabilities through policies enforced by Microsoft’s eXecution Container, or MXC.

The release is not just another safety toggle. It is a public admission that agent security has two different control planes, and confusing them is how a useful coding assistant becomes a local administrator with a chat interface.

Approval is not containment

VS Code’s Agent Host documentation separates the protections cleanly:

ControlQuestion it answers
ApprovalShould this action run automatically, or does a person need to confirm it?
SandboxingWhich files, networks, credentials, and child processes can the action reach?

Those controls complement each other, but neither substitutes for the other.

A user can approve a command that is still limited to the active workspace and a deny-by-default network policy. Conversely, a sandbox can confine commands while a permissive approval mode lets the agent run every command it can reach inside that boundary.

The model is not the security boundary. The policy applied when its tools execute is the boundary.

What the release actually contains

GitHub says local sandboxing can control several concrete surfaces:

  • Read and write access to selected files and directories.
  • Outbound internet and local-network access.
  • Git and GitHub CLI credentials.
  • Local MCP and language servers where supported.
  • Commands that are allowed to bypass the sandbox.

The GitHub documentation says local sandboxing is off by default. Until it is enabled, Copilot-run shell commands execute with the same access as the current user. That means the agent can reach any files, networks, and credentials already available to that account.

In Copilot CLI, the documented interactive switch is:

/sandbox enable

For VS Code Agent Host, the setting is:

{
  "chat.agent.sandbox.enabled": "on"
}

Those snippets are not a complete security configuration. They only turn on the mechanism. The effective policy still determines whether the agent can reach the network, use credentials, start local servers, or request a one-command bypass.

The boundary is lighter than a VM

MXC translates a common policy into operating-system controls across Windows, macOS, and Linux. That is useful, but the word sandbox can invite the wrong mental model.

GitHub’s documentation describes local sandboxing as the lighter-weight end of the isolation spectrum. It restricts what a process can read, write, and reach on the network. It does not put every command inside a separate virtual machine or container.

VS Code makes the same limitation explicit: Agent Host sandboxing is not a virtual machine or a user-account boundary. The process still runs on the execution host under your account, and extra paths, credentials, network access, developer tools, and bypass permissions all weaken the isolation.

That is not a failure. It is a boundary with a defined strength. The operational mistake is treating it as stronger than the implementation says it is.

The exceptions are the architecture

The most important details are not the happy-path restrictions. They are the places where enforcement changes shape.

VS Code says terminal commands and their child processes can be sandboxed. MCP and language servers launched or managed by Agent Host can also be covered. But built-in tools that do not start operating-system processes use permission checks inside the agent host process itself.

GitHub’s Copilot documentation describes a similar split for the CLI: built-in file tools run in-process, so the operating-system sandbox cannot intercept them. Those tools must check and honour the policy in application code. Remote MCP servers are outside the local sandbox entirely.

That gives operators a boundary map rather than a single box:

agent model
    |
    +-- shell command -> OS policy
    |                    |
    |                    +-- child process
    |
    +-- built-in file tool -> in-process policy check
    |
    +-- local MCP or LSP -> policy depends on how it is launched
    |
    +-- remote MCP -> remote system's own boundary

Every arrow is a separate trust question. A policy that protects shell execution does not automatically protect a remote tool. An OS rule that catches a child process does not automatically constrain an in-process file operation. A prompt asking for approval does not turn either one into least privilege.

What agent builders should change

The first change is to stop describing an agent as sandboxed without naming the execution surfaces that are covered.

Record, for each tool path:

  1. Which process performs the action.
  2. Which policy enforces its filesystem and network limits.
  3. Whether credentials enter the process at all.
  4. Whether local servers inherit the same restrictions.
  5. What happens when the required isolation mechanism is unavailable.
  6. Which actions can bypass the policy, and where that decision is logged.

The second change is to make failure fail closed. VS Code says that when an operating-system dependency is unavailable, Agent Host does not silently run the command without the sandbox. That is the right default for autonomous execution: missing isolation should block the action, not downgrade it invisibly.

The third change is to start with a deny policy. The VS Code documentation warns that outbound network access is not blocked by default in the current Agent Host configuration. If an agent does not need the network, do not grant it because the tool happens to support it. If it needs one service, allow that service rather than the whole network.

Finally, treat every approved bypass as a security event. A bypass may be legitimate, but it changes the trust boundary. The audit record should say which agent, workspace, user, tool, path, network destination, and credential scope were involved.

The uncomfortable truth about local autonomy

Cloud sandboxes can provide a fully isolated, ephemeral environment. Local sandboxing solves a different problem: it lets an agent work on the developer’s machine while reducing the blast radius of the commands it runs.

That is a valuable tradeoff, especially because local sandboxing is included with Copilot at no additional charge. It is also a reminder that autonomy does not make the host disappear. The host remains the place where credentials, source code, local services, and developer trust meet.

The interesting part is not that GitHub shipped a sandbox. It is that the documentation names the seams: approvals versus containment, OS enforcement versus in-process checks, local tools versus remote MCP, and sandboxing versus a VM.

Those seams are where an agent security review should begin.

A model can choose the action. An approval gate can ask for consent. Only the execution policy can decide what the action is capable of touching.

The sandbox is not the perimeter. It is the policy that defines how much perimeter remains.

Sources

Keep reading

The Smallest Cyber Model Still Needs a Sandbox The Kernel Held. The Allowlist Didn't. The Pin Was a Label, Not a Check: How Plugin4Shell Walked Past SHA Pinning in Four Coding Agents