Warum eine Copilot-App mit Leserechten trotzdem Guthaben verbraucht

Tech
Aufrufe 3

Ein nächtlicher Analyseagent hängt manchmal am Login einer einzelnen Person. Seit dem 27. Oktober bietet GitHub für organisationsweit installierte GitHub Apps mit Copilot SDK eine öffentliche Vorschau der Server-zu-Server-Authentifizierung. Der Dienst handelt als App-Installation. Auffällig ist die Berechtigung: Read-only kann kostenpflichtige KI-Anfragen erlauben.

Leserechte bedeuten keine kostenlosen Anfragen

Die App erhält die Organisationsberechtigung Copilot Requests mit Read-only und nutzt ein kurzlebiges Installationstoken. Nutzung und Rechnung gehören zur Organisation, der die Installation gehört. Das Leserecht erlaubt hier Anfragen, die KI-Guthaben verbrauchen.

Eigene Gegenüberstellung: oben Organisations-App mit Copilot Requests: Read-only, unten Actions mit GITHUB_TOKEN und copilot-requests: write. Keine Produktoberfläche oder Ausführungsmessung.
Eigene Gegenüberstellung: oben Organisations-App mit Copilot Requests: Read-only, unten Actions mit GITHUB_TOKEN und copilot-requests: write. Keine Produktoberfläche oder Ausführungsmessung.

Ein hypothetisches Unternehmen betreibt eine Analyse-App und einen Dokumentenzusammenfasser. Beide können nur Leserechte haben und dennoch Kosten verursachen. Keine Dateien zu ändern und Modellkapazität zu verbrauchen passt zusammen. Die neue Identität ändert die Zuordnung, nicht den Preis der Inferenz.

Actions und externe Server nutzen andere Zugänge

Externe Dienste und andere CI-Systeme übergeben ein Installationstoken explizit über eine SDK-Option wie gitHubToken. Nur Organisationsinstallationen sind unterstützt, keine persönlichen oder Enterprise-Installationen. Die frühere Freigabe von Enterprise-Installationen hat einen anderen Geltungsbereich.

In einem Organisationsrepository kann GitHub Actions stattdessen GITHUB_TOKEN nutzen. Dafür stehen im YAML copilot-requests: write und die Organisationsrichtlinie Allow use of Copilot CLI billed to the organization muss aktiv sein. Die App-Authentifizierung braucht diese Richtlinie nicht. Read-only und write bezeichnen hier unterschiedliche Zugänge.

Nach einer Stunde muss die Identität weiter funktionieren

Installationstoken laufen nach einer Stunde ab. Ein neues Token muss auch den laufenden Dienst erreichen. Laut SDK-Dokumentation startet man einen Client im Kindprozess mit dem neuen Token neu; bei eingebetteten oder bestehenden Laufzeiten den Host. Eine geänderte Datei garantiert noch keine Übernahme durch den Prozess.

useLoggedInUser: false deaktiviert die automatische Suche nach Zugangsdaten einschließlich Umgebungsvariablen. Das Token muss dann explizit an die SDK-Option gehen. Funktioniert der Laptop, der Server aber nicht, lohnt die Unterscheidung zwischen persönlichem Fallback und tatsächlich übergebenem Token.

Hypothetische Token-Lebensdauer: Ersatz vor Ablauf einer Stunde erzeugen und an die Laufzeit übergeben. Eigene Illustration, keine Telemetrie.
Hypothetische Token-Lebensdauer: Ersatz vor Ablauf einer Stunde erzeugen und an die Laufzeit übergeben. Eigene Illustration, keine Telemetrie.

App-Zuordnung, gemeinsames Organisationsbudget

Organisationsinhaber finden Apps in KI-Nutzungs-CSV-Dateien über organization und app_client_id. Der Abgleich mit client_id der Installations-API liefert app_slug. Die Webansicht zeigt diese Zuordnung derzeit nicht. Pro App sichtbare Nutzung bedeutet kein eigenes App-Budget. Ein Budget nur mit Warnungen stoppt keinen Verbrauch.

Das Aussetzen oder Entfernen einer Installation stoppt auch ihren Zugriff auf andere Organisationsressourcen. Der Gewinn ist eine eindeutigere Verantwortung für automatisierte Arbeit unter Modell- und Ausgabenrichtlinien. Beim Ablösen persönlicher Logins sollten Tokenwechsel und Kostenzuordnung mitwandern.

Offizielle Quellen

GitHub Changelog · 2026-10-27

GitHub Docs · Server-to-server authentication

GitHub Docs · Manage app Copilot access