Un único mensaje de chat bastó para que un grupo de investigadores de seguridad tomara el control de todos los agentes de inteligencia artificial desplegados en una misma cuenta y región de Amazon Web Services. El hallazgo, revelado por la firma Zenity Labs, pone en el centro del debate la seguridad de las plataformas que las empresas usan para construir agentes de IA autónomos.
El descubrimiento resulta especialmente relevante porque AWS ha abierto su servicio Bedrock AgentCore a todas las empresas, y Amazon cita entre sus clientes a compañías como Sony y Ericsson. Si un agente de atención al cliente, expuesto al público, puede convertirse en la puerta de entrada hacia sistemas internos de finanzas o datos sensibles, el riesgo afecta a cualquier organización que haya adoptado esta tecnología.
Cómo un agente entregó sus propias credenciales
El fallo, que Zenity bautizó como AgentCorruption, se apoyó en el Servicio de Metadatos de Instancia que AWS mantiene en la dirección interna 169.254.169.254. Ese servicio entrega credenciales temporales a las cargas de trabajo para que puedan autenticarse, y quien logra capturarlas puede hacerse pasar por la instancia original.
Según el informe técnico de Zenity, AgentCore carecía del aislamiento necesario para impedir que un agente llegara a ese servicio. Los investigadores montaron un agente de prueba con Strands, un framework de código abierto de AWS que incluye una herramienta de navegación web, y le pidieron en lenguaje natural que consultara el servicio de metadatos y enviara el resultado a un servidor externo.
El agente obedeció sin resistencia. Los investigadores describieron que la frontera de aislamiento que esperaban encontrar simplemente no existía.
Credenciales válidas fuera de la plataforma
El servicio de metadatos devolvió las credenciales temporales completas del agente, incluidas claves y un token de sesión. Al probarlas desde su propio equipo, fuera de AWS, los investigadores confirmaron que seguían siendo válidas. A partir de ese momento, ya no necesitaban interactuar con el agente para continuar el ataque.
El mismo servicio expuso también material de certificados y claves de un servicio interno de AWS, además de una URL prefirmada de almacenamiento S3 que no pertenecía a la cuenta de los investigadores. Según Zenity, eliminar la herramienta web del agente no habría solucionado el problema, porque el defecto residía en la propia plataforma. De hecho, el ataque también funcionó a través de una herramienta de línea de comandos.
Permisos por defecto que alcanzaban toda la región
El elemento que convirtió un fallo puntual en una brecha masiva fueron los permisos predeterminados de AgentCore. Según el informe, esos permisos no se limitaban al agente que los recibía, sino que se aplicaban a todos los agentes de la misma cuenta y región, con capacidades de lectura, escritura y borrado que permitían operaciones destructivas.
Con ese nivel de acceso, los investigadores listaron todos los agentes disponibles, descargaron sus paquetes de código en cuestión de segundos e invocaron cada uno de ellos. Un script automatizado extrajo las imágenes de contenedor de todos los agentes de la región y copió su código fuente, un material que suele contener contraseñas o claves de API olvidadas por los desarrolladores.
De la atención al cliente a los datos financieros
El escenario de riesgo que describe Zenity es concreto: un atacante podía partir de un agente público de atención al cliente y saltar hasta un agente interno de finanzas, accediendo a su información. Los investigadores también leyeron conversaciones privadas entre usuarios y agentes en toda la región afectada.
En los agentes con memoria a largo plazo activada, lograron además alterar esa memoria para condicionar su comportamiento futuro. Zenity detalló en otra publicación cómo plantaron instrucciones que hacían que los agentes reenviaran conversaciones posteriores hacia un destino externo, sin que los usuarios notaran nada extraño al seguir conversando con un agente que parecía de confianza.
AWS recomienda a sus clientes guardar contraseñas y claves de API fuera de los agentes, en almacenamiento seguro. Pero según Zenity, los permisos por defecto de AgentCore anulaban esa protección al permitir que los agentes accedieran a esas credenciales, incluidas claves de servicios ajenos a AWS.
La respuesta de AWS
Zenity afirma haber comunicado los hallazgos a AWS el 25 de diciembre de 2025. Tras el aviso, AWS convirtió IMDSv2, una versión más segura del servicio de metadatos, en la opción predeterminada para los nuevos despliegues de AgentCore.
Según el relato actualizado de Zenity, hacia agosto AWS también modificó el rol de ejecución predeterminado. El nuevo rol ya no permite que los agentes invoquen a otros agentes, lean conversaciones privadas ni recuperen credenciales almacenadas en AWS Secrets Manager. AWS restringió además otros permisos, aunque los investigadores siguen recomendando que cada empresa cree roles propios con acceso más limitado.
Conviene señalar que Zenity comercializa una plataforma de seguridad para agentes de IA, por lo que tiene un interés comercial directo en este tipo de hallazgos.
El director de tecnología de la firma, Michael Bargury, resume el conflicto de fondo: la seguridad en la nube se basa en la segmentación y el mínimo privilegio, mientras que los agentes de IA necesitan libertad de acción para resultar útiles.
Un patrón ya conocido en otras plataformas
Los hallazgos de AgentCore siguen una pauta que Zenity ya había documentado en otros entornos: una entrada de apariencia inofensiva termina volviendo al agente contra su propia organización. En su investigación previa bautizada AgentFlayer, ataques sin necesidad de clic hicieron que Salesforce Einstein, Copilot Studio y Cursor desviaran datos de clientes o filtraran credenciales.
Con otro caso, denominado AgentForger, un enlace manipulado en ChatGPT bastó para crear un agente autónomo en los Workspace Agents de OpenAI con los requisitos de aprobación desactivados. OpenAI corrigió ese fallo en cuatro días, un plazo muy inferior a los meses que tardaron en resolverse los permisos excesivos de AgentCore tras el aviso de Zenity.
Sobre el riesgo de manipular la memoria de los agentes, Google DeepMind incluye esta técnica como una categoría propia dentro de su taxonomía de vulnerabilidades para agentes de IA. Según ese marco, pueden bastar unos pocos documentos envenenados en una base de conocimiento para desviar las respuestas de un sistema.
Qué revisar si usas agentes en AgentCore
Los hallazgos de Zenity dejan una serie de comprobaciones prácticas para las empresas que ya tienen agentes desplegados en Bedrock AgentCore.
Es recomendable verificar qué rol de ejecución usan los agentes existentes, ya que los creados antes de los cambios de AWS pueden conservar permisos que permiten invocar a otros agentes o leer conversaciones ajenas.
También conviene asignar a cada agente un rol propio con los permisos mínimos necesarios, en lugar de depender del rol predeterminado de la plataforma, tal como recomiendan expresamente los investigadores.
Revisar los paquetes de código en busca de contraseñas o claves de API olvidadas es otro paso clave, especialmente si esos paquetes pudieron haberse descargado durante el periodo en que las credenciales estaban expuestas.
Separar los agentes de cara al público de los que gestionan información interna reduce el riesgo de que una brecha en el primero alcance al segundo, sobre todo si comparten cuenta y región. Por último, conviene confirmar que los despliegues nuevos usan IMDSv2 y vigilar cualquier agente con herramientas web capaces de consultar direcciones internas.
Qué implica para las empresas
Aunque AWS ha endurecido los valores predeterminados de AgentCore, el cambio de roles se aplica únicamente a los nuevos despliegues, por lo que los agentes ya existentes pueden necesitar una revisión manual. Los investigadores insisten en que la defensa fiable pasa por crear roles propios y limitados, sin depender de la configuración por defecto de la plataforma.
Para cualquier empresa con agentes de cara al público, la recomendación es tratar cada mensaje recibido como una posible instrucción hostil. El caso de AgentCorruption demuestra que una sola conversación bastó para exponer conversaciones privadas, código fuente y credenciales de toda una región en AWS.
Preguntas frecuentes
¿Qué es AgentCorruption?
Es el nombre que la firma de seguridad Zenity Labs dio a una vulnerabilidad detectada en Amazon Bedrock AgentCore, que permitía tomar el control de todos los agentes de IA de una misma cuenta y región de AWS a partir de un único mensaje enviado a un agente.
¿Qué datos quedaron expuestos?
Los investigadores accedieron a conversaciones privadas entre usuarios y agentes, código fuente de los paquetes de los agentes y credenciales temporales, incluidas claves que funcionaban fuera de la plataforma de AWS.
¿AWS ya ha corregido el fallo?
AWS cambió IMDSv2 a opción predeterminada en los nuevos despliegues y modificó el rol de ejecución predeterminado hacia agosto para impedir que los agentes invoquen a otros agentes o lean conversaciones privadas, pero los agentes creados antes de estos cambios pueden seguir expuestos si no se revisan manualmente.
¿Qué empresas usan AWS Bedrock AgentCore?
AWS ha abierto esta plataforma a todas las empresas y cita entre sus clientes a compañías como Sony y Ericsson.
¿Qué deben hacer las empresas con agentes en AgentCore?
Zenity recomienda crear roles de ejecución propios con permisos mínimos para cada agente, revisar el código en busca de credenciales olvidadas, separar agentes públicos de internos y confirmar que los despliegues usan IMDSv2.
¿Zenity Labs tiene algún interés comercial en este hallazgo?
Sí, Zenity vende una plataforma de seguridad orientada a agentes de inteligencia artificial, por lo que tiene un interés comercial relacionado con este tipo de investigaciones sobre vulnerabilidades.
Samuel Gil es especialista en infraestructura tecnológica, administración de servidores y desarrollo de servicios digitales. Con una sólida trayectoria en entornos web de alta exigencia, optimización de servidores y gestión de arquitecturas de red, Samuel dedica su labor en faq-box.com a desglosar cuestiones técnicas complejas para convertirlas en guías prácticas, transparentes y de alto valor técnico.
Su enfoque editorial prioriza el rigor, la seguridad en los sistemas y la resolución eficiente de problemas técnicos cotidianos y avanzados. A través de sus análisis, busca ofrecer respuestas directas y contrastadas para profesionales y entusiastas del sector tecnológico.
Cuenta con una sólida formación en el área tecnológica, destacando su especialización a través del Máster en Inteligencia Artificial Aplicada a la Gestión Empresarial y el MBA in Digital Transformation & Artificial Intelligence de ISEEN.EU, lo que aporta un rigor técnico avanzado a cada análisis de desarrollo y arquitectura digital.
