GitLost demuestra que tu agente de IA no necesita ser hackeado para filtrar tus datos
Un atacante no necesitó una contraseña robada, ni un correo de phishing, ni una cadena de exploits para extraer código fuente confidencial de una organización de GitHub. Una sola frase, escrita en un Issue público de GitHub, fue suficiente. Los investigadores de seguridad de Noma Labs revelaron la falla el 6 de julio de 2026 y la llamaron GitLost. Se encuentra en los Agentic Workflows de GitHub, que combinan GitHub Actions con un agente de IA respaldado por Claude o GitHub Copilot, y no es un bug en el sentido tradicional. Es una demostración de lo que ocurre cuando a un agente de IA se le otorga más acceso del necesario para una sola tarea y luego se le pide leer contenido que nadie revisó.
Así de simple: el agente no fue hackeado. Hizo su trabajo. Leyó un Issue, siguió las instrucciones incrustadas en ese Issue y usó la herramienta que tenía —publicar un comentario público— para entregar a un desconocido el contenido de un repositorio privado. Dark Reading informó que GitHub actualizó su documentación en respuesta. Noma afirma que la falla de diseño subyacente seguía activa al momento de la publicación.
Esa diferencia importa más que la vulnerabilidad en sí. Los equipos de seguridad llevan dos décadas construyendo detección alrededor del acceso no autorizado —credenciales robadas, escalamiento de privilegios, movimiento lateral. GitLost evitó todo eso. El agente estaba autorizado. Hacía exactamente lo que debía hacer. Simplemente, no debía poder llegar a donde llegó.
Puntos Clave
1. Una frase, cero credenciales.
Noma Labs, el brazo de investigación de Noma Security, exfiltró datos privados de repositorios de GitHub ocultando una instrucción en inglés sencillo dentro de un Issue público —sin comprometer cuentas, sin malware ni habilidades de programación.
2. El control falló por una palabra.
Anteponer la instrucción inyectada con «Additionally» fue suficiente para que el agente de IA de GitHub tratara el secuestro como una tarea legítima en vez de una amenaza a rechazar.
3. El problema fue el acceso, no la inteligencia.
El agente comprometido tenía acceso de lectura permanente a todos los repositorios públicos y privados de la organización para completar una tarea de triage de un solo Issue. Esto es una exposición de propiedad intelectual a escala organizacional, no una vulnerabilidad puntual.
4. Este es el patrón dominante ahora, no un caso aislado.
El GenAI Security Project de OWASP vincula la inyección de prompts con seis de las diez categorías de su Top 10 para aplicaciones agenticas y la identifica como la principal causa de fallos de seguridad en IA agentica en producción.
5. La mayoría de las organizaciones ni siquiera ve la brecha, mucho menos la cierra.
Investigaciones de Cloud Security Alliance encontraron que menos de una de cada cuatro organizaciones tiene políticas documentadas de gobernanza de identidad de IA, y solo el 12% confía mucho en poder detener un ataque dirigido a una identidad no humana. Un análisis de riesgos formal que compare el alcance de acceso actual de cada agente de IA con el mínimo necesario para su tarea asignada es el punto de partida para cerrar esta brecha.
¿Qué Ocurrió? Así Fue la Cadena de Ataque de GitLost
El flujo de trabajo que Noma Labs apuntó era común. Se activaba cuando se asignaba un Issue, leía el título y el cuerpo del Issue, y publicaba una respuesta usando la herramienta de comentarios del agente. Para hacer ese trabajo, funcionaba con acceso de lectura a todos los demás repositorios de la organización —públicos y privados.
Un atacante sin credenciales, sin acceso a repositorios y sin habilidades de programación abrió un Issue público que parecía una solicitud interna rutinaria. Oculta en el cuerpo había una instrucción en inglés sencillo, ordenando al agente obtener un archivo de un repositorio privado y pegar su contenido en un comentario público. Cuando se asignó el Issue, el agente leyó el texto, trató la instrucción incrustada como parte legítima de su tarea, recuperó el archivo privado y lo publicó públicamente. El proof of concept de Noma extrajo datos privados de repositorios de esta manera en cuestión de minutos.
Sin malware. Sin exploit. Sin apropiación de cuenta. Solo lenguaje, dentro de contenido que el agente estaba diseñado para leer como parte de su trabajo normal.
Esa es la parte que todo CISO debe considerar. No fue un fallo de los controles de acceso en el sentido habitual. El agente tenía el acceso para el que fue configurado. El error estuvo en lo que «configurado para tener» se permitió significar. Cada archivo privado de repositorio que un agente puede alcanzar sin una verificación de autorización por solicitud es potencialmente un vector de exfiltración —la clasificación de datos aplicada al contenido del repositorio al menos permitiría identificar qué activos implican mayor exposición regulatoria o competitiva si se filtran.
El Control Falló por una Palabra
GitHub tenía controles diseñados específicamente para evitar esto. Los investigadores de Noma probaron el flujo de trabajo como lo haría un atacante, iterando la redacción hasta que algo funcionó. Lo que funcionó fue casi insultantemente simple: anteponer la instrucción inyectada con la palabra «Additionally».
Léelo de nuevo. Una palabra, elegida porque reformulaba el intento de secuestro como una tarea rutinaria, bastó para que el modelo cumpliera en vez de rechazar.
Esto debería preocupar a cualquiera que confíe su programa de seguridad de IA en filtros a nivel de prompt. Una defensa que puede ser burlada con una sola conjunción no es una defensa. Es un tope, y los topes no detienen a atacantes que pueden iterar gratis, en privado, todo el tiempo que quieran, hasta que algo pase.
La Inyección de Prompts Ya No Es un Riesgo Teórico
GitLost no es una excepción. Es el patrón. El State of Agentic AI Security and Governance versión 2.01 del GenAI Security Project de OWASP vincula la inyección de prompts con seis de las diez categorías de su Top 10 para Aplicaciones Agenticas —y según informes de Help Net Security sobre los hallazgos de 2026 del grupo, el informe identifica la inyección de prompts como la principal causa de fallos de seguridad en IA agentica actualmente en producción.
La causa raíz es arquitectónica, no una brecha de entrenamiento que mejores modelos terminarán cerrando. Los modelos de lenguaje procesan el prompt del sistema, la solicitud del usuario y cualquier texto recuperado de fuentes externas como un solo flujo de tokens. No existe un mecanismo confiable para marcar algunos de esos tokens como comandos confiables y otros como datos no confiables. Una frase hostil oculta en un Issue de GitHub, una invitación de calendario o un correo de cliente tiene exactamente la misma autoridad para el modelo que una instrucción de su operador real.
Esa única realidad arquitectónica es la razón por la que «solo escribe un mejor prompt de sistema» sigue fallando como estrategia, incluido GitLost.
Las pruebas no se limitan a GitLost. Investigadores revelaron el CVE-2025-6514, una falla de ejecución remota de código con una puntuación de 9.6 en la escala CVSS, en un paquete Model Context Protocol ampliamente usado, después de quince versiones limpias antes de añadir silenciosamente una línea de código de exfiltración, según los hallazgos citados por OWASP y cubiertos por Help Net Security. Por separado, el CVE-2026-22708 contra el agente de codificación Cursor mostró que un atacante que envenena el entorno de ejecución del agente puede convertir sus propios comandos permitidos en un mecanismo de entrega de cargas arbitrarias —la lista blanca facilitó el ataque, no lo dificultó, porque aprobaba automáticamente los comandos que el atacante necesitaba. El CVE-2025-59532 contra Codex CLI de OpenAI demostró que la propia salida del agente podía redefinir el límite de su sandbox.
Tres proveedores distintos, tres mecanismos diferentes, una causa raíz compartida: un agente confió en contenido o comandos que debió tratar como hostiles, y nadie limitó su acceso lo suficiente como para contener las consecuencias cuando lo hizo. Una filtración de datos atribuible a cualquiera de estos vectores implica las mismas obligaciones regulatorias de notificación que una filtración de credenciales —el canal de exfiltración es IA, pero el reloj de cumplimiento corre desde el descubrimiento en ambos casos.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Lee ahora
La Vulnerabilidad Real Es el Acceso Permanente, No el Comportamiento del Modelo
Aquí es donde se pone incómodo. El instinto de la industria de la seguridad tras un incidente como este es interrogar al modelo: por qué cayó ante «Additionally», qué filtro debió detectarlo, qué proveedor lo parchea primero. Ese instinto trata el síntoma como si fuera la enfermedad.
El agente de GitLost solo necesitaba permiso para leer un Issue en un repositorio para hacer su trabajo. Tenía acceso de lectura permanente a todos los repositorios de la organización, públicos y privados, indefinidamente. Esa brecha entre lo que una tarea requiere y lo que se le otorga a una identidad fue la que causó el verdadero daño. La inyección de prompt solo fue el detonante.
Llámalo como es: el agente con acceso total. Las organizaciones están aprovisionando agentes de IA igual que los departamentos de TI aprovisionaban cuentas de servicio en 2005 —amplio, permanente, rara vez revisado— pero ahora esas credenciales están detrás de un sistema que puede ser convencido de usarlas por cualquiera que escriba una frase.
El informe de Cloud Security Alliance sobre el estado de la identidad no humana y la seguridad de IA pone cifras exactas a cuán extendida está esa brecha. Menos de una de cada cuatro organizaciones tiene políticas documentadas y formalmente adoptadas para crear o retirar identidades de IA. Solo el 12% reporta alta confianza en su capacidad para prevenir un ataque lanzado a través de una identidad no humana. Más del 16% ni siquiera rastrea cuándo se crean nuevas identidades relacionadas con IA.
Doce por ciento. Eso no es un error de redondeo en un modelo de madurez. Es casi nueve de cada diez líderes de seguridad admitiendo, cuando se les pregunta directamente, que no podrían detener esto si les ocurriera mañana. Los programas de gestión de riesgos de la cadena de suministro que gobiernan el acceso de proveedores humanos pero no incluyen las identidades de agentes de IA aprovisionadas por esos mismos proveedores están ignorando la población de identidades no humanas de mayor crecimiento en la empresa.
Por Qué los Controles Solos Seguirán Fallando
Hay dos respuestas intuitivas a GitLost, y ambas son incorrectas.
La primera es bloquear la IA agentica por completo hasta que la tecnología madure —congelar los Agentic Workflows de GitHub, congelar las integraciones de Copilot, esperar a que los proveedores lo resuelvan. Eso sacrifica la productividad real que un agente gestionando Issues 24/7 aporta, y no resiste la presión del mercado competitivo. Los equipos de ingeniería a los que se les diga que no buscarán una alternativa, sea aprobada o no. Esa alternativa es IA en la sombra —agentes no gobernados operando fuera del perímetro de políticas, sin trazabilidad ni revisión de alcance de acceso.
La segunda es confiar en el modelo. Enviar mejores prompts, suscribirse a la última actualización de controles del proveedor, tratar «Additionally» como un bug puntual que la próxima versión del modelo detectará. El informe State of AI Agent Security 2026 de Gravitee muestra exactamente cómo va esa apuesta: el 88% de las organizaciones que ejecutan agentes de IA en producción confirmaron o sospecharon un incidente de seguridad relacionado en el último año, incluso cuando el 82% de los ejecutivos afirmaron que sus políticas actuales ya los protegen de acciones no autorizadas de agentes.
Ambas cosas son ciertas. Al mismo tiempo. Los ejecutivos creen estar cubiertos. Los datos de incidentes dicen lo contrario. Esa brecha entre confianza y realidad es donde prosperan los ataques tipo GitLost, y ningún nivel de ingeniería de prompts la cierra, porque el control está en la capa equivocada.
La solución no es ni bloquear la IA ni confiar ciegamente en ella. Es tratar el acceso de los agentes igual que los equipos de seguridad ya tratan el acceso humano, y la mayoría simplemente no lo ha hecho aún.
La Brecha de Gobernanza Oculta Tras la Adopción de Agentes de IA
Cada organización que ejecuta un agente de IA sobre sus propios datos ya tomó una decisión implícita sobre cuánto puede ver ese agente. Casi ninguna la tomó de forma deliberada.
El acceso permanente, amplio y rara vez auditado es la norma no porque alguien lo eligió, sino porque limitar el acceso por tarea requiere más trabajo que aprovisionarlo una vez y olvidarse. Es el mismo atajo que produjo permisos excesivos en cuentas de servicio, roles IAM olvidados y las integraciones de terceros que nadie recuerda haber autorizado. La IA agentica simplemente se mueve más rápido, toca más sistemas y —como muestra GitLost— puede ser dirigida por cualquiera que escriba una frase en un foro público.
Las propias recomendaciones de Noma para desarrolladores dejan clara la prioridad: nunca trates contenido controlado por el usuario como instrucción confiable, restringe lo que cualquier agente puede publicar públicamente y —en primer lugar— limita los permisos al mínimo que la tarea requiere. Dos de esas tres recomendaciones no tienen nada que ver con el modelo. Son sobre gobernanza de datos, simple y llanamente. La minimización de datos aplicada al alcance de acceso de agentes de IA —aprovisionando a cada agente solo con acceso de lectura a los repositorios, archivos o tipos de datos específicos que requiere su tarea asignada— es la implementación operativa de ese principio de gobernanza.
Los reguladores tampoco están esperando a que la industria lo resuelva a su ritmo. El informe de OWASP rastrea 42 instrumentos regulatorios distintos en 10 jurisdicciones que ya abordan la respuesta a incidentes de IA, y varios establecen ventanas de notificación medidas en horas, no en trimestres. Una organización que no puede responder «¿a qué podía acceder este agente?» el día de un incidente no lo responderá lo suficientemente rápido para satisfacer a un regulador, ni mucho menos a un cliente. Un plan de respuesta a incidentes documentado que cubra explícitamente escenarios de exfiltración por agentes de IA —incluyendo guías para el escenario «el agente publicó datos privados públicamente» que demostró GitLost— convierte el caos post-incidente en una respuesta practicada y acotada en el tiempo.
Cómo Cerrar la Brecha: Acceso de Agentes de IA Limitado y Gobernado
Deja de preguntarte si tu modelo es lo suficientemente inteligente para resistir instrucciones maliciosas. Esta es la pregunta realmente importante: si este agente es secuestrado ahora mismo, ¿a qué podría acceder realmente?
Para responder eso se necesitan cuatro controles específicos, no un compromiso vago con la «gobernanza de IA».
- Limita el acceso por tarea, no por identidad. Un agente que gestiona un Issue no necesita visibilidad permanente a todos los repositorios privados de la organización. Las políticas de control de acceso basado en roles y control de acceso basado en atributos que evalúan cada solicitud según clasificación, sensibilidad y contexto —en vez de otorgar un permiso amplio de una sola vez— reducen el radio de impacto a lo que esa tarea realmente requiere. Es la misma disciplina de mínimo privilegio aplicada a cuentas humanas durante dos décadas, finalmente extendida a las identidades que ya las superan en número.
- Aísla las credenciales de la capa de razonamiento. Los tokens que usa un agente para actuar deben estar en un llavero o bóveda que el modelo de lenguaje nunca vea. Kiteworks construyó su Secure MCP Server precisamente bajo este principio: las credenciales OAuth se almacenan en el almacén de credenciales del sistema operativo y nunca están disponibles en el contexto del LLM, así que un agente secuestrado no puede extraer las llaves para ir más allá de lo que la sesión actual ya permite.
- Gobierna la capa de datos independientemente de lo que el agente diga sobre su intención. El propósito declarado de un agente no es un control de seguridad —es una sugerencia generada por el propio agente. Kiteworks Compliant AI aplica decisiones de política RBAC y ABAC en la capa de contenido para cada solicitud de IA, evaluada en tiempo real, sin importar lo que el razonamiento del agente concluya que debería poder hacer. El CISO Dashboard muestra cada evento de acceso a datos de IA en tiempo real, dando a los equipos de seguridad la visibilidad necesaria para detectar actividad anómala de agentes antes de que se complete una exfiltración.
- Asume que el canal de exfiltración será cualquier herramienta legítima que ya tenga el agente, y audita en consecuencia. GitLost no necesitó una capacidad nueva. Reutilizó la publicación de comentarios, una función que el agente debía usar. Registros auditables completos e inviolables de cada archivo que tocó el agente y todo lo que publicó convierten un incidente en una consulta forense de cinco minutos, y marcan la diferencia entre adivinar lo que hizo un agente y poder demostrarlo. Alimentar esos registros en tiempo real a una plataforma SIEM da a los equipos de seguridad el motor de correlación necesario para detectar patrones de exfiltración en varios pasos que un solo registro de auditoría no mostraría.
Nada de esto evita que ocurra la inyección de prompts. Nada en el mercado actual lo hace de forma confiable. Lo que determina si una inyección se convierte en una filtración no es si el modelo fue engañado. Es si el agente que cayó tenía acceso a algo que valiera la pena robar.
¿Qué Hacer el Lunes por la Mañana?
Deja de debatir qué proveedor de IA tiene mejores controles. Empieza a auditar a qué pueden acceder realmente tus agentes actuales.
Extrae la lista de permisos de cada agente de IA o flujo de trabajo automatizado con acceso a tus repositorios, almacenes de archivos o entorno de intercambio de datos de confianza cero. Para cada uno, anota lo que se supone que debe hacer el agente y compáralo con lo que realmente está autorizado a tocar. Donde esas dos listas no coincidan, tienes un GitLost esperando a ocurrir.
Luego corrige la brecha en la capa de acceso, no en la de prompts. Limita los permisos a la tarea. Aísla las credenciales de todo lo que el modelo pueda ver o influir. Haz que cada solicitud de datos impulsada por IA pase por una política de control que no dependa de lo que el agente diga que quiere hacer. Registra todo como si un auditor fuera a pedirlo, porque tarde o temprano lo hará.
Las organizaciones que sufran la próxima versión de GitLost serán las que sigan discutiendo qué modelo es más seguro, en vez de preguntarse a qué nunca debieron poder acceder sus agentes.
Para saber más sobre cómo gobernar el acceso a datos de agentes de IA antes de que un incidente tipo GitLost afecte a tu organización, solicita una demo personalizada hoy.
Preguntas Frecuentes
GitLost es una falla de inyección de prompts revelada por Noma Labs el 6 de julio de 2026 en los Agentic Workflows de GitHub. Un atacante oculta instrucciones en inglés sencillo dentro de un Issue público de GitHub; cuando un agente de IA con acceso de lectura permanente a los repositorios de la organización procesa ese Issue, sigue las instrucciones ocultas y publica datos privados del repositorio como comentario público. No se requieren credenciales, malware ni habilidades de programación. Las organizaciones que evalúan estrategias de protección de datos de IA deben tratar esto como representativo de una clase de riesgo más amplia, no como un bug aislado de GitHub. Un análisis de riesgos que compare el alcance de acceso actual de cada agente de IA con el inventario de tareas asignadas es el paso fundamental —las organizaciones que no lo hayan realizado no pueden responder con precisión «¿a qué podían acceder nuestros agentes?» ante una consulta regulatoria o una obligación de notificación a clientes.
Los investigadores de Noma descubrieron que anteponer la instrucción inyectada con la palabra «Additionally» hizo que el modelo reinterpretara el secuestro como una tarea legítima en vez de una instrucción a rechazar. Los filtros a nivel de prompt operan sobre la redacción, y la redacción puede reformularse infinitamente —un filtro ajustado para detectar la frase de hoy fallará ante el sinónimo de mañana. Por eso los principios de arquitectura de confianza cero, que asumen que cualquier solicitud puede ser hostil sin importar la redacción, importan más que una mejor detección de palabras. La clasificación de datos aplicada al contenido que un agente puede recuperar no evita la inyección, pero limita qué activos clasificados quedan dentro del radio de impacto —un agente que solo puede acceder a contenido público no puede exfiltrar código fuente confidencial sin importar las instrucciones que reciba.
No es un caso aislado. El GenAI Security Project de OWASP vincula la inyección de prompts con seis de las diez categorías de su Top 10 para aplicaciones agenticas y la identifica como la principal causa de fallos de seguridad en IA agentica actualmente en producción, según el informe de junio de 2026 de Help Net Security sobre los hallazgos del grupo. El informe State of AI Agent Security 2026 de Gravitee encontró por separado que el 88% de las organizaciones que ejecutan agentes de IA en producción confirmaron o sospecharon un incidente de seguridad relacionado en el último año, por lo que los programas de protección de datos de IA ya no pueden tratar la inyección de prompts como un caso marginal. Las organizaciones sujetas a obligaciones de cumplimiento normativo —HIPAA, CMMC, GDPR— deben tratar la inyección de prompts identificada por OWASP como un riesgo documentado que sus programas de gobernanza de IA deben abordar, no como un bug de proveedor que se puede posponer hasta que llegue un parche.
Limita el acceso de cada agente a la tarea específica que realiza en lugar de otorgar permisos permanentes a toda la organización. Aísla las credenciales que usa el agente del contexto del modelo de lenguaje para que un agente secuestrado no pueda extraerlas. Aplica decisiones de política RBAC y ABAC en la capa de datos para cada solicitud, independientemente de lo que el agente declare como intención, y mantén registros auditables completos de lo que cada agente accedió y publicó. Este es el modelo detrás de Kiteworks Compliant AI y el Kiteworks Secure MCP Server. Las organizaciones también deben documentar un plan de respuesta a incidentes que cubra específicamente el escenario «el agente de IA publicó datos privados públicamente» —el reloj de notificación, los pasos de evaluación de alcance y la secuencia de comunicación deben estar definidos antes del incidente, no durante.
El informe de Cloud Security Alliance sobre el estado de la identidad no humana y la seguridad de IA encontró que menos de una de cada cuatro organizaciones tiene políticas documentadas y formalmente adoptadas para crear o retirar identidades de IA, y solo el 12% reporta alta confianza en su capacidad para prevenir un ataque dirigido a una identidad no humana. Más del 16% no rastrea la creación de nuevas identidades relacionadas con IA, dejando una población creciente de agentes prácticamente invisible para los programas de gobernanza de datos diseñados para cuentas humanas. Las organizaciones deben extender sus prácticas de gestión de riesgos de la cadena de suministro para cubrir identidades de agentes de IA aprovisionadas por proveedores externos —el agente de IA de un proveedor operando en tu organización de GitHub con permisos amplios y permanentes es un riesgo de cadena de suministro que la mayoría de los marcos actuales de gobernanza de proveedores no abordan explícitamente.
Recursos adicionales
- Artículo del Blog
Estrategias de confianza cero para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones está fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.