Governança em runtime no Bedrock: o que mudou

TL;DR

A atualização de governança em runtime do Amazon Bedrock AgentCore coloca políticas no caminho das chamadas do agente para ferramentas, usando Cedar no Gateway para permitir ou negar acesso antes da execução. Na prática, isso reduz a dependência de regras “soft” no prompt e aproxima governança de um modelo verificável, auditável e mais fácil de operar em produção.

O ponto mais relevante para equipes técnicas é que segurança, autorização e observabilidade passam a fazer parte do desenho do runtime, e não só da camada de aplicação. Para quem trabalha com agentes em nuvem, isso muda o jeito de pensar controle de acesso, segregação de funções e resposta a incidentes.

O que mudou na governança do AgentCore

O centro da atualização é a Policy in Amazon Bedrock AgentCore, que ficou GA em 2026-03-03 segundo a publicação oficial da AWS: blog de lançamento. Em vez de confiar apenas no comportamento emergente do modelo ou em guardrails de conteúdo, a autorização agora acontece no caminho entre o agente e o Gateway, antes da tool ser acionada.

Isso é importante porque o controle deixa de ser só “o que o modelo deveria fazer” e passa a ser “o que o runtime pode efetivamente permitir”. O enforcement com Cedar é descrito pela AWS no contexto de agentic workflows e nas páginas de policies do AgentCore.

Por que Cedar importa aqui

Cedar entra como linguagem de política para combinar principal, action, resource e conditions. A documentação de início rápido mostra uma política com condição sobre o contexto de entrada e também a aplicação via CLI com o comando agentcore add policy: getting started.

O ganho prático é separar regra de negócio e autorização do código do agente. Em um fluxo de reembolso, por exemplo, a regra pode bloquear automaticamente valores acima de um limite sem depender da “interpretação” do modelo no momento da chamada. Isso é particularmente útil quando a stack mistura várias tools, múltiplos times e requisitos de auditoria.

Governança em runtime é diferente de guardrail de conteúdo

Guardrails tradicionais costumam atuar no texto produzido ou consumido pelo modelo. Já a policy do AgentCore atua na fronteira do acesso. Essa distinção parece sutil, mas muda bastante o perfil de risco: em vez de analisar só saída, você controla a ação antes que ela alcance o sistema alvo.

Isso é especialmente relevante para agentes que operam dados sensíveis, automações financeiras ou fluxos com impacto operacional. A AWS posiciona esse enforcement no Gateway e descreve políticas com permit e forbid, o que aproxima o controle de um modelo determinístico de autorização, com menos espaço para ambiguidade do que um prompt.

Validação e análise de políticas

Outro ponto importante é que as políticas podem ser escritas em Cedar ou geradas a partir de linguagem natural, mas o fluxo documentado inclui validação e análise estática antes do enforcement. O objetivo é evitar regras que concedem acesso demais, negam tudo ou contêm condições inviáveis. A AWS detalha essa abordagem em seu blog de segurança e na documentação do AgentCore.

Na prática, isso ajuda times de segurança e compliance que precisam revisar regras sem depender de lógica proprietária espalhada pelo código. A política vira um artefato auditável, com semântica mais estável do que um prompt em produção.

O runtime também endureceu

Além da camada de policy, a atualização traz endurecimento das bases de runtime. A documentação de security best practices informa que, a partir de 2026-06-30, runtimes sem MMDSv2 passam a falhar na invocação com ValidationException, e a configuração é feita por meio de UpdateAgentRuntime com requireMMDSV2=true.

Esse tipo de mudança é importante porque fecha uma classe de riscos de infraestrutura que, em ambientes de agentes, costuma ser subestimada. Para equipes que operam automações com credenciais temporárias e dependências de metadata, a disciplina de runtime deixa de ser opcional e passa a ser requisito explícito.

Esta seção descreve a linha de runtime anunciada pela AWS em 2026. Como serviços de IA e seus controles mudam rápido, confira sempre o changelog oficial antes de levar qualquer ajuste para produção.

Observabilidade e passagem de contexto

As release notes também apontam evolução em recursos como custom header passthrough, alinhados à propagação de contexto pelo Gateway: release notes. Para agentes, isso tem valor operacional porque autorização, rastreabilidade e correlação de eventos dependem de sinais consistentes atravessando camadas.

Quando você precisa investigar uma decisão de policy, esses headers ajudam a montar o caminho entre solicitação, decisão e execução. Em sistemas distribuídos, esse encadeamento costuma ser o que separa uma investigação rápida de uma caça a logs desconexos.

Como isso se encaixa em um desenho de produção

Em um desenho maduro, o agente gera intenção, mas não decide sozinho o acesso final. A policy no Gateway define se uma tool pode ser chamada, sob quais condições e com qual escopo. O resultado é uma fronteira mais clara entre raciocínio probabilístico e controle determinístico.

Isso também favorece segregação de funções. Você pode ter times distintos cuidando do agente, da política e do alvo da tool, sem misturar regra de negócio com instrução de prompt. Em ambientes com auditoria forte, essa separação reduz retrabalho e facilita revisão de mudanças.

Exemplo de leitura prática da policy

O exemplo documentado pela AWS com reembolso limitado mostra bem essa lógica: a policy restringe a ação com base em um campo do contexto de entrada, e o runtime faz o enforcement no ponto de passagem. O detalhe técnico está na documentação de Policy in AgentCore.

Esse padrão é útil para qualquer caso em que o agente possa propor ações legítimas, mas nem todas as ações sejam aceitáveis sob a mesma circunstância. Em vez de confiar no filtro posterior, você impede a chamada inadequada antes da execução.

Por que isso importa pro dev brasileiro

No Brasil, a discussão sobre agentes não é só técnica: ela encosta em LGPD, rastreabilidade e limites claros de acesso a dados pessoais. Um agente que consulta cadastro, histórico financeiro ou dados de cliente precisa de autorização verificável, não apenas de um prompt “bem escrito”. Isso pesa ainda mais em setores regulados como bancos, seguradoras e saúde, onde o custo de uma falha operacional é alto e o compliance é parte do dia a dia.

Há também um fator de infraestrutura bem concreto. Muitas equipes brasileiras ainda operam workloads em regiões da AWS fora do país, frequentemente com latência e orçamento em BRL pressionados por câmbio. Quando cada chamada de ferramenta custa tempo, tráfego e risco, governança no runtime ajuda a evitar chamadas indevidas e reduz desperdício operacional em fluxos que já são sensíveis a custo.

Para o dev BR que saiu de bootcamp, migrou de back-end para cloud ou trabalha em time pequeno, esse tipo de controle oferece um caminho mais pragmático do que tentar resolver toda a segurança “na conversa” do modelo. A política vira documentação executável, o que conversa bem com o jeito como muitos times brasileiros precisam prestar contas para produto, jurídico e segurança ao mesmo tempo.

Limites e cuidados ao adotar

Mesmo com a nova camada de governança, o agente continua sujeito a erros de escopo, desenho ruim de tools e dependências externas frágeis. Policy não substitui testes, revisão de permissões, segmentação de credenciais nem observabilidade de ponta a ponta.

Também vale lembrar que políticas escritas de forma excessivamente permissiva podem virar uma falsa sensação de segurança. O valor do modelo está no fato de que a regra é explícita, revisável e aplicada no caminho da execução; o risco continua sendo o desenho inicial malfeito.

Conclusão

A atualização do Bedrock AgentCore sinaliza uma mudança importante: governança de agentes está saindo do terreno subjetivo do prompt e entrando no terreno verificável do runtime. Com Cedar, validação de políticas e endurecimento do runtime, a AWS aproxima agentes de um modelo em que autorização, auditoria e execução caminham juntas.

Se você mantém agentes em produção, o próximo passo prático é revisar quais tools hoje dependem só de prompt ou guardrail e mapear quais delas já podem ser protegidas por policy de runtime. Em até uma hora, abra a documentação oficial de Policy in AgentCore e adapte uma regra simples do seu caso de uso para entender onde a fronteira de autorização caberia no seu desenho atual.

Conteúdos da DIO para quem quer aprofundar

• AWS - Agentes de IA em Campo — trilha prática para criar soluções com Amazon Bedrock, AgentCore, automação e projetos aplicados em cenários reais.
• Nexa - Fundamentos de IA Generativa com Bedrock — fundamentos de IA generativa com os principais serviços da AWS, incluindo Bedrock, Nova e AgentCore.
• Nexa - Engenharia de Prompts na AWS com Claude — trilha curta para entender engenharia de prompts e uso prático de Claude no ecossistema AWS.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.