AI Agent Security After Copilot's Sandbox Went GA: The Default Policy Still Lets Agent Commands Read Your Registry Tokens

GitHub made local sandboxing for Copilot generally available on 7 October, in Copilot CLI, the Copilot app, and VS Code sessions using Agent Host. The announcement describes a policy boundary around the files, networks, and credentials an agent's commands can reach, with enterprise settings that developers cannot weaken. For AI agent security planning, the obvious reading is that the sandbox now lets you approve fewer prompts.

The documentation behind the announcement supports a narrower reading. The sandbox is worth turning on. But it ships off, and its default policy is tuned to keep builds working, not to keep secrets in.

What the default policy actually grants

Local sandboxing is off by default. Until someone enables it, the docs say, the shell commands Copilot runs have the same access as your user account. Turning it on with /sandbox enable gives you a deny-by-default filesystem policy, which then gets several grants added automatically. In the CLI, these are on by default:

• Include working directory. Read/write on the current directory and the repository's .git, plus read access to the whole repository when you are in a subdirectory.
• Allow dev tool access. Read access to developer-tool configuration and caches, including package-manager registries and the tokens they store, plus write access to shared build caches. The filesystem-policy page adds that some of these writable caches are shared with commands you run outside the sandbox.
• Allow outbound connections. Outbound internet is open. With no allow rules configured, every host stays reachable unless a deny rule blocks it.
• Authenticate git and Authenticate gh. A GitHub token is injected for HTTPS git, and GH_TOKEN is exported for the GitHub CLI. Both go through a local proxy that masks them.
• Allow sandbox bypass. The model can ask to rerun a blocked command outside the sandbox, subject to your approval. The same prompt can switch the sandbox off for the rest of the session.

Put the second and third bullets together and you have the central claim of this post. On a default configuration, a command an agent runs inside the sandbox can read your registry tokens and reach any host on the internet. The sandbox stops that command from rewriting your home directory. It does not stop it from sending what it read somewhere else. If /sandbox policy npm install on a fresh, unmanaged install shows no read grant for your registry configuration, or if outbound traffic turns out to be closed by default, this claim is wrong.

Where enforcement is software, not the kernel

Three more boundaries are in the docs and not in the announcement.

First, the CLI's built-in file-reading and file-editing tools run inside the CLI process, which is not itself sandboxed. They check the policy in code before they act, and GitHub calls that check best-effort. We wrote in August about an evaluation sandbox that existed only as a sentence in the prompt. A check in code is a step better than that, but it is still not the operating system enforcing the policy.

Second, remote MCP servers are never sandboxed. They run off your machine, so the filesystem policy does not constrain them, although the network policy can still restrict the CLI's connections to them. Local MCP and language servers are sandboxed by default.

Third, network enforcement differs by platform. When host rules are set, macOS and Linux force every connection through the local proxy. On Windows it relies on programs honoring the proxy settings, so a program that ignores them can get around your host rules. On Linux, bubblewrap cannot control local-network access separately for spawned processes.

Under all of this sits Microsoft eXecution Container (MXC), which GitHub describes as lighter-weight isolation, not a VM or a container. MXC tagged v1.0.0 on 7 October, the same day as the GA. The day before, issue 1430 reported that on the macOS Seatbelt backend, stat() on a denied path still returned the file's real size and timestamps. The fix merged after the v1.0.0 tag, and a comparison of the tag against main shows the v1.0.0 tag does not include it. It leaks metadata, not contents.

On Linux, bubblewrap's own README is the independent check here. It says bubblewrap is a tool for building sandboxes, not a ready-made sandbox with a security policy. How much protection you get depends entirely on the arguments the calling program passes. In other words, the security is in Copilot's policy, and the defaults above are that policy.

The AI agent security decision for this quarter

If your plan was to loosen approval prompts because the sandbox is now GA, do the following before you loosen anything.

1. Require the sandbox, and make it fail closed. Set sandbox.enabled and sandbox.failIfUnavailable to true through enterprise managed settings. Without failIfUnavailable, a server-managed requirement to sandbox is declined on a host that cannot support it, and that machine runs unsandboxed. With both set, the CLI blocks model requests and tool execution when it cannot enforce the sandbox.
2. Set sandbox.allowBypass to false. Otherwise, one approved prompt can turn the sandbox off for the rest of the session.
3. Turn off Allow dev tool access, or add deny rules for each registry configuration file. Then grant back only the caches your builds need. Check the result with /sandbox policy npm install, which shows the grants without running anything.
4. Add at least one host Allow rule. Once a single Allow rule exists, hosts that are not on the list are blocked, apart from localhost entries added automatically in one configuration. Enterprise rules can only narrow that list.
5. Treat remote MCP servers as outside the filesystem boundary, and Windows host rules as advisory. Decide which remote MCP servers are allowed at all, and enforce that somewhere other than the sandbox. Our post on the enterprise-managed agent permissions that went GA in September covers where that permission model reaches and where it does not.

This is the integration work we described in why enterprise AI doesn't ship: the agent reads and writes your real systems, and the auth around it is what decides the outcome. Writing that managed policy for a fleet is part of our AI agent development work.

This advice is wrong for a team whose developer machines hold no long-lived registry tokens. That is the case, for example, if you publish only from CI with short-lived credentials and developers pull through an unauthenticated mirror. There, dev tool access exposes nothing worth stealing, and turning it off only breaks builds. Run /sandbox policy npm install first to see which case you are in.