Am 27. Oktober 2026 hat GitHub eine öffentliche Vorschau der Server-zu-Server-Authentifizierung für GitHub Copilot gestartet. Bisher musste jeder automatisierte Dienst, der Copilot aufrief, die Zugangsdaten einer angemeldeten Person nutzen. Der neue Mechanismus führt eine Identität ein, die der Organisation selbst gehört, gedacht für Agenten und Integrationen, die ohne eine Person direkt am Steuer laufen.
Welches Problem gelöst wird
Ein Agent für Code-Reviews, ein Dokumentations-Bot oder jeder auf dem Copilot SDK aufgebaute Dienst musste bisher die Identität eines Nutzerkontos annehmen, um Anfragen zu stellen. Diese Abhängigkeit brachte zwei wiederkehrende Probleme mit sich: Abrechnung und Kontingente blieben an diese Person gebunden, und das Deaktivieren ihres Kontos konnte den Dienst unbemerkt stören. Der neue Mechanismus entkoppelt die automatisierte Nutzung von jedem individuellen Konto.
Wie die Organisationsidentität funktioniert
Die Umsetzung baut auf GitHub Apps auf, die bereits auf Organisationsebene installiert sind. Eine Administratorin erteilt der App die schreibgeschützte Organisationsberechtigung Copilot Requests und installiert sie anschließend in der betreffenden Organisation. Der Dienst tauscht dann ein kurzlebiges Installations-Zugriffstoken gegen Aufrufe an das Copilot SDK, das fortan im Namen der Organisation und nicht einer einzelnen Entwicklerin handelt.
| Vorher | Mit Server-zu-Server-Authentifizierung |
|---|---|
| Identität an ein persönliches Konto gebunden | Identität gehört der Organisation |
| Abrechnung an die Nutzerin gebunden | Abrechnung und Kontingente auf Organisationsebene |
| Dienst kann beim Weggang einer Person ausfallen | Unabhängig von jedem Einzelkonto |
| Begrenzte Nachvollziehbarkeit in Nutzungsberichten | Zuordnung über das Feld app_client_id |
Ein vereinfachtes Beispiel eines mit einem Installationstoken authentifizierten Aufrufs, wie von GitHub dokumentiert:
POST /copilot/requests HTTP/1.1
Host: api.github.com
Authorization: Bearer <installation_access_token>
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2026-10-01
Die Nutzung wird nun der Organisation zugeordnet und in Rechnung gestellt, die die Installation besitzt, gemäß den von ihr festgelegten Modellrichtlinien und Ausgabenobergrenzen.
Was Administratoren kontrollieren können
Organisationsinhaber behalten die Kontrolle über diesen neuen Zugangsweg. Sie können einsehen, welche Apps zur Nutzung von Copilot berechtigt sind, die von jeder App erzeugte Nutzung in CSV-Nutzungsberichten über das Feld app_client_id identifizieren und den Zugriff durch Sperren oder Deinstallieren der App widerrufen.
Warum das für agentenlastige Teams zählt
Dieser Schritt fügt sich in ein breiteres Muster bei GitHub ein, das bereits eine Copilot-Modellrichtlinien-API eingeführt hat und seine assistierten Berechtigungen Richtung allgemeiner Verfügbarkeit treibt. Die Organisationsidentität vervollständigt diese Governance-Ebene: Sie macht es im großen Maßstab praktikabel, Agenten zu betreiben, die Copilot fortlaufend aufrufen, ohne dass eine einzelne Person die technische Verantwortung für das dahinterliegende Konto trägt.
Das Wichtigste in Kürze
GitHub bietet Organisationen seit dem 27. Oktober 2026 in öffentlicher Vorschau eine eigene Identität für automatisierte Copilot-Nutzung. Der Mechanismus stützt sich auf eine GitHub App mit der Berechtigung Copilot Requests und ein kurzlebiges Installationstoken. Abrechnung, Modellrichtlinien und Nachvollziehbarkeit folgen nun der Organisation statt eines einzelnen Kontos, was den Betrieb langlaufender Agenten vereinfacht.
Bei Projekten, in denen ich erlebt habe, wie Code-Review-Bots still und leise ausfielen, weil ein Dienstkonto abgelaufen war oder seine Rechte verloren hatte, geht diese Entkopplung in die richtige Richtung. Offen bleibt, ob die Standardkontingente für einen Agenten ausreichen, der dauerhaft auf einem aktiven Repository läuft — genau dort enttäuschen Vorschauversionen in der Produktion häufig. — Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung im GitHub-Changelog.
