GitHub made assisted permissions generally available on October 26, 2026 in Copilot CLI, the Copilot app, and VS Code. A model can now approve eligible actions it judges safe without interrupting the developer. For security teams, the rollout decision is which approvals may be delegated to that model and which must remain with a person.
Start with the operations whose approval carries organizational authority: releasing a package, changing production configuration, or sending private material outside the company. A model's assessment of the action cannot establish that a named human authorized it. Keep those gates explicit before reducing prompts elsewhere.
This guide combines documented behavior with proposed acceptance checks. General Analysis has not tested these controls in a Copilot tenant. Use the managed-permissions deployment guide to establish how policy reaches each client, and securing coding agents for the wider security baseline.
Resolve what ask means before relying on it#
GitHub's assisted-permissions guide says eligible CLI shell, file-read, file-write, and URL requests can satisfy enterprise ask rules through model approval. It excludes other enterprise-required tool approvals and local sandbox-bypass requests from that review.
The general managed-settings reference still describes ask as fresh human approval that automatic approval cannot satisfy. These sources disagree as reviewed on October 27. Do not interpret the general promise as proof of a human gate in assisted CLI sessions, or extend the CLI exception to every client and tool.
Consider a hypothetical release task with an ask rule for its shell command. If your requirement is that a release manager approves each invocation, a model-approved request would fail that requirement even if the command and destination were correct. The relevant evidence is who approved that exact invocation, not whether the task completed successfully.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Configure the human-only group explicitly#
GitHub provides separate controls for assisted and unconditional approval. A manual default only chooses how a new session starts; users can select another permitted mode. The settings reference documents the independent switches.
For a pilot group that requires human approval, merge the following fragment into its reviewed managed policy. It uses a harmless workspace fixture so the approval path can be checked without a release credential. This is a proposed configuration, not a complete enterprise policy or a tested deployment.
Code source: illustrative configuration using GitHub's managed-permission schema.
{
"permissions": {
"defaultMode": "manual",
"disableAssistedPermissionsMode": true,
"disableBypassPermissionsMode": "disable",
"ask": ["Edit(/approval-pilot/review.txt)"],
"deny": ["Read(/approval-pilot/blocked.txt)"]
}
}
Preserve existing deny and allow rules when applying the fragment. The example's two selectors cover direct file operations; they do not establish what a shell process can read or write. Keep filesystem and network restrictions in the execution environment. The Copilot sandbox guide covers that separate decision.
For a group allowed to delegate approvals, keep bypass mode disabled and decide explicitly whether Assisted should be its default. Do not describe that group as requiring a person for every sensitive action merely because its policy contains ask rules.
Check the session that will do the work#
The GA announcement gives the interactive entry points: /permissions in the CLI, Tool permissions in the app's mode menu, and the permissions picker in VS Code. Confirm the effective mode inside each pilot session.
VS Code's enterprise guidance says that marking a tool ineligible for automatic approval removes Allow all from a Copilot harness session's picker. Assisted and saved session approvals can still approve it. That setting alone does not prove per-call human confirmation.
Use the following proposed checks with synthetic files and approved test destinations. Record the client version, harness, policy revision, session mode, actual tool request, and decision together. Repeat them for the session types your organization permits.
| Acceptance question | Harmless check | Evidence needed before rollout |
|---|---|---|
| Does the human-only group retain its gate? | Request two separate edits to approval-pilot/review.txt. | Each invocation waits for a new human decision; the write has not happened beforehand. |
| Is denial enforced independently of model judgment? | Request the dummy blocked.txt file. | A policy denial, rather than a model choosing not to call the tool. |
| Can a user select a prohibited mode? | Inspect and attempt the ordinary mode selection after policy refresh. | Assisted and unconditional approval remain unavailable to the human-only group. |
| Did an older session retain different settings? | Compare a new session with a resumed pilot session. | Effective mode and loaded policy recorded for each; a changed default is insufficient. |
| Does VS Code use the expected approval path? | Repeat the fixture through the intended harness and actual tool. | The observed decision agrees with the requirement, rather than only with a picker label. |
The managed default reference says resumed sessions retain their saved mode subject to current restrictions. Refresh and inspect them explicitly. Where a required check fails, hold that deployment group and investigate the effective policy; do not broaden permissions to make the pilot pass.
Treat unattended approval failures as incomplete work#
For non-interactive CLI work, GitHub documents --assisted-approval. Its automation guidance also warns about combining flags: assisted tool review does not remove unrestricted path or URL grants. If assisted mode cannot activate, a separately supplied --allow-all-tools can remain effective, with a warning on standard error.
Review the entire launch command and environment before accepting an unattended job. Remove unconditional grants that contradict the intended policy. Preserve startup warnings, and make an assisted-activation failure a reason to stop the job rather than accept its output. A warning discovered after a run cannot undo actions already taken; prohibit unwanted grants through managed policy before launch.
Requests still requiring approval are denied when no person can answer. Define the required task outputs and checks outside the agent: for example, a review job must produce a review for the intended commit and complete its required scanner. A conversational success message cannot substitute for those artifacts. Preserve denied operations with the result so a reviewer can distinguish a completed task from an attempted alternative.
Approval also leaves the execution boundary unchanged. VS Code's approval documentation separates permission to invoke an action from sandbox restrictions on its resources. Keep credentials, writable paths, and network destinations narrow enough for an approved action to make a mistake without acquiring unrelated authority.
Frequently asked questions
- Does blocking Allow all also block assisted permissions?
No. GitHub documents separate managed controls. Set permissions.disableBypassPermissionsMode to disable to block unconditional approval, and permissions.disableAssistedPermissionsMode to true to block assisted permissions. A manual default alone does not prevent a permitted mode change.
- Does a Copilot enterprise ask rule always require a person?
GitHub's sources disagree. The general managed-settings reference says ask requires fresh human approval, but the assisted-permissions guide says eligible CLI shell, read, write, and URL ask rules can receive model approval. Disable assisted permissions where a person must approve, and verify the intended client and operation.
- Can unattended Copilot runs wait for human approval?
GitHub says requests that still need approval are denied in non-interactive runs and autopilot. Treat the resulting work as incomplete until required checks pass. Do not add unconditional permission flags to make an approval failure disappear.
