Amazon Bedrock AgentCore ganha Policy para controlar o acesso de agentes de IA

A Amazon mostrou como o Bedrock AgentCore permite tirar o controle de acesso dos agentes de IA para uma camada separada, a Policy. As regras são escritas em linguagem natural, traduzidas para Cedar e então usadas para checar cada chamada de ferramenta via AgentCore Gateway. A ideia é simples: o agente não decide sozinho o que pode fazer. Isso é definido de forma determinística pelas políticas, com base na identidade do usuário e em suas permissões.

Processado por IA de AWS Machine Learning Blog; editado por Hamidun News
Amazon Bedrock AgentCore ganha Policy para controlar o acesso de agentes de IA
Fonte: AWS Machine Learning Blog. Colagem: Hamidun News.
Ouvir artigo
Ficha técnica e números-chave
ParâmetroDados
Fonte originalAWS Machine Learning Blog ↗
Editor-chefe
Quem exatamente iniciou a solicitaçãoum usuário específico, um papel ou um grupo
Dado-chave #2A qual ferramenta o agente recorre e qual ação ele quer executar
Dado-chave #3Se o usuário tem direito de ver esses dados ou de executar esse workflow

A Amazon descreveu um novo mecanismo separado, o Policy, no Bedrock AgentCore para proteger agentes de IA. Sua função é verificar o acesso a ferramentas e dados não pelo "bom senso" do modelo, mas por regras rígidas, executadas independentemente do raciocínio dele, tirando a segurança dos prompts e levando-a para uma camada de infraestrutura gerenciável.

Uma camada separada de regras

A ideia central é que o Policy no AgentCore cria uma camada de controle determinística. Mesmo que o agente decida que, para responder, deve abrir um serviço interno, baixar um arquivo ou chamar uma ferramenta com privilégios elevados, a decisão final não é dele. A solicitação passa por um sistema de regras separado, e só ele determina se a ação é permitida ou não.

Essa abordagem reduz o risco de o modelo interpretar mal as instruções, entender a tarefa do usuário de forma ampla demais ou tentar chegar a dados que não deveria ver.

A AWS também descreve um caminho mais prático para configurar essas restrições. As regras de negócio podem ser formuladas primeiro em linguagem natural e depois traduzidas para políticas Cedar, uma linguagem criada para descrever permissões com precisão. Em vez de um prompt vago como "não mostre documentos de outras pessoas", há uma verificação formal: quem, sob quais condições e com quais direitos o agente pode de fato abrir determinada ferramenta ou conjunto de dados. Em cenários corporativos, isso importa mais do que mais uma camada de instruções dentro do próprio prompt.

Isso é especialmente importante para agentes em cenários longos e com vários passos. O modelo pode começar a tarefa corretamente e, no meio da cadeia, decidir que precisa de mais uma ferramenta ou de um acesso mais amplo. Sem uma política externa, essas ampliações costumam ser controladas apenas pelo prompt. O Policy no AgentCore propõe um esquema mais rígido: cada novo passo é conferido de novo com as regras, mesmo que o próprio agente esteja convicto de que age no interesse do usuário.

Verificação no gateway

Na prática, o Policy é aplicado por meio do AgentCore Gateway. Esse gateway intercepta, em tempo de execução, cada solicitação do agente a uma ferramenta e a verifica antes de a ação ser executada. Ou seja, não se trata de uma configuração única no início da sessão, mas de controle em runtime: o agente pode acessar dezenas de vezes APIs, bancos de dados, armazenamentos de arquivos e serviços internos, e cada um desses passos é avaliado pela política. Isso aproxima a proteção do comportamento real do agente, e não de suas intenções iniciais.

  • Quem exatamente iniciou a solicitação: um usuário específico, um papel ou um grupo
  • A qual ferramenta o agente recorre e qual ação ele quer executar
  • Se o usuário tem direito de ver esses dados ou de executar esse workflow
  • Se é preciso negar, permitir ou restringir o acesso, dependendo do contexto

O principal destaque é o acesso identity-aware. O agente não recebe uma permissão abstrata para "trabalhar com o CRM" ou "ler documentos", mas direitos vinculados à identidade e às atribuições do usuário em cujo nome age. Se um funcionário tem acesso apenas a parte dos registros de clientes, o agente deve enxergar o mesmo limite. Se um gerente tem acesso a um conjunto de ferramentas e um analista a outro, isso também deve ser respeitado automaticamente.

Essa abordagem é particularmente útil quando o mesmo agente atende funcionários diferentes, com níveis de acesso distintos. Com isso, o Bedrock AgentCore oferece não apenas guardrails para as respostas, mas um modelo mais rigoroso de gestão das ações.

O que isso significa

A Amazon caminha para agentes de IA mais maduros para empresas, em que importa não só uma interface inteligente, mas também a execução previsível das regras. Se essa abordagem pegar, as empresas poderão conectar agentes a sistemas internos sem depender o tempo todo do cuidado do modelo. O controle de acesso passará a ser uma camada externa e verificável, o que facilita confiar tarefas reais aos agentes, da busca de dados ao acionamento de ferramentas em nome de um funcionário.

História

Perguntas frequentes sobre a notícia

O que se sabe sobre Uma camada separada de regras?

A ideia central é que o Policy no AgentCore cria uma camada de controle determinística. Mesmo que o agente decida que, para responder, deve abrir um serviço interno, baixar um arquivo ou chamar uma ferramenta com privilégios elevados, a decisão final não é dele. A solicitação passa por um sistema de regras separado, e só ele determina se a ação é permitida ou não. Essa abordagem reduz o risco de o modelo interpretar mal as instruções, entender a tarefa do usuário de forma ampla demais ou tentar chegar a dados que não deveria ver. A AWS também descreve um caminho mais prátic

O que se sabe sobre Verificação no gateway?

Na prática, o Policy é aplicado por meio do AgentCore Gateway. Esse gateway intercepta, em tempo de execução, cada solicitação do agente a uma ferramenta e a verifica antes de a ação ser executada. Ou seja, não se trata de uma configuração única no início da sessão, mas de controle em runtime: o agente pode acessar dezenas de vezes APIs, bancos de dados, armazenamentos de arquivos e serviços internos, e cada um desses passos é avaliado pela política. Isso aproxima a proteção do comportamento real do agente, e não de suas intenções iniciais. Quem exatamente iniciou a solicit

O que isso significa?

A Amazon caminha para agentes de IA mais maduros para empresas, em que importa não só uma interface inteligente, mas também a execução previsível das regras. Se essa abordagem pegar, as empresas poderão conectar agentes a sistemas internos sem depender o tempo todo do cuidado do modelo. O controle de acesso passará a ser uma camada externa e verificável, o que facilita confiar tarefas reais aos agentes, da busca de dados ao acionamento de ferramentas em nome de um funcionário.

ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
O que você acha?
Carregando comentários…