Copilot can now judge permission requests. Decide what it may touch first.

A new approval option, with an older development history

GitHub announced assisted permissions as generally available in Copilot CLI, the Copilot app and Visual Studio Code on October 26. A language model assesses command, file-path and URL requests; those judged clearly safe can proceed automatically, while others need approval.

This is a release milestone, not the invention of the feature yesterday: CLI prerelease 1.0.104-0, published October 23, had already removed its experimental-mode requirement.

Our interest is the handoff of a decision. A developer might want uninterrupted help writing a parser while retaining control over publishing the resulting package. Those are separate parts of the job, even when one short instruction mentions both. Agreeing on that division makes the new option easier to assess.

Source notes: 1, 2. Original editorial examples and interpretations are identified separately.

Understand which requests reach the reviewer

GitHub’s permission reference says existing rules and approvals are evaluated first. The model reviews eligible unresolved requests against task authority. Existing deny rules remain effective; a request already permitted may run without a new model review.

For eligible requests, an uncertain assessment returns to normal approval handling. In non-interactive or autopilot runs, a request still needing human approval is denied. The reference excludes sandbox-bypass requests from assisted review and warns that the model can approve dangerous or unintended actions.

For a team assessing this feature, our recommendation is to describe the task in terms of resources and effects. “Repair this local example” should identify the example and the intended output. A terse request to “fix everything” makes it harder for the person reviewing the work to distinguish necessary changes from an expansion of scope.

Source notes: 3. Original editorial examples and interpretations are identified separately.

Start with a four-row decision matrix

Here is an original editorial proposal, not a tested Copilot policy. Put four activities on separate rows: inspecting a disposable project, changing its source, contacting an outside service and publishing an artifact. For each row, name the allowed resource, expected effect, accountable person and evidence of completion.

For inspection, a hypothetical team might authorize one checkout and keep unrelated customer folders outside the exercise. For editing, it could require a recoverable starting version and a reviewable diff. For network access, it could identify the specific documentation service needed. Publication could remain a separate decision made after the candidate has been inspected.

These rows describe business intent, not a promise that natural-language instructions enforce it. The team must map its decisions to controls actually supported by its client and environment. A project can deserve a useful coding assistant without giving that assistant credentials capable of changing every system the organization operates.

Source notes: 1. Original editorial examples and interpretations are identified separately.

Keep execution boundaries separate from approval choices

VS Code documents approvals and sandboxing as separate layers. An enabled sandbox can restrict terminal file and network access after approval, but does not cover every tool. Its guidance also says a model-based risk assessment can make mistakes.

Enterprise administrators can block unconditional approval separately from assisted permissions. GitHub’s managed-settings reference also distinguishes a default mode from a locked choice: users can select another permitted mode, and a prohibited or unavailable default falls back to manual approval.

Our practical reading is to examine the reachable environment before counting how often a dialog appears. If the exercise only needs a sample dataset, prepare that dataset. If publishing is outside the exercise, do not supply publishing credentials merely because the agent can use them. An approval preference cannot explain an unnecessarily broad account assignment.

Source notes: 4, 5. Original editorial examples and interpretations are identified separately.

Check the installed client before copying setup instructions

There is a documentation mismatch worth making explicit. The October 26 announcement calls the feature generally available, while the VS Code approvals page inspected for this article still labels it experimental and describes harness and isolation restrictions.

We therefore use the dated announcement for the release event and avoid promising one universal setup recipe. A developer should establish which client, version and organizational rules are in use before following instructions from a different environment. An absent picker option is a reason to check that combination, rather than assume a workplace restriction should be removed.

For a shared team guide, our suggested record is a short, dated note containing the client identity, selected mode and responsible administrator. Keep a previous working configuration available during the trial. Screenshots can help colleagues find a control, but they do not prove that a particular command will be approved or that a policy applies.

Source notes: 1, 4. Original editorial examples and interpretations are identified separately.

Security and useful completion need separate evidence

Independent research supplies useful evaluation context. The NeurIPS 2024 AgentDojo paper evaluates tool-using agents over untrusted data using 97 tasks and 629 security cases. It finds that agents can fail legitimate tasks as well as succumb to malicious instructions. It does not test this Copilot release.

The relevant lesson for our proposed trial is to record two outcomes: whether the intended work finished and whether the agreed boundary held. A run that makes no consequential changes may have remained contained while achieving nothing. A correct-looking patch may still be unacceptable if its preparation exceeded the authority assigned to the task.

Use a harmless rehearsal with synthetic material and a recoverable checkout. Identify the expected output beforehand, inspect the resulting changes and record any unexplained requests. These are proposed acceptance steps, not an account of tests performed by Lumacta. We provide no measured security rating or claim that a successful rehearsal establishes general resistance to attacks.

Source notes: 6. Original editorial examples and interpretations are identified separately.

Choose the next permission from observed work

A worthwhile trial should leave its owner able to explain what changed, what remained outside scope and which evidence supports completion. If a session repeatedly needs a broader resource, review that need as a task-design question. Do not let the absence of interruptions become the only definition of success.

Our recommendation is to expand access only when a specific next task justifies it, with a person accountable for the resulting effect. For everyday development, the benefit could be a calmer working session. For a team maintaining customer systems, the more valuable outcome is a permission choice that remains understandable when somebody reviews the work later.

Source notes: 1. Original editorial examples and interpretations are identified separately.