Copilot permissions should be policy, not a prompt

What happened: agent permissions can now be centrally enforced

The managed policy separates operations into deny, ask and allow rules. Selectors cover shell commands, filesystem reads and edits, and network domains. GitHub documents deny > ask > allow precedence: a denied operation remains blocked even if another rule would permit it, while an ask rule requires a fresh one-time approval instead of accepting auto-approval, a hook, bypass mode or an approval saved earlier.

Administrators can also disable bypass or allow-all modes. GitHub says managed restrictions cannot be weakened by user or workspace settings, and policies can be specialised for different enterprise teams. That makes the control materially different from publishing recommended settings that developers may change locally.

Why it matters: the prompt is no longer the primary control boundary

Agentic coding tools can execute commands, edit repositories and reach external services. A developer-facing confirmation prompt is useful context, but it is a fragile security boundary when users are moving quickly, approvals can be remembered or allow-all modes exist. Central policy lets security and platform teams express non-negotiable limits close to the action.

The details still matter. An allow rule that is too broad can silently remove a valuable review point; an ask rule applied to routine low-risk actions can produce approval fatigue; and a deny pattern that misses command variants or alternate domains creates false assurance. Team-specific overrides also need ownership, because exceptions can become permanent privilege paths.

Client coverage must be proven rather than assumed. The announcement names the Copilot app, CLI and VS Code sessions using Agent Host. Organisations using other clients, older versions or workflows outside Agent Host need to identify whether the same controls apply before treating the policy as universal.

The practical implication: design and test an effective policy

Begin with a small set of high-consequence boundaries: block access to credential stores and sensitive system paths, deny destructive command patterns, and restrict unapproved network destinations. Require fresh approval for actions that cross a trust boundary, such as publishing code, changing protected source or contacting production services. Pre-authorise only narrow, repeatable operations with understood inputs and outputs.

Test the effective result with representative users and each supported client. Attempt an explicitly denied action, an action that must prompt every time, an approved routine action and an unmatched action. Verify that local auto-approval, saved grants and allow-all controls cannot override the enterprise decision, then repeat the tests for every team-specific policy.

Pair permissions with telemetry and operational ownership. Record policy changes, approval frequency, denials, exceptions and failed developer workflows. Review broad rules after incidents and tool updates, and give every team exception an owner and expiry decision. The objective is a control that is restrictive where impact is high and quiet where risk is understood—not a wall of prompts that teaches people to click through.