El agente de IA de GitHub tiene un problema serio de prompt injection
Si usas GitHub Agentic Workflows en tu organización, vas a querer leer esto con atención. Noma Labs descubrió una vulnerabilidad que llamaron GitLost, y es de esas que te hacen repensar toda la confianza que le has dado a los agentes de IA en tu infraestructura.
La idea de GitHub Agentic Workflows es bacán: escribes tus workflows en Markdown, y un agente de IA (puede ser Claude o GitHub Copilot) lee issues, llama herramientas y responde solo. Suena eficiente, cachai. Pero el problema es que este agente lee contenido que cualquier persona puede escribir, y lo trata como una fuente confiable de instrucciones.
Cómo funciona el ataque
El investigador de Noma Labs no necesitó credenciales, acceso, ni siquiera saber programar. Solo abrió un issue en un repositorio público de una organización que usa estos workflows. En el cuerpo del issue, escondió instrucciones en inglés plano que el agente siguió sin cuestionar.
El workflow vulnerable estaba configurado para:
– Dispararse cuando se asignaba un issue
– Leer el título y cuerpo del issue
– Publicar un comentario como respuesta
– Tener acceso de lectura a otros repositorios de la organización, incluyendo los privados
El agente leyó el issue, siguió las instrucciones ocultas, fue a buscar el contenido de archivos README.md de repositorios privados, y los publicó como comentario público en el issue. Así de simple. Cero credenciales, cero exploits complejos, cero código malicioso. Solo texto bien redactado.
El detalle que me dejó pensando
GitHub tenía guardrails para evitar exactamente este escenario. Pero el investigador descubrió que usar la palabra «Additionally» en el prompt inyectado era suficiente para que el modelo restructurara su output y eludiera las protecciones. Una sola palabra. Eso me parece preocupante, porque demuestra que los modelos de IA no tienen un concepto real de límites de confianza. Siguen instrucciones, y si las instrucciones están bien redactadas, los guardrails se vuelven una sugerencia más que una barrera real.
Mi opinión
Como ingeniero de sistemas, veo esto como el equivalente a una inyección SQL pero para agentes de IA. Con SQL injection aprendimos que nunca debes mezclar datos con instrucciones. Con prompt injection estamos exactamente en la misma situación: el contenido que el agente lee es simultáneamente dato e instrucción potencial, y el modelo no distingue entre los dos.
Las recomendaciones de Noma Labs son las correctas: nunca tratar contenido controlado por usuarios como instrucción confiable, dar permisos mínimos al agente, restringir lo que puede publicar públicamente, y sanitizar el input antes de pasarlo al modelo. Pero siendo honesto, me parece que esto va a empeorar antes de mejorar. Cada vez más herramientas integran agentes de IA que leen contenido externo, y el ataque de GitLost es replicable en cualquier plataforma que haga lo mismo.
Si tienes workflows agenticos corriendo en producción, mi consejo es que revises los permisos de acceso del agente hoy mismo. No mañana. Si tu agente tiene acceso cross-repository a repos privados y puede publicar comentarios en repos públicos, tienes exactamente el mismo problema que GitHub tenía antes del reporte.
La seguridad de los agentes de IA no es un problema que se resuelve con guardrails. Es un problema de arquitectura. Y mientras la industria siga tratando el prompt injection como un edge case en vez de lo que es —una clase entera de vulnerabilidades sistemática—, vamos a seguir viendo GitLost una y otra vez con distintos nombres.
Fuente de inspiración: GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos
