Amazon Bedrock AgentCore: governança de agentes em 2026
TL;DR
Em 2026, o Amazon Bedrock AgentCore passou a tratar governança de agentes como um problema de execução, não só de prompt: a camada de Policy decide o que pode ou não chamar tools no Gateway, com regras Cedar e modos como enforce e log-only. Em paralelo, o módulo de Evaluations mede qualidade com traces e scoring automatizado, o que ajuda a detectar regressões antes de ampliar o tráfego.
O que mudou no AgentCore em 2026
A atualização de 2026 reposiciona a governança de agentes dentro da infraestrutura da AWS. Em vez de depender só de regras escondidas no código do agent, o controle passa a ser aplicado no boundary do Gateway, com decisão centralizada sobre cada chamada de tool. A própria AWS descreve essa combinação como Policy para autorização e Evaluations para medição de qualidade, em um fluxo que conecta execução, auditoria e observabilidade.
Isso importa porque agentes autônomos tendem a acumular risco quando a lógica de decisão, o acesso a ferramentas e a evolução de prompts ficam misturados. Ao separar governança da implementação do agent, a arquitetura fica mais próxima de um sistema com limites claros: o modelo pode propor ações, mas a infraestrutura valida o que é aceitável antes de executar. A base oficial dessa mudança está no anúncio da AWS sobre o AgentCore e na documentação pública de Policy e Evaluations.
Policy: autorização declarativa para tool calls
No modelo descrito pela AWS, a Policy fica entre o Gateway e a execução da ferramenta. Isso significa que cada request pode ser avaliada por um engine de políticas antes de liberar ou negar a ação, com regras escritas em Cedar. Cedar é a linguagem de authorization da AWS para expressar condições de ALLOW e DENY de forma declarativa e auditável, algo valioso quando o agente precisa operar com permissões diferentes por contexto.
Na prática, esse desenho é útil quando o mesmo agent conversa com ferramentas de buscar informação, consultar sistemas internos e acionar automações. Você pode liberar o uso de uma busca pública, mas negar o acesso a uma ferramenta sensível que escreve em banco ou altera estados. A arquitetura reduz o raio de impacto sem exigir que cada decisão dependa da disciplina do código do agent.
O ponto central aqui é arquitetura: governança na borda é mais fácil de revisar, auditar e padronizar do que controles espalhados por prompts e handlers.
Modo log-only antes de enforce
Um detalhe operacional importante é o uso de mode log-only antes de enforce. Esse padrão permite observar quais decisões seriam bloqueadas sem interromper o tráfego real, o que ajuda a calibrar políticas, entender falsos positivos e ajustar exceções com menos risco. Em ambientes que já carregam legados e integrações, esse degrau intermediário costuma ser mais seguro do que ativar bloqueio total de uma vez.
Para times que lidam com agentes em produção, esse é um ganho concreto: dá para transformar uma revisão teórica de governança em um experimento controlado. Em vez de perguntar apenas se a política está correta, você compara o comportamento esperado com o comportamento observado, antes de mudar o modo para enforcement.
Evaluations: qualidade baseada em traces
O outro eixo da atualização é o AgentCore Evaluations. A documentação oficial descreve um fluxo que converte traces de execução para um formato unificado e aplica avaliadores para produzir scores de qualidade. Isso aproxima a verificação de agentes de uma rotina de engenharia de software: você mede comportamento real, não só saída isolada em um prompt de teste.
Na prática, isso abre espaço para comparar versões do mesmo agent quando mudam prompts, tools, políticas ou estratégias de roteamento. Se uma alteração melhora a taxa de sucesso, mas piora consistência em edge cases, as avaliações ajudam a enxergar esse trade-off com dados. É um passo importante para times que querem sair do “funcionou no teste manual” e chegar a um ciclo mais repetível de validação.
A AWS também expõe evaluators por ARN e documenta controles de acesso para esses recursos, o que reforça a ideia de governança aplicada ao ciclo de vida do agent. Em outras palavras, não se trata só de rodar avaliações, mas de integrar isso ao processo de implantação e de observação contínua.
LLM-as-a-Judge com limite
O uso de técnicas do tipo LLM-as-a-Judge aparece como parte do arsenal de avaliação. Isso é útil para tarefas qualitativas, como relevância, completude e aderência a instruções, mas não substitui métricas operacionais nem validações humanas em fluxos críticos. Para produção, o desenho mais responsável é combinar score automático, amostragem manual e monitoramento de incidentes reais.
O valor do AgentCore aqui não está em prometer perfeição, e sim em fornecer uma trilha de avaliação padronizada. Quando o agente muda de comportamento, você tem uma forma de evidenciar a mudança em vez de confiar apenas em percepção subjetiva.
Como isso afeta a engenharia de agentes
A atualização empurra a equipe para um desenho mais modular. O agent gera intenções, o Gateway controla acesso, a Policy define fronteiras e as Evaluations medem qualidade ao longo do tempo. Isso facilita a separação entre experimentação e produção, e também reduz a dependência de revisão manual em cada ajuste de prompt.
Esse modelo combina bem com times que já usam infraestrutura como código e desejam registrar regras de acesso em formato revisável. Em vez de embutir permissões em várias camadas de aplicação, você concentra a autorização em uma política única, com alternativas claras para observação, auditoria e bloqueio.
Se o seu agent toma decisões que afetam dados, automações ou custos, a pergunta deixa de ser “o modelo respondeu certo?” e passa a ser “quem impede uma ação errada de virar execução?”.
Por que isso importa pro dev brasileiro
No contexto brasileiro, há um fator concreto que pesa bastante: custo e latência de operação em nuvem. Muitos times rodando workloads na AWS precisam equilibrar orçamento em BRL com regiões fora do país, o que torna ainda mais importante evitar chamadas indevidas de tool e retrabalho por regressão. Se um agent dispara ações erradas em uma automação paga, o impacto aparece rápido na fatura.
Existe também a questão regulatória. Em cenários com dados pessoais, a LGPD exige mais atenção a finalidade, minimização e controle de acesso, então uma política declarativa na borda ajuda a demonstrar que o agente não tem liberdade irrestrita sobre ferramentas sensíveis. Para empresas brasileiras que lidam com atendimento, operações financeiras ou dados de clientes, isso encurta a distância entre engenharia e compliance.
Além disso, o mercado brasileiro mistura muito time novo em cloud, bootcampers e profissionais em transição com sistemas legados e alta pressão por entrega. Um mecanismo de governança que sai do código do agent e fica no boundary reduz a chance de erro por lacuna de experiência individual. Isso é especialmente relevante quando a equipe precisa colocar IA em produção sem multiplicar a complexidade operacional.
Como começar com segurança
O caminho mais prudente é tratar Policy e Evaluations como etapas complementares. Primeiro, modele quais tools um agent realmente precisa acessar e comece com perguntas simples: o que deve ser sempre negado, o que pode ser liberado por contexto e quais ações merecem logs antes de bloqueio. Depois, use avaliações para observar se a mudança de regras alterou acurácia, taxa de falha ou comportamento em casos extremos.
Se o seu agent já existe, a migração faz mais sentido quando você consegue medir uma linha de base. Sem baseline, qualquer política nova vira opinião. Com baseline, você compara antes e depois com mais clareza, especialmente em fluxos onde o risco maior não é a resposta textual, mas a execução de uma ferramenta errada.
A documentação oficial da AWS muda com frequência em serviços de IA, então vale conferir o changelog e os limites atuais antes de levar um fluxo para produção.
Conclusão
O update de 2026 do Amazon Bedrock AgentCore mostra uma mudança importante: em vez de confiar só na inteligência do agent, a arquitetura passa a controlar ações e medir qualidade no nível de infraestrutura. Policy, com Cedar, cuida das fronteiras de execução; Evaluations cuida da leitura contínua de comportamento, usando traces e sinais de qualidade. Para quem está construindo agentes em produção, isso é uma base mais sólida do que depender apenas de prompts e testes manuais.
Se você quer transformar isso em prática em menos de uma hora, abra a documentação oficial do Cedar no AgentCore e escreva uma política simples de default-deny para uma tool não sensível do seu desenho atual. Em seguida, leia a página de Evaluations e anote quais traces do seu agent poderiam virar uma linha de base de qualidade.
Conteúdos da DIO para quem quer aprofundar
- AWS - Agentes de IA em Campo — trilha prática para construir soluções com Amazon Bedrock, agentes autônomos e projetos aplicados em AWS.
- Formação AWS Cloud Foundations — base para entender serviços essenciais da AWS, arquitetura cloud e segurança de ambientes.
- Nexa - Engenharia de Prompts na AWS com Claude — foco em engenharia de prompts e uso prático de IA generativa no ecossistema AWS.
- Descubra a Nuvem AWS – LocalizaLabs — introdução à computação em nuvem na AWS para quem está começando ou migrando de carreira.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
