)
Última actualización: 6 de noviembre, 2026
¿Qué nivel de seguridad ofrece Amazon Bedrock AgentCore a los agentes de IA de una empresa? AgentCore da a quien construye en AWS buenas piezas: aislamiento de sesiones en microVMs, credenciales gestionadas y políticas deterministas sobre las llamadas a herramientas. En 2026 también mostró dónde acaba el modelo: unos investigadores hallaron un canal DNS en el modo Sandbox de Code Interpreter y se parchearon dos CVE de inyección de comandos en el SDK. Con la responsabilidad compartida, las sesiones, los roles IAM, las políticas y las amenazas de prompt siguen siendo cosa tuya.
TL;DR: puntos clave
- Veredicto: AgentCore encaja bien en proyectos nativos de AWS, y quien ejecuta agentes en varias nubes y on-premises suele sumar 1 control independiente como TrustGate (Agent Gateway).
- BeyondTrust Phantom Labs informó en marzo de 2026 de que el modo Sandbox permitía consultas DNS públicas, y asegura que AWS corrigió el túnel DNS el 15 de abril de 2026.
- 2 boletines de AWS cubren la inyección de comandos en el helper install_packages() del SDK: 2026-044-AWS (17 de junio) y 2026-065-AWS (23 de julio). Actualiza a bedrock-agentcore 1.18.1 o posterior.
- AWS afirma que AgentCore no impone el vínculo entre sesión y usuario, y las sesiones pueden durar hasta 8 horas.
- Las puntuaciones de guardrails en Policy tienen 6 niveles, de 0 a 1,0, y no son deterministas, a diferencia de las decisiones de la política.
De un vistazo: controles de seguridad de AgentCore
Respuesta rápida
¿Es AgentCore lo bastante seguro para agentes de IA empresariales?
AgentCore ofrece una seguridad de infraestructura sólida en AWS, con una microVM dedicada por sesión, credenciales gestionadas y políticas deterministas sobre las llamadas de Gateway. Con el modelo de responsabilidad compartida, a ti te toca el vínculo entre sesión y usuario, los roles IAM, las políticas, las versiones del SDK y las amenazas de prompt. Con agentes en varios entornos, suele hacer falta una capa independiente.
| Servicio | Qué hace | Seguridad incluida | Qué sigue siendo tuyo |
|---|---|---|---|
| Runtime | Runtime serverless para agentes y herramientas | Una microVM dedicada por sesión, saneada al terminar | Vínculo sesión-usuario, rol de ejecución y validación de entradas |
| Gateway | AI gateway gestionado para herramientas, agentes y modelos | Autenticación de entrada y salida, almacén de credenciales | Endurecer los targets y el código de interceptores |
| Policy | Reglas para cada llamada a herramientas que pasa por Gateway | Decisiones deterministas de permitir o prohibir | Escribir, probar y mantener las políticas |
| Identity | Identidad y credenciales gestionadas para agentes | SigV4, flujos OAuth 2.0 y claves de API | Configurar el proveedor y los scopes de los tokens |
| Code Interpreter | Ejecución de código en sandbox para agentes | Modos de red Sandbox, Public y VPC | Modo de red, rol de ejecución y versión del SDK |
| Memory | Memoria a corto y largo plazo de los agentes | Cifrado de la memoria almacenada | Qué pueden escribir y leer los agentes |
Cómo comparamos
El 6 de noviembre de 2026 releímos las páginas de la Amazon Bedrock AgentCore Developer Guide sobre Runtime, Gateway, interceptores, Policy y Code Interpreter, además de dos boletines de seguridad de AWS y dos análisis de BeyondTrust Phantom Labs. No desplegamos AgentCore. Citamos estas páginas por su título, sin enlace, según nuestra política sobre enlaces a proveedores externos.
Qué cambió en la seguridad de AgentCore en 2026
Tres hechos marcaron la seguridad de AgentCore en 2026: un hallazgo de DNS en el modo Sandbox de Code Interpreter, dos CVE de inyección de comandos en el SDK de Python y nuevos controles de AWS para Runtime y Policy. AWS corrigió o documentó cada uno. Todos caen del lado del cliente en la división de la responsabilidad compartida.
| Fecha (2026) | Hecho | Fuente | Tu acción |
|---|---|---|---|
| 16 de marzo | El modo Sandbox permitía consultas DNS públicas; corregido el 15 de abril | BeyondTrust Phantom Labs | Inventariar los modos de red |
| 17 de junio | CVE-2026-12530, corregido en el SDK 1.6.1 | Boletín de AWS 2026-044-AWS | Actualizar el SDK |
| 30 de junio | MMDSv2 obligatorio en Runtime | Documentación de Runtime de AWS | Revisar cada runtime |
| 23 de julio | CVE-2026-16796, corregido en el SDK 1.18.1 | Boletín de AWS 2026-065-AWS | Actualizar a 1.18.1 o posterior |
El hallazgo de DNS en Sandbox
El 16 de marzo de 2026, BeyondTrust Phantom Labs mostró que Code Interpreter en modo de red Sandbox aún podía enviar consultas DNS públicas. Un atacante con ejecución de código dentro del intérprete podía usar ese canal para mando y control o para sacar datos.
Según BeyondTrust, AWS puntuó primero el informe con CVSS 7,5, lo trató como comportamiento previsto y actualizó su documentación. La actualización de BeyondTrust del 22 de abril dice que AWS corrigió el túnel DNS el 15 de abril de 2026. La documentación actual de AWS lista tres modos de red: Sandbox (acceso limitado a servicios de AWS como Amazon S3), Public y VPC. Para cargas sensibles, BeyondTrust recomienda el modo VPC con Route 53 Resolver DNS Firewall.
Los CVE de inyección de comandos en el SDK
AWS publicó 2 boletines sobre el SDK de Python open source bedrock-agentcore. El CVE-2026-12530 (2026-044-AWS, 17 de junio) afecta a las versiones desde la 1.1.3 hasta la anterior a la 1.6.1. El helper install_packages() usaba una lista de bloqueo incompleta para los nombres de paquete, así que argumentos manipulados como los flags --index-url y -r de pip lograban pasar.
El CVE-2026-16796 (2026-065-AWS, 23 de julio) afecta a todas las versiones anteriores a la 1.18.1. Según AWS, podría permitir que un usuario autenticado de forma remota ejecute comandos arbitrarios dentro del sandbox del intérprete. BeyondTrust, que publicó su análisis el 28 de septiembre, sitúa ambos CVE en CVSS 3.1 7,3 y CVSS 4.0 8,4. AWS los gestionó mediante divulgación coordinada y la solución es actualizar. Su medida alternativa es no pasar a install_packages() cadenas aportadas por usuarios ni generadas por modelos.
El impacto depende de lo que alcance el intérprete. BeyondTrust señala que un rol asociado al intérprete expone sus credenciales al código que se ejecuta dentro, y que los registros de CloudTrail de InvokeCodeInterpreter no incluyen parámetros de la petición, así que los comandos solo aparecen en los logs de Observability. Nuestra guía sobre logs de auditoría MCP explica qué debe contener un buen registro.
)
Qué controles de AgentCore gestiona AWS y cuáles te tocan
AWS protege la infraestructura que ejecuta AgentCore y tú proteges lo que construyes encima. La documentación de AWS (2026) describe la seguridad como una responsabilidad compartida, dividida en seguridad de la nube y seguridad en la nube. Los agentes añaden tareas nuevas a tu lado de esa división.
AgentCore no es un solo producto. La visión general lista 13 servicios, y cada configuración es una decisión de seguridad que queda de tu lado.
Una frase de la visión general merece revisión por parte de gobierno de datos. Según AWS (2026), AgentCore puede usar y almacenar tu contenido para mejorar tu experiencia con el servicio, y AWS indica que esas mejoras son para tu uso y no para otros clientes. Los sectores regulados deberían contrastarlo con sus reglas de datos.
Sesiones de Runtime: aislamiento sólido, con huecos que te tocan
AgentCore Runtime asigna a cada sesión su propia microVM, con cómputo, memoria y sistema de archivos aislados. Al terminar la sesión, AWS destruye la microVM y sanea la memoria. Es un aislamiento fuerte entre sesiones. Los huecos están alrededor: quién es dueño de una sesión, qué puede leer el código de dentro y quién puede llamar al runtime directamente.
La página de sesiones de Runtime lo deja claro: "AgentCore does not enforce session-to-user mappings", así que tu backend debe mantener la relación entre usuarios e IDs de sesión. AWS aconseja IDs de al menos 33 caracteres. Las sesiones duran hasta 8 horas en microVMs y hasta 14 días en Instances.
La página de buenas prácticas de seguridad de Runtime añade cuatro puntos que conviene leer con calma.
- Cualquier código dentro de la microVM puede leer las credenciales del rol de ejecución a través del servicio de metadatos. AWS exige MMDSv2 en los runtimes desde el 30 de junio de 2026.
- El rol de ejecución que crea la CLI por defecto permite invocar todos los modelos fundacionales de la cuenta. AWS dice que lo revises antes de producción.
- InvokeAgentRuntimeForUser y su cabecera user-id no se verifican contra un proveedor de identidad. AWS recomienda autenticación JWT.
- Los permisos del sistema de archivos no se aplican dentro de la microVM, y los bloques toolUse aportados por el usuario pueden hacer que algunos frameworks ejecuten una herramienta sin evaluación del modelo.
AWS también indica poner Gateway delante de Runtime para que apliquen políticas, guardrails e interceptores. Solo protegen el tráfico que pasa por el gateway, así que restringe la invocación directa.
Una checklist práctica para Runtime:
- Genera los IDs de sesión en el servidor con una fuente criptográficamente segura, nunca a partir de datos del usuario.
- Vincula cada ID a un usuario autenticado en tu propia base de datos y compruébalo en cada llamada.
- Acota el rol de ejecución a los modelos, tablas y buckets que necesita el agente, y bloquea la invocación directa.
- Registra la creación y reutilización de sesiones, y alerta si un mismo ID aparece con dos identidades.
Gateway, Policy e interceptores: reglas deterministas sobre las herramientas
AgentCore Policy evalúa cada llamada a herramientas que pasa por un AgentCore Gateway frente a las reglas que defines, antes de que el agente use la herramienta. Es un control fuerte de autorización. Solo ve el tráfico que pasa por Gateway, y la calidad de las reglas es cosa tuya.
Las políticas pueden escribirse en Cedar, en Dogwood, que AWS describe como compatible con Cedar, o en lenguaje natural, donde unas comprobaciones de razonamiento automatizado señalan políticas demasiado permisivas, demasiado restrictivas o imposibles de cumplir. Las políticas temporales se limitan a una sesión, como aprobaciones obligatorias o presupuestos, y las decisiones se registran en CloudWatch.
El mayor cambio es que los guardrails ya forman parte documentada de Policy. Respaldados por Amazon Bedrock Guardrails, cubren filtrado de contenido, ataques de prompt (jailbreak, prompt injection y fuga de prompt) e información sensible. Según AWS, las puntuaciones tienen seis niveles de 0 a 1,0, y el umbral por defecto para ataques de prompt es 0,4.
AWS separa los dos tipos de decisión: las puntuaciones de guardrails no son deterministas y las decisiones de la política sí. Un modo LOG_ONLY permite probar antes de aplicar. Un detalle merece una prueba: si ningún JSONPath se resuelve, la evaluación falla en cerrado, pero una ruta mal escrita junto a otras correctas falla en silencio.
La disponibilidad regional también importa. A 6 de noviembre de 2026, la página de guardrails en políticas lista siete regiones, entre ellas Londres y Estocolmo, pero no Fráncfort, Irlanda ni París. Consulta la lista vigente antes de diseñar un despliegue europeo sobre ella.
Los interceptores añaden lógica propia, con límites. Un gateway admite un interceptor REQUEST y uno RESPONSE, ambos funciones Lambda, así que su código, dependencias y parches son tuyos. Las cabeceras no pasan salvo que passRequestHeaders sea true, y como Gateway puede reintentar, las funciones deben ser idempotentes. AWS indica que el rol de ejecución solo debe invocar esas funciones concretas.
Si no conoces el ataque que frenan estos controles, nuestra prueba de MCP prompt injection en Bedrock muestra cómo la salida de una herramienta puede dirigir a un agente.
Code Interpreter, Identity y credenciales: donde empieza la agencia excesiva
Según AWS, AgentCore Identity centraliza las identidades y credenciales de los agentes mediante SigV4, flujos OAuth 2.0 y claves de API, mientras Gateway gestiona la autenticación de entrada y salida de las herramientas. Eso reduce la dispersión de secretos y concentra el acceso delegado, así que acotar permisos es el control principal.
Gateway ofrece integraciones de un clic con Salesforce, Slack, Jira, Asana y Zendesk, y cada una da al agente permisos reales en un sistema de negocio. AWS llama a Gateway la única solución que combina autenticación de entrada y de salida completas en un servicio totalmente gestionado. Es una afirmación de AWS, y si encaja en tu entorno es otra cuestión.
La agencia excesiva, cuando un agente tiene más funcionalidad, permisos o autonomía de los que necesita su tarea, es el patrón que vigilar. Code Interpreter es un ejemplo claro en 2026. Un intérprete con un rol amplio, red abierta y un SDK antiguo convierte una instrucción inyectada en una llamada a la API de AWS.
Cuatro reglas para mantener esta capa bajo control:
- Usa credenciales separadas por herramienta y por entorno.
- Da a cada intérprete el modo de red más estricto que funcione, y pasa las cargas sensibles al modo VPC.
- Asocia un rol de ejecución solo si el código necesita acceso a AWS, y acótalo a recursos concretos.
- Actualiza el SDK y activa los eventos de datos de CloudTrail y los logs de Observability para que los comandos dejen registro.
Para diseñar roles, consulta nuestra guía sobre por qué los agentes de IA necesitan RBAC.
Amenazas de prompt y memoria: lo que Policy no juzga por sí sola
Policy decide si una llamada a herramientas está permitida. Una puntuación de guardrail ya puede alimentar esa decisión, pero sigue siendo una señal probabilística que configuras, ajustas y pruebas. La prompt injection indirecta, la memoria a largo plazo envenenada y las salidas inseguras del modelo aún requieren inspección de contenido y reglas estrictas.
Piensa en una acción permitida: a un agente que puede publicar en Slack, una instrucción oculta en un correo puede ordenarle publicar datos sensibles en abierto. La llamada cumple las reglas, así que solo la inspección de contenido o una regla más estricta la detendría.
AgentCore Memory plantea algo parecido. La memoria a largo plazo también permite que el contenido inyectado persista. Trata las escrituras en memoria como escrituras en una base de datos: valídalas, atribúyelas a una fuente y revisa qué pueden guardar los agentes. Es una recomendación nuestra, no un requisito de AWS.
| Amenaza | Pieza de AgentCore | Hueco que cerrar |
|---|---|---|
| Prompt injection indirecta | Guardrail PromptAttack en Policy | Ajustar umbrales, probar en modo LOG_ONLY y comprobar la región |
| Uso no autorizado de herramientas | Policy sobre el tráfico de Gateway | Cubrir todas las rutas, también la invocación directa del runtime |
| Abuso de ejecución de código | Modos de red de Code Interpreter | Modo VPC, rol acotado y SDK parcheado |
| Envenenamiento de memoria | Servicio Memory | Validar y revisar las escrituras |
Para ver los controles de contenido de Bedrock en la práctica, lee nuestra prueba de detección de temas con Bedrock Guardrails.
Seguridad y gobernanza: proteger agentes más allá de una nube
La mayoría de empresas no ejecutará todos sus agentes en una sola plataforma. Habrá agentes en AWS, otras nubes, herramientas SaaS y sistemas on-premises, y seguridad necesita una capa común de políticas y visibilidad. AgentCore cubre bien el lado de AWS. Una capa independiente cubre el resto y separa a quien ejecuta los agentes de quien los audita.
Nosotros vendemos TrustGate, así que valora esta sección con eso en mente. El Agent Gateway (TrustGate) enruta llamadas a modelos, servidores MCP, herramientas y otros agentes. Según la página de producto de NeuralTrust, reenvía la identidad del usuario final en cada salto, aplica RBAC por agente y por herramienta y guarda pistas de auditoría criptográficas. Funciona como servicio gestionado con residencia en EE. UU. o la UE, como híbrido con plano de datos privado o on-premises sobre Kubernetes.
La página de precios, consultada el 6 de noviembre de 2026, muestra 7 días de retención de logs en Free y 30 días en Standard, con despliegue privado e integraciones OpenTelemetry o SIEM en Enterprise. Agent Runtime Security (TrustGuard) añade protección frente a prompt injection, también multi-turno, y controles sobre las respuestas de herramientas MCP.
Agent Posture Management (TrustLens) y AI Red Teaming (TrustTest) cubren el inventario y las pruebas previas al lanzamiento. Nada de esto sustituye los controles de AgentCore. Es una segunda opinión que no depende de dónde se construyó el agente.
¿Cuál deberías elegir?
Elige según dónde viven tus agentes. Para agentes que corren sobre todo en AWS, AgentCore da runtime, identidad y políticas de herramientas gestionados con precio por consumo. Para agentes repartidos entre nubes, herramientas SaaS y sistemas on-premises, un gateway independiente como TrustGate da un único punto de control. Muchas organizaciones usarán ambos.
| Si eres... | Elige | Por qué |
|---|---|---|
| Un CISO con agentes en AWS, otras nubes y on-premises | Gateway independiente | Un único punto de políticas fuera de cualquier nube |
| Una empresa regulada con reglas estrictas de residencia de datos | Gateway independiente | Residencia gestionada en EE. UU. o la UE, y opciones híbridas u on-premises |
| Un equipo nativo de AWS con su primer agente en producción | AgentCore | Runtime, Identity y Policy gestionados con precio por consumo |
| Un equipo que necesita autorización con Cedar dentro de AWS | AgentCore Policy | Reglas deterministas sobre las llamadas de Gateway |
| Un equipo que ya usa AgentCore y quiere evidencia independiente | Ambos | Controles de AgentCore y una capa aparte para auditoría |
Conclusión
AgentCore da a los equipos de AWS buenas piezas de seguridad para agentes, y 2026 demostró que el trabajo no termina en el límite de la plataforma. Un canal DNS en el modo Sandbox, dos CVE del SDK y las nuevas advertencias de Runtime caen del lado del cliente. Parchea el SDK, acota los roles, vincula sesiones a usuarios, prueba los guardrails como señales probabilísticas y suma una capa independiente si tus agentes viven en varios entornos.
Asegura tus agentes de AgentCore en producción con NeuralTrust
Gobierna cada agente, llamada a herramientas y conexión MCP desde un gateway que se ejecuta donde viven tus agentes.
)
Comparativas relacionadas
- Los 6 mejores MCP gateways para empresas (2026)
- AI gateway vs MCP gateway: diferencias clave
- Qué es la agencia excesiva
- El AI control plane para la seguridad agéntica
Preguntas frecuentes sobre AgentCore
1. ¿Qué es AgentCore?
Amazon Bedrock AgentCore es una plataforma de AWS para crear, desplegar y operar agentes de IA con cualquier framework y modelo fundacional. La visión general lista 13 servicios, entre ellos Runtime, Memory, Gateway, Identity, Code Interpreter, Policy y Registry. El precio es por consumo, sin compromiso inicial, según AWS.
2. ¿Ha tenido AgentCore vulnerabilidades de seguridad en 2026?
Sí, en el SDK de Python open source. AWS publicó el CVE-2026-12530 el 17 de junio y el CVE-2026-16796 el 23 de julio, ambos en el helper install_packages() de Code Interpreter. Las correcciones llegaron en las versiones 1.6.1 y 1.18.1 del SDK. BeyondTrust también informó en marzo de un canal DNS en el modo Sandbox, que según ella AWS corrigió el 15 de abril.
3. ¿AgentCore Gateway es un servidor MCP?
AgentCore Gateway funciona como un endpoint gestionado para herramientas MCP. Convierte APIs, funciones Lambda y servicios existentes en herramientas compatibles con MCP y se conecta a servidores MCP ya existentes. AWS lo llama AI gateway gestionado porque también da acceso a otros agentes y enruta peticiones de inferencia entre proveedores de modelos.
4. ¿Cómo funciona AgentCore Policy?
AgentCore Policy intercepta las llamadas a herramientas que pasan por AgentCore Gateway y las compara con las reglas de un motor de políticas. Escribes las reglas en Cedar, en Dogwood o en lenguaje natural. Pueden permitir, prohibir o poner condiciones, como contadores de sesión, presupuestos y puntuaciones de guardrails, que según AWS no son deterministas, a diferencia de las decisiones de la política.
5. ¿Qué modo de red de Code Interpreter debería usar?
Para cargas sensibles, usa el modo VPC, que conecta el intérprete a tu propia VPC. El modo Sandbox da acceso limitado a servicios de AWS como Amazon S3 y el modo Public abre internet. BeyondTrust recomienda combinar el modo VPC con Route 53 Resolver DNS Firewall, y AWS indica que el modo Public conlleva consideraciones de seguridad.
6. ¿AgentCore Runtime vincula las sesiones con los usuarios?
No. AWS afirma que AgentCore no impone el vínculo entre sesión y usuario, así que tu backend debe mantenerlo. Cada sesión sigue teniendo su propia microVM, y la memoria se sanea al terminar. AWS aconseja IDs de sesión de al menos 33 caracteres y recomienda autenticación JWT frente a la cabecera user-id.
Sobre el autor
Roger Howroyd es Head of Global SEO and AI en NeuralTrust, donde dirige la estrategia de búsqueda de la compañía en SEO, AEO, GEO y optimización para LLM. Está especializado en búsqueda impulsada por IA, estrategia de contenidos y SEM. Conecta con él en LinkedIn.
NeuralTrust es la plataforma líder para proteger y escalar agentes de IA. Nombrada pionera en el Gartner Emerging Market Quadrant for AI Application Security 2026, reconocida en cuatro informes Gartner Hype Cycle en 2026 y destacada en la Gartner Market Guide for Guardian Agents 2026, la Gartner Market Guide for AI Gateways 2025 y el KuppingerCole Leadership Compass for Generative AI Defense 2025. Con sede en Barcelona y oficinas en Londres y Nueva York. Certificada ISO 27001.
Fuentes
Todas las páginas consultadas el 6 de noviembre de 2026. Los materiales de AWS y BeyondTrust se citan por su título y sin enlace, según nuestra política de enlaces a proveedores externos.
- AWS, "What is Amazon Bedrock AgentCore?", Amazon Bedrock AgentCore Developer Guide.
- AWS, "Security in Amazon Bedrock AgentCore", Amazon Bedrock AgentCore Developer Guide.
- AWS, "Use isolated sessions for agents" y "Security best practices", Amazon Bedrock AgentCore Developer Guide (Runtime).
- AWS, "Amazon Bedrock AgentCore Gateway: A secure AI gateway for agents, tools, and models" y "Using interceptors with Gateway", Developer Guide.
- AWS, "Policy in Amazon Bedrock AgentCore" y "Guardrails in policies", Developer Guide.
- AWS, "Resource management" (modos de red de Code Interpreter), Amazon Bedrock AgentCore Developer Guide.
- AWS Security Bulletin 2026-044-AWS, "CVE-2026-12530", publicado el 17 de junio de 2026.
- AWS Security Bulletin 2026-065-AWS, "CVE-2026-16796", publicado el 23 de julio de 2026.
- BeyondTrust Phantom Labs, investigación sobre el modo Sandbox de Code Interpreter y el DNS, publicada el 16 de marzo de 2026 y actualizada el 22 de abril de 2026.
- BeyondTrust Phantom Labs, "Two RCE CVEs in the Amazon Bedrock AgentCore Python SDK Code Interpreter Helper", 28 de septiembre de 2026.