Uma arquitetura de análise de IA multi-tenant precisa levar a identidade de cada usuário até as permissões aplicadas aos dados. No tutorial publicado em 5 de novembro de 2026, a AWS descreve esse caminho com uma declaração do Amazon Cognito que seleciona uma função IAM; o Amazon Athena consulta com credenciais temporárias, e o AWS Lake Formation avalia as permissões de acesso. A AWS explica a arquitetura e seus exemplos. Assim, a autorização da consulta depende das credenciais e dos controles de dados, não apenas da pergunta enviada ao agente.
Do login à consulta: como a identidade define o acesso
No exemplo para usuários externos, o Cognito emite um token de identidade com a declaração custom:team. O frontend envia os tokens de acesso e de identidade ao runtime do AgentCore. O AgentCore Gateway valida o token de acesso e encaminha o token de identidade à função Lambda de destino no cabeçalho X-ID-Token.
As regras do Cognito Identity Pool associam o valor de custom:team a uma função IAM. A Lambda usa chamadas do Cognito Identity para trocar o token por credenciais temporárias dessa função. O Athena executa a consulta com essas credenciais, e o Lake Formation aplica as permissões e os filtros correspondentes à função.
Na configuração, os valores da declaração e os nomes das funções têm grafias diferentes: Team A é associado à função TeamA, e Team B, à função TeamB. Como custom:team é mutável e participa da seleção da função, controlar quem pode alterar essa declaração faz parte do limite de autorização.
Por que a Lambda intermedeia as credenciais
A função Lambda de destino atua como intermediária: a AWS lista para ela as ações cognito-identity:GetId e cognito-identity:GetCredentialsForIdentity. A função de execução da Lambda não recebe permissões de dados para Athena, Amazon S3 ou AWS Glue. Quem consulta os dados é o Athena, usando as credenciais temporárias da função IAM associada ao usuário; o Lake Formation avalia as permissões dessa função.
A identidade precisa acompanhar a consulta até a camada de dados: no exemplo, a declaração seleciona a função cujas permissões serão avaliadas.
O que as regras de equipe filtram
O exemplo usa as LF-Tags TeamA, TeamB e shared para controlar o acesso às tabelas. A tabela venue é associada a Team A, category a Team B e users à tag compartilhada. A tabela sales_extended recebe filtros de linhas por equipe. No cenário descrito pela AWS, Team A consulta suas linhas e as tabelas venue e users; Team B consulta suas linhas e category e users.
A configuração exibida para sales_extended libera todas as colunas e filtra as linhas com a expressão team = 'Team A'. Portanto, essa regra restringe linhas, enquanto o acesso a colunas permanece aberto. O exemplo concreto trata de acesso a tabelas e filtragem de linhas.
Identidade externa e verificações descritas pela AWS
Para aplicações voltadas a clientes e outros usuários externos, o tutorial usa Cognito User Pools e Identity Pools. Para identidades de funcionários, apresenta o IAM Identity Center com Trusted Identity Propagation. São caminhos de identidade distintos dentro da arquitetura descrita.
A validação proposta pela AWS compara o resultado de consultas feitas como Team A e Team B: quais tabelas aparecem e quais linhas de sales_extended cada equipe recebe. O roteiro também altera uma tag e o filtro de linhas de Team A para conferir a mudança de acesso. A AWS observa que alterações de permissões do Lake Formation podem levar vários minutos para se propagar.
