Un equipo de investigación de ciberseguridad informó sobre una vulnerabilidad en Amazon Kiro, un IDE impulsado por IA que funciona de manera agentic. El hallazgo es relevante porque describe cómo la prompt injection en Kiro puede terminar en la exfiltración de datos sensibles hacia un punto externo, sin que el usuario tenga que redactar un prompt malicioso.
Según el reporte, el problema afecta a una versión concreta del software en Windows y no incluye identificador CVE (al menos en el momento del disclosure). A continuación, explicamos qué se vio, qué condiciones son necesarias para explotar el fallo y qué se recomienda hacer para reducir el riesgo.
Qué es la vulnerabilidad y por qué importa
De acuerdo con Mindguard, la falla se observó en Kiro IDE 0.7.45 para Windows. El investigador Fergal Glynn señaló que el error permitía que contenido de repositorios controlados por un atacante influyera en el agente de Kiro. El impacto final podía ser el envío de información local sensible a un destino externo.
El punto crítico es el “camino” que sigue la información: no se trata solo de que el modelo “obedezca” un texto. En este caso, el contenido del proyecto puede influir en operaciones internas que terminan convirtiendo datos locales en actividad de red, incluso si el usuario no solicita explícitamente que Kiro acceda o transmita esa información.
Rol de Kiro Powers y el archivo POWER.md
La publicación también pone el foco en Kiro Powers. En lugar de limitarse a “habilidades”, esta funcionalidad agrupa configuraciones y componentes como servidores basados en Model Context Protocol (MCP), archivos de direccionamiento y elementos de contexto.
Entre esos componentes destaca el archivo de direccionamiento POWER.md. La idea es que actúe como un manual de incorporación: proporciona contexto persistente e indica al agente qué herramientas MCP están disponibles y en qué situaciones conviene utilizarlas.
Si el contenido controlado por un atacante logra “interponerse” en cómo Kiro interpreta instrucciones y aplica configuraciones, el riesgo se amplifica: el agente puede leer información local y luego escribirla en configuraciones sensibles para que una capacidad posterior genere tráfico de red.
Requisitos para que el ataque funcione
Según Mindguard, la explotación requiere dos acciones del usuario, y el detalle importa porque no basta con abrir el proyecto de cualquier forma.
- El usuario debe abrir un proyecto malicioso mediante un archivo de workspace utilizando la opción File → Open Workspace From File.
- Después, debe enviar un mensaje al agente de Kiro.
En cambio, la apertura “directa” de la carpeta (en vez de hacerlo mediante el archivo de workspace) no sería suficiente para activar el flujo vulnerable, al menos en el escenario descrito.
Además, el informe afirma que el problema es reproducible tanto contra workspaces confiables como no confiables. Eso reduce el valor de la expectativa “si es confiable, no pasa nada”.
Qué ocurre durante el flujo vulnerable
Una de las piezas más inquietantes del reporte es que el usuario no tiene que introducir un prompt malicioso ni referenciar contenido controlado por el atacante. En cuanto el archivo de workspace cuidadosamente elaborado se abre, enviar cualquier mensaje puede activar la secuencia vulnerable.
Mindguard describe la falla como un fallo del límite de confianza a lo largo de toda la cadena: contenido controlado por el repositorio influye en el agente, el agente lee información local sensible, esa información se incorpora en configuraciones relevantes para seguridad del IDE y una capacidad posterior termina convirtiendo esa configuración en actividad de red.
En términos simples: la “instrucción” no tiene que ser el mensaje del usuario. Puede venir empaquetada dentro del proyecto y usarse como contexto para que el IDE ejecute rutas internas que, finalmente, facilitan la salida de datos.
Cómo encaja con el contexto de seguridad en herramientas de IA
El caso de Kiro no se presenta como un hecho aislado. Los investigadores lo enmarcan en una tendencia: los entornos de desarrollo con IA cada vez más combinan interpretación y ejecución dentro del mismo flujo de trabajo.
En ese escenario, archivos del repositorio pueden servir como fuente de contexto para el modelo, pero a la vez el agente puede leer archivos, invocar herramientas y activar funcionalidades adicionales de la aplicación. Cuando estos pasos no respetan adecuadamente los límites de confianza, surgen fallas donde el contenido “solo informativo” termina provocando acciones con impacto real.
El reporte, además, menciona que en fechas previas se observaron otros problemas en herramientas de desarrollo con IA, incluyendo vulnerabilidades que involucran prompt injection indirecta, escapes de sandbox y ejecuciones no intencionadas al interactuar con capacidades del IDE.
Versiones afectadas y corrección aplicada por Amazon
En el informe, la vulnerabilidad se asocia con Kiro IDE 0.7.45 para Windows. También se indica que la versión más reciente al momento del disclosure era 1.0.337, mientras que el fix se incorporó en Kiro IDE 0.8.140 tras el disclosure responsable.
Si usa Kiro en un entorno de desarrollo, el consejo práctico es claro: actualiza a una versión que incluya la corrección. Mantener el IDE al día es una de las medidas más efectivas cuando la superficie de ataque depende de la lógica de interpretación y de integración con herramientas.
Qué pueden hacer equipos y desarrolladores para reducir el riesgo
Más allá de instalar el parche, el caso enseña hábitos de seguridad útiles cuando trabajas con agentes de IA:
- Minimiza la exposición: evita abrir workspaces provenientes de fuentes no verificadas.
- Presta atención al modo de apertura: el reporte destaca que el flujo vulnerable requiere abrir el workspace desde archivo (File → Open Workspace From File).
- Revisa el contexto: si tu entorno usa funciones equivalentes a “powers” y archivos de direccionamiento, considera políticas internas sobre qué proyectos pueden usarse con configuraciones que otorgan herramientas.
- Observa el comportamiento: si notas actividad de red inusual o accesos inesperados al workspace, detén el trabajo y verifica la integridad del entorno.
Estas acciones no eliminan la necesidad de parches, pero ayudan a reducir la probabilidad de que un proyecto malicioso dispare una secuencia no deseada.
Conclusión
La prompt injection en Kiro descrita por Mindguard muestra cómo una cadena de interpretación y ejecución dentro de un IDE puede terminar en exfiltración de datos locales hacia un endpoint externo. Lo relevante es que el usuario no tiene que escribir un prompt malicioso: con abrir un workspace preparado y enviar un mensaje, el flujo vulnerable puede activarse.
La buena noticia es que Amazon implementó una corrección en Kiro IDE 0.8.140. El siguiente paso para reducir el impacto es actualizar y reforzar prácticas de manejo de workspaces y contextos, especialmente cuando el IDE integra herramientas y configuraciones que expanden las capacidades del agente.
Fuente: https://thehackernews.com/2026/08/amazon-kiro-prompt-injection-can.html
