Inteligencia Artificial Edición diaria
INTELIGENCIA ARTIFICIAL AGENTES Y SEGURIDAD
Un repositorio no confiable podía reescribir las reglas globales de Kiro
AWS ha corregido en Kiro IDE una vulnerabilidad que permitía a un repositorio preparado alterar configuraciones globales incluso cuando el espacio de trabajo se trataba como no confiable. El fallo no convierte todos los asistentes de código en inseguros, pero demuestra que el prompt no es la única entrada que un agente debe considerar hostil.
AWS publicó el 24 de septiembre el aviso 2026-117 para Kiro IDE. La vulnerabilidad, identificada como CVE-2026-95985, afectaba a versiones anteriores a la 1.0.242 y aparecía precisamente donde el producto prometía reducir riesgo: un espacio de trabajo marcado como no confiable. Un repositorio preparado podía introducir instrucciones en el contexto del agente y conseguir que su herramienta de escritura modificara rutas globales que Kiro carga automáticamente. A partir de ahí era posible alterar el comportamiento de sesiones posteriores y, según el aviso, llegar a ejecutar comandos arbitrarios. La corrección ya existe; AWS no ofrece una mitigación alternativa.
El detalle cambia la forma de entender un repositorio. Para un IDE clásico, el proyecto contiene código que una persona abre, lee y decide ejecutar. Para un agente, también es contexto operativo: nombres de archivos, documentación, reglas, tareas y configuraciones pueden influir en su siguiente acción. Si una fuente controlada por un tercero logra escribir en el directorio que define permisos globales, el límite entre el proyecto y el usuario desaparece. La etiqueta «no confiable» conserva valor sólo cuando la infraestructura aplica restricciones que el propio contenido no puede reinterpretar.
No es el primer aviso reciente sobre esa frontera. El 11 de septiembre, AWS corrigió otro fallo de Kiro por el que un repositorio podía modificar una configuración del espacio de trabajo y apuntar el registro de extensiones a un destino externo. La interfaz mostraba la edición para aprobación, pero el archivo ya estaba en disco; abrir el panel antes de responder podía iniciar la petición. Son vulnerabilidades distintas y ambas están parcheadas. Juntas ilustran un patrón: una confirmación visible no protege si llega después del efecto que pretende autorizar.
La aprobación llega tarde si el efecto ya alcanzó la configuración que decide la confianza
Para los equipos de desarrollo, la primera respuesta es prosaica. Hay que actualizar Kiro a la versión 1.0.242 o posterior y revisar el directorio global indicado por AWS: `~/.kiro` en macOS y Linux, o `%USERPROFILE%\.kiro` en Windows, en busca de entradas no creadas por el usuario. Quien trabajara antes con repositorios no confiables debería comprobar además credenciales, reglas y conectores. La ausencia de un incidente conocido no sustituye esa revisión, aunque el boletín tampoco aporta evidencia de explotación masiva.
La segunda respuesta pertenece al diseño. Un repositorio externo debe abrirse con identidad sin privilegios, secretos ausentes, red limitada y sistema de archivos desechable. Las políticas que gobiernan comandos, conectores y rutas protegidas deberían residir fuera del alcance del agente, firmarse o compararse con una referencia inmutable. La aprobación humana debe interrumpir la cadena antes de una escritura sensible, una llamada de red o una ejecución. Después, el registro tiene que conservar qué archivo originó la instrucción, qué herramienta actuó y qué cambió realmente.
Eso no significa encerrar todo asistente en una máquina sin utilidad. El coste se controla por capas: los repositorios propios y verificados pueden usar un perfil de trabajo más amplio; un proyecto nuevo empieza en modo restringido; y una excepción concreta caduca al terminar la tarea. Los contenedores de desarrollo y las máquinas virtuales efímeras reducen el radio de impacto, pero no deben compartir el directorio personal completo ni el agente SSH del anfitrión. La comodidad de montar la carpeta del usuario es precisamente lo que vuelve global un error local.
Lo que conviene vigilar ahora es si la frontera de confianza se somete a pruebas independientes y si los complementos heredan el mismo modelo de permisos. También importa la telemetría: una organización necesita saber cuántas veces un agente intentó tocar rutas globales, qué aprobación recibió y si una actualización cambió el comportamiento. El aviso de Kiro no invalida la programación asistida. La coloca en su categoría correcta: software capaz de actuar sobre una estación de trabajo, cuya seguridad depende de permisos aplicados por el sistema y no de que el modelo recuerde obedecerlos.
La clave
Actualizar a Kiro IDE 1.0.242 o posterior cierra el fallo documentado. La lección más amplia es separar proyecto, usuario y máquina, hacer inmutables las políticas críticas y pedir aprobación antes de escribir, ejecutar o comunicar, no después.
Etiquetas
- Kiro
- seguridad de agentes
- IDEs agénticos
- CVE-2026-95985
BOLDERROR Edición diaria Rubén Campoy