AWS mostra como impedir que um agente LLM leia documentos alheios: o gateway injeta o userContext

Imagine um assistente interno usado por toda a empresa. Um funcionário do departamento A pede: "Compare o plano do meu departamento com o comunicado geral e mostre as iniciativas atrasadas". O próprio agente formula as consultas de busca e vasculha os documentos até reunir informação suficiente. A mesma pergunta é feita por um funcionário do departamento B. Se a busca não estiver vinculada a uma pessoa específica, o plano de negócios de um departamento pode facilmente aparecer na resposta para outro. Em um SaaS multilocatário, o mesmo acontece com as empresas clientes, e o custo do erro ali é maior.

O AWS Machine Learning Blog publicou uma análise de como fechar essa brecha na combinação de Amazon Bedrock Managed Knowledge Base e AgentCore Gateway.

Por que com agentes é mais difícil do que em um aplicativo comum

Em um aplicativo clássico, o próprio código sabe quem entrou no sistema e pesquisa com as permissões desse usuário. Em um agente, quem chama a ferramenta é o LLM, e os argumentos também são escolhidos por ele. Se a ferramenta de busca tem um parâmetro "em nome de quem pesquisar", ele será preenchido pelo modelo. Basta o usuário dizer "pesquise como user-b", um erro do modelo ou uma prompt injection indireta em um documento encontrado, e o agente passa a pesquisar sob a identidade de outra pessoa.

O Managed Knowledge Base tem o modo ACL awareness. Ao carregar os dados, a base memoriza as permissões dos documentos e, na busca, devolve apenas o que é permitido ao usuário indicado em userContext.userId (o e-mail dele). Mas a base não autentica usuários: ela acredita no que recebe. E quando é publicada como ferramenta MCP via AgentCore Gateway, o userContext se torna um argumento comum, construído pelo modelo. Nem o gateway nem a base verificam se o valor pertence à pessoa que fez login.

Quatro camadas: duas principais e duas de segurança adicional

O princípio é simples: o LLM não decide quem é o usuário. Quem decide é um código confiável, com base em dados verificados pelo provedor de identidade. A requisição segue este caminho:

• O usuário faz login pelo Amazon Cognito e recebe um JWT. O gatilho Lambda pre token generation adiciona ao token um claim com o e-mail.
• O agente encaminha o token no cabeçalho Authorization, e o autorizador do gateway verifica a assinatura, o prazo de validade e o client ID.
• O request interceptor, ou seja, uma Lambda no gateway, extrai o e-mail do token verificado e sobrescreve o userContext em cada chamada tools/call. Seja o que for que o cliente ou o modelo enviar, a base receberá o e-mail do usuário real. Lotes (batches) e corpos de requisição inválidos são rejeitados segundo o princípio fail-closed.
• A Policy in AgentCore verifica, por meio de uma política Cedar, se userContext.userId coincide com o e-mail do JWT. Se não coincidir, a requisição é rejeitada.
• A resource-based policy da base de conhecimento proíbe a busca para todos, exceto o papel de execução do gateway.

As duas primeiras camadas (interceptador e ACL) são a proteção principal. Para requisições via gateway, elas bastam se ninguém mais puder acessar a base diretamente. A política Cedar e a resource-based policy servem para o caso de um bug no interceptador ou de um principal externo com permissão bedrock:Retrieve na mesma conta. O próprio agente, construído com Strands Agents, não contém lógica de acesso: apenas repassa o token adiante.

Armadilhas

• As ACLs para S3 são definidas por um arquivo global por prefixo ou por um metarquivo por documento. Um documento sem ACL simplesmente não entra no índice.
• As alterações de permissões só são aplicadas após a próxima sincronização: o S3 não faz verificação em tempo real.
• Erros nas ACLs não geram exceções, os documentos desaparecem silenciosamente dos resultados. Verifique isso com testes.
• Uma requisição sem userContext não retornará documentos de uma fonte com ACL ativada, mas os documentos de uma fonte sem ACL serão vistos por todos.
• Para personalizar o access token no Cognito, é necessário o plano Essentials ou Plus. No Lite, o e-mail não aparecerá no token.
• Para que o interceptador possa gravar o userContext, ele precisa ser exposto no esquema da ferramenta via parameterOverrides, mesmo que os clientes não o definam.

O que fazer com isso

A conclusão vai além de um único produto da AWS. Nenhum parâmetro que determine identidade ou permissões deve ser um argumento preenchido pelo modelo. Injete-o no nível do gateway ou do servidor de ferramentas a partir de um token verificado e, por cima, adicione uma verificação independente. Se você constrói um agente multilocatário, veja se não está entregando ao modelo o tenant_id ou o user_id.

Um exemplo pronto em CDK está no repositório sample-managed-knowledge-base-patterns, no diretório agentcore-access-control. Ressalva: este é um esquema para a stack da AWS e, em outras plataformas, será preciso reproduzi-lo por conta própria.