GitHub Copilot Berechtigungen: KI prüft jetzt Befehle

Wer mit einem KI-Agenten programmiert, kennt das Dilemma: Entweder bestätigst du jeden einzelnen Befehl. Oder du gibst dem Agenten Vollzugriff und hoffst, dass nichts schiefgeht. GitHub bietet für Copilot jetzt einen dritten Weg an, bei dem ein Sprachmodell vorsortiert. Stand: Oktober 2026.

Was passiert ist

Am 26. Oktober 2026 hat GitHub den Modus „Assisted permissions“ allgemein verfügbar gemacht. Er gilt laut Changelog für drei Produkte: die GitHub Copilot CLI, die GitHub Copilot App und Visual Studio Code.

Will Copilot etwas tun, wofür er eine Berechtigung braucht, bewertet ein Large Language Model die Anfrage. Stuft das Modell sie als eindeutig sicher ein, läuft sie automatisch weiter. Alles andere landet wie bisher bei dir zur Freigabe.

Geprüft werden laut GitHub drei Arten von Anfragen: das Ausführen von Befehlen, der Zugriff auf Pfade im Dateisystem und das Öffnen von URLs.

Welche Berechtigungsmodi gibt es bei Copilot jetzt?

Die GitHub-Dokumentation unterscheidet drei Stufen:

Modus	Was passiert	Risiko
Manual	Copilot fragt bei jeder Aktion, die nicht schon erlaubt ist	gering, aber viele Klicks
Assisted	Ein Modell prüft, du wirst nur bei Zweifeln gefragt	mittel
Allow all	Breite Erlaubnis ohne Prüfung und ohne Rückfrage	hoch

GitHub beschreibt Assisted selbst als Mittelweg zwischen manueller Freigabe und dem Allow-All-Modus. Allow All heißt in der CLI --allow-all oder --yolo und ist laut Doku die freizügigste Option.

Aktionen, die du schon vorher erlaubt hast, laufen ohne Prüfung durch. Und wenn das Modell nicht sicher ist, dass eine Anfrage harmlos ist, fragt Copilot dich.

Welches Modell prüft die Befehle?

Laut Doku wählt Copilot das Prüfmodell selbst, und es kann sich von dem Modell unterscheiden, mit dem du gerade chattest. Ist das Prüfmodell nicht verfügbar, nutzt Copilot unter Umständen das aktive Modell deiner Sitzung. Hast du einen eigenen Modellanbieter angebunden, übernimmt das aktive Sitzungsmodell die Prüfung.

Welche Daten dabei an das Prüfmodell gehen und ob die Prüfung Kontingent kostet, steht weder im Changelog noch in der Doku. Wer mit sensiblen Kundendaten arbeitet, sollte das vor dem Einsatz bei GitHub klären.

Wo liegen die Grenzen?

GitHub ist hier deutlich. In der Dokumentation steht sinngemäß: Das Modell kann Fehler machen und gefährliche oder ungewollte Aktionen genehmigen. Assisted Permissions sei kein Ersatz für Sandboxing oder Zugriffsbeschränkungen. Und: Der Modus reduziere die Zahl der Rückfragen, nehme dir aber nicht die Verantwortung für das ab, was Copilot tut.

Weitere Details aus der Doku:

• Verbote bleiben Verbote. Deny-Regeln aus dem Unternehmen gelten weiterhin. Bei „ask“-Regeln des Unternehmens wird es kleinteiliger: In der CLI kann für Shell-Befehle, Dateizugriffe und URLs eine Freigabe durch das Modell die Regel erfüllen. Andere Tool-Aufrufe, für die das Unternehmen eine Freigabe verlangt, und Versuche, die lokale Sandbox zu umgehen, prüft das Modell nicht. Für sie gilt die normale Berechtigungsabfrage der Sitzung.
• Autopilot und nicht-interaktive Läufe. Dort werden Anfragen, die eine Zustimmung bräuchten, abgelehnt.
• Kombination mit Allow All. Wer in der CLI --assisted-approval mit --allow-all kombiniert, hat weiterhin unbeschränkten Zugriff auf Pfade und URLs.

Was können Admins festlegen?

Enterprise-Admins können über die verwalteten Einstellungen „Allow All“ sperren und „Assisted“ trotzdem verfügbar lassen.

Die Referenz zu den Enterprise-Einstellungen nennt drei Schalter:

• permissions.disableBypassPermissionsMode sperrt den Allow-All- bzw. YOLO-Modus. Assisted Permissions bleibt davon unberührt. Laut Tabelle wirkt das in Copilot CLI, VS Code, der Copilot App und JetBrains.
• permissions.disableAssistedPermissionsMode verhindert, dass Nutzer Assisted aktivieren.
• permissions.defaultMode legt fest, ob neue Sitzungen mit „manual“, „assisted“ oder „allow-all“ starten. Das ist ein Standard, keine Sperre: Entwickler können innerhalb der Richtlinien wechseln. Ist der Standard verboten oder nicht verfügbar, startet die Sitzung mit manueller Freigabe.

Über allem stehen die Regeln deny, ask und allow, wobei Verbieten vor Nachfragen vor Erlauben gilt. Wie GitHub zentrale Standards für Copilot ausrollt, habe ich mir auch bei der neuen Standardrichtlinie für Copilot-Einstellungen angesehen.

So schaltest du den Modus ein

Laut Changelog:

• Copilot CLI: /permissions ausführen und „assisted“ wählen.
• GitHub Copilot App: Mode-Picker öffnen, „Tool permissions“ anklicken, „Assisted“ wählen.
• VS Code: Permissions-Picker öffnen, „Assisted permissions“ wählen.

Für die CLI gibt es zusätzlich die Einstellung defaultPermissionMode sowie für nicht-interaktive Läufe den Schalter --assisted-approval oder die Umgebungsvariable COPILOT_ASSISTED_APPROVAL=true (Doku).

Was es für dich bedeutet

Wenn du allein oder in einem kleinen Team mit Copilot arbeitest, ist Assisted für viele Alltagsaufgaben ein vernünftiger Standard. Tests starten, Dateien im Projekt lesen, eine Doku-Seite öffnen: Für solche Routine willst du nicht jedes Mal klicken.

Drei Dinge würde ich trotzdem beachten:

Erstens: Assisted ist eine Komfortfunktion, keine Sicherheitsfunktion. GitHub sagt das selbst. Wenn dein Agent auf einem Rechner mit Zugangsdaten zu Kundensystemen, Produktivdatenbanken oder deinem Buchhaltungsordner läuft, gehören feste Grenzen dazu: ein eigenes Projektverzeichnis, ein Container oder eine Deny-Regel für alles, was nie passieren darf.

Zweitens: Lege fest, was nie automatisch laufen darf. Löschen außerhalb des Projekts, Deployments, Zugriffe auf .env-Dateien. Solche Dinge gehören in eine feste Regel statt in die Einschätzung eines Modells. Wie du einen Agenten grundsätzlich einordnest, erkläre ich im Ratgeber Was ist ein KI-Agent?.

Drittens: Die Admin-Sperren stehen in der Enterprise-Dokumentation. Ob und wie du sie in kleineren Plänen nutzen kannst, geht aus Changelog und Doku nicht hervor. Prüfe das für deinen Plan, bevor du dich darauf verlässt.

Ich arbeite bei meinem eigenen Agenten mit demselben Grundgedanken: Bei Sokrates geht nichts nach außen, ohne dass ich es im Studio freigebe. Ein Modell als Vorfilter spart Zeit. Die letzte Entscheidung über alles, was sich schwer rückgängig machen lässt, bleibt beim Menschen. Einen anderen Ansatz zur Agenten-Sicherheit zeigt Microsoft mit Claude Code in Defender.

Quellen

• GitHub Changelog: GitHub Copilot assisted permissions generally available (26.10.2026)
• GitHub Docs: Allowing safe commands
• GitHub Docs: Enterprise-managed settings, Abschnitt Permissions

Häufige Fragen

Was sind Assisted Permissions bei GitHub Copilot?

Ein Berechtigungsmodus, bei dem ein Sprachmodell prüft, ob ein Befehl, ein Dateizugriff oder eine URL sicher ist. Hält das Modell die Aktion für sicher, läuft sie ohne Rückfrage. Sonst fragt Copilot dich.

Wie schalte ich Assisted Permissions in der Copilot CLI ein?

In der Copilot CLI führst du den Befehl /permissions aus und wählst „assisted“. In VS Code wählst du im Permissions-Picker „Assisted permissions“, in der GitHub Copilot App unter „Tool permissions“ den Eintrag „Assisted“.

Ist Assisted Permissions so sicher wie manuelles Bestätigen?

Nein. GitHub schreibt selbst, dass das Prüfmodell Fehler machen und gefährliche Aktionen durchlassen kann. Der Modus ersetzt weder Sandboxing noch Zugriffsbeschränkungen, und die Verantwortung für die Aktionen bleibt bei dir.

Können Admins den Allow-All-Modus von Copilot verbieten?

Ja. Über die Enterprise-verwalteten Einstellungen lässt sich der Bypass- bzw. Allow-All-Modus sperren, während Assisted Permissions verfügbar bleibt. Assisted lässt sich auch separat abschalten.