GitHub Copilot lets admins block, gate or allow agent shell commands, file edits and network calls across an enterprise

GitHub has released enterprise-managed permissions for GitHub Copilot agent operations, generally available in the GitHub Copilot app, the GitHub Copilot CLI and Visual Studio Code sessions that use Agent Host. The changelog post went up on 9 September. Enterprise admins can now set one of three states for each sensitive agent action across their organisation: block it, require a human approval before it runs, or allow it to run without prompting.

The controls cover the three moves an agent can make that an incident later traces back to: shell commands, file reads and edits, and network domains. GitHub says admins can also apply different policies to different teams, so a research team can hold a wider allowlist than a team that ships to production.

What the lock actually does

The important line in the changelog is that the managed restrictions cannot be overridden by user settings, workspace configurations, or auto-approval features. That is the part that decides whether the policy is real or advisory.

Until now, an agent asking permission to run a shell command usually ended in the developer clicking approve, sometimes on the general auto-approval setting that unlocks every future prompt in the session. The developer's click makes sense in the moment, and it is a bad place to hold an organisation-wide security decision. Moving the decision to a policy the admin sets means an engineer stops being asked, and stops being able to widen the answer, on the actions that matter.

Where it fits and what it does not do

This is release plumbing rather than a new agent feature, so what it changes is how much a team can trust the tool it already runs. If your organisation runs Copilot's agent modes in CLI, in VS Code or through the standalone app, the security team now has a single place to say what an agent can do without asking, what it must ask about, and what it must never do.

Two limits worth naming. The changelog does not describe how the policy handles a novel network domain the agent has never seen, so treat allowlist and blocklist behaviour as an integration question until you have read your own trace. And the announcement covers agent operations from the three named Copilot surfaces; a third-party agent installed through a plugin is a separate policy story.

For teams that had been putting off wider Copilot agent adoption because the sandbox-per-developer story was too loose, this closes the biggest gap. For teams already running the agents at scale, the honest first move is to set the policy to match what your engineers are already approving, then tighten it once you have data on which prompts are worth the interruption.

Source

• Enterprise managed permissions for GitHub Copilot agent operations, GitHub Changelog, 9 September 2026