La empresa de seguridad Noma revelo GitLost, un fallo que permitio que un simple issue publico de GitHub enganara al agente de IA de GitHub para filtrar datos de repos privados. Segun Noma, cuyo trabajo recogieron Dark Reading, The Hacker News y SiliconANGLE, el truco no necesitaba codigo ni cuenta en el objetivo. Es un caso de manual de los riesgos de la seguridad de agentes de IA. Asi funciono.
Que son GitHub Agentic Workflows
GitHub lanzo hace poco Agentic Workflows, que combina GitHub Actions - su sistema de automatizacion - con un agente de IA impulsado por Claude o GitHub Copilot. Los equipos escriben el workflow en Markdown, y el agente lee issues, llama a herramientas y responde solo. Es un verdadero agente de codigo de IA conectado a tus repositorios.
El problema: un agente autonomo actua sobre cualquier texto que lee. Y parte de ese texto viene de fuentes publicas no confiables.
Como funciono el ataque
Segun Noma, el exploit uso inyeccion de prompt indirecta - instrucciones hostiles enterradas en el contenido que el agente lee, que el modelo luego sigue como si vinieran de su operador.
El workflow vulnerable se activaba al asignar un issue. Leia el titulo y el cuerpo, publicaba un comentario en respuesta, y corria con acceso de lectura a los repos publicos y privados de la organizacion. El ataque, paso a paso:
- Un atacante abrio un issue publico en un repo publico de la misma organizacion.
- Ocultos en el cuerpo, presentados como una peticion rutinaria de un comercial, habia comandos en lenguaje claro para el agente.
- Cuando la automatizacion de GitHub lo asigno, el agente los siguio: obtuvo archivos README de un repo publico y uno privado.
- Luego publico ese contenido privado como comentario publico legible por cualquiera.
Sin codigo de exploit. Sin login en el objetivo. Solo un issue bien redactado.
Por que importa
GitLost no es un bug en una linea de codigo. Es el riesgo central de la IA agentica: un agente con acceso amplio de lectura que ademas lee entrada no confiable puede ser dirigido por esa entrada. El modelo no distingue de forma fiable "instrucciones de mi operador" de "texto de un issue que me dijeron que leyera".
Es la misma debilidad que hay detras de la inyeccion de prompt en general, aqui apuntando a un producto real con acceso a codigo privado.
Como protegerte
- Minimo privilegio. No des a un workflow de agente acceso amplio de lectura a repos privados que no necesita.
- Desconfia de los disparadores no confiables. Cuidado con los workflows activados por issues, comentarios o pull requests publicos: es texto controlado por el atacante.
- Separa instrucciones y datos. Trata todo lo que el agente lee como datos, no comandos, y manten tu prompt de confianza aparte.
- Humano en el bucle. Exige revision antes de que un agente publique o actue sobre algo sensible.
La conclusion honesta
Dos matices. Primero, GitLost se divulgo de forma responsable a GitHub - es una debilidad demostrada, recogida por medios de seguridad, no prueba de explotacion masiva. Segundo, el arreglo no es exotico: minimo privilegio, higiene de entrada no confiable y revision humana son seguridad estandar, aplicada a una nueva superficie agentica.
La lectura honesta: los workflows agenticos son potentes porque leen tus issues y actuan sobre tus repos, y peligrosos por exactamente la misma razon. Al conectar agentes a sistemas reales, asume que cualquier texto que leen podria ser una instruccion, y limita lo que pueden alcanzar. Para elegir de entrada modelos capaces y bien portados, nuestro resumen de mejores LLM de codigo 2026 ayuda.
