Updated 8 Oct 2026: Adds Oct 7 GA of MXC-backed local Copilot sandboxes across CLI, desktop app and VS Code Agent Host, with OS-enforced filesystem/network/credential boundaries and mandatory enterprise policies; distinguishes JetBrains preview.

Key details

  1. GitHub announced enterprise-managed permissions for Copilot agent operations on September 9, 2026.
  2. Admins can govern shell commands, file reads and edits, and network domains.
  3. Each operation can be blocked, require human approval or proceed without a prompt.
  4. Managed restrictions cannot be weakened by user/workspace settings, auto-approval or previously saved approvals.
  5. Different enterprise teams can receive specialized policies.
  6. The controls are generally available in the GitHub Copilot app, Copilot CLI and VS Code Agent Host sessions.
  7. JetBrains separately supports public-preview enterprise-managed sandbox controls for filesystem, network, proxy, developer tools and macOS Keychain.
  8. Existing enterprise controls continue to cover MCP servers, plugins, telemetry and permissive agent modes.
  9. On October 7, 2026, GitHub made local Copilot sandboxing generally available in Copilot CLI, the Copilot app and VS Code Agent Host.
  10. Microsoft MXC maps common policies to native controls on Windows, macOS and Linux.
  11. Policies can restrict agent-run filesystem, network and credential access; supported local MCP and language-server tools can also be covered.
  12. Enterprise administrators can require sandboxing and prevent developer-local overrides.
  13. Local sandboxing is included with GitHub Copilot at no additional charge.

What builders should take away

  1. Separate low-risk automation from high-impact operations in enterprise policy instead of choosing one global autonomy level.
  2. Put production-changing shell commands, sensitive filesystem paths and privileged network domains behind required approval or explicit blocks.
  3. Test managed restrictions against saved approvals and local workspace settings so developers understand which controls the enterprise owns.
  4. Use operation permissions and sandbox limits together: approval policy governs intent, while sandboxing constrains what an allowed action can physically reach.
  5. Keep production authorization server-side even when the Copilot client is centrally managed.
  6. Use team-specific policies where development roles genuinely require different tool, filesystem or network boundaries.
  7. Enable local sandboxing for agent-driven shell/tool execution rather than treating a permission prompt as the only boundary.
  8. Verify that managed sandbox policy restricts credential and network access even when a model or tool changes.
  9. Keep the JetBrains preview and GA CLI/app/VS Code scopes separate when documenting rollout.

What changed

GitHub added generally available enterprise-managed permissions for Copilot agent operations on September 9, 2026. Copilot Business and Enterprise administrators can centrally classify shell commands, file reads and edits, and network domains as blocked, requiring human approval or allowed without a prompt. Managed restrictions cannot be weakened by user or workspace settings, auto-approval or previously saved approvals, and enterprises can define different policies for different teams. The controls apply to the GitHub Copilot app, Copilot CLI and Visual Studio Code sessions using Agent Host. This extends the same governance direction already visible in JetBrains, where GitHub added public-preview managed sandbox policies on September 8 for sandbox enablement, filesystem/network access, proxy behavior, developer tools and macOS Keychain access. On October 7, 2026, GitHub made local sandboxing generally available in Copilot CLI, the Copilot app and VS Code sessions using Agent Host. The local execution boundary is powered by Microsoft eXecution Container (MXC), which translates shared policies into native OS controls on Windows, macOS and Linux. Policies can restrict files, directories, network destinations and credentials, including local MCP tools and language servers where supported. Enterprise settings can require sandboxing and prevent developers from weakening restrictions. This is distinct from the JetBrains-specific sandbox controls, which GitHub previously described as public preview.

Why it matters

AI coding governance now has an enforceable operation layer rather than only client-wide settings. An organization can let agents work autonomously on low-risk actions while requiring approval or blocking higher-risk shell, filesystem or network operations, and those restrictions survive local attempts to relax them. The JetBrains sandbox remains a complementary boundary: operation permissions govern what actions may proceed, while the sandbox limits what the local execution environment can reach. Together they show GitHub converging on centralized policy for both agent intent and execution across multiple clients. The October GA milestone means teams can rely on a supported local execution-isolation layer across three mainstream Copilot surfaces rather than only approval prompts or a preview switch. The model still does not become intrinsically trustworthy: containment applies to tool execution, and server-side authorization remains essential.

Enterprise policy can now govern individual agent operations

Administrators can centrally define policy for shell commands, file reads and edits, and network domains. Operations can be blocked, require a human approval prompt or be allowed without prompting. GitHub says managed restrictions cannot be weakened by user settings, workspace settings, auto-approval or approvals a user saved previously.

The permission layer spans multiple Copilot clients

The September 9 controls are generally available in the GitHub Copilot app, Copilot CLI and Visual Studio Code sessions using Agent Host. Enterprises can also apply specialized policies to different teams, making the control model more granular than a single organization-wide autonomous-versus-manual switch.

JetBrains adds a complementary local sandbox boundary

GitHub's September 8 JetBrains update remains relevant because it governs the local execution environment itself: sandbox enablement, filesystem and network access, proxy settings, developer-tool access and macOS Keychain access. Those managed restrictions override developer-local choices and are still public preview.

MCP, plugins and telemetry remain part of the broader policy stack

Existing managed settings continue to govern plugin marketplaces, MCP server allow/deny lists, OpenTelemetry and permissive agent modes. The newer operation permissions add finer-grained action control without replacing those external-integration and observability policies.

Central policy does not remove server-side authorization needs

A client-side permission system and sandbox reduce accidental or unauthorized local actions, but production systems should still enforce their own identity, authorization and review boundaries. High-impact infrastructure, billing and deployment APIs should not rely solely on a coding client's approval prompt.

Local sandboxing is now GA across three Copilot surfaces

On October 7 GitHub made MXC-backed local sandboxing generally available in Copilot CLI, the Copilot app and VS Code Agent Host sessions. A common policy maps to native Windows, macOS and Linux restrictions for agent-run commands and tools. This is separate from the earlier JetBrains preview.

Sandbox policy limits capabilities, not just prompts

The execution boundary can restrict filesystem read/write scope, network access and access to Git/GitHub CLI credentials, with some local MCP and language-server integrations also covered. Enterprises can require sandboxing and disallow local weakening of managed settings. Model selection does not change the sandbox policy.

What to watch next

  • Expansion of managed operation permissions into JetBrains and other Copilot clients.
  • Whether GitHub adds richer tool-level or MCP-call permissions beyond server allow/deny controls.
  • Audit/export APIs showing which operation policies were applied and which approvals were granted.
  • When the JetBrains enterprise-managed sandbox reaches general availability.
  • Independent testing of policy precedence and sandbox bypass boundaries across supported clients.
  • JetBrains sandbox GA timing and cross-client parity.
  • Independent evaluations of MXC policy enforcement and local tool/MCP edge cases.

Still unclear

  • GitHub's operation-permission controls are GA, but public evidence on real-world policy-bypass edge cases is still limited.
  • JetBrains sandbox policy remains public preview and may change.
  • The exact operation vocabulary and matching semantics can evolve as GitHub adds tools and agent surfaces.
  • Client policy should be treated as defense in depth rather than a substitute for authorization enforced by the systems an agent calls.
  • The GitHub GA announcement does not establish that every IDE integration or MCP tool is covered by the same isolation controls.

Sources

Direct reading behind this dossier.

5 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment