El esquema usa tokens JWT enriquecidos y credenciales temporales con alcance de sesión para que cada servicio downstream aplique control de acceso propio.
AWS publicó un patrón de arquitectura para Amazon Bedrock AgentCore que resuelve un problema estructural en despliegues de agentes de IA multiusuario: cómo garantizar que cada empleado vea únicamente los datos que le corresponden, sin que el agente tenga que implementar lógica de autorización propia. El enfoque traslada el control de acceso a la infraestructura y los servicios de datos, de modo que incluso si el agente es comprometido por inyección de prompts o errores de aplicación, no puede acceder a información fuera del alcance del usuario que hizo la consulta. El patrón sigue la práctica AGENTSEC03 del AWS Well-Architected Agentic AI Lens y está documentado en el blog de seguridad de AWS.
Cómo se propaga el contexto de autorización desde la autenticación inicial hasta cada fuente de datos
El flujo arranca cuando el usuario se autentica contra Amazon Cognito, que actúa como proveedor de identidad. Un Lambda trigger de pre-generación de tokens versión 2 intercepta la emisión del JWT y lo enriquece con claims personalizados y metadatos de etiquetas de sesión AWS. En el caso de uso de ejemplo — una aplicación de chat CRM donde empleados de Ventas y Finanzas acceden a datos aislados por departamento — el trigger extrae el atributo de departamento del perfil del usuario y lo inyecta tanto en el token de identidad como en el token de acceso. El claim de departamento viaja en formato estándar, mientras que las etiquetas de sesión se empaquetan en el claim https://aws.amazon.com/tags, que es el formato específico que AWS Security Token Service requiere para extraer session tags durante AssumeRoleWithWebIdentity.
Cuando la aplicación web envía la solicitud del usuario al agente desplegado en Amazon Bedrock AgentCore Runtime, el runtime valida el JWT entrante y, a través de Bedrock AgentCore Identity, emite un token de acceso de carga de trabajo que vincula las identidades del usuario y del agente. Este token de carga de trabajo es el que el agente usa para invocar servicios downstream, y cada servicio aplica su propio mecanismo de control de acceso sobre la base de los claims y etiquetas que trae el token.
Tres tipos de fuentes de datos, tres mecanismos de aislamiento distintos
El patrón cubre tres categorías de origen de datos, cada una con su estrategia de enforcement. Para consultas que requieren documentos internos almacenados en Amazon Bedrock Knowledge Bases — respaldadas por un vector store en Amazon S3 — el agente usa su rol IAM para ejecutar la consulta, pero aplica filtrado de metadatos: solo se devuelven documentos cuyo metadato de departamento coincide con el claim del usuario. En el caso de registros de clientes en Amazon DynamoDB, el agente obtiene credenciales temporales con alcance de sesión etiquetadas con el departamento del usuario, de modo que DynamoDB aplica políticas de acceso basadas en esas etiquetas y solo retorna filas autorizadas.
Para datos externos en Salesforce, el patrón implementa intercambio de tokens RFC 8693 del tipo on-behalf-of. Bedrock AgentCore Identity recupera credenciales de AWS Secrets Manager y las usa para solicitar a Salesforce un token de acceso con alcance del usuario original. Salesforce recibe ese token, aplica sus propias reglas de compartición (sharing rules) y devuelve únicamente los registros que el usuario está autorizado a ver. En ninguno de los tres casos el agente almacena credenciales persistentes ni toma decisiones de autorización: actúa como orquestador de llamadas a herramientas, mientras que cada servicio downstream aplica su propio control de acceso.
Por qué esto importa en contextos donde los agentes acceden a múltiples fuentes de datos corporativas
El riesgo que este patrón mitiga es que el agente, al no tener conciencia de quién pregunta, podría devolver datos que el usuario no debería ver. En despliegues donde un mismo agente sirve a múltiples departamentos o roles, la tentación tradicional es escribir lógica de autorización dentro del código del agente — verificar manualmente el claim de departamento antes de cada consulta, por ejemplo. Ese enfoque tiene dos problemas: primero, centraliza la responsabilidad de seguridad en un componente que puede ser manipulado por ataques de inyección de prompts; segundo, no escala cuando el agente accede a decenas de fuentes de datos con políticas de acceso heterogéneas.
El patrón de AWS invierte esa lógica: el agente no es el guardián de los datos, sino un coordinador que pasa contexto de autorización a servicios que ya saben cómo aplicar políticas de acceso. Esto significa que incluso si un atacante logra manipular el comportamiento del agente mediante prompts maliciosos, no puede sortear las políticas de IAM en DynamoDB, el filtrado de metadatos en Knowledge Bases o las sharing rules en Salesforce, porque esas políticas se evalúan fuera del alcance del agente.
Exposición en América Latina por dependencia de arquitecturas de agentes sin aislamiento de contexto
Aunque el patrón publicado por AWS no menciona casos de implementación específicos en América Latina, la dependencia regional de plataformas SaaS multiusuario y agentes de IA desplegados sobre infraestructura compartida hace que el problema de aislamiento de datos por usuario sea estructuralmente relevante. Empresas en Brasil y México que operan agentes de IA para atención al cliente o automatización de procesos internos — especialmente en sectores regulados como banca y salud — enfrentan el mismo riesgo: si el agente no propaga contexto de autorización, un empleado de un departamento podría acceder a datos de otro, o un cliente podría ver información de otro cliente en caso de falla del agente.
La ausencia de un patrón de arquitectura documentado para este problema significa que muchos equipos en la región implementan soluciones ad hoc — lógica de autorización escrita a mano en el código del agente, verificaciones manuales de claims antes de cada consulta — que no resisten ataques de inyección de prompts ni errores de implementación. El patrón de AWS ofrece una alternativa basada en infraestructura que delega el enforcement a servicios que ya tienen mecanismos de control de acceso probados, lo que reduce la superficie de ataque y simplifica auditorías de cumplimiento.
Nuestro análisis
Este patrón de arquitectura representa un cambio de enfoque en cómo se piensa la autorización en sistemas de IA agentica: en lugar de tratar al agente como un componente confiable que toma decisiones de acceso, se lo trata como un orquestador no confiable que pasa contexto de autorización a servicios downstream que aplican políticas propias. Esa inversión de responsabilidad es coherente con el principio de defensa en profundidad — si el agente es comprometido, las políticas de IAM, los filtros de metadatos y las sharing rules de servicios externos siguen aplicándose. El uso de tokens de carga de trabajo que vinculan identidades de usuario y agente, combinado con credenciales temporales con alcance de sesión, hace que cada solicitud del agente lleve consigo el contexto de quién la originó, sin que el agente tenga que almacenar credenciales persistentes ni implementar lógica de autorización propia.
Lo que todavía no está documentado es cómo este patrón se comporta en escenarios donde el agente necesita acceder a fuentes de datos que no soportan filtrado de metadatos ni intercambio de tokens RFC 8693 — bases de datos legacy sin políticas de acceso basadas en etiquetas de sesión, APIs internas sin soporte para on-behalf-of, sistemas que solo aceptan credenciales de servicio compartidas. En esos casos, el patrón requiere adaptaciones que podrían reintroducir lógica de autorización en el agente o en capas intermedias, lo que debilita la garantía de que el enforcement ocurre fuera del alcance del agente. ¿Qué pasa cuando la mayoría de las fuentes de datos corporativas en una organización no cumplen los requisitos de infraestructura que este patrón asume?