Copilot Assisted Permissions: Entscheidungsgrenzen vor dem Lauf klären

GitHub hat Assisted Permissions am 26. Oktober 2026 für CLI, Copilot-App und VS Code als allgemein verfügbar angekündigt. Ein Modell bewertet geeignete Anfragen zu Befehlen, Dateipfaden und URLs; Enterprise-Verwaltung kann Assisted und Allow All getrennt beschränken. (GitHub)

Drei Fragen vor jeder Automatisierung

Erstens: Welches Ergebnis wurde beauftragt? Zweitens: Wie wird eine einzelne notwendige Aktion freigegeben? Drittens: Auf welche Systeme kann der ausführende Prozess tatsächlich zugreifen? Schreiben Sie diese Antworten getrennt auf. Ein gut formulierter Auftrag begrenzt kein Betriebssystemkonto und entzieht einem vorhandenen Token keine Rechte.

Die Dokumentation lässt Deny-Regeln und Enterprise-Grenzen bestehen. Enterprise-Ask kann für geeignete Aktionen durch Modellprüfung erfüllt werden. Unbeaufsichtigt werden weiterhin genehmigungspflichtige Anfragen abgelehnt. Pfad-/URL-Freigaben bleiben separat. Scheitert Assisted, kann separat gesetztes allow-all-tools ohne Modellprüfung fortgelten. Cloud-Sitzungen der App bieten keine Tool-Berechtigungssteuerung. Eine Modellentscheidung ist kein Ersatz für Isolation. (GitHub)

Mit einem eng begrenzten Arbeitsauftrag beginnen

Als hypothetisches Beispiel soll ein Agent die Darstellung einer Fehlermeldung in einer lokalen Testanwendung verbessern. Die Ausgabe darf Dateien in diesem Arbeitsbereich ändern. Daraus folgt keine Befugnis, eine produktive Konfiguration zu lesen, einen fremden Dienst anzuschreiben oder einen Deployment-Schlüssel zu verwenden. Dieses Beispiel wurde hier nicht ausgeführt.

Die Matrix ist keine zusätzliche Freigabe. Sie macht offene Entscheidungen sichtbar, die vor einem Versuch geklärt werden müssen. Besonders bei Agenturarbeit können Arbeitsverzeichnis, Kundentoken und Netzwerkzugang aus verschiedenen Zuständigkeiten stammen. Ein erlaubter Repository-Zugriff allein löst diese Abgrenzung nicht.

Unbeaufsichtigte Arbeit braucht einen sichtbaren Haltezustand

Ein Lauf ohne erreichbare Person muss auch dann nützlich enden, wenn er nicht alle Schritte ausführen darf. Definieren Sie dafür ein ablegbares Zwischenergebnis: geprüfte Dateien, verbleibende Aufgabe und konkret fehlende Freigabe. So lässt sich der Lauf fortsetzen, ohne seine Rechte pauschal zu erweitern.

• Prüfen Sie beim Start den tatsächlich wirksamen Modus sowie Administrator- und Hostvorgaben; eine persönliche Voreinstellung ist kein Laufnachweis.
• Behandeln Sie Warnungen über nicht aktivierte Prüffunktionen als offene Konfigurationsabweichung. Ein gestarteter Prozess beweist nicht, dass die beabsichtigte Freigabeprüfung läuft.
• Halten Sie Systemzugriffe unabhängig vom Modellurteil möglichst eng. Dokumentieren Sie, welche Identität auf Dateien, Netzwerk und externe Werkzeuge zugreift.
• Kontrollieren Sie das entstandene Ergebnis und wesentliche Aktionen. Die Abnahme einer Änderung bleibt eine eigene Aufgabe.

Was vor einer Einführung noch offen sein kann

Aus der allgemeinen Verfügbarkeit folgt nicht, dass jeder Host dieselben Optionen bietet oder jeder Tarif sie in derselben Form bereitstellt. Prüfen Sie Client, effektive Unternehmensrichtlinien, Lizenzumfang und Abrechnung für die vorgesehene Umgebung. Dieser Beitrag führt keine Berechtigungsänderung durch und empfiehlt keinen pauschalen Allow-All-Modus.

Die sinnvolle Pilotentscheidung benennt einen begrenzten Auftrag, einen überprüften Ausführungsbereich und einen Umgang mit verweigerten Aktionen. Anschliessend kann ein freigegebener Versuch zeigen, ob der Arbeitsfluss mit diesen Grenzen praktikabel ist. Eine Sicherheitsgarantie durch das Modell lässt sich daraus nicht ableiten.