La IA, en tu trabajo.

Una identidad para el servicio

GitHub anunció el 27 de octubre la preview pública de autenticación entre servidores para Copilot SDK. Los agentes y servicios pueden realizar solicitudes mediante una GitHub App instalada en una organización, sin depender de las credenciales de una persona conectada. El consumo se atribuye y factura a esa organización, cuyas políticas de modelos también se aplican.

La documentación de administración sitúa la función en Copilot Business y Copilot Enterprise, con gestión por propietarios de la organización. Esta modalidad admite instalaciones en organizaciones; quedan fuera las instalaciones en cuentas personales y en la propia cuenta empresarial. La preview está sujeta a cambios. Además, la guía técnica exige que la organización esté habilitada para esta autenticación.

Cómo se autentica una aplicación

Para servicios externos a GitHub Actions, la guía técnica indica crear una GitHub App, conceder el permiso de organización `Copilot Requests` en `Read-only` e instalarla. En el ejemplo con un proceso hijo, el token se pasa explícitamente al SDK; `useLoggedInUser: false` desactiva la búsqueda automática de credenciales.

Los tokens de instalación caducan tras una hora. La guía técnica pide renovarlos antes del vencimiento y reiniciar el cliente o el runtime, según el despliegue.

GitHub Actions dispone de otra vía con `GITHUB_TOKEN` y políticas específicas. Para la modalidad con GitHub Apps, la guía de administración aclara que no es necesario activar la política «Allow use of Copilot CLI billed to the organization».

Qué autoriza el permiso

Aunque se denomine `Read-only`, este permiso permite consumir créditos de IA, según la guía de administración.

Las acciones sobre repositorios requieren los permisos correspondientes a cada API. Autorizar solicitudes a Copilot no sustituye la autorización para leer contenido o realizar otras operaciones de la tarea.

Al generar el token de instalación, pueden restringirse sus permisos y repositorios. El token no puede obtener más acceso del concedido a la instalación.

Seguimiento por app, presupuesto de organización

La documentación presupuestaria confirma que el consumo de estas instalaciones cuenta contra el presupuesto de la organización. No existe un presupuesto individual por app o instalación. Para bloquear solicitudes al alcanzar el límite debe activarse «Stop usage when budget limit is reached»; un presupuesto configurado solo para alertar permite que el gasto continúe.

La referencia de informes define `app_client_id` como el identificador de cliente de la GitHub App asociada al consumo. Se utiliza junto con `organization` en el informe CSV de uso de IA. Puede estar vacío, por ejemplo, en consumo atribuido a usuarios, GitHub Actions o registros anteriores a la disponibilidad de esta atribución.

La guía de administración precisa que la atribución por app está disponible en los CSV, no en la vista de uso de IA de GitHub.

La gestión de instalaciones permite suspender temporalmente o desinstalar una app para bloquear su acceso a recursos de la organización. Esa retirada afecta al conjunto del acceso de la instalación.

Ejemplo hipotético: un asistente que resume cambios

Imaginemos un servicio interno que prepara resúmenes de cambios para un equipo de desarrollo. Este ejemplo editorial propone decisiones de diseño; no describe una implementación probada ni resultados medidos.

• Propósito: trabajar primero sobre un repositorio de pruebas y entregar un borrador al equipo.
• Permisos: inventariar por separado las solicitudes a Copilot, la lectura del repositorio y cualquier escritura posterior.
• Responsabilidad: asignar un equipo que mantenga las credenciales y revise el consumo atribuido.
• Contención: diseñar límites de frecuencia y una parada en el propio servicio. Serían controles de la aplicación, distintos del presupuesto organizativo de GitHub.
• Retirada: ensayar la suspensión de la instalación y revisar qué otras funciones del servicio perderían acceso.

Lectura de Nexo

Nuestra interpretación es que esta preview ofrece un punto de gobierno más claro para servicios automatizados: la instalación de la app. Su adopción debería vincular cada servicio con un equipo responsable y comprobar renovación de credenciales, atribución y retirada de acceso en un piloto. Identificar el gasto de una aplicación ayuda a supervisarla; el límite presupuestario continúa siendo compartido.