En el ejemplo que AWS publicó el 5 de noviembre de 2026, la identidad de un usuario externo determina qué rol obtiene y, con él, qué datos puede consultar mediante Athena y AWS Lake Formation. La cadena empieza con la afirmación custom:team de Amazon Cognito y termina con permisos aplicados a las tablas y a las filas; no depende solo de las instrucciones que reciba el agente. AWS explica la arquitectura en su tutorial.
Una arquitectura multiinquilino permite que usuarios de distintos clientes compartan una aplicación y datos alojados en una infraestructura común, con permisos que delimitan el acceso de cada grupo. En este patrón, la identidad debe acompañar a la consulta hasta la capa que controla los datos.
Del inicio de sesión a la consulta con permisos
El usuario inicia sesión en Amazon Cognito y recibe tokens, entre ellos un token de identidad con la afirmación custom:team. La aplicación envía el token de acceso y el de identidad a Amazon Bedrock AgentCore. AgentCore Gateway valida el token de acceso y transmite el token de identidad a una función de AWS Lambda mediante la cabecera X-ID-Token.
Después, las reglas de Amazon Cognito Identity Pool relacionan el valor de custom:team con un rol de AWS IAM. Lambda intercambia el token de identidad por credenciales temporales de ese rol. Amazon Athena ejecuta la consulta con esas credenciales y AWS Lake Formation aplica los permisos y filtros asociados antes de que los datos lleguen al usuario.
La asignación es concreta: la regla de Team A apunta al rol TeamA, y la de Team B, al rol TeamB. La interfaz de Amazon Cognito también indica que las reglas se evalúan de arriba abajo.
Por qué Lambda solo gestiona credenciales
En el ejemplo de AWS, la función de destino de Lambda hace de intermediaria de credenciales. Su rol enumera dos acciones de Cognito Identity: cognito-identity:GetId y cognito-identity:GetCredentialsForIdentity. AWS indica que esa función no tiene permisos de datos para Athena, Amazon S3 ni AWS Glue.
Los roles asignados a los equipos son los que permiten el acceso a los servicios de datos; Lake Formation restringe ese acceso según los permisos aplicables. Así, la función que recibe el token no consulta directamente los datos con sus propias credenciales de ejecución.
Qué controlan las reglas de equipo
El tutorial usa las etiquetas LF-Tag TeamA, TeamB y shared. En su ejemplo, la tabla venue está asociada a Team A, category a Team B y users a ambos mediante la etiqueta compartida. La tabla sales_extended tiene filtros de filas específicos para cada equipo.
La pantalla del filtro de Team A muestra la expresión team = 'Team A' y acceso a todas las columnas de sales_extended. El control que concreta esa configuración es el acceso a tablas y el filtrado de filas; no demuestra una regla de denegación de columnas.
El atributo custom:team se declara mutable y su valor interviene en la selección del rol IAM. Por tanto, controlar quién puede modificarlo forma parte del límite de autorización: si cambia la asignación del equipo, puede cambiar también el rol utilizado para consultar los datos.
Al adaptar este patrón, protege los cambios en la afirmación de equipo: de ella depende la selección del rol que recibe las credenciales de consulta.
Identidad externa y comprobación de permisos
Para usuarios externos, AWS plantea el uso de Cognito User Pools e Identity Pools. Para identidades de trabajadores, el tutorial presenta AWS IAM Identity Center con Trusted Identity Propagation. Son rutas de identidad distintas para tipos de usuarios distintos.
AWS describe una comprobación con sesiones de Team A y Team B: comparar las tablas visibles y verificar que cada equipo recibe las filas correspondientes en sales_extended. El recorrido también cambia la etiqueta de category y amplía el filtro de filas de Team A para comprobar el efecto en el acceso. AWS advierte que los cambios de permisos de Lake Formation pueden tardar varios minutos en propagarse.
