El 27 de octubre de 2026, GitHub abrió una vista previa pública de la autenticación de servidor a servidor para GitHub Copilot. Hasta ahora, cualquier servicio automatizado que llamara a Copilot debía tomar prestadas las credenciales de una persona con sesión iniciada. El nuevo mecanismo introduce una identidad propiedad de la organización, pensada para agentes e integraciones que funcionan sin una persona detrás en cada llamada.
El problema que resuelve
Un agente de revisión de código, un bot de documentación o cualquier servicio construido sobre el SDK de Copilot debía hasta ahora suplantar la cuenta de un usuario para hacer peticiones. Esa dependencia generaba dos problemas recurrentes: la facturación y las cuotas quedaban ligadas a esa persona, y la desactivación de su cuenta podía interrumpir el servicio sin previo aviso. El nuevo mecanismo desacopla el uso automatizado de cualquier cuenta individual.
Cómo funciona la identidad de organización
La implementación se apoya en las GitHub Apps ya instaladas a nivel de organización. Un administrador concede a la aplicación el permiso de organización de solo lectura Copilot Requests y la instala en la organización correspondiente. El servicio intercambia entonces un token de instalación de corta duración por llamadas al SDK de Copilot, que actúa en nombre de la organización y no de un desarrollador concreto.
| Antes | Con autenticación de servidor a servidor |
|---|---|
| Identidad ligada a una cuenta personal | Identidad propiedad de la organización |
| Facturación asociada al usuario | Facturación y cuotas a nivel de organización |
| El servicio puede romperse si alguien se va | Independiente de cualquier cuenta individual |
| Trazabilidad limitada en los informes de uso | Atribución mediante el campo app_client_id |
Ejemplo simplificado de una llamada autenticada con un token de instalación, tal como lo documenta GitHub:
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
El uso queda ahora atribuido y facturado a la organización propietaria de la instalación, bajo las políticas de modelos y los límites de gasto que esta haya definido.
Qué pueden controlar los administradores
Los propietarios de la organización conservan el control de este nuevo canal de acceso. Pueden revisar qué aplicaciones están autorizadas a usar Copilot, identificar el uso generado por cada aplicación en los informes CSV gracias al campo app_client_id, y revocar el acceso suspendiendo o desinstalando la aplicación.
Por qué importa a los equipos que usan agentes
Este movimiento encaja en una tendencia más amplia en GitHub, que ya había lanzado una API de políticas de modelos para Copilot y lleva sus permisos asistidos hacia la disponibilidad general. La identidad de organización completa esa capa de gobernanza: hace viable, a escala, tener agentes que consultan Copilot de forma continua sin que una persona concreta cargue con la responsabilidad técnica de la cuenta utilizada.
Lo que hay que recordar
GitHub ofrece a las organizaciones una identidad propia para los usos automatizados de Copilot, en vista previa pública desde el 27 de octubre de 2026. El mecanismo se apoya en una GitHub App con el permiso Copilot Requests y un token de instalación de corta duración. La facturación, las políticas de modelos y la trazabilidad siguen ahora a la organización en lugar de a una cuenta individual, lo que simplifica la operación de agentes de larga duración.
En los proyectos donde he visto bots de revisión de código fallar en silencio porque la cuenta de servicio había expirado o perdido permisos, este tipo de desacoplamiento va en la dirección correcta. Queda por ver si las cuotas por defecto serán suficientes para un agente que funciona de forma continua sobre un repositorio activo: es justo ahí donde las vistas previas suelen decepcionar una vez en producción. — Simon Janvier
Para saber más: el anuncio oficial en el changelog de GitHub.
