GitHub anunció el 27 de octubre de 2026 la autenticación entre servidores para servicios y agentes construidos con el SDK de Copilot, su biblioteca de integración. Está en preview pública, sujeta a cambios: una GitHub App instalada en una organización puede hacer solicitudes sin utilizar las credenciales de una persona conectada. El consumo se atribuye y factura a esa organización.
Esto permite separar la identidad de un servicio de la cuenta del empleado que lo puso en marcha. No concede automáticamente acceso a repositorios ni convierte las acciones del agente en seguras: hay que revisar esos permisos por separado.
Qué necesita una organización
La documentación de administración sitúa esta función en Copilot Business y Enterprise, con gestión por los propietarios de la organización. La aplicación debe tener el permiso de organización Copilot Requests, configurado como Read-only.
Ese nombre merece atención: Read-only permite consumir créditos de IA y generar gasto. No describe una modalidad gratuita. La autenticación se aplica a instalaciones en organizaciones; quedan fuera las instalaciones en cuentas personales y las instalaciones de ámbito empresarial.
La organización controla qué modelos puede utilizar la aplicación. Sus políticas y controles de facturación siguen aplicándose, pero no se puede crear un presupuesto separado para cada aplicación o instalación. Antes de aprobar acceso conviene acordar quién responde por el servicio y qué consumo se espera.
Tokens temporales y renovación
Según la guía técnica del SDK, el servicio obtiene un token de instalación que caduca tras una hora y lo pasa explícitamente al cliente. Desactivar la búsqueda automática de credenciales mediante useLoggedInUser: false también desactiva la detección de tokens del entorno: no basta con dejar uno en una variable y esperar que se utilice.
Hay que emitir el siguiente token antes del vencimiento. Para un proceso hijo, la guía indica reiniciar el cliente del SDK con el nuevo token; para un runtime existente o integrado en el proceso, reiniciar ese entorno con la credencial renovada. Una identidad propia evita depender del inicio de sesión de un empleado, pero sigue necesitando gestionar su ciclo de vida.
GitHub Actions tiene una ruta diferente: los flujos de repositorios de organización usan el GITHUB_TOKEN integrado, el permiso copilot-requests: write y la política Allow use of Copilot CLI billed to the organization. Esa política no es un requisito de la ruta con GitHub App instalada en una organización. Conviene identificar primero dónde se ejecuta el servicio.
Cómo seguir el gasto y cortar el acceso
Los informes CSV de uso permiten atribuir solicitudes mediante app_client_id; esa atribución no aparece en la vista AI usage de GitHub. Para detener consumo al llegar al presupuesto, debe estar activado Stop usage when budget limit is reached: un presupuesto que solo envía alertas no lo bloquea.
Suspender o desinstalar la aplicación detiene su acceso, y también afecta a los demás recursos que utilizaba esa instalación. Es una decisión más amplia que apagar únicamente sus solicitudes de Copilot.
Un ejemplo hipotético, no ejecutado por Puntoes, sería un servicio nocturno que lee resultados de pruebas y pide una explicación de los fallos. La instalación de la organización aporta una identidad estable para esas solicitudes; el equipo todavía debe limitar acceso a archivos, revisar las salidas y controlar el gasto. Tampoco sustituye los permisos asistidos de Copilot, que tratan la aprobación de operaciones dentro de una sesión.