GitHub Unifies Agent Tool Permissions Under Enterprise Policy, but Software Rules Are Not the Same as OS-Level Isolation

GitHub has made “managed permissions” generally available for Copilot Business and Enterprise, allowing administrators to use the same rules to control the Copilot App, Copilot CLI, and VS Code sessions that use Agent Host. Rules can currently match four operation types—`Shell`, `Read`, `Edit`, and `Domain`—and set each to `deny`, `ask`, or `allow`. Enterprises can also apply different policies to different teams without disabling agent mode across the board.

This update addresses permission drift commonly seen in agent front ends: previously saved user approvals, workspace settings, `allow-all`, and automatic approvals cannot weaken centrally managed restrictions. VS Code’s public preview shows that the evaluation precedence is deny over ask, and ask over allow, while unmatched operations require confirmation by default. Path rules can distinguish among the workspace, current directory, home directory, and filesystem root. Individual domains can also be added to allowlists or denylists, making it possible to block credential directories, restrict `git push`, or permit access only to internal package registries.

Importantly, managed permissions are policies enforced by Agent Host/Copilot SDK at the tool-call layer and should not be confused with strong isolation provided by a kernel or container. GitHub’s own CLI documentation notes that Shell commands can install software, delete files, push code, and send network requests. If managed rules permit command execution, the actual capabilities still depend on the process’s host permissions and whether a local or cloud sandbox has been separately enabled. This also differs from the enterprise sandbox recently added to JetBrains: the former determines whether an agent may attempt an operation, while the latter limits which resources a launched process can actually access.

Teams deploying the feature should first use a minimal rule set to validate wildcard handling, symbolic links, workspace-root resolution, and command wrappers, and should include denial events in their audit processes. Key issues to watch next include whether MCP tools, browser operations, and subagents can be brought under the same permission syntax, and whether enforcement semantics remain consistent across platforms.