Un desconocido sin autenticar abrió un issue en un repo público de GitHub, escribió un párrafo y esperó. El agente de IA de GitHub leyó el issue, entró en los repositorios privados de la organización y publicó un README privado como comentario público. El párrafo fue el detonante. El token del agente, con alcance sobre toda la organización en lugar del único issue que tenía delante, es la razón de que la fuga llegara tan lejos.

El equipo de investigación de Noma Security montó una organización en GitHub como lo hacen hoy muchos equipos: un puñado de repositorios públicos, varios privados, y GitHub Agentic Workflows conectado para encargarse del trabajo rutinario. Los GitHub Agentic Workflows son instrucciones en Markdown plano que GitHub Actions entrega a un agente de IA, respaldado por Claude o Copilot, para que el agente pueda triar issues, responder preguntas y abrir pull requests en nombre del equipo. Después, los investigadores jugaron a ser el atacante. Abrieron un issue de aspecto ordinario en uno de los repositorios públicos, escondieron unas cuantas frases extra en el cuerpo y dejaron correr el workflow. El agente leyó el issue, obtuvo el contenido de un README.md de un repositorio privado y lo pegó en un comentario público donde cualquiera podía leerlo.

El atacante no usó contraseña, ni clave robada, ni código de exploit, y no hay CVE. Noma llama a la técnica GitLost, la reportó a GitHub y publicó con conocimiento de la empresa. Todo el payload era prosa en inglés dentro de un campo que el agente estaba construido para leer.

El issue que respondió con un repo privado.

La mecánica es corta, y eso es lo que la hace digna de dibujarse. Un workflow se dispara con un evento, como un issue que se abre o se asigna. El agente lee el título y el cuerpo del issue como su tarea. Enterradas en ese cuerpo había instrucciones que le decían al agente que obtuviera el README de un repositorio privado y lo publicara como comentario. GitHub tenía barreras delante de esto: sandboxing, tokens que por defecto son de solo lectura, limpieza de la entrada y una pasada de detección de amenazas sobre el texto. Noma probó variaciones hasta que una se coló. Anteponer a la petición maliciosa la palabra "Additionally" ("adicionalmente") fue suficiente para superar el filtro, porque el modelo la leyó como una tarea de continuación en lugar de como una petición a rechazar. Un cambio de una sola palabra llevó la inyección al otro lado de la línea.

GitLost, de principio a fin, en los servidores de GitHub. Un atacante sin autenticar abre un issue en un repo público y espera. El workflow se dispara, y el agente lee el cuerpo del issue como su tarea. Las barreras de GitHub (sandbox, token de solo lectura por defecto, limpieza de entrada, detección de amenazas) están en el camino, pero una petición con el prefijo 'Additionally' se lee como una tarea de continuación y se cuela. El agente usa entonces el token de su entorno, con acceso de lectura a cada repo público y privado de la organización, para obtener un README privado y publicarlo como comentario público. La tarea delante del agente era un issue público; el token alcanzaba toda la org.

Reformular vence al filtro.

Un filtro que lee el cuerpo del issue y decide si contiene un ataque está adivinando la intención a partir de la redacción, y la redacción tiene un suministro inagotable de variaciones. Noma no rompió el modelo ni encontró un fallo de memoria. Reformularon la misma petición hasta que el clasificador la puntuó por debajo de su propio umbral, y "Additionally" fue la redacción que aterrizó.

Esta es la propiedad estructural de los agentes que usan herramientas que describimos la semana pasada: un agente lee sus instrucciones y los datos que obtiene como una sola corriente plana de tokens, e infiere qué parte es una orden por el tono y la posición, como una persona que lee en diagonal. El cuerpo de un issue son datos. La inyección es la jugada que da a datos no confiables la forma de una orden y apuesta a que el modelo actuará sobre ella. La detección ayuda y vale la pena ejecutarla, y fallará: un clasificador tiene un umbral, y un atacante con intentos ilimitados sondea hasta que una redacción puntúa por debajo.

La brecha que dimensionó la fuga.

Una parte de GitLost sobrevive a cualquier filtro que GitHub publique después. La tarea del workflow era triar un issue en un repositorio público. El token que GitHub Actions colocó en el entorno de ese workflow tenía acceso de lectura a cada repositorio público y privado de la organización, porque los equipos conceden esa amplitud para que el agente pueda traer contexto de varios repos. El atacante eligió el objetivo; el alcance del token fijó el límite del daño. Reformula el ataque de cien maneras y ese límite sigue siendo el mismo: todo lo que el token puede ver.

La propia recomendación de Noma señala la misma costura. Su consejo a los defensores es acotar el token al único repositorio que el workflow tría en lugar de a toda la organización. Ese consejo admite que la inyección a veces aterrizará, y que cuando lo haga, el radio de daño debería tener el tamaño de la tarea y no el tamaño de la cuenta.

Alcance de la tarea frente a alcance de la credencial. La barra azul es lo que el workflow necesitaba para hacer su trabajo: leer un issue público. La barra roja es lo que podía alcanzar el token de su entorno: cada repo público y privado de la organización. La inyección eligió un objetivo en algún punto del rojo. La distancia entre las dos barras es el radio de daño, y lo fijó el token, no la redacción del ataque. Encoger la barra roja al tamaño de la azul es la defensa que aguanta sin importar qué redacción supere el filtro.

La ruta de exfiltración era el trabajo diario del agente.

El README privado salió de la organización a través de un comentario público, que es algo que el agente está supuesto a poder hacer. Comentar en issues es su función. Nada en el cable parecía un robo: ningún endpoint raro, ningún blob codificado saliendo por una puerta lateral. Un monitor de red vigilando tráfico malicioso habría visto al agente publicar un comentario, cosa que hace todo el día. Cuando el canal de exfiltración es una capacidad autorizada, la defensa que rinde es restringir lo que el agente puede alcanzar en primer lugar.

Donde tú sí puedes cambiar la arquitectura.

Dos cosas de GitLost están fuera de tu alcance. El fallo le toca a GitHub arreglarlo, y GitHub está en ello. Y el agente corría en los servidores de GitHub, dentro de GitHub Actions, donde ningún producto que instales se interpone en el camino. Bromure Agentic Coding corre en el Mac de un desarrollador. No está delante del workflow del lado del servidor de GitHub y no pretende estarlo. Si tu única exposición a esta clase de problema es un agente alojado que opera otro, la palanca que tienes es la que Noma nombró: acota el token.

La lección transferible es para el creciente número de equipos que ejecutan agentes de codificación en máquinas que controlan, donde la arquitectura es tuya para definirla. Dos principios se trasladan desde GitLost, y ninguno depende de atrapar la inyección. Mantén el entorno delgado, para que un agente secuestrado herede poco que valga la pena llevarse. Acota la credencial a la tarea, para que el alcance de un compromiso tenga el tamaño del trabajo y no el tamaño de la cuenta. Bromure Agentic Coding es una disposición concreta de esos principios.

Bromure Agentic Coding ejecuta tu agente de codificación, Claude Code, Codex o Grok, dentro de una VM Linux desechable por perfil: su propio kernel, su propio sistema de archivos, su propia pila de red, a un hipervisor de distancia de tu Mac sobre el framework de virtualización de Apple. Un perfil es un ámbito de trabajo coherente, un cliente o un servicio. Las credenciales reales nunca entran en esa VM. Bromure las guarda en el host detrás de un broker y envía al invitado valores falsos que parecen reales a las herramientas que los leen; un proxy en tu Mac sustituye el stub por el secreto real en el cable cuando la petición sale, y el sandbox que guardaba la clave recorre el mecanismo. Un agente al que convencen de ejecutar cat sobre un archivo de credenciales encuentra un marcador de posición, porque el valor que quería nunca estuvo en su lado de la frontera.

El mismo fallo, en un lugar que controlas. A la izquierda: un agente secuestrado que hereda una credencial real y amplia (la forma de GitLost) llega tan lejos como esa credencial, y por eso la fuga abarcó la org. A la derecha: el agente corre en una VM desechable por perfil, la clave real se queda en el host detrás de un broker y se sustituye en el cable, y el token que sí gasta está acotado a la tarea y expira. La inyección aún puede aterrizar; la diferencia es el tamaño del mundo en el que aterriza: el alcance de una tarea, y luego una VM que se evapora al cerrar la sesión, en lugar de una concesión permanente sobre toda la cuenta.

El token que el agente sí llega a gastar está acotado y expira, de modo que una fuga es un uso estrecho y limitado en el tiempo en lugar de una concesión permanente. Toda el área de trabajo es una VM que desaparece cuando cierras la sesión. Pasa la forma de GitLost por esa disposición y la inyección aún puede aterrizar, porque el aislamiento no des-engaña a un modelo. Un agente convencido de exfiltrar busca una credencial y encuentra un stub, gasta un token que solo cubre el único perfil en el que trabajaba, y está sentado en una caja sin camino al resto de tu máquina. El alcance del compromiso tiene el tamaño de la tarea.

Mantén el entorno delgado

Un agente secuestrado solo puede entregar lo que contiene su entorno. Stubs en el invitado y secretos reales en el host significan que la inyección que aterriza encuentra marcadores de posición donde esperaba claves.

Acota la credencial a la tarea

El consejo de Noma para los workflows de GitHub es el mismo principio: un token que cubre un repo limita el daño a un repo. El alcance y la expiración convierten una fuga en un evento estrecho y acotado en el tiempo.

Haz la caja desechable

Cuando el área de trabajo es una VM que se evapora al cerrarla, la persistencia no tiene ningún lugar duradero donde asentarse y el radio de daño termina con la sesión.

Asume que será inyectado

La detección vale la pena y fallará. Diseña para que el resultado de un fallo sea sobrevivible, en lugar de apostar a atrapar cada redacción.

Lo que esto deja en pie.

Acotar no hace que sea seguro apuntar un agente a un secreto real. Si colocas una credencial viva dentro de la VM y al agente lo convencen de leerla, ningún hipervisor la des-lee; el cambio está en lo que el agente puede alcanzar, no en si un modelo engañado deja de estarlo. El problema de exfiltración que Noma destacó tiene una pieza que el aislamiento por sí solo tampoco cierra: un agente que puede publicar un comentario, abrir un PR o enviar un mensaje puede sacar datos por ese canal autorizado, y el acotamiento decide cuántos datos están al alcance para moverlos, no si el canal existe. Y GitLost en sí pertenece a GitHub. Actualiza cuando publiquen el parche, y acota tus tokens de workflow mientras tanto, porque esa es la palanca que la plataforma te entrega.

Dondequiera que ejecutes un agente, los investigadores seguirán reportando las inyecciones, y el alcance de la credencial en el entorno del agente seguirá determinando si cada una termina como un casi accidente registrado o como un repositorio privado en una página pública. La corrección de Noma y la arquitectura de Bromure apuntan en la misma dirección: dale al agente el alcance que necesita la tarea y nada más ancho.

Bromure Agentic Coding ejecuta Claude Code, Codex y Grok en VMs Linux desechables sobre Apple Silicon, con las credenciales reales guardadas en el host detrás de un broker y sustituidas en el cable, detección de inyección de prompt sobre las entradas del agente, y cada llamada escrita en una traza que el agente no puede editar. Es gratuito, de código abierto, y está disponible hoy en bromure.io. Con agradecimiento a Noma Security, cuyo análisis de GitLost motivó este artículo.