Agentes de IA: un solo mensaje bastó para tomar el control
El 8 de octubre, la empresa de seguridad Zenity Labs mostró que un solo mensaje mandado a un agente de IA expuesto en internet alcanzaba para tomar el control de los demás agentes de esa misma cuenta en Amazon Bedrock AgentCore, el servicio de AWS para correr agentes de IA. Desde ahí se podía leer conversaciones privadas de otros usuarios, copiar el código de los agentes y sacar credenciales guardadas. AWS dice que no es una falla sino el comportamiento esperado cuando un desarrollador le da de más permisos a un agente — y ese desacuerdo es, en el fondo, el problema.

Cómo un mensaje llegó tan lejos
El ataque arrancó con algo simple: uno de los agentes tenía una herramienta para hacer pedidos web, y los investigadores le pidieron, en lenguaje natural, que consultara el servicio de metadatos de la máquina virtual donde corría — un servicio interno que entrega credenciales temporales para que el agente opere con los permisos de AWS que tiene asignados. Nada bloqueaba ese tráfico, así que el agente devolvió esas credenciales sin preguntar nada raro. Con ellas, desde su propia computadora, los investigadores listaron los demás agentes de la cuenta, invocaron algunos que no debían ser accesibles desde afuera y leyeron charlas privadas de otros usuarios con esos mismos agentes.
La parte que no se arregla con un parche: la memoria
Para no tener que repetir el ataque cada vez, los investigadores insertaron un evento falso en la memoria de largo plazo del agente — la misma función de la nota pasada, que un agente recuerde a un cliente entre charlas. El sistema lo guardó como una instrucción permanente: antes de cada respuesta, consultar una página web que ellos controlaban. Les alcanzaba con editar esa página para cambiar lo que el agente hacía, en cualquier momento, sin volver a tocar la memoria. Es la misma pieza que hace útil a un agente —que recuerde, que actúe solo— la que, mal delimitada, le da a un mensaje bien armado un lugar donde quedarse.

Qué dice AWS, y qué queda para el que arma un bot
AWS no reconoce esto como una vulnerabilidad: dice que el reporte describe "comportamiento esperado y documentado" y que un agente solo llega a otros recursos si el desarrollador le da el permiso explícitamente, con la recomendación de siempre: el mínimo permiso necesario. Zenity reportó el acceso a metadatos en diciembre de 2025 y el permiso amplio del rol por defecto (el paquete de accesos que AWS le asigna solo a un agente nuevo) en enero; en una revisión previa a esta publicación, en septiembre, confirmó que AWS lo había recortado — ya no incluye invocar otros agentes, leer conversaciones privadas ni acceder a los secretos guardados. Lo que no quedó claro es si los agentes que ya estaban corriendo antes de ese cambio lo heredaron solos.
Para un negocio chico que arma o contrata un bot —de WhatsApp, de atención, lo que sea— con acceso a una base de datos o una API, la pregunta que vale no es si la IA puede fallar: es qué puede tocar ese bot si alguien, con un mensaje bien armado en una sola conversación, consigue que haga algo que no le pidieron. Si todas las charlas comparten una única credencial con acceso a todo, ese es el límite real, más allá de qué tan bien responda el modelo.
Qué permiso tiene el bot que atiende a tus clientes
Antes de sumar un bot con acceso a tus sistemas, vale la pena mirar qué puede tocar si algo sale mal en una sola conversación.
Conocé cómo se arma la atención automática de tu negocio →