Empresas estão correndo para implantar agentes de IA que acessam bancos de dados, repositórios de documentos, plataformas SaaS e bases de conhecimento internas para automatizar fluxos de trabalho. No entanto, um risco silencioso se esconde sob essa conveniência: a maioria dos agentes não tem consciência incorporada de quem está realmente fazendo a pergunta, o que significa que um agente comprometido ou manipulado poderia entregar dados que o usuário solicitante nunca estava autorizado a ver.
Arquitetura de autorização na infraestrutura
A AWS publicou uma arquitetura detalhada usando o Amazon Bedrock AgentCore que fecha essa lacuna, movendo a autorização do código do agente para a própria infraestrutura. A correção tradicional para esse risco tem sido dar ao agente credenciais amplas e confiar na própria lógica do agente para filtrar resultados, muitas vezes por meio de condições de consulta simples. A orientação da AWS identifica isso como uma fraqueza estrutural.
Se um atacante manipular o agente por meio de injeção de prompt ou explorar um bug nesse código de filtragem, o conjunto de dados subjacente completo do agente fica exposto. A resposta proposta pela AWS, alinhada com a melhor prática AGENTSEC03 na lente Well-Architected Agentic AI da AWS, trata o agente puramente como um orquestrador que coordena chamadas de ferramentas e raciocínio, enquanto as decisões de acesso reais são impostas pelos serviços com os quais o agente se comunica.
Padrões de propagação de identidade
A demonstração centra-se em um aplicativo de chat de CRM compartilhado por funcionários de Vendas e Finanças, cada um precisando de acesso isolado a registros de clientes no Amazon DynamoDB, documentos marcados por departamento em Amazon Bedrock Knowledge Bases e dados de CRM externos no Salesforce. Quando um usuário faz login por meio de um pool de usuários Amazon Cognito, um gatilho Lambda de pré-geração de token injeta uma declaração de departamento e metadados de tag de sessão AWS diretamente no JSON Web Token antes que ele chegue ao aplicativo.
O Amazon Bedrock AgentCore Runtime valida esse token na chegada e rejeita qualquer solicitação cuja declaração de departamento não corresponda a um valor permitido, bloqueando chamadas não autorizadas antes que o código do agente seja executado. A partir daí, a AWS demonstra três padrões distintos para propagar essa identidade verificada a jusante.
Implementação técnica por serviço
Para o DynamoDB, o agente troca o token de ID assinado do usuário por credenciais temporárias e escopadas por usuário por meio de AssumeRoleWithWebIdentity, permitindo que o AWS Identity and Access Management avalie uma condição LeadingKeys vinculada à tag de departamento do usuário, para que consultas entre departamentos sejam rejeitadas no nível da política, em vez de filtradas após o fato.
Para as Bases de Conhecimento do Bedrock, os documentos são marcados com metadados de departamento na ingestão, e o agente anexa um filtro de metadados correspondente a cada chamada de recuperação, um controle de camada de aplicação já que a API de recuperação ainda não expõe filtros como condições IAM.
Para o Salesforce, a Identidade do AgentCore realiza uma troca de token em nome do usuário sob o RFC 8693, trocando a identidade autenticada do usuário por um token reconhecido pelo Salesforce sem que nenhuma credencial toque o agente, permitindo que as próprias regras de compartilhamento do Salesforce governem o que retorna.
Impacto na segurança de agentes
A importância prática é que, mesmo um agente totalmente comprometido, um manipulado por injeção de prompt ou uma falha de codificação, não pode ir além do que o usuário autenticado tem direito a ver, porque a função de execução do agente não possui permissões diretas de armazenamento de dados. Cada solicitação carrega credenciais de curta duração, derivadas criptograficamente e vinculadas ao usuário, que expiram rapidamente e não podem ser reutilizadas ou forjadas.
A AWS enquadra isso como um padrão generalizável: o escopo de departamento no exemplo mapeia tão facilmente para controles de acesso baseados em função, unidade de negócios, região ou projeto em outros ambientes. À medida que as organizações expandem a IA agêntica para sistemas sensíveis que lidam com dados financeiros, de saúde ou de clientes, essa mudança para autorização imposta pela infraestrutura, em vez de confiar em um agente orientado por LLM para se auto-policiar, representa um endurecimento significativo contra a classe crescente de ataques de injeção de prompt e sequestro de agentes que pesquisadores de segurança sinalizaram como uma preocupação principal para 2026.
O que os CISOs devem fazer agora
As equipes de segurança devem revisar as arquiteturas de agentes de IA atuais para garantir que a autorização não dependa apenas da lógica do agente. A implementação de validação de tokens na camada de infraestrutura é crítica. Além disso, a auditoria de permissões de serviço deve ser rigorosa, garantindo que funções de execução de agentes não tenham acesso direto a dados sensíveis sem mediação de políticas de identidade.