GitHub a introduit l'authentification de serveur à serveur pour les applications créées avec Copilot SDK, offrant ainsi aux charges de travail automatisées un moyen d'accéder à Copilot sans avoir recours aux identifiants d'un développeur connecté.

La fonctionnalité, publiée en version préliminaire publique le 27 octobre, utilise une GitHub application installée sur une organisation. L'application obtient un jeton d'installation de courte durée et l'utilisation de Copilot est attribuée et facturée à l'organisation propriétaire de l'installation. Les politiques modèles, les budgets et les contrôles des dépenses de l'organisation s'appliquent également aux demandes formulées par l'application.

Cela modifie le modèle opérationnel pour les équipes qui intègrent Copilot dans les services internes, l'automatisation des référentiels ou les outils de développement destinés aux clients. L'authentification peut désormais représenter la charge de travail elle-même plutôt que l'employé qui l'a autorisée.

Des identifiants utilisateur à l'identité de l'application

De nombreuses intégrations d'agents commencent par un jeton d'accès personnel ou un autre identifiant lié à un développeur individuel. Cela peut être pratique lors d'un prototype, mais cela crée des problèmes lorsque l'intégration devient un service persistant. Les employés changent de rôle, les informations d'identification expirent ou sont révoquées, et les enregistrements d'audit peuvent faire ressembler une activité automatisée à une activité humaine.

Le nouveau chemin de

GitHub utilise un jeton d'installation émis pour une application GitHub. Les jetons d'installation sont de courte durée et limités à l'installation et aux autorisations de l'application, ce qui les rend mieux adaptés aux charges de travail sans surveillance qu'un identifiant utilisateur de longue durée.

La distinction est importante pour la gouvernance. Une organisation peut identifier l'application responsable de la consommation de Copilot au lieu d'attribuer chaque demande à un opérateur nominal. GitHub inclut un champ app_client_id dans les rapports CSV d'utilisation de l'IA, permettant aux propriétaires de séparer l'utilisation provenant de l'application lors de l'analyse.

Pour les équipes qui créent un plan de contrôle IA API pour les équipes de développeurs, il s'agit d'un modèle d'identité utile : les utilisateurs humains, les comptes d'automatisation et les applications déployées ne doivent pas partager des informations d'identification ou des enregistrements de facturation indiscernables.

La facturation suit l'organisation

Les demandes authentifiées de cette manière consomment l'allocation Copilot de l'organisation et sont régies par ses politiques modèles, ses budgets et ses contrôles de dépenses existants. Cela donne aux administrateurs un endroit unique pour décider quels modèles une application peut utiliser et combien de dépenses globales en IA l'organisation autorisera.

Cela signifie également que les propriétaires d'applications ne peuvent pas traiter l'accès de serveur à serveur comme un pool de capacité indépendant. Une intégration chargée peut bénéficier du même budget organisationnel que les autres activités Copilot éligibles. Les équipes devront surveiller la consommation automatisée parallèlement à l'utilisation interactive et décider comment les incidents, les tentatives et les boucles de requêtes inattendues doivent affecter les limites partagées.

L'aperçu actuel ne prend pas en charge un budget distinct pour chaque application ou installation. Le champ app_client_id peut faciliter l'attribution rétrospective, mais la création de rapports par application n'équivaut pas à l'application d'un plafond strict spécifique à l'application. Les organisations qui ont besoin d'isolation peuvent toujours avoir besoin de leur propre couche de mesure ou de IA API contrôles des dépenses pour les équipes face aux charges de travail automatisées.

Ce que les développeurs doivent changer

Les développeurs qui adoptent la fonctionnalité doivent créer une GitHub application, l'installer sur l'organisation concernée et échanger les informations d'identification de l'application contre un jeton d'installation. L'application utilise ensuite ce jeton de courte durée lors de l'appel via le Copilot SDK. Les systèmes de déploiement doivent donc gérer l'émission et le renouvellement des jetons plutôt que de stocker indéfiniment un jeton de développeur statique.

Les enregistrements opérationnels doivent conserver à la fois l'identité de l'application GitHub et l'organisation facturée pour chaque demande. Ceci est particulièrement important pour les plates-formes au service de plusieurs organisations : un jeton émis pour une installation ne doit pas être réutilisé pour acheminer la charge de travail d'un autre client, et les exportations d'utilisation doivent être rapprochées du bon locataire.

Le modèle affecte également l'offboarding. La suppression d'un développeur ne nécessite plus de désactiver une intégration appartenant à l'organisation, tandis que la désinstallation de l'application GitHub ou la modification de ses autorisations offrent un contrôle plus direct sur l'application elle-même. Le résultat pratique est une séparation plus nette entre l'identité de la main-d'œuvre et l'identité de la charge de travail.

Les limites restantes

L'authentification de serveur à serveur est encore une version préliminaire publique, donc GitHub peut modifier son contrat avant la disponibilité générale. GitHub n'a pas annoncé la prise en charge des installations au niveau de l'entreprise ou des comptes personnels via ce chemin d'authentification.

Le manque de budgets par application constitue la lacune de contrôle la plus immédiate. Les organisations peuvent voir quelle application a généré une utilisation, mais elles ne peuvent pas encore attribuer à chaque application ou installation un budget Copilot indépendant. Cela devient encore plus important à mesure que les entreprises déploient plusieurs agents de codage, services de révision et automatisations de référentiels au sein d'une seule organisation.

Même avec cette limitation, la version établit un modèle de propriété plus clair pour le trafic Copilot généré par la machine. L'authentification, la politique et la facturation sont désormais liées à une application installée et à son organisation, créant ainsi une base plus défendable pour une automatisation persistante que les informations d'identification de développeur empruntées.