Como a AWS divide o controle de acesso de agentes de IA

Controle de acesso de agentes de IA é o conjunto de verificações que limita quais ferramentas um agente pode acionar e quais dados pode acessar em nome de um usuário. No desenho descrito pela AWS com Okta e Amazon Bedrock AgentCore, o Gateway valida a identidade delegada, Cedar avalia o acesso às ferramentas e o servidor MCP verifica as permissões do usuário. Essa separação ajuda a entender quem decide cada parte do acesso — e por que autorizar chamadas individuais não responde, por si só, ao que um agente pode deduzir ao combinar resultados. A AWS descreve essa arquitetura e relata os testes correspondentes.

Regra prática: controlar cada chamada é uma etapa; também importa o que o agente pode inferir ao cruzar as respostas que recebeu.

O caminho do ID-JAG até a ferramenta

A autorização passa por verificações distintas. Um ID-JAG (Identity Assertion JWT Authorization Grant) é a concessão de acesso delegado da Okta usada no exemplo. O Gateway verifica se o emissor, o público, o cliente permitido e os escopos correspondem à configuração do agente e do recurso. Os escopos configurados para o destino também precisam corresponder aos do ID-JAG.

Em seguida, Cedar avalia se aquele agente pode listar ou acionar a ferramenta solicitada dentro do escopo delegado. As políticas de permissão do exemplo seguem o padrão permit-only: se nenhuma permissão aplicável autoriza a ação, o padrão é negar.

A verificação não termina no Gateway. O servidor MCP (Model Context Protocol) confere separadamente os grupos do usuário e o escopo da solicitação. Assim, uma política que permite ao agente chamar uma ferramenta não substitui a checagem de que aquele usuário pode executar a ação.

No desenho com vários agentes, cada agente tem seu próprio Gateway e provedor de credenciais, pois o provedor se autentica como um agente específico. A AWS também descreve a retirada das permissões de troca de token e acesso a segredos da função de execução do agente.

XAA e consentimento OAuth por usuário

O XAA (Cross App Access) se aplica, no padrão descrito, a destinos cujo servidor de autorização aceita ID-JAGs. Um administrador da Okta define quais agentes podem agir em nome de quais usuários, e a Okta avalia a política a cada solicitação de token. O usuário não recebe uma solicitação de consentimento para esse fluxo.

Para um destino com servidor de autorização próprio, como o GitHub no exemplo da AWS, o fluxo usa consentimento OAuth por usuário. A diferença também apareceu no teste de suspensão e desconexão relatado pela AWS:

A escolha depende do servidor de autorização de cada destino: aceitar ID-JAGs permite o fluxo XAA; um destino com autorização própria pode exigir consentimento por usuário. O comportamento de suspensão descrito na tabela pertence ao teste da AWS.

O que a AWS relatou nos testes

No teste da AWS, o Agente A listou seis ferramentas. Alice e Carol não puderam criar tarefas, enquanto Bob conseguiu. O Agente B listou quatro ferramentas porque Cedar ocultou suas ferramentas de escrita; para Bob, esse agente não tinha uma ferramenta de escrita disponível. A AWS também relata que o Agente B rejeitou em 98 ms um ID-JAG destinado ao Agente A, antes de uma chamada ao modelo.

A tabela reúne medianas (p50) e percentis 90 (p90) dos spans do Gateway A observados durante 24 horas. O p50 é a mediana; o p90 indica o valor abaixo do qual ficaram 90% das observações daquele span.

São medições da implantação de teste da AWS, não uma referência de desempenho para qualquer configuração. A empresa também relata que o span authz.check do servidor MCP ficou abaixo de 1 ms e que eventos da Okta chegaram ao fluxo de logs cerca de um segundo depois de publicados no teste.

Condições práticas da implementação

Algumas escolhas de configuração afetam a aplicação das políticas e a observabilidade:

• Políticas Cedar que nomeiam ferramentas não puderam ser associadas a destinos com listas de ferramentas dinâmicas nos testes da AWS. O Gateway também pagina tools/list por destino; o cliente precisa seguir o cursor para receber as ferramentas das páginas seguintes.
• A política precisa estar em estado ACTIVE antes de ser associada ao mecanismo de políticas.
• No padrão de EKS Auto Mode descrito pela AWS, o grupo de nós de uso geral roda em amd64; a AWS montou imagens para múltiplas arquiteturas. Na configuração de contêiner citada, o SDK Python do AgentCore precisa da variável DOCKER_CONTAINER=true.
• Para exportar spans dos servidores MCP com ADOT, a AWS indica que pode ser necessário incluir botocore. A instrumentação de cliente HTTP também precisa permanecer ativa na configuração do BFF para propagar o contexto de rastreamento.

A AWS correlaciona spans do AgentCore com eventos do System Log da Okta no CloudWatch. Os trechos de código do tutorial são conceituais, não compõem uma solução completa de implantação, e o código de exemplo é destinado a uso não produtivo.

Quando resultados permitidos revelam algo em conjunto

Um participante da comunidade r/LLMDevs descreveu um cenário hipotético: uma ferramenta retorna o total da folha de pagamento por equipe e outra informa o número de pessoas em cada equipe. Se uma equipe tiver uma pessoa só, combinar os resultados pode revelar o salário individual, mesmo que cada consulta tenha sido permitida separadamente.

O exemplo sugere uma pergunta diferente da autorização de cada chamada: quais conclusões podem surgir quando as respostas são cruzadas? O participante propôs controlar a consulta combinada em uma ferramenta sujeita a política ou impedir que os resultados sejam reunidos. São sugestões para esse cenário, não garantias de proteção.