GitHub Copilot agent permissions changed for real on September 9, 2026, when GitHub's changelog entry for enterprise managed permissions shipped a three-state deny, ask, allow framework for agent operations. The three states aren't the interesting part. What's interesting is that once an admin sets the policy, nothing on the developer's side can move it: not a local user setting, not a workspace setting, not auto-approval, not an approval saved from an earlier session. That applies on GitHub Copilot Business and Enterprise, across the Copilot app, Copilot CLI, and VS Code sessions running Agent Host.
What GitHub Copilot's enterprise permissions actually control
The model is a straightforward three-state switch: deny, ask, or allow. An admin sets it per surface, not per individual action. There are three surfaces in scope: shell commands, file reads and edits, and network domains. Set shell commands to ask and an agent has to check in before it runs anything from the terminal. Set network domains to deny outside an allowlist and the agent can only reach the destinations you named, not whatever it decides it needs mid-task. Deny doesn't mean the option is hidden from the interface. It means the request fails, regardless of what the developer's own settings would otherwise have allowed.
This lands on GitHub Copilot Business and GitHub Copilot Enterprise. Free and Individual plans aren't in scope, so this is a policy question for organizations, not something an individual developer configures for themselves. Enterprises can also set different policies for different enterprise teams rather than one blanket rule across the org, and that matters more than it sounds like it should: a platform team running infrastructure automation and a marketing team's frontend squad touching a CMS don't carry the same blast radius, and a single policy that treats them identically will be wrong for at least one of them.
Where the policy applies, and where it doesn't
Three clients enforce this: the GitHub Copilot app, Copilot CLI, and VS Code sessions running Agent Host. If your team's agent work happens in one of those three, the managed policy binds it, full stop.
JetBrains IDEs aren't on that list, and it's worth flagging before someone assumes Copilot inside IntelliJ or PyCharm inherits the same deny, ask, allow rules automatically. It doesn't. JetBrains gets its own control, shipped a day earlier, and it's a genuinely different feature. More on that below.
The part that actually matters: local settings can't override it
Here's the line worth reading twice: the changelog states that managed restrictions "can't be weakened by user or workspace settings, auto-approval, or previously saved approvals." Read that list backward and it tells you what the gap used to be. If those four things can no longer weaken a managed restriction, they were capable of it before September 9. An admin could set a policy, and a developer's own configuration, an auto-approval rule that fires on repeat prompts, a saved approval from three weeks ago, could still quietly cancel it out. None of that required bad faith. It's the ordinary residue of a developer tuning their own tools to be less annoying, and until this release, that residue could beat an org's intent without anyone noticing.
That's the same shape of failure Pillar Security documented in Google's adk-python repository: a boundary that looked closed on paper had a path around it nobody had tested. Different mechanism, same lesson. A permission model is only as strong as its weakest local override, and until now, GitHub's had several.
It's also where GitHub and GitLab, in the same month, landed on opposite defaults. GitLab ships a permissive-by-default policy that stays adjustable locally: read-only tools default to always allow, write and delete default to always ask, and an admin can move either threshold at the project or group level whenever they want, per GitLab's shipped tool-permission default. GitHub just made that kind of local loosening structurally impossible for anything an admin has locked down.
That contrast is sharper than it looks, because the loosening GitHub now blocks is exactly what we told teams to do in our own writeup of GitLab's policy: once a tool earns trust through a track record, loosen its threshold. GitHub's non-overridable model leaves no room for that per-tool adjustment once an admin has set a restriction, and on reflection, I think that's the right call. The reason isn't GitLab's, it's ours: we also warned in that same piece that too many approval prompts train reviewers to click through without reading, and that's exactly the condition under which a locally loosened threshold stops being a considered decision and turns into habit. An admin revisiting an org-wide policy on a schedule is slower than an individual loosening a setting because a prompt got annoying. Slower is the point. The failure mode GitHub just closed is the one where trust gets extended by accident, one tired approval at a time, not the one where a team deliberately decides a specific tool has earned more room.
The separate JetBrains sandbox preview (don't confuse the two)
One day earlier, on September 8, 2026, GitHub shipped a related but separate feature: enterprise managed sandbox for Copilot in JetBrains IDEs, in public preview. It is not the deny, ask, allow model. It's a sandbox: admins configure sandbox enablement, filesystem and network access, proxy settings, developer-tool access, and macOS Keychain access, and the managed sandbox policy takes precedence over whatever a user has set locally.
Same week, same company, same underlying idea that an admin's policy should win over a developer's local settings. But treat it as a cousin, not a sibling, of the permissions feature above. It's JetBrains-only, it's scoped to sandboxing rather than shell, file, and network permissions, and it's a preview, not general availability. If your team runs Copilot in IntelliJ or PyCharm and wants sandbox-level control there, that's a separate rollout on a separate maturity timeline, not an extension of what shipped on September 9.
How to set an agent permissions policy
GitHub's changelog says what the three states are. It doesn't say how to choose between them for a given team, or what to do first. That part is HighCircl's own recommendation, not GitHub's, drawn from watching how these rollouts tend to go.
1. Inventory what your agents actually touch
Pull 30 days of real shell commands, file paths, and network domains your agents have called, not the theoretical list from documentation. Most teams can name what an agent is supposed to do. Few can name everything it has actually called. Start there, because you can't set a policy on a surface you didn't know was in use.
2. Sort by blast radius, not by surface type
A read of a config file and a write to main both count as file access, but they aren't the same risk. Group requests by what happens if the agent gets it wrong, not by which of the three categories the request technically falls into. Two requests hitting the same surface can sit in different risk tiers.
3. Default network domains to deny outside your allowlist
This is the surface most first-pass policies miss. Shell commands and file writes get scrutiny by habit, because they're the categories people already worry about. An outbound call to an unfamiliar API gets waved through more often, simply because nobody's built the habit of checking it yet.
4. Set ask, not allow, for anything destructive during rollout
Over-restricting here costs friction. Under-restricting costs an incident. Those aren't symmetric costs, so bias toward ask on anything that deletes, deploys, or merges while the policy is new, and loosen it later once there's a track record to loosen it against.
5. Pilot on one enterprise team before rolling out org-wide
The policy supports per-team scoping, so use it. Run the policy against a team whose workflows you understand well enough to catch a false positive immediately, fix what breaks, then expand to the rest of the org.
6. Re-audit against the original inventory after 30 days
Permissions drift as agents pick up new tools and new workflows. A policy set once and never revisited recreates, at the policy layer, the exact failure GitHub just closed at the settings layer: a rule that technically exists but no longer matches what's actually happening.
What breaks if you over-restrict
The cost of over-restricting isn't always visible, which is what makes it dangerous. A denied shell command usually fails loudly: the agent hits a wall, reports back, and someone notices the pipeline stalled. A denied network domain the agent genuinely needed fails quietly instead. The agent doesn't error out dramatically, it just can't reach the API it needed, produces a worse or incomplete answer, and nobody traces that back to the permission policy unless they already suspect it.
There's a fatigue cost too, and it shows up before either of those. Set too much to ask, and whoever's approving requests starts clicking through without reading, the same pattern that erodes any approval gate once it fires too often. A policy full of prompts that get rubber-stamped isn't stricter than a looser one. It's the same looseness with extra clicks in front of it.
Worth being precise about what this control governs and what it doesn't. Deny, ask, and allow decide what an agent is permitted to touch once it acts. They say nothing about when an agent decides to act in the first place, and that's a live design question elsewhere in the market: Cursor's coordinator agent inside a Project decides on its own when to start work, including on events like a pull request merging, with no equivalent deny, ask, allow gate on the decision to start. Scope and timing are different problems. Solving one doesn't solve the other.
One more thing worth a calendar note if you administer Copilot Business or Enterprise: GitHub also changed how it bills assigned seats this quarter, starting October 1. Different subject, same admin settings screen you're already in.
FAQ
Is this available on GitHub Copilot Free or Individual plans?
No. The three-state permissions framework is scoped to GitHub Copilot Business and GitHub Copilot Enterprise. Free and Individual users don't get a managed policy to configure, because there's no organization admin in that setup to set one.
Can a developer override a managed permission with their own settings?
No. GitHub's changelog is explicit that managed restrictions can't be weakened by a user's own settings, a workspace setting, auto-approval, or an approval saved from an earlier session. That non-overridability is the actual news in this release, not the existence of deny, ask, and allow as options.
Does this cover JetBrains IDEs?
Not this feature. JetBrains IDEs get a separate enterprise-managed sandbox control that shipped a day earlier, on September 8, 2026, and it's still in public preview. It governs sandbox-level filesystem, network, and proxy access rather than the shell, file, and network permission categories covered here.