GitHub hat die Server-zu-Server-Authentifizierung für Anwendungen eingeführt, die mit Copilot SDK erstellt wurden, und gibt automatisierten Arbeitslasten eine Möglichkeit, auf Copilot zuzugreifen, ohne auf die Anmeldeinformationen eines angemeldeten Entwicklers angewiesen zu sein.

Die Funktion, die am 27. Oktober als öffentliche Vorschau veröffentlicht wurde, nutzt eine GitHub App, die in einer Organisation installiert ist. Die App erhält ein kurzlebiges Installationstoken und die Copilot-Nutzung wird der Organisation zugeordnet und in Rechnung gestellt, die Eigentümer der Installation ist. Die Modellrichtlinien, Budgets und Ausgabenkontrollen der Organisation gelten auch für Anfragen, die von der App gestellt werden.

Dies ändert das Betriebsmodell für Teams, die Copilot in interne Dienste, Repository-Automatisierung oder kundenorientierte Entwicklertools einbetten. Die Authentifizierung kann jetzt die Arbeitslast selbst darstellen und nicht den Mitarbeiter, der sie autorisiert hat.

Von Benutzeranmeldeinformationen bis zur Anwendungsidentität

Viele Agent-Integrationen beginnen mit einem persönlichen Zugriffstoken oder anderen Anmeldeinformationen, die an einen einzelnen Entwickler gebunden sind. Das kann während eines Prototyps praktisch sein, führt jedoch zu Problemen, wenn die Integration zu einem dauerhaften Dienst wird. Mitarbeiter ändern ihre Rollen, Anmeldeinformationen laufen ab oder werden widerrufen und Prüfaufzeichnungen können dazu führen, dass automatisierte Aktivitäten wie menschliche Aktivitäten aussehen.

Der neue Pfad von

GitHub verwendet ein Installationstoken, das für eine GitHub-App ausgestellt wurde. Installationstokens sind kurzlebig und hängen von der Installation und den Berechtigungen der App ab. Dadurch eignen sie sich besser für unbeaufsichtigte Arbeitslasten als langlebige Benutzeranmeldeinformationen.

Die Unterscheidung ist wichtig für die Governance. Eine Organisation kann die für den Copilot-Verbrauch verantwortliche Anwendung identifizieren, anstatt jede Anfrage einem nominellen Betreiber zuzuordnen. GitHub enthält ein app_client_id-Feld in CSV-Berichten zur KI-Nutzung, sodass Besitzer die von der App stammende Nutzung während der Analyse trennen können.

Für Teams, die eine KI-APIKontrollebene für Entwicklerteams aufbauen, ist dies ein nützliches Identitätsmuster: Menschliche Benutzer, Automatisierungskonten und bereitgestellte Anwendungen sollten keine ununterscheidbaren Anmeldeinformationen oder Abrechnungsdatensätze teilen.

Abrechnung folgt der Organisation

Anfragen, die auf diese Weise authentifiziert werden, verbrauchen das Copilot-Kontingent der Organisation und unterliegen den bestehenden Modellrichtlinien, Budgets und Ausgabenkontrollen. Dies gibt Administratoren einen Ort, an dem sie entscheiden können, welche Modelle eine Anwendung verwenden darf und wie viel KI-Gesamtausgaben das Unternehmen zulässt.

Es bedeutet auch, dass Anwendungseigentümer den Server-zu-Server-Zugriff nicht als unabhängigen Kapazitätspool behandeln können. Eine ausgelastete Integration kann aus demselben Organisationsbudget wie andere förderfähige Copilot-Aktivitäten finanziert werden. Teams müssen neben der interaktiven Nutzung auch den automatisierten Verbrauch überwachen und entscheiden, wie sich Vorfälle, Wiederholungsversuche und unerwartete Anforderungsschleifen auf gemeinsame Grenzwerte auswirken sollen.

Die aktuelle Vorschau unterstützt kein separates Budget für jede App oder Installation. Das Feld app_client_id kann bei der retrospektiven Zuordnung hilfreich sein, aber die Berichterstattung nach Anwendung ist nicht gleichbedeutend mit der Durchsetzung einer harten anwendungsspezifischen Obergrenze. Organisationen, die Isolierung benötigen, benötigen möglicherweise immer noch eine eigene Messebene oder KI API Ausgabenkontrollen für Teams vor automatisierten Arbeitslasten.

Was Entwickler ändern müssen

Entwickler, die die Funktion übernehmen, müssen eine GitHub App erstellen, diese in der entsprechenden Organisation installieren und die Anmeldeinformationen der App gegen ein Installationstoken austauschen. Die Anwendung verwendet dann dieses kurzlebige Token, wenn sie über den Copilot SDK aufruft. Bereitstellungssysteme müssen daher die Ausgabe und Erneuerung von Token abwickeln, anstatt ein statisches Entwickler-Token auf unbestimmte Zeit zu speichern.

Betriebsaufzeichnungen sollten sowohl die GitHub App-Identität als auch die für jede Anfrage in Rechnung gestellte Organisation bewahren. Dies ist besonders wichtig für Plattformen, die mehrere Organisationen bedienen: Ein für eine Installation ausgestelltes Token darf nicht wiederverwendet werden, um die Arbeitslast eines anderen Kunden weiterzuleiten, und Nutzungsexporte sollten mit dem richtigen Mandanten abgeglichen werden.

Das Modell wirkt sich auch auf Offboarding aus. Das Entfernen eines Entwicklers muss nicht länger eine organisationseigene Integration deaktivieren, während die Deinstallation der GitHub-App oder das Ändern ihrer Berechtigungen eine direktere Kontrolle über die Anwendung selbst ermöglicht. Das praktische Ergebnis ist eine sauberere Trennung zwischen Workforce Identity und Workload Identity.

Die verbleibenden Limits

Die Server-zu-Server-Authentifizierung ist noch eine öffentliche Vorschau, daher kann GitHub seinen Vertrag vor der allgemeinen Verfügbarkeit ändern. GitHub hat keine Unterstützung für Installationen auf Unternehmensebene oder persönliche Konten über diesen Authentifizierungspfad angekündigt.

Der Mangel an Budgets pro App ist die unmittelbarste Kontrolllücke. Organisationen können sehen, welche App die Nutzung generiert hat, sie können jedoch noch nicht jeder App oder Installation ein unabhängiges Copilot-Budget zuweisen. Dies wird immer wichtiger, wenn Unternehmen mehrere Codierungsagenten, Überprüfungsdienste und Repository-Automatisierungen unter einer Organisation bereitstellen.

Trotz dieser Einschränkung führt die Version ein klareres Eigentumsmodell für maschinengenerierten Copilot-Verkehr ein. Authentifizierung, Richtlinien und Abrechnung hängen jetzt mit einer installierten Anwendung und ihrer Organisation zusammen und schaffen so eine vertretbarere Grundlage für die dauerhafte Automatisierung als geliehene Entwickleranmeldeinformationen.