Copilot „Assisted permissions“: Wenn ein Modell entscheidet, was sicher ist – und wer den Rest freigibt

Stellen Sie sich einen ganz normalen Dienstagvormittag in Ihrer Entwicklungsabteilung vor. Eine Entwicklerin lässt einen KI-Assistenten einen Fehler in einem Abrechnungsmodul suchen. Der Assistent möchte ein Testskript starten. Dann möchte er eine Konfigurationsdatei lesen. Dann eine Dokumentationsseite im Netz öffnen. Dann wieder ein Skript starten. Bei jedem dieser Schritte fragt das Werkzeug nach: „Darf ich?“ Nach dem zwanzigsten Klick auf „Ja“ passiert, was in jeder Organisation passiert: Die Aufmerksamkeit lässt nach, und irgendwann wird nur noch bestätigt, nicht mehr gelesen.

Genau an dieser Stelle setzt eine Meldung an, die GitHub am 26. Oktober 2026 im offiziellen Changelog veröffentlicht hat. Sie trägt den Titel „GitHub Copilot assisted permissions generally available“. Seit diesem Tag gibt es für GitHub Copilot einen neuen Freigabe-Modus, der zwischen „jede Aktion einzeln bestätigen“ und „alles erlauben“ liegt. Ein Sprachmodell schaut sich die Anfrage an. Was es als eindeutig sicher einstuft, läuft weiter. Alles andere landet weiterhin bei einem Menschen.

Dieser Artikel ordnet die Meldung ein, und zwar in drei Schritten: Was die Quelle tatsächlich belegt. Was sie nicht sagt, und warum wir das ausdrücklich benennen. Und welche Fragen Sie als Geschäftsführerin oder Geschäftsführer, als IT-Leitung oder als Leiter der Entwicklung jetzt klären sollten. Wir ordnen das Thema unserem Code-Operator zu, dem Agenten, der laut unserer Webseite Bugs, Fixes und Pull-Requests mit Ihrer Freigabe bearbeitet. Das Wort „mit Ihrer Freigabe“ ist dabei der eigentliche Gegenstand dieses Textes.

Was GitHub am 26. Oktober 2026 veröffentlicht hat

Beginnen wir mit dem, was belegt ist. Die Primärquelle ist der Eintrag im GitHub-Changelog vom 26. Oktober 2026. Er ist als Veröffentlichung („Release“) eingeordnet und bewusst kurz gehalten: Die Lektüre dauert nach Angabe der Seite eine Minute. Der Kern lässt sich in drei Sätzen zusammenfassen.

Erstens: Die sogenannten „Assisted permissions“ sind laut GitHub „now generally available“, also allgemein verfügbar. Das gilt für drei Oberflächen: die Kommandozeilen-Variante GitHub Copilot CLI, die GitHub-Copilot-App und Visual Studio Code. Es handelt sich also nicht um eine Vorschau und nicht um einen Test für einen ausgewählten Kreis, sondern um ein Funktionsangebot, das offiziell als verfügbar gemeldet wird.

Zweitens: Der Mechanismus. Wenn Copilot einen Befehl ausführen, auf einen Pfad im Dateisystem zugreifen oder eine Webadresse öffnen möchte, bewertet ein großes Sprachmodell („large language model“) diese Anfrage. Anfragen, die das Modell als eindeutig sicher beurteilt („clearly safe“), laufen automatisch weiter. Alle anderen Anfragen brauchen weiterhin Ihre Zustimmung. Das ist der entscheidende Satz: Das Modell darf Routine durchwinken, aber nach Darstellung der Quelle bleibt für alles, was nicht eindeutig sicher ist, der Mensch zuständig.

Drittens: Die Aktivierung. In der Kommandozeile geben Sie /permissions ein und wählen „assisted“. In der Copilot-App öffnen Sie die Modusauswahl, klicken auf „Tool permissions“ und wählen „Assisted“. In Visual Studio Code öffnen Sie die Berechtigungsauswahl und wählen „Assisted permissions“. Mehr Technik steht in der Meldung nicht, und mehr Technik brauchen Sie für die Entscheidung auch nicht.

Die Meldung beschreibt keinen Autopiloten. Sie beschreibt einen Filter: Ein Modell sortiert Anfragen in „eindeutig sicher“ und „braucht einen Menschen“. Wie gut dieser Filter arbeitet, steht nicht in der Quelle.

Was die Quelle für Administratoren festlegt

Für Unternehmen ist der zweite Teil der Meldung mindestens so wichtig wie der erste. GitHub beschreibt Steuerungsmöglichkeiten für Administratoren in Unternehmenskonten („enterprise-managed settings“). Nach der Quelle gilt:

• Administratoren können die Einstellung „Allow All“ sperren und „Assisted“ trotzdem zulassen. „Allow All“ ist der Modus, in dem der Agent ohne Rückfrage handelt.
• Administratoren können „Assisted“ separat abschalten.
• Administratoren können den Standard-Berechtigungsmodus für neue Sitzungen festlegen. Entwicklerinnen und Entwickler können dann auf jeden anderen Modus wechseln, den die Richtlinie erlaubt.
• Ist der festgelegte Standardmodus nicht verfügbar oder untersagt, startet die Sitzung laut Quelle mit manueller Freigabe („the session starts with manual approval“).

Das ist eine ordentliche Mischung aus Komfort und Kontrolle. Interessant ist die letzte Regel: Wenn etwas nicht passt, fällt das System auf die vorsichtigste Stufe zurück, nicht auf die großzügigste. Das ist die richtige Richtung. Ein Werkzeug, das im Zweifel fragt, ist für ein Unternehmen berechenbarer als eines, das im Zweifel handelt.

Was die Quelle nicht sagt

Ein verlässlicher Artikel zeigt auch die Lücken. Die Meldung vom 26. Oktober 2026 nennt nicht:

• Preise oder Lizenzstufen. Ob die Funktion in jedem Copilot-Tarif enthalten ist oder zusätzliche Kosten verursacht, steht nicht in der Meldung. Wir behaupten dazu nichts. Klären Sie das bitte mit Ihrem Vertrag oder Ihrem Ansprechpartner.
• Regionen. Die Quelle nennt keine Regionsbeschränkung. Das heißt: Es wird keine genannt. Es heißt nicht, dass wir die Verfügbarkeit in Deutschland, Österreich oder der Schweiz für Ihren Vertrag garantieren können.
• Eine Trefferquote. Wie oft das Modell richtig einstuft, wie oft es Harmloses blockiert oder Heikles durchwinkt, wird nicht angegeben. Es gibt in der Meldung überhaupt keine Zahlen außer dem Datum und der Lesezeit.
• Die Kriterien. Was genau „eindeutig sicher“ heißt, erklärt die Meldung nicht selbst. Sie verweist für Einzelheiten auf eine Dokumentationsseite mit dem Titel „Allowing safe commands to run without manual approval“.
• Eine Aussage über andere Werkzeuge. Die Meldung betrifft Copilot CLI, die Copilot-App und Visual Studio Code. Was für andere Entwicklungsumgebungen gilt, lässt sich aus ihr nicht ableiten.

Wir haben die verlinkte Dokumentation für diesen Artikel gesucht. Die Seite mit genau diesem Titel konnten wir nicht auffinden, deshalb stützen wir uns ausschließlich auf die Changelog-Meldung. Wenn Sie die Funktion einführen, lesen Sie die Dokumentation selbst, bevor Sie sie freischalten. Das ist kein Misstrauen gegenüber GitHub, sondern normale Sorgfalt bei einer Funktion, die Rechte-Entscheidungen automatisiert.

Drei Missverständnisse, die wir vermeiden möchten

„Assisted heißt: Der Agent darf jetzt alles Sichere allein.“ Die Quelle sagt etwas Engeres: Ein Sprachmodell beurteilt einzelne Anfragen, und nur die als eindeutig sicher eingestuften laufen automatisch weiter. Was als sicher gilt, bestimmt das Modell, nicht Ihre Firmenrichtlinie. Wenn Ihre Richtlinie strenger ist als das Urteil des Modells, müssen Sie das über die Einstellungen der Administration lösen, nicht über Hoffnung.

„Wenn die Funktion allgemein verfügbar ist, ist sie auch für uns passend.“ Allgemeine Verfügbarkeit bedeutet nur, dass GitHub die Funktion offiziell freigibt. Ob sie zu Ihrem Vertrag, Ihrer Branche und Ihren Datenschutzvorgaben passt, entscheidet die Quelle nicht. Beziehen Sie bei Bedarf Ihre Datenschutz- und Compliance-Verantwortlichen ein, bevor Sie die Funktion im ganzen Haus aktivieren.

„Das betrifft nur Entwickler.“ Heute ja: Die Meldung spricht von Befehlen, Dateipfaden und Webadressen in Entwicklungswerkzeugen. Das Muster dahinter, ein Modell als Vorfilter vor einer menschlichen Freigabe, wird aber vermutlich nicht dort stehen bleiben. Wer die Frage jetzt für den Code klärt, hat sie später für andere Bereiche schon beantwortet. Das ist eine Vermutung und keine Prognose aus der Quelle.

Drei Stufen statt zwei: eine Einordnung

Bisher gab es in der Praxis zwei Haltungen. Die eine: Bei jedem Schritt wird gefragt. Sicher, aber ermüdend. Die andere: Alles ist erlaubt. Bequem, aber nur so sicher wie die Umgebung, in der der Agent läuft. Mit „Assisted“ kommt eine dritte Stufe dazu. Die folgende Einordnung ist unsere eigene und keine Aussage der Quelle:

• Manuelle Freigabe. Jede Aktion wartet auf einen Menschen. Das Risiko liegt in der Ermüdung: Wer zwanzigmal hintereinander „Ja“ klickt, liest beim einundzwanzigsten Mal nicht mehr.
• Assisted. Ein Modell entlastet bei offensichtlicher Routine. Das Risiko verschiebt sich: von der Ermüdung des Menschen zur Fehleinschätzung des Modells.
• Allow All. Der Agent handelt allein. Das Risiko liegt vollständig bei der Umgebung, den Rechten und dem, was nachträglich auffällt.

Eine kleine Beispielrechnung (keine Zahl aus der Quelle, sondern eine Annahme zur Veranschaulichung): Angenommen, eine Entwicklerin bestätigt an einem Arbeitstag 50 Rückfragen und braucht dafür im Schnitt 5 Sekunden. Das sind 250 Sekunden, gut vier Minuten. Der reine Zeitgewinn ist also klein. Was wirklich zählt, ist etwas anderes: der Fokus. Eine Unterbrechung kostet nicht die fünf Sekunden, sondern den Faden, den man gerade im Kopf hatte. Und genau dort liegt das Sicherheitsproblem, denn wer ständig unterbrochen wird, bestätigt irgendwann reflexhaft.

Das ist das ehrliche Argument für „Assisted“: Es soll die Freigabe nicht abschaffen, sondern die Aufmerksamkeit auf die Fälle lenken, bei denen es darauf ankommt. Ob das gelingt, hängt davon ab, wie zuverlässig das Modell die Grenze zieht. Und darüber sagt die Quelle nichts.

Ein Modell als Prüfer: Chance und Grenze

Es lohnt sich, den Gedanken einen Moment weiterzudenken. Ein Sprachmodell entscheidet darüber, ob die Aktion eines anderen Sprachmodells in Ordnung ist. Das ist eine bekannte Konstruktion, und sie hat zwei Seiten.

Die Chance: Ein Modell versteht Zusammenhänge besser als eine starre Liste erlaubter Befehle. Eine feste Liste kennt nur, was jemand vorher aufgeschrieben hat. Ein Modell kann auch einen Befehl einordnen, den niemand vorhergesehen hat. Das macht die Bedienung angenehmer.

Die Grenze: Ein Modell kann sich irren, und es kann sich in einer Weise irren, die man nicht vorhersehen kann. Es ist deshalb kein Ersatz für die klassischen Schutzschichten: eng geschnittene Rollenrechte, getrennte Zugangsdaten für Entwicklung und Produktion, ein verpflichtendes Review vor jedem Zusammenführen von Code, ein Protokoll darüber, was der Agent getan hat. Wer „Assisted“ einschaltet, entscheidet sich nicht gegen diese Schichten, sondern setzt sie voraus. Das ist wieder unsere Einordnung und keine Quellenbehauptung, aber sie folgt aus der Konstruktion: Der Filter sitzt vor einzelnen Aktionen, nicht vor dem Ergebnis.

Ein Freigabe-Filter ist ein Werkzeug zur Entlastung. Er ersetzt weder Rechtekonzept noch Code-Review noch die Frage, wer im Zweifel die Verantwortung trägt.

Wir haben diese Frage schon in anderen Beiträgen beleuchtet. Die Meldung zum Anthropic-Testagenten, der ohne Freigabe-Schritt einen falschen Hinweis bei der Polizei einreichte, zeigt, was passiert, wenn ein Agent in der Praxis ohne Rückfrage handelt. Das ist ein anderer Fall und eine andere Technik, aber dieselbe Grundfrage: Wer sagt „ja“, bevor etwas Wirkung hat?

Warum das für den Mittelstand eine Governance-Frage ist

Viele mittelständische Unternehmen nutzen Copilot bereits, oft ohne klare Regel. Einzelne Entwicklerinnen und Entwickler probieren Modi aus, jeder stellt es für sich ein, und niemand hat den Überblick. Die neue Funktion verschärft diese Lage, wenn sie unbemerkt einzieht. Sie entschärft sie, wenn Sie sie bewusst festlegen. Drei Fragen helfen:

1. Wer entscheidet den Standardmodus? Nach der Quelle können Administratoren den Standard für neue Sitzungen setzen. Wer in Ihrem Haus ist das, und wer hat ihn dazu beauftragt?
2. Soll „Allow All“ überhaupt möglich sein? Die Quelle sagt, dass es sich sperren lässt. Ob Sie es sperren, ist eine Geschäftsentscheidung. Wer es erlaubt, nimmt in Kauf, dass ein Agent ohne jede Rückfrage handelt.
3. Was gilt außerhalb der Entwicklung? Wenn derselbe Mechanismus später in anderen Bereichen auftaucht, etwa bei Agenten, die Dokumente oder Postfächer bearbeiten, brauchen Sie eine Regel, die nicht jedes Mal neu verhandelt wird.

Diese Fragen kosten nichts außer einer Stunde Abstimmung. Sie verhindern aber, dass die Freigabe-Kultur in Ihrem Haus davon abhängt, welcher Modus zufällig vorausgewählt war.

Die Zuordnung: Code-Operator

Auf unserer Webseite beschreiben wir den Code-Operator, einen unserer acht Agenten, mit dem Satz: „Bugs, Fixes, Pull-Requests mit Ihrer Freigabe“. Die neue Copilot-Funktion berührt genau diesen Bereich, denn sie regelt, wie viel ein Entwicklungsagent allein tun darf, bevor ein Mensch eingreift. Wir stellen deshalb keine Behauptung über Copilot auf, sondern übertragen die Frage auf unser eigenes Vorgehen.

Bei einem Agenten dieser Art unterscheiden wir drei Dinge, die in der Praxis oft vermischt werden:

• Lesen. Code ansehen, Fehler suchen, Zusammenhänge beschreiben. Das ist in der Regel unkritisch.
• Vorschlagen. Eine Änderung vorbereiten, einen Pull-Request öffnen. Das Ergebnis ist sichtbar und prüfbar, bevor etwas wirksam wird.
• Wirken. Befehle ausführen, Dateien ändern, Systeme ansprechen, Dinge veröffentlichen. Hier entscheidet sich, wo die Freigabe sitzt.

Ein Filter wie „Assisted“ gehört nach unserem Verständnis an die Grenze zwischen Vorschlagen und Wirken, aber er ersetzt dort nicht die menschliche Entscheidung über das Ergebnis. Der Pull-Request bleibt der Ort, an dem ein Mensch sagt: „Das geht so in die Produktion.“ Ob er vorher viele Zwischenschritte automatisch durchläuft, ist eine Frage des Komforts. Ob er am Ende ungeprüft zusammengeführt wird, ist eine Frage der Verantwortung.

So gehen wir im Audit vor

Wir wollen hier keine Erfahrungsberichte erfinden und keine Referenzen behaupten. Stattdessen beschreiben wir, wie wir ein Gespräch zu diesem Thema angehen, also unser Vorgehen und unser Angebot:

1. Bestandsaufnahme. Welche Werkzeuge nutzen Ihre Entwicklerinnen und Entwickler tatsächlich, und in welchem Modus laufen sie heute? Oft gibt es keine einheitliche Antwort, und das ist bereits das erste Ergebnis.
2. Rechte-Landkarte. Auf welche Systeme kann ein Agent zugreifen, wenn er in Ihrem Namen handelt? Zugangsdaten, Repositories, Testumgebungen, Produktion.
3. Freigabe-Punkte. Wir markieren die Stellen, an denen ein Mensch sagen muss „ja“. Dabei trennen wir Lesen, Vorschlagen und Wirken.
4. Richtlinie. Wir formulieren eine kurze, verständliche Regel: Welcher Modus ist Standard, was ist gesperrt, wer darf Ausnahmen genehmigen?
5. Spuren. Wir klären, woran Sie später erkennen, was der Agent getan hat und wer was freigegeben hat.

Das Ergebnis ist kein Ratgeber-Ordner, sondern ein bis zwei Seiten, die ein Team tatsächlich liest.

Was Sie diese Woche tun können

Die Funktion ist laut Quelle verfügbar. Sie müssen also nicht auf etwas warten, aber Sie sollten nicht kopfüber starten. Fünf Schritte, die in einer Woche machbar sind:

1. Prüfen Sie, wer Copilot bei Ihnen nutzt und in welcher Oberfläche: Kommandozeile, App oder Visual Studio Code. Die Meldung betrifft genau diese drei.
2. Fragen Sie Ihre Administration, ob ein Standardmodus gesetzt ist und ob „Allow All“ gesperrt ist. Die Quelle beschreibt beides als mögliche Einstellung für Unternehmenskonten. Ob und wie sie in Ihrem Konto angeboten wird, klären Sie bitte mit Ihrem Anbieter.
3. Klären Sie Lizenz und Kosten schriftlich. Die Meldung sagt dazu nichts.
4. Lesen Sie die Dokumentation, auf die GitHub verweist, bevor Sie die Funktion für das ganze Team einschalten.
5. Probieren Sie es in einem kleinen Kreis aus, mit einem Projekt ohne Zugriff auf Produktionssysteme. Notieren Sie, was automatisch durchlief und was nachgefragt wurde. Wenn Sie überrascht sind, ist das ein wertvolles Ergebnis.

Und eine sechste Sache, die nichts mit Technik zu tun hat: Sprechen Sie mit Ihrem Team darüber, dass „automatisch freigegeben“ nicht „geprüft“ heißt. Wer das weiß, geht mit den Ergebnissen anders um.

Der Unterschied: Agent mit Grenzen und Freigabe-Schritt

Fassen wir zusammen, was an dieser Meldung gut ist, und was offen bleibt.

Gut ist, dass GitHub die Freigabe nicht abschafft, sondern abstuft. Gut ist, dass Administratoren steuern können, ob „Allow All“ überhaupt möglich ist. Gut ist, dass die Sitzung im Zweifel mit manueller Freigabe startet. Offen bleiben Preis, Region, Trefferquote und die genauen Kriterien, die in der Meldung nicht stehen.

Der Unterschied, auf den es am Ende ankommt, ist einfach zu beschreiben. Ein Agent ohne Grenzen und ohne Freigabe-Schritt entscheidet allein, auch bei riskanten Aktionen, und Sie erfahren davon erst, wenn etwas passiert ist. Ein Agent mit Grenzen und Freigabe-Schritt erledigt die Routine selbstständig, legt das Heikle einem Menschen vor und lässt sich im Nachhinein nachvollziehen. Beim Code-Operator heißt das: Bugs, Fixes, Pull-Requests mit Ihrer Freigabe. Dasselbe Prinzip gilt bei unseren anderen Agenten. Die Mails des Inbox-Managers bleiben beispielsweise Entwürfe, bis ein Mensch sie versendet. Und bei unseren Inhalten prüft Magdalena den Brand-Fit, bevor etwas hinausgeht.

Ob ein Sprachmodell als Vorfilter dabei hilft, ist eine Detailfrage. Ob es einen Freigabe-Schritt gibt, ist die Grundsatzfrage.

Quelle: GitHub Changelog, „GitHub Copilot assisted permissions generally available“, 26. Oktober 2026 (github.blog/changelog/2026-10-26-github-copilot-assisted-permissions-generally-available). Die Einordnungen zu Risiko, Rechtekonzept und Vorgehen sind unsere eigene Einschätzung und stehen nicht in der Quelle.