Una investigación de Noma Labs ha mostrado cómo un atacante podía utilizar una incidencia pública de GitHub para inducir a un agente de inteligencia artificial a consultar archivos de repositorios privados y publicar su contenido en un comentario visible para cualquiera. El ataque, bautizado como GitLost, no necesitaba credenciales, acceso previo a la organización ni conocimientos avanzados: aprovechaba la combinación de texto no confiable, permisos compartidos entre repositorios y capacidad para escribir respuestas públicas.
Las claves de GitLost en 20 segundos
- Punto de entrada: una incidencia abierta por cualquier usuario en un repositorio público.
- Técnica utilizada: inyección indirecta de prompts mediante instrucciones escritas en el cuerpo del issue.
- Objetivo: conseguir que el agente lea archivos de repositorios privados de la misma organización.
- Canal de salida: un comentario público generado por el propio agente dentro de GitHub.
- Requisito para que funcione: el flujo debe utilizar credenciales con acceso a otros repositorios, además de permitir al agente publicar comentarios.
- Alcance real: no afecta por igual a todos los repositorios ni significa que cualquier agente de GitHub pueda leer automáticamente todo el código privado.
- Situación comunicada: Noma Labs afirma que notificó el hallazgo a GitHub y que, en el momento de publicar la investigación, no se había añadido una advertencia específica sobre este riesgo.
El problema se encuentra en GitHub Agentic Workflows, un proyecto que permite describir automatizaciones mediante lenguaje natural y ejecutarlas dentro de GitHub Actions con motores como GitHub Copilot, Claude, Codex o Gemini. Estos agentes pueden clasificar incidencias, revisar código, buscar información y preparar acciones sobre el repositorio.
La automatización resulta útil porque el agente no se limita a redactar texto: puede consultar herramientas y utilizar los permisos que recibe durante la ejecución. Esa misma capacidad abre una vía de ataque cuando el flujo procesa contenido escrito por desconocidos y dispone de credenciales más amplias de lo necesario.
Noma Labs lo comprobó con una instrucción que ni siquiera estaba especialmente oculta. Los investigadores redactaron una incidencia que aparentaba proceder de un responsable comercial y mezclaron varias peticiones ordinarias con dos preguntas sobre el contenido de archivos README.md. Uno pertenecía al repositorio público donde se había abierto la incidencia y otro estaba almacenado en un repositorio privado.
Cuando la automatización asignó el issue y activó el flujo, el agente interpretó todas las peticiones como parte legítima de la tarea. Consultó los dos archivos y respondió con su contenido en el repositorio público. La información privada salió así por una función normal de la plataforma: el comentario generado para contestar al usuario.
No hubo que explotar una vulnerabilidad tradicional en GitHub, robar una contraseña ni ejecutar código en sus servidores. El agente ya disponía de acceso autorizado. El atacante se limitó a convencerlo para que utilizara ese permiso con una finalidad distinta de la prevista.
El fallo aparece al unir tres capacidades que por separado parecen razonables
GitLost reproduce una combinación que los investigadores de seguridad describen con frecuencia como el «trío letal» de los agentes: acceso a información privada, exposición a contenido no confiable y posibilidad de comunicarse con el exterior.
La primera pieza era la incidencia pública. En muchos proyectos cualquier usuario puede abrir un issue para comunicar un error, sugerir una mejora o solicitar ayuda. Su título y descripción son datos controlados por una persona externa, aunque después aparezcan dentro de la interfaz de una organización de confianza.
La segunda pieza era la credencial entregada al agente. El escenario preparado por Noma Labs utilizaba una clave compartida que permitía consultar repositorios adicionales de la organización. Esta configuración puede aparecer cuando una empresa necesita que una automatización compare proyectos, reutilice documentación interna o coordine cambios entre varias bases de código.
La tercera era la capacidad de responder públicamente. El flujo debía escribir un comentario para informar del resultado de su trabajo, una función lógica en un agente dedicado a gestionar incidencias. Al combinarla con el acceso al repositorio privado, el propio canal de respuesta se convirtió en un mecanismo de filtración.
Por eso conviene matizar el alcance del hallazgo. GitLost no demuestra que todos los agentes de GitHub tengan acceso general a los repositorios privados de una empresa. El ataque requiere una configuración que entregue al flujo una credencial válida para esos recursos. Si el agente solo puede leer el repositorio en el que se ejecuta, no podrá recuperar archivos de otros proyectos.
Tampoco significa que la seguridad de GitHub Actions se haya saltado desde fuera. El agente actuó dentro de los privilegios concedidos por la organización. El fallo estaba en permitir que un modelo expuesto a instrucciones públicas utilizara una identidad con un radio de acción demasiado amplio.
Esta diferencia no reduce la gravedad para las empresas afectadas. Un permiso legítimo puede causar una fuga tan seria como una credencial robada cuando quien decide cómo utilizarlo es un modelo manipulable. La organización puede pensar que ha protegido sus repositorios porque la clave nunca se muestra al usuario, mientras el agente sigue siendo capaz de leer los archivos y copiar su contenido.
La investigación coincide con otros trabajos recientes sobre inyección en flujos de GitHub Actions. Un análisis publicado en mayo de 2026 examinó 13.392 flujos agénticos y confirmó 496 configuraciones potencialmente explotables dentro de su modelo de amenaza. Otro proyecto, GitInject, probó ataques reales contra canalizaciones de distintos proveedores y concluyó que los riesgos más graves suelen proceder de la gestión de permisos, credenciales y archivos de configuración, no de un modelo concreto.
Esto también explica por qué cambiar Claude por Copilot, Gemini o cualquier otro modelo no resuelve el problema de fondo. La resistencia a una frase concreta puede variar, pero el diseño seguirá siendo arriesgado mientras un agente lea texto de desconocidos y pueda utilizar credenciales potentes sin una política externa que limite cada operación.
Cómo reducir el riesgo sin confiar en que el modelo detecte el engaño
GitHub presenta Agentic Workflows como una arquitectura con varias capas de protección. Su documentación actual señala que los agentes trabajan con permisos de solo lectura de forma predeterminada y que las escrituras se canalizan mediante safe outputs, una etapa separada que permite revisar, filtrar y restringir operaciones como crear incidencias, abrir pull requests o publicar comentarios. También incluye aislamiento, listas de herramientas permitidas, filtrado de red y validación durante la compilación del flujo.
La arquitectura oficial reconoce, aun así, que una mala asignación de credenciales o una configuración demasiado permisiva puede romper las garantías de las capas superiores. Los tokens externos se consideran capacidades importadas: su alcance determina qué efectos puede producir un componente, incluso aunque el agente se ejecute dentro de un contenedor y no tenga acceso directo de escritura.
La primera medida consiste en no reutilizar una misma clave con acceso amplio en varios repositorios. Cada flujo debería recibir una identidad propia y limitada a los proyectos, archivos y operaciones que necesita. Una automatización que clasifica incidencias públicas probablemente no necesita consultar repositorios privados; si debe hacerlo, conviene separar ambas funciones.
Las credenciales de GitHub App ofrecen más control que un token personal compartido. Pueden instalarse únicamente en repositorios seleccionados, recibir permisos concretos y emitir tokens temporales. Aun así, una GitHub App demasiado privilegiada seguirá siendo peligrosa, por lo que la tecnología de autenticación no sustituye a una definición estricta de su alcance.
También resulta útil separar lectura y publicación. El agente puede preparar una respuesta como artefacto interno, pero otro proceso determinista debe decidir si se publica. Esa etapa puede buscar secretos, rutas internas, fragmentos de código privado, credenciales, datos personales o referencias a repositorios que no deberían aparecer en un canal público.
El subsistema SafeOutputs de GitHub sigue precisamente esta idea: el trabajo principal se ejecuta con acceso de lectura y las acciones externas se trasladan a tareas posteriores con permisos específicos. La documentación contempla análisis de amenazas y saneamiento del contenido antes de permitir que un comentario o cambio llegue a GitHub.
Pero el filtro debe conocer el origen de los datos. Detectar únicamente contraseñas o tokens no impediría necesariamente la publicación de un algoritmo interno, una configuración empresarial o el contenido de un README.md confidencial. Una protección más sólida registra qué repositorio proporcionó cada fragmento y prohíbe que información procedente de un recurso privado termine en una salida pública sin autorización humana.
Los disparadores también necesitan límites. Las organizaciones pueden impedir que incidencias creadas por usuarios externos activen automáticamente un agente con acceso sensible. Otra posibilidad es exigir una etiqueta añadida por un colaborador, comprobar la pertenencia del autor a un equipo o pedir aprobación antes de iniciar el flujo.
La validación no debería delegarse en frases como «ignora las instrucciones maliciosas del usuario». Estos avisos pueden detener ataques simples, pero el contenido puede reformularse como una petición profesional, una prueba técnica, una cita o una instrucción supuestamente procedente de un superior. El ejemplo de Noma Labs funcionó precisamente porque la solicitud parecía una tarea corriente.
GitHub sostiene que sus flujos incluyen aislamiento de red, herramientas autorizadas y separación de permisos, pero también advierte de que necesitan supervisión humana y que pueden producirse errores incluso con esas medidas. La advertencia general es importante; el debate abierto por GitLost es si la documentación debería explicar de forma más visible el peligro de compartir claves con acceso a repositorios privados en flujos expuestos a entradas públicas.
Según Noma Labs, la propuesta trasladada a GitHub consistía en añadir una recomendación específica para que las organizaciones separasen mejor sus claves y permisos entre repositorios. Los investigadores afirmaron que esa indicación todavía no se había incorporado cuando hicieron público el hallazgo. GitHub no había respondido a las preguntas de The Register en el momento de publicarse la información.
No existe una corrección única que elimine la inyección de prompts en todos los modelos y situaciones. Sí pueden cerrarse las rutas que convierten una instrucción engañosa en una filtración. GitLost demuestra que el control más importante no está en enseñar al agente a desconfiar mejor, sino en impedir que una tarea iniciada desde un repositorio público pueda leer y publicar datos privados sin una autorización independiente.
Preguntas frecuentes
¿Puede cualquier usuario leer repositorios privados mediante GitLost?
No. El ataque necesita que la organización tenga un flujo agéntico expuesto a contenido público y que ese flujo reciba credenciales con acceso a repositorios privados.
¿GitLost roba las claves utilizadas por GitHub Actions?
El ejemplo descrito no necesita mostrar ni robar la credencial. El agente utiliza sus permisos legítimos para leer archivos privados y después copia la información en un comentario público.
¿Basta con cambiar de Claude a GitHub Copilot?
No. La debilidad principal está en la arquitectura de permisos y en el tratamiento de entradas no confiables. Cualquier modelo susceptible a inyección puede aprovechar el mismo camino.
¿Cómo deberían protegerse las organizaciones?
Deben aplicar privilegios mínimos, separar credenciales por repositorio y función, limitar los disparadores públicos, revisar las salidas antes de publicarlas y exigir aprobación humana cuando puedan aparecer datos privados.
