El archivo ya estaba en el disco
El 11 de septiembre AWS publicó CVE-2026-89332: un repositorio manipulado consigue que el agente de Kiro reescriba el archivo de ajustes del workspace y apunte el registro Powers al endpoint de un atacante. Kiro sí mostraba el cambio para su aprobación, con los datos insertados y la URL. La escritura ya había ocurrido, así que abrir el panel Powers antes de responder enviaba igualmente los datos del workspace. AWS dice que hay que rotar las credenciales de cualquier proyecto que abrieras con una versión anterior. En un workspace de Bromure Agentic Coding, el registro de herramientas no es un archivo que el invitado pueda escribir, la petición se topa con una regla de egreso al salir, y las credenciales que llevaría son señuelos.
El diálogo de aprobación saltó, nombró la URL del atacante y mostró los datos que iban hacia allí. Llegó después de que la escritura por la que preguntaba ya hubiera aterrizado en el disco.
Clonas un repositorio que alguien te ha enviado y apuntas el agente hacia él. Entra deslizándose una tarjeta: el agente quiere cambiar un ajuste, aquí está la línea que ha insertado, aquí está la URL. Piensas leerla. Primero pasas al panel de plugins, por curiosidad sobre lo que arrastra este proyecto, y ese clic consuma el ataque.
El 11 de septiembre, AWS publicó el boletín de seguridad 2026-111-AWS para CVE-2026-89332 en Kiro, su IDE agéntico. El registro CVE lo describe en el lenguaje plano del catálogo:
La inclusión de funcionalidad procedente de una esfera de control no confiable en la función Kiro Powers del IDE Amazon Kiro anterior a la versión 0.8.135 podría permitir a actores remotos no autenticados obtener información sensible de una estación de trabajo de desarrollo.
El registro lo puntúa con 5,5 en CVSS 3.1, AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N:
impacto alto en confidencialidad, sin impacto en integridad ni disponibilidad.
Kiro 0.8.135 lo corrige, y AWS no indica ninguna solución alternativa.
Powers, y el archivo que dice de dónde vienen
Los Powers son el formato de plugin de Kiro: un paquete de herramientas MCP, skills y conocimiento de referencia en un solo instalable. MCP es el Model Context Protocol, el enchufe que permite a un agente de programación llamar a herramientas externas y leer sus resultados. Recorres los Powers desde un registro dentro del IDE y haces clic en instalar, igual que recorrerías las extensiones.
Un ajuste nombra el registro que el IDE recorre, y en un workspace no confiable
el agente de Kiro podía escribir el archivo de ajustes del workspace. Un
repositorio manipulado lo usa para apuntar la URL del registro Powers a un
endpoint que controla el atacante. Kiro va a buscar esa URL cuando abres el panel
Powers, y la petición se lleva consigo datos del workspace: en un proyecto de
verdad, lo que haya junto al código, como el contenido de .env, claves de
acceso a la nube, tokens de API y URL de bases de datos.
Kiro ya ha pasado por aquí. En julio, una página de documentación envenenada reescribió la configuración que lanza los servidores MCP de Kiro, sin ninguna petición de aprobación. AWS añadió la petición, y el boletín de septiembre deja constancia de cómo se comportó esa petición.
Escribir primero, preguntar después
El relato que hace el boletín de la secuencia es la parte que merece la pena guardar:
Kiro presentaba el cambio al usuario para su aprobación, mostrando los datos insertados y la URL, pero el archivo ya estaba escrito en el disco, de modo que abrir el panel Powers antes de responder a la petición lanzaba la solicitud de todos modos.
El diálogo hizo su trabajo de diálogo. Mostraba los datos insertados y la URL de destino, que es todo lo que un revisor necesita para juzgar el cambio. El archivo estaba en el disco mientras la pregunta seguía abierta, así que la pregunta narraba un suceso en lugar de gobernarlo. Entre la escritura y tu respuesta hay una ventana, y dentro de ella el ajuste gobierna lo que Kiro va a buscar. Un clic en un panel dentro de esa ventana es todo el ataque.
Una petición cuya carrera se puede perder
Una petición de aprobación controla un resultado solo cuando el resultado espera tu respuesta. Comprometes el efecto primero y la petición se convierte en una notificación con botones, y cuánto te protege pasa a depender de lo rápido que leas y de lo que pulses mientras lees. Kiro escribió primero y preguntó después, que es el orden que hace que un IDE agéntico se sienta rápido. Cualquier herramienta que entregue a un agente una herramienta de escritura de archivos y atornille encima una capa de consentimiento se enfrenta al mismo trato, y los fabricantes seguirán aceptándolo.
El salto de versión cierra este caso concreto. Lo que sobrevive es dónde vive el ajuste, y qué puede alcanzar en cuanto cambia.
Dónde aterriza esa escritura en un workspace de Bromure
Bromure Agentic Coding ejecuta agentes de programación dentro de una VM Linux con virtualización por hardware en tu Mac, con los controles de seguridad en el lado anfitrión de esa frontera. Al ataque le quedan cuatro jugadas en cuanto alcanza un workspace, y a cada una responde una parte distinta del producto.
El registro de herramientas no es un archivo que el invitado pueda escribir.
En Bromure defines los servidores MCP una vez, en el panel MCP de la aplicación,
en el anfitrión. La aplicación traduce cada definición al formato de
configuración nativo del agente que esté corriendo, ~/.claude.json para Claude
Code, un bloque TOML en ~/.codex/config.toml para Codex, el archivo de ajustes
de usuario para Grok Build, y la inyecta en la VM durante el arranque. El manual
enuncia la consecuencia: añadir, editar o quitar un servidor surte efecto en el
siguiente arranque de la sesión del workspace, no en caliente dentro de una
sesión en curso. Un agente que reescriba la configuración de herramientas dentro
de la VM ha editado una copia, en una máquina que no es la tuya, y esa copia solo
se convierte en herramienta viva en un arranque de sesión que lee en su lugar la
definición del anfitrión. No se abre ninguna ventana, porque el cambio y el
efecto residen en sitios distintos. Para servidores MCP por HTTP el token también
se queda en el anfitrión, bajo un campo de credencial con el rótulo never sent
to VM, swapped by proxy.
La escritura aterriza en una VM. Cada workspace posee su propia VM Linux persistente, con su propio kernel, disco, dirección MAC y espacio de nombres de red. Un proceso de agente descontrolado puede destrozar esa VM y solo esa VM; tu Mac, tus otros workspaces y tus archivos de verdad quedan intactos, aparte de las carpetas que compartiste a propósito. El repositorio manipulado consigue modificar un archivo de ajustes en una máquina que existe para ser modificada y, si hace falta, borrada.
La petición tiene que salir. La
historia de escaneo de Vite de
ayer no tenía tramo saliente que bloquear. Esta sí: la exfiltración es una
petición corriente a un anfitrión elegido por el atacante, y para eso sirve
precisamente un cortafuegos de egreso por workspace. Guardrails aplica un
conjunto de reglas ordenado, al estilo pf, sobre cada conexión que abre la VM,
por anfitrión, IP o CIDR, protocolo, puerto, y hasta los verbos HTTP concretos
para el tráfico web, de modo que un workspace puede leer una API en la que no
tiene permiso de escritura. Bromure lo aplica en el conmutador virtual y otra vez
en el proxy, con los flujos del invitado por los puertos 80 y 443 desviados al
proxy para que nada dentro de la VM escape a la inspección. Los cambios de reglas
llegan de inmediato a las sesiones en curso. Un workspace cuyas reglas nombran tu
registro, tu forja y tu proveedor de modelos no lleva ninguna línea que diga
attacker.example.
La petición habría llevado señuelos. La expresión del boletín es
«información sensible de una estación de trabajo de desarrollo», y en un
workspace de Bromure esa información es un señuelo. Bromure sustituye cada
credencial que configuras por una falsa que preserva la estructura dentro de la
VM, derivada del valor real más una sal de 32 bytes por instalación mediante
HKDF-SHA256, conservando la forma que esperan los validadores del lado del
cliente: sk-ant-api03-brm-… para Anthropic, ghp_ más 36 caracteres para
GitHub, glpat- más 20 para GitLab, brm-k8s-… para Kubernetes, brm-db-… para
un secreto de base de datos. Esas falsas van a las variables de entorno y a
~/.git-credentials, ~/.docker/config.json, ~/.kube/config, ~/.aws/config
y las configuraciones MCP. Los valores reales permanecen cifrados en el Mac, y el
proxy del anfitrión intercambia cada uno en el cable en el último momento,
acotado al anfitrión de destino al que pertenece.
La alarma que salta con la petición misma
Los señuelos hacen un segundo trabajo. Cada falsa tiene una única familia de destinos legítimos, el ámbito de anfitrión para el que fue acuñada, así que una falsa en una petición dirigida a cualquier otro sitio significa que algo dentro de la VM está mandando una credencial fuera de la máquina. El proxy examina cada petición saliente, cabeceras y cuerpo, con un autómata de Aho-Corasick, lo bastante barato como para correr en todas.
Ante una coincidencia el proxy rechaza la petición con un HTTP 451 y no reenvía ni un byte, y luego pone la VM en pausa. Una alerta ofrece Shut down, Save for Investigation, que antes exporta el disco, la carpeta personal y las carpetas compartidas para el análisis forense, o Continue por tu cuenta y riesgo. La detección aterriza como línea roja Credential brokering en la Security Timeline, y Bromure marca el workspace como comprometido, de modo que tu próximo arranque pregunta si quieres limpiar el disco de la VM y la carpeta personal persistente conservando tus tokens, claves y ajustes. No activas nada. El detector corre por omisión.
La tarjeta de aprobación de Kiro hacía una pregunta sobre un archivo que ya había cambiado. El detector de compromiso no pregunta nada: detiene la petición en vuelo, congela la máquina que la envió, y te lo cuenta después. Las propias peticiones de consentimiento de Bromure funcionan en ese sentido. En modo Ask, el escáner de inyección de prompt retiene la petición saliente antes de que ningún byte alcance el anfitrión del modelo, los diálogos de escritura de Guardrails retienen la llamada a la API en lugar de informar de ella, y cuando conduces un workspace en remoto esas peticiones se dibujan en el anfitrión, donde un invitado comprometido no puede verlas ni falsificarlas, y donde un tiempo agotado o un descarte cuentan como denegación.
No rotar nada
La remediación de AWS tiene dos pasos. Actualizar a 0.8.135 y luego rotar las credenciales presentes en cualquier proyecto que hayas abierto con una versión anterior. El segundo paso cuesta más que el primero, y cuesta de una manera particular: no lo puedes acotar. No sabes qué repositorios estaban manipulados, ni qué clics de panel cayeron dentro de qué ventana, así que rotas lo que estaba al alcance y vuelves a autenticar las herramientas que dependían de ello.
La documentación de Bromure Agentic Coding pone el mismo pensamiento del revés: como solo se filtró la falsa, la credencial de verdad nunca necesita rotación. Mantén en el anfitrión el registro de herramientas que hace fe, ejecuta el repositorio no confiable en una máquina que puedas tirar, y llena el directorio personal de esa máquina de señuelos. Una carrera que pierdas te cuesta entonces una imagen de VM.
Instala Bromure Agentic Coding, y deja que el próximo repositorio intente reescribir un ajuste.