GitHub has made enterprise-managed permissions for Copilot agent operations generally available as of September 9, 2026. The controls let Copilot Business and Copilot Enterprise administrators centrally define how supported shell commands, file reads and edits, and network domains are handled.
For engineering organizations using agentic coding workflows, the change provides a way to keep automation available while setting organization-wide boundaries around potentially sensitive operations. Administrators can block an operation, require a fresh human approval, or allow it without a prompt, depending on the rule and client support.
What changed
The announcement covers the GitHub Copilot app, GitHub Copilot CLI, and Visual Studio Code sessions that use Agent Host. GitHub’s broader managed-settings documentation also lists Copilot CLI, VS Code, the Copilot app, Copilot cloud agent, and JetBrains IDEs as supported clients, but it warns that individual clients do not necessarily support every managed-settings property.
The permission schema includes permissions.deny, permissions.ask, permissions.allow, and permissions.disableBypassPermissionsMode. The documented selectors include:
- Shell, with Bash available as a compatibility alias
- PowerShell
- Read
- Edit, with Write available as an alias
- Domain
Rules can target command patterns, file paths or globs, and network hosts according to the supported selector behavior. The supplied documentation does not fully establish the enterprise-specific URL canonicalization behavior for domain matching, so domain policies should be tested in the client surfaces an organization intends to use.
How permission precedence works
Managed rules use a restrictive precedence model: deny takes priority over ask, and ask takes priority over allow. A deny rule therefore blocks a matching operation even if another applicable rule allows it.
Multiple managed sources can also narrow the effective policy. Deny and ask rules are combined across applicable managed sources. Allow rules are different: when multiple sources declare allowlists, an operation must be admitted by every applicable allowlist. The result is an intersection, not a union.
This behavior matters when an enterprise combines organization-wide settings with team-specific policies. A permissive team setting cannot weaken a higher-priority managed restriction, and an allowlist added in one source does not automatically expand the permissions granted by another source.
An ask rule requires fresh, one-time approval. GitHub’s documentation states that the requirement is not satisfied by bypass mode, automatic approval, hooks, other approval shortcuts, or an approval saved from an earlier request. Administrators can also set permissions.disableBypassPermissionsMode to disable to prevent documented allow-all or YOLO-style behavior from granting broader permissions. The Copilot CLI documentation describes allow-auto-only as another mode that blocks full allow-all escalation while permitting assisted approval.
Deployment options for enterprise administrators
GitHub documents three ways to distribute managed settings: server-managed, MDM-managed, and file-based deployment.
With server-managed deployment, administrators place copilot/managed-settings.json in the enterprise’s .github-private repository and commit it to the default branch. This method applies to users receiving a Copilot license from the enterprise.
MDM-managed deployment uses native policy locations on Windows and macOS. File-based deployment is documented for macOS, Windows, and Linux and uses the platform-specific managed-settings file locations. These two machine-level approaches apply to users with settings installed on their machines regardless of where their Copilot license originated.
Deployment and refresh behavior differs by method. Server-managed settings are generally applied within about an hour, although restarting the client or signing in again triggers an immediate refresh. MDM-managed clients check hourly. File-based settings require a client restart. GitHub also documents a VS Code policy-sync command for testing MDM delivery.
Teams can receive specialized policies through overridable properties, team-specific settings files, and mappings stored in copilot/team-mappings.json. This allows administrators to tailor permissions for different enterprise groups while retaining the managed precedence rules.
Why this matters for development teams
Agent workflows often need access to tools, source files, and external services. A single policy can now define which operations are always blocked, which require a new decision from a person, and which can proceed without an interactive prompt.
That gives platform and security administrators a more specific control surface than simply enabling or disabling agent functionality. For example, an organization can inventory sensitive commands, file paths, and network domains, then create rules that require review or block access where appropriate. The supplied examples are policy patterns rather than universal recommendations, so each organization must determine its own boundaries.
The fresh-approval behavior is particularly important for teams that want review requirements to remain meaningful after a user has previously approved a similar operation. Saved approvals and automatic approval settings do not satisfy a managed ask rule, and bypass behavior cannot override it.
However, these controls should not be treated as evidence of a guaranteed security, compliance, productivity, or performance outcome. GitHub describes the feature as centralized permission management for supported operations; the supplied sources do not provide measured results from adopting it.
What you should do
- Inventory risky operations. Identify shell commands, file locations, and network domains that should be denied, require fresh approval, or remain available without a prompt.
- Build a narrowly scoped policy. Use the documented
Shell,PowerShell,Read,Edit, andDomainselectors. Treat example rules as starting points, not organization-wide defaults. - Decide whether bypass behavior is acceptable. Review
permissions.disableBypassPermissionsModeand determine whether users should be prevented from enabling allow-all or YOLO-style controls. - Choose a delivery method. Use server-managed settings for enterprise license recipients, or select MDM-managed or file-based delivery when policies need to be installed on machines independently of license source.
- Test every intended client. Validate the policy in each surface your organization supports. GitHub explicitly warns that not every client supports every managed-settings property.
- Check refresh behavior. Account for hourly polling, client restarts, sign-in refreshes, or the documented VS Code policy-sync workflow when testing changes.
Availability and remaining limitations
The granular controls are generally available as of September 9, 2026, for the explicitly announced Copilot app, Copilot CLI, and VS Code Agent Host sessions. The wider documentation set includes additional clients, but it does not establish identical granular deny, ask, and allow behavior across every integration.
JetBrains documentation confirms enterprise-managed settings, including permission control, for the GitHub Copilot plugin. It distinguishes that plugin from the JetBrains AI Assistant integration and from Copilot CLI. Copilot cloud agent is available through several IDE environments, including JetBrains IDEs, but the supplied material does not establish that all granular enterprise-managed permission behavior is identical across those environments. The cloud-agent documentation identifies Copilot cloud agent in JetBrains IDEs as public preview.
GitHub has not documented minimum client versions for these controls in the supplied sources. Organizations should therefore verify support in their deployed clients rather than assuming that every listed surface has the same capabilities.
Sources
- GitHub Changelog: Enterprise-managed permissions for GitHub Copilot agent operations
- GitHub documentation: Enterprise-managed settings
- GitHub documentation: Get started with managed settings
- GitHub documentation: Deploy managed settings
- GitHub documentation: Copilot CLI configuration directory reference
- GitHub documentation: Copilot in JetBrains IDEs
- GitHub documentation: Use Copilot cloud agent in your IDE
