Cómo un agente de GitHub filtró repos privados

Un agente de IA dentro de GitHub puede parecer una ayuda inocente: resume issues, propone cambios y acelera tareas repetitivas. El problema aparece cuando ese agente tiene acceso a contexto sensible, permisos amplios y una forma de interpretar instrucciones que no siempre distingue entre una petición legítima y un intento de manipulación.

Eso es, en esencia, lo que expone GitLost. El hallazgo muestra que un agente integrado a GitHub puede terminar funcionando como una vía de exfiltración de repos privados si alguien combina prompts cuidadosamente diseñados con permisos demasiado amplios y repositorios que contienen información sensible. No hace falta un exploit clásico; basta con mover la conversación al terreno donde la IA decide qué buscar, qué resumir y qué devolver.

Qué encontró GitLost y por qué importa

GitLost parte de una idea que ya conocemos en seguridad: si un sistema puede leer datos, también puede ser empujado a revelarlos. En este caso, el blanco no fue un servidor mal configurado ni una API expuesta, sino un agente de IA conectado al entorno de GitHub, con capacidad para interactuar con repositorios y contexto asociado.

El punto crítico no es solo que el agente “vea” información privada, sino que pueda ser inducido a tratar esa información como parte de una tarea normal. Si el modelo tiene acceso a repos privados, issues, PRs o metadatos internos, un prompt bien armado puede pedirle que busque patrones, compare archivos o resuma contenido. Si no hay controles estrictos, el resultado puede terminar fuera del perímetro esperado.

La lección para tu equipo es simple: no evalúes estos agentes solo por su utilidad. Evalúalos como cualquier otra superficie de ataque con acceso a datos sensibles. Si un bot puede leer tu código privado, también puede convertirse en un canal para sacarlo.

El mecanismo no necesita magia

No estamos hablando de un fallo de criptografía ni de una brecha en GitHub como plataforma. El riesgo aparece cuando se juntan tres piezas: un agente con permisos, un prompt que lo guía y un repositorio con datos que no debería exponer. Esa combinación basta para que un atacante intente extraer fragmentos de código, nombres de archivos o detalles internos.

En términos prácticos, el agente se comporta como un intermediario obediente. Si le pides que reviste un repo para encontrar referencias a una variable, luego que compare otro repositorio, y después que te entregue un resumen, estás empujándolo a recorrer contenido privado. El límite entre asistencia y filtración se vuelve muy fino.

Cómo funciona el riesgo de exfiltración

La exfiltración no siempre ocurre en un solo paso. En escenarios con IA, suele ser incremental. Primero se obtiene contexto, luego se confirma un patrón y, por último, se pide una salida más específica. Ese proceso puede parecer una conversación normal para el modelo, pero para seguridad es una cadena de extracción.

GitHub publica documentación sobre su ecosistema de automatización y permisos, y ahí está la pista más útil: los agentes no son omniscientes, dependen del acceso que les des. Puedes revisar la documentación oficial de permisos y automatización en GitHub para entender cómo se delimitan acciones y tokens: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication. También conviene mirar la documentación sobre GitHub Apps si tu organización usa integraciones con acceso a repos: https://docs.github.com/en/apps.

El problema es que muchas organizaciones configuran herramientas de IA con el mismo criterio con el que instalan una extensión de productividad: “si ayuda al equipo, déjala leer lo necesario”. Ese enfoque funciona hasta que el entorno incluye secretos, código propietario o documentación interna que no debería salir del perímetro.

Prompt injection en un contexto de repositorios

La prompt injection no necesita acceso al modelo base. Le basta con inyectar instrucciones dentro de contenido que el agente va a leer. En un entorno GitHub, eso puede ocurrir en un issue, un comentario de PR, un README o incluso en texto que el agente procesa como parte de su tarea.

Un ejemplo realista sería pedirle al agente que revise un PR y, dentro del texto del PR, incluir instrucciones que parecen parte de la revisión pero que en realidad le ordenan buscar archivos privados, resumirlos o exponer fragmentos. Si el agente no separa bien el contenido de usuario y las instrucciones del sistema, puede obedecer lo que no debería.

Esto no es teoría. Ya hemos visto ataques similares en asistentes de correo, navegadores y herramientas de soporte. La diferencia aquí es el valor del objetivo: código fuente, secretos operativos, documentación interna y detalles de infraestructura.

Permisos demasiado amplios

El otro lado del problema es el clásico exceso de permisos. Si el agente necesita leer un repo concreto, no debería tener acceso a todos los privados de la organización. Si solo debe comentar un issue, no debería poder listar archivos, abrir PRs o inspeccionar secretos asociados.

Cuando el control de acceso no está bien segmentado, la IA hereda el peor defecto de los bots con privilegios: hace exactamente lo que puede, no necesariamente lo que debe. Y como la IA puede convertir texto en acciones, el alcance del daño sube rápido.

La siguiente tabla resume escenarios típicos y su nivel de riesgo:

Qué parte del stack se rompe primero

Lo primero que se rompe no suele ser el modelo, sino el modelo operativo alrededor del modelo. La organización define un agente para ahorrar tiempo, pero no define con el mismo rigor qué puede leer, qué puede escribir y qué tipo de contenido debe tratar como sensible. Ahí aparece el hueco.

En GitHub, el entorno de trabajo mezcla código, discusión y automatización. Eso es útil para desarrollo, pero también significa que un atacante tiene varios puntos de entrada semánticos. Un comentario en un issue puede ser tan peligroso como un payload técnico si el agente lo interpreta como instrucción.

El error de tratar al agente como un usuario más

Un usuario humano puede sospechar de un texto raro. Un agente, si está mal diseñado, puede no hacerlo. Por eso no conviene darle el mismo trato que a un colaborador normal. Necesita límites distintos, observabilidad distinta y permisos mucho más finos.

Si tu equipo usa agentes para tareas de ingeniería, pregúntate esto: ¿el bot puede leer más de lo que necesitaría un humano para la misma tarea? Si la respuesta es sí, ya tienes una superficie de riesgo innecesaria.

El riesgo de la salida, no solo de la lectura

Mucha gente piensa en seguridad solo como “quién puede entrar”. En IA, también importa mucho “qué puede salir”. Un agente puede leer un repositorio privado y luego resumirlo de forma que revele nombres de módulos, rutas, dependencias internas o incluso fragmentos de lógica sensible.

Eso hace que el problema no sea binario. No necesitas que el bot descargue un repo completo para tener una fuga. A veces basta con que devuelva un resumen demasiado detallado o una lista de archivos que no debería haber expuesto.

Controles que sí reducen el riesgo

La buena noticia es que este tipo de riesgo se puede bajar bastante con controles concretos. No se trata de prohibir la IA en GitHub, sino de tratarla como una integración de alto riesgo y no como una ayuda más del equipo.

Empieza por el principio de mínimo privilegio. Dale al agente acceso solo al repositorio o al conjunto de recursos que necesita para una tarea concreta. Si la tarea termina, revoca el acceso o usa credenciales de corta duración. Si el flujo lo permite, separa agentes para lectura, escritura y automatización.

También necesitas separar contenido confiable de contenido no confiable. Un issue abierto por terceros no debería tener la misma autoridad que una instrucción del sistema. Y si el agente procesa texto externo, ese texto debe pasar por filtros o por una capa de validación antes de ejecutar acciones.

Checklist práctico para tu equipo

1. Limita permisos por repositorio y por tarea, no por conveniencia.
2. Revisa si el agente puede leer repos privados fuera de su alcance real.
3. Bloquea acciones de escritura si el caso de uso solo requiere lectura.
4. Separa instrucciones del sistema de contenido aportado por usuarios.
5. Registra prompts, respuestas y acciones para auditoría posterior.
6. Revisa secretos expuestos en repos antes de conectar cualquier agente.
7. Usa tokens de corta duración y revócalos cuando no se necesiten.

Si trabajas en una empresa en Ecuador o en cualquier equipo de LatAm con recursos limitados, este checklist te ayuda a priorizar sin montar un programa enorme. No necesitas empezar con un SOC de ciencia ficción. Necesitas visibilidad, permisos acotados y una política clara sobre qué datos puede tocar la IA.

Qué deberían revisar CTOs y líderes de ingeniería

Si lideras ingeniería, el problema no es solo técnico. También es de proceso. Cuando incorporas agentes, cambias la forma en que se toman decisiones dentro del flujo de desarrollo. Y si nadie revisa esa nueva capa, la organización termina confiando en un sistema que puede leer demasiado.

Lo primero es inventariar dónde están los agentes y qué credenciales usan. Muchas veces el riesgo no está en el agente principal, sino en una automatización secundaria que lo alimenta con contexto. Una integración que parece inofensiva puede terminar con acceso a varios repos privados.

Luego toca definir políticas de uso: qué tipos de repos pueden ser analizados, qué información nunca debe entrar en el prompt y qué tareas requieren aprobación humana. Si el agente va a resumir código interno, alguien debe validar que no esté filtrando más de la cuenta.

GitHub tiene documentación útil para entender la base de permisos y automatización de su plataforma. Vale la pena revisarla en paralelo con tus políticas internas, no después del incidente. Para flujos de autenticación y acceso en automatizaciones, la referencia oficial sigue siendo la mejor línea base: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication.

Tabla resumen

La lectura correcta de GitLost no es “la IA es peligrosa”. Eso sería simplificar demasiado. La lectura útil es otra: si conectas un agente a repos privados, debes asumir que cualquier texto que procese puede convertirse en una instrucción y cualquier permiso que tenga puede transformarse en una vía de salida.

Si tu organización está evaluando copilots, asistentes de código o agentes autónomos, este caso te sirve como prueba de estrés mental. Antes de activar una herramienta, pregúntate qué datos puede leer, qué puede escribir, quién la puede engañar con texto y cómo vas a detectar una fuga si ocurre. Esa conversación vale más que cualquier demo.