Copilot "Assisted Permissions": When a Model Decides What Is Safe – and Who Approves the Rest

Picture an ordinary Tuesday morning in your development department. A developer asks an AI assistant to find a bug in a billing module. The assistant wants to run a test script. Then it wants to read a configuration file. Then open a documentation page on the web. Then run another script. At every one of these steps, the tool asks: "May I?" By the twentieth click on "Yes", what happens in every organization happens here too: attention fades, and at some point people only confirm instead of reading.

This is exactly where a release that GitHub published in its official changelog on October 26, 2026 comes in. It is titled "GitHub Copilot assisted permissions generally available". Since that day, GitHub Copilot has a new approval mode that sits between "confirm every single action" and "allow everything". A language model looks at the request. What it judges clearly safe continues. Everything else still goes to a human.

This article puts the release into context in three steps: what the source actually confirms; what it does not say, and why we name that explicitly; and which questions you should settle now as a managing director, head of IT or head of development. We assign the topic to our Code Operator, the agent that, according to our website, handles bugs, fixes and pull requests with your approval. The words "with your approval" are the real subject of this text.

What GitHub published on October 26, 2026

Let us start with what is confirmed. The primary source is the GitHub changelog entry from October 26, 2026. It is classified as a release and kept deliberately short: according to the page, it takes one minute to read. The core fits into three sentences.

First: "Assisted permissions" are, according to GitHub, "now generally available". This applies to three surfaces: the command-line version GitHub Copilot CLI, the GitHub Copilot app and Visual Studio Code. So this is not a preview and not a test for a selected group, but a feature that is officially reported as available.

Second: the mechanism. When Copilot wants to run a command, access a file system path or open a web address, a large language model evaluates the request. Requests the model judges clearly safe proceed automatically. All other requests still need your approval. That is the decisive sentence: the model may wave routine through, but according to the source, a human remains responsible for everything that is not clearly safe.

Third: how to turn it on. In the command line, you enter /permissions and select "assisted". In the Copilot app, you open the mode picker, click "Tool permissions" and select "Assisted". In Visual Studio Code, you open the permissions picker and select "Assisted permissions". The release contains no more technical detail than that, and you do not need more for the decision either.

The release does not describe an autopilot. It describes a filter: a model sorts requests into "clearly safe" and "needs a human". How well that filter works is not stated in the source.

What the source sets out for administrators

For companies, the second part of the release is at least as important as the first. GitHub describes controls for administrators in enterprise accounts ("enterprise-managed settings"). According to the source:

• Administrators can block "Allow All" while keeping "Assisted" available. "Allow All" is the mode in which the agent acts without asking.
• Administrators can disable "Assisted" separately.
• Administrators can set the default permission mode for new sessions. Developers can then switch to any other mode that the policy allows.
• If the configured default mode is unavailable or prohibited, the session starts with manual approval, according to the source ("the session starts with manual approval").

That is a sensible mix of convenience and control. The last rule is interesting: when something does not fit, the system falls back to the most cautious level, not the most generous one. That is the right direction. A tool that asks when in doubt is more predictable for a company than one that acts when in doubt.

What the source does not say

A reliable article also shows the gaps. The release of October 26, 2026 does not state:

• Prices or license tiers. Whether the feature is included in every Copilot plan or causes additional costs is not in the release. We claim nothing about this. Please clarify it with your contract or your contact person.
• Regions. The source names no regional restriction. That means none is named. It does not mean we can guarantee availability in Germany, Austria or Switzerland for your contract.
• A hit rate. How often the model classifies correctly, how often it blocks harmless requests or waves through risky ones, is not stated. The release contains no numbers at all apart from the date and the reading time.
• The criteria. What exactly "clearly safe" means is not explained in the release itself. For details, it points to a documentation page titled "Allowing safe commands to run without manual approval".
• A statement about other tools. The release concerns Copilot CLI, the Copilot app and Visual Studio Code. What applies to other development environments cannot be derived from it.

We searched for the linked documentation for this article. We could not locate the page with exactly this title, so we rely solely on the changelog entry. If you roll the feature out, read the documentation yourself before you switch it on. That is not distrust of GitHub, but normal diligence for a feature that automates permission decisions.

Three common misunderstandings we would like to avoid

"Assisted means the agent may now do everything safe on its own." The source says something narrower: a language model judges individual requests, and only those judged clearly safe proceed automatically. What counts as safe is determined by the model, not by your company policy. If your policy is stricter than the model's judgment, you have to solve that through administrator settings, not through hope.

"If the feature is generally available, it also suits us." General availability only means that GitHub officially releases the feature. Whether it fits your contract, your industry and your data protection requirements is not decided by the source. Involve your data protection and compliance officers if needed before you activate the feature company-wide.

"This only concerns developers." Today, yes: the release talks about commands, file paths and web addresses in development tools. But the pattern behind it, a model as a pre-filter in front of a human approval, will probably not stay there. Whoever settles the question now for code will already have answered it later for other areas. That is a guess and not a forecast from the source.

Three levels instead of two: our classification

Until now there were, in practice, two attitudes. One: every step is asked about. Safe, but tiring. The other: everything is allowed. Convenient, but only as safe as the environment the agent runs in. With "Assisted", a third level arrives. The following classification is our own and not a statement from the source:

• Manual approval. Every action waits for a human. The risk lies in fatigue: whoever clicks "Yes" twenty times in a row no longer reads at the twenty-first.
• Assisted. A model relieves you of obvious routine. The risk shifts: from the human's fatigue to the model's misjudgment.
• Allow All. The agent acts alone. The risk lies entirely with the environment, the permissions and whatever is noticed afterwards.

A small sample calculation (not a figure from the source, but an assumption for illustration): suppose a developer confirms 50 prompts on a working day and needs 5 seconds on average for each. That is 250 seconds, a good four minutes. The pure time saving is small. What really counts is something else: focus. An interruption does not cost the five seconds but the train of thought you were just following. And that is exactly where the security problem lies, because whoever is constantly interrupted eventually confirms by reflex.

That is the honest argument for "Assisted": it is not meant to abolish approval but to direct attention to the cases where it matters. Whether that succeeds depends on how reliably the model draws the line. And the source says nothing about that.

A model as reviewer: opportunity and limit

It is worth thinking this through for a moment. A language model decides whether the action of another language model is acceptable. This is a familiar construction, and it has two sides.

The opportunity: a model understands context better than a rigid list of permitted commands. A fixed list only knows what someone wrote down beforehand. A model can also classify a command nobody foresaw. That makes the tool more pleasant to use.

The limit: a model can be wrong, and it can be wrong in ways you cannot predict. It is therefore not a replacement for the classic layers of protection: narrowly scoped role permissions, separate credentials for development and production, a mandatory review before code is merged, a log of what the agent did. Whoever turns on "Assisted" does not decide against these layers but presupposes them. This is again our classification and not a claim from the source, but it follows from the construction: the filter sits in front of individual actions, not in front of the result.

An approval filter is a tool for relief. It replaces neither a permissions concept nor a code review nor the question of who is responsible in case of doubt.

We have looked at this question in other articles. The report on the Anthropic test agent that filed a false tip with the police without an approval step shows what happens when an agent acts in practice without asking. That is a different case and a different technology, but the same basic question: who says "yes" before something takes effect?

Why this is a governance question for mid-sized companies

Many mid-sized companies already use Copilot, often without a clear rule. Individual developers try out modes, everyone configures it for themselves, and nobody has an overview. The new feature makes this situation worse if it arrives unnoticed. It makes it better if you define it deliberately. Three questions help:

1. Who decides the default mode? According to the source, administrators can set the default for new sessions. Who in your company is that, and who commissioned them?
2. Should "Allow All" be possible at all? The source says it can be blocked. Whether you block it is a business decision. Whoever allows it accepts that an agent acts without any prompt.
3. What applies outside development? If the same mechanism later appears in other areas, for example with agents that handle documents or mailboxes, you need a rule that is not renegotiated every time.

These questions cost nothing but an hour of alignment. But they prevent the approval culture in your company from depending on which mode happened to be preselected.

The assignment: Code Operator

On our website, we describe the Code Operator, one of our eight agents, with the sentence: "Bugs, fixes, pull requests with your approval". The new Copilot feature touches exactly this area, because it governs how much a development agent may do alone before a human steps in. We therefore make no claim about Copilot but transfer the question to our own approach.

With an agent of this kind, we distinguish three things that are often mixed up in practice:

• Reading. Looking at code, searching for errors, describing connections. This is usually uncritical.
• Proposing. Preparing a change, opening a pull request. The result is visible and reviewable before anything takes effect.
• Acting. Running commands, changing files, addressing systems, publishing things. This is where it is decided where the approval sits.

In our understanding, a filter like "Assisted" belongs at the boundary between proposing and acting, but it does not replace the human decision about the result there. The pull request remains the place where a human says: "This goes into production like this." Whether it passes through many intermediate steps automatically beforehand is a question of convenience. Whether it is merged at the end unreviewed is a question of responsibility.

How we proceed in an audit

We do not want to invent field reports or claim references here. Instead, we describe how we approach a conversation on this topic, that is, our approach and our offer:

1. Inventory. Which tools do your developers actually use, and in which mode do they run today? Often there is no uniform answer, and that is already the first result.
2. Permissions map. Which systems can an agent access when it acts on your behalf? Credentials, repositories, test environments, production.
3. Approval points. We mark the places where a human has to say "yes". In doing so, we separate reading, proposing and acting.
4. Policy. We write a short, understandable rule: which mode is the default, what is blocked, who may approve exceptions?
5. Traces. We clarify how you can later tell what the agent did and who approved what.

The result is not a binder of advice but one or two pages that a team actually reads.

What you can do this week

According to the source, the feature is available. So you do not have to wait for anything, but you should not rush in headfirst. Five steps that are doable within a week:

1. Check who uses Copilot at your company and in which interface: command line, app or Visual Studio Code. The release concerns exactly these three.
2. Ask your administration whether a default mode is set and whether "Allow All" is blocked. The source describes both as possible settings for enterprise accounts. Whether and how they are offered in your account, please clarify with your provider.
3. Clarify license and costs in writing. The release says nothing about this.
4. Read the documentation GitHub points to before you switch the feature on for the whole team.
5. Try it in a small group, with a project that has no access to production systems. Note what ran automatically and what was queried. If you are surprised, that is a valuable result.

And a sixth thing that has nothing to do with technology: talk with your team about the fact that "automatically approved" does not mean "reviewed". Whoever knows this handles the results differently.

The difference: an agent with limits and an approval step

Let us sum up what is good about this release and what remains open.

What is good: GitHub does not abolish approval but grades it. Administrators can control whether "Allow All" is possible at all. The session starts with manual approval when in doubt. What remains open: price, region, hit rate and the exact criteria, none of which are in the release.

The difference that matters in the end is simple to describe. An agent without limits and without an approval step decides alone, even on risky actions, and you only find out when something has happened. An agent with limits and an approval step handles routine on its own, puts the delicate parts in front of a human and can be traced afterwards. For the Code Operator, that means: bugs, fixes, pull requests with your approval. The same principle applies to our other agents. The Inbox Manager's emails, for example, remain drafts until a human sends them. And with our content, Magdalena checks the brand fit before anything goes out.

Whether a language model helps as a pre-filter is a detail question. Whether there is an approval step is the fundamental question.

Source: GitHub Changelog, "GitHub Copilot assisted permissions generally available", October 26, 2026 (github.blog/changelog/2026-10-26-github-copilot-assisted-permissions-generally-available). The assessments on risk, permissions concept and approach are our own view and are not stated in the source.