Une application Copilot en lecture seule peut aussi consommer des crédits
Un agent nocturne dépend parfois de la connexion personnelle de son créateur. Le 27 octobre, GitHub a lancé un aperçu public de l’authentification serveur à serveur pour les GitHub Apps installées dans une organisation avec le Copilot SDK. Le service agit au nom de son installation. La surprise : Read-only peut autoriser des requêtes payantes.
Lecture seule ne veut pas dire gratuit
L’application reçoit la permission d’organisation Copilot Requests en Read-only et emploie un jeton d’installation de courte durée. La consommation et la facture reviennent à l’organisation propriétaire de l’installation. Ici, ce droit permet des requêtes consommant des crédits d’IA.
Prenons une entreprise fictive avec une application d’analyse et une autre de résumé. Toutes deux peuvent avoir des droits de lecture tout en générant des frais. Ne pas modifier de fichiers et utiliser un modèle sont compatibles. L’identité du service change la responsabilité, pas le coût de l’inférence.
Actions et les serveurs externes ont des chemins distincts
Un service externe ou un autre CI transmet le jeton par une option explicite du SDK, comme gitHubToken. Seules les installations d’organisation conviennent, pas celles de comptes personnels ou d’entreprise. La disponibilité des installations d’entreprise abordée précédemment concerne un autre périmètre.
Dans un dépôt d’organisation, GitHub Actions peut utiliser GITHUB_TOKEN. Cette voie requiert copilot-requests: write dans le YAML et la politique Allow use of Copilot CLI billed to the organization. L’authentification d’une application installée ne nécessite pas cette politique. Les libellés Read-only et write correspondent à deux voies différentes.
Faire fonctionner l’identité au-delà d’une heure
Un jeton d’installation expire après une heure. Son remplaçant doit atteindre le processus. La documentation demande de redémarrer le client enfant avec le nouveau jeton, ou le runtime hôte pour une exécution intégrée ou existante. Modifier un fichier ne suffit pas à prouver sa prise en compte.
useLoggedInUser: false désactive la découverte automatique des identifiants, y compris les jetons des variables d’environnement. Il faut donc passer le jeton explicitement au SDK. Un succès sur le portable et un échec sur le serveur peuvent révéler un repli personnel involontaire plutôt qu’un problème de permission.
Une attribution par application, un budget collectif
Les propriétaires repèrent les applications dans les CSV d’usage avec organization et app_client_id. Le rapprochement avec client_id de l’API des installations donne app_slug. Cette distinction n’est pas disponible dans la vue web d’usage de l’IA. Il n’existe pas de budget individuel par application et une simple alerte ne bloque pas la consommation.
Suspendre ou désinstaller l’installation bloque aussi ses autres accès aux ressources de l’organisation. L’intérêt est une responsabilité plus lisible sous les politiques de modèles et de dépenses. Détacher le service d’une personne implique aussi de transférer le renouvellement des jetons et la propriété des coûts.