Governança de agentes no AWS Bedrock AgentCore
TL;DR
Em 2026, o AWS Bedrock AgentCore consolidou duas peças de governança para agentes: Policy, com enforcement baseado em Cedar e lógica default-deny, e Evaluations, para medir qualidade e segurança de forma contínua. Na prática, isso tira parte do controle crítico do código do agente e leva a decisão para uma camada declarativa, mais auditável e previsível.
O efeito para times de produto e plataforma é direto: o agente deixa de “poder tudo até dar erro” e passa a operar dentro de regras explícitas sobre tools, dados e contexto de execução. Para quem constrói IA em nuvem no Brasil, isso é especialmente útil quando a solução precisa conviver com LGPD, auditoria interna e limites claros de acesso a dados sensíveis.
A mudança de paradigma: agente com permissão explícita
O ponto central do lançamento de Policy in Amazon Bedrock AgentCore é simples: governança deixa de ser um conjunto de checagens espalhadas no runtime do agente e passa a ser controlada por política, no gateway, com semântica de autorização definida por Cedar. A AWS descreve esse comportamento como default-deny: se nenhuma regra de permissão casar, a ação é negada.
Isso importa porque agentes não falham só por bugs tradicionais. Eles também podem escolher ferramentas erradas, acessar dados fora do escopo ou executar ações válidas no papel, mas inadequadas para o contexto do negócio. Ao colocar a decisão de permitir ou negar fora do fluxo livre do modelo, você reduz a dependência de prompts “bons o suficiente” para manter o sistema seguro.
O que a policy controla na prática
Segundo a documentação oficial, a policy no AgentCore é aplicada para governar interações de agent-to-tool e também o uso de dados no gateway, com enforcement estruturado no ponto de entrada (docs oficiais). Isso permite tratar acesso a ferramenta como uma capacidade explicitamente concedida, e não como consequência implícita de prompt ou do comportamento do modelo.
Esse detalhe é importante para times que trabalham com fluxos mais sensíveis. Um agente que acessa sistemas internos, integrações de finanças, bases de RH ou informações de clientes precisa de um modelo de autorização que possa ser revisado por segurança, plataforma e engenharia juntos.
Cedar e o valor do default-deny
A semântica padrão do Cedar ajuda a criar previsibilidade operacional. Em vez de confiar em “se o modelo entender, ele faz”, você define o que é permitido, o que é negado e em quais condições a decisão muda. A AWS reforça essa abordagem no material sobre segurança de agentes com policy no AgentCore.
Na prática, isso aproxima agentes de um modelo que equipes de segurança já conhecem melhor: autorização explícita, revisão de regras e rastro de decisão. Para ambientes corporativos, isso é muito mais defensável em auditoria do que checks dispersos em código e prompts.
Policy e Evaluations: governança não termina no deploy
O anúncio da AWS posiciona Policy e Evaluations como camadas complementares para “trusted AI agents” em produção (AWS News Blog). A lógica é boa: não basta impedir comportamento indevido se você não mede continuamente a qualidade do agente em cenários reais.
Em outros termos, policy reduz o risco de ação indevida, enquanto evaluations ajudam a observar degradação de qualidade, regressões e edge cases. Isso é especialmente relevante em agentes que mudam com frequência, recebem novos tools ou passam a operar em domínios mais sensíveis.
O que o AgentCore Evaluations adiciona
O recurso AgentCore Evaluations chegou a GA em 2026-03 para permitir avaliação automatizada de agentes com amostragem de traces e avaliadores built-in ou customizados. A proposta é acompanhar comportamento ao longo do ciclo de vida do agente, não apenas em testes pontuais antes do release.
Para times que operam em CI/CD, isso permite criar uma camada de validação contínua: o agente sobe, executa, gera traços e passa por medições de qualidade e segurança ao longo do tempo. Em uma stack de produção, essa observabilidade vira tão importante quanto logs e métricas tradicionais.
Como pensar a arquitetura de forma operacional
Se você estiver montando um agente em Bedrock AgentCore, vale separar mentalmente três planos. O primeiro é o plano da intenção, onde o modelo decide a próxima ação. O segundo é o plano de autorização, onde policy barra ou libera a ação. O terceiro é o plano de avaliação, onde você mede se o comportamento resultante continua aceitável.
Esse recorte ajuda a evitar um erro comum: empurrar toda a responsabilidade para o prompt. Prompt ajuda, mas não substitui autorização estruturada nem análise contínua de qualidade. Em ambientes de produção, essa divisão de funções reduz surpresa operacional.
Fluxo de confiança em uma implementação típica
O tutorial oficial de primeiros passos com Policy no AgentCore mostra o caminho de configurar a policy, associá-la ao gateway e testar o enforcement. O valor do fluxo está menos no comando em si e mais no padrão: criar regras, vinculá-las ao ponto de controle e validar a resposta do sistema antes de expor o agente para uso amplo.
Em sistemas com múltiplos tools, esse fluxo permite impor fronteiras bem claras. Você pode, por exemplo, autorizar apenas um subconjunto de ações em ambiente de homologação, e expandir gradualmente conforme a maturidade do caso de uso aumenta.
Esta seção descreve a versão 2026 do AWS Bedrock AgentCore. APIs e fluxos de agentes mudam rápido — confira a documentação oficial antes de adotar em produção.
Por que isso importa pro dev brasileiro
No Brasil, governança de agentes não é só uma questão técnica; ela conversa com LGPD e com a necessidade de justificar acesso a dados pessoais e dados sensíveis em auditorias internas. Em muitas empresas daqui, o mesmo agente que automatiza atendimento ou busca em base interna também cruza informações de cliente, contrato e operação, então a autorização precisa ser detalhada e rastreável.
Além disso, o cenário brasileiro costuma combinar times enxutos, orçamento em reais e dependência forte de serviços gerenciados na AWS. Nesse contexto, investir em um modelo de governança que já nasce com policy e evaluations pode ser mais viável do que criar uma camada própria de autorização e testes para cada agente do zero.
Há também um fator prático de operação: várias aplicações brasileiras usam regiões globais da AWS para reduzir esforço de arquitetura, mas isso aumenta a relevância de controles consistentes de acesso, compliance e observabilidade. Quando a latência e a distribuição geográfica já são desafios, simplificar a governança dentro da plataforma ajuda a reduzir complexidade na pilha.
Onde o time costuma errar
Um erro recorrente é confundir “o agente sabe o que não deve fazer” com “o sistema impede que ele faça”. São coisas diferentes. O primeiro depende da qualidade do modelo e do prompt; o segundo depende de policy, fronteiras de execução e validação no gateway.
Outro erro é usar avaliação só no final do projeto. Com agentes, o comportamento muda quando o catálogo de ferramentas cresce, quando a base de conhecimento é atualizada ou quando o prompt sofre ajustes. Evaluations contínuas ajudam a capturar essas mudanças antes que elas virem incidente.
Boas perguntas para revisão arquitetural
- Quais tools este agente realmente precisa acessar?
- Quais ações devem ser explicitamente negadas por padrão?
- Quais decisões precisam ser auditáveis por segurança e compliance?
- Quais métricas de qualidade precisam ser monitoradas após cada mudança?
Essas perguntas parecem simples, mas resolvem boa parte dos problemas que aparecem quando um agente sai do laboratório e entra em ambiente corporativo.
Conclusão
O avanço do AWS Bedrock AgentCore em 2026 mostra uma direção clara: agentes confiáveis não dependem só de prompts melhores, e sim de governança declarativa e avaliação contínua. Policy com Cedar estabelece fronteiras objetivas; Evaluations cria o hábito de medir o que o agente faz ao longo do tempo.
Se você trabalha com IA em produção, comece com um passo pequeno: escolha um agente interno, liste as ações que ele pode executar e desenhe uma policy de default-deny para um único tool crítico. Em seguida, leia a seção de getting started da documentação oficial e adapte esse controle ao seu fluxo atual em menos de 1 hora.
Conteúdos da DIO para quem quer aprofundar
- Nexa - Fundamentos de IA Generativa com Bedrock — trilha curta para entender como aplicar serviços da AWS, incluindo Bedrock e AgentCore, em projetos práticos de IA generativa.
- Nexa - Engenharia de Prompts na AWS com Claude — reforça fundamentos de prompting e uso prático de IA generativa na AWS, útil para quem vai integrar agentes com mais controle.
- Formação AWS CLF-02 Practitioner — base sólida de computação em nuvem AWS, com conceitos de custo, segurança, conformidade e arquitetura.
- Nexa - Análise Avançada de Imagens e Texto com IA na AWS — traz aplicações práticas de IA na AWS para multimodalidade, análise e automação de tarefas.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
