AI Agent Guardrails: Copilot Assisted Permissions Is a Third Mode Your Allow-All Lock Does Not Cover

On 26 October GitHub made assisted permissions generally available in Copilot CLI, the Copilot app and VS Code. It is a third approval mode. A language model reads each shell command, file access or URL fetch that no rule has already settled, and lets the safe ones run without asking you. Everything it is unsure about still comes to you. If you already restricted allow-all, you probably believe your AI agent guardrails are settled. The reference documentation says otherwise, and the gap is one setting wide.

What the managed-settings reference says about the lock

The enterprise reference has two separate keys. permissions.disableBypassPermissionsMode turns off allow-all. permissions.disableAssistedPermissionsMode stops users enabling assisted. The reference states that neither one implies the other: the first does not block assisted mode, and in the CLI the commands that switch to assisted are not blocked by it.

So an organization that spent September removing allow-all can have developers whose agent is approved by a model and not by them, with no policy change on the admin side. Managed deny rules still apply under assisted mode. Read-only operations and requests already covered by an allow rule proceed as before.

The ask rule and the model

The reference describes an ask rule as demanding a fresh human decision each time, and lists what cannot satisfy one: bypass mode, auto-approval settings, hooks and earlier persisted grants. Assisted mode is not on that list. The concepts page then says that in the CLI, enterprise ask rules for shell commands, file reads and writes, and URLs can be satisfied by a model approval, while deny rules still apply. We read both pages this week and did not find a sentence reconciling them. If your policy uses ask for the operations you most care about, test what it does under assisted before you rely on it.

Other details the announcement left out, all from the concepts page:

• GitHub says it chooses the review model, which may differ from the model in your conversation. If you bring your own model provider, the session's active model reviews instead.
• The page defines safety only as whether an action is safe within the scope of the task. It does not say what data the reviewer receives, and it does not address billing.
• In autopilot and non-interactive runs, a request that would need approval is denied, and the model's explanation is passed back to the agent.
• If the review cannot run, the request falls back to normal permission handling. In the CLI, if assisted cannot be enabled, a warning goes to standard error and any separate allow-all-tools option still applies.
• The page itself warns that the model can approve dangerous or unintended actions and is not a replacement for sandboxing.

What the miss rate looks like elsewhere

No GitHub page we read gives an error rate for assisted permissions. The nearest published numbers are for a different product. Anthropic's engineering post on Claude Code auto mode reports that its two-stage classifier blocked 0.4% of about 10,000 real benign tool calls, missed 17% of 52 real cases of an agent overreaching, and missed 5.7% of 1,000 synthetic exfiltration attempts. Anthropic attributes most of the 17% to the classifier treating an earlier user statement as consent for a wider action than the user meant.

Those figures say nothing about GitHub's reviewer. They show what honest reporting for this kind of control looks like: a false-block rate, a miss rate on real overreach, and a small test set called small. LM Studio's design for its Auto Review mode takes a different route, running a deterministic parser first and sending only what it cannot clear to a model that sees user and assistant messages but not tool results. Its author says prompt injection cannot be fully prevented. Two vendors have published their limits. For assisted permissions, the limit that GitHub's pages do state is the warning in the previous section.

The decision for this quarter

Decide assisted mode on purpose, per client, before developers decide it for you.

1. In managed settings, set permissions.disableAssistedPermissionsMode to true wherever allow-all is already disabled and you have not measured the reviewer. The reference does not say which clients beyond the CLI honor this key, so confirm it in each client you run.
2. Where you allow it, set permissions.defaultMode to manual or assisted explicitly. If the chosen default is blocked, sessions start in manual.
3. Replay 50 commands from your own agent logs, ten of which should be ones you would never approve, and count what runs without a prompt. Our threshold: any approved never-approve command means assisted stays off for that team. A reviewer that misses roughly one in six real overreach cases, as Anthropic reports for its own, would let some of those ten through.
4. Keep the sandbox. Our sandbox teardown covers why that policy, and not a prompt, is the control that holds, and the last-mile argument applies directly: the model was never the weak point, the unowned policy around it was.

This advice is wrong if /permissions assisted is blocked in your tenant by the bypass key alone, which takes five minutes to check, or if GitHub publishes a miss rate on real overreach well under Anthropic's. Teams building agents with approval gates they have to defend can start from our AI agent development work.