AWS Bedrock AgentCore: governança em runtime na prática
TL;DR
As novidades mais recentes do Amazon Bedrock AgentCore reforçam governança em tempo de execução em três frentes: isolamento por sessão, autorização no boundary entre gateway e tools, e controles operacionais de ciclo de vida. Na prática, isso reduz a chance de um agente executar ações fora da política esperada e ajuda a manter previsibilidade quando o fluxo envolve ferramentas, dados e estado persistente.
O que mudou na governança do runtime
O ponto central não é só “rodar um agente”, mas decidir o que ele pode fazer enquanto executa. A documentação de segurança do AgentCore descreve que cada sessão roda em uma microVM dedicada, com isolamento de CPU, memória e filesystem, e que operações de runtime passam por avaliações de autorização no runtime e no endpoint. Isso coloca a governança dentro do caminho crítico da execução, em vez de tratá-la como uma camada externa e opcional. Fonte oficial
O segundo eixo é a camada de Policy in AgentCore. O Gateway intercepta requests do agente e avalia cada chamada de tool antes de liberar acesso, usando Cedar como linguagem de política. O efeito prático é simples de entender: o agente não “ganha” acesso porque pediu; ele só avança se a policy permitir. Policy no AgentCore · Cedar no AgentCore
Em paralelo, o runtime ganhou evolução de dados e estado, como filesystem bring-your-own e session storage gerenciado. Isso importa porque governança não é só bloqueio: também é delimitar onde o estado vive, como ele é persistido e quando ele expira. BYO filesystem no runtime · Session storage gerenciado
Isolamento por sessão: a base do controle
Quando se fala em agente com tools, o primeiro risco prático é o vazamento entre sessões. A resposta do AgentCore é isolar cada sessão em uma microVM dedicada. Isso significa que a superfície operacional deixa de ser um processo compartilhado e passa a ser um ambiente com fronteiras mais claras para dados e execução. Documentação de segurança do runtime
Esse detalhe é importante para times que lidam com credenciais temporárias, execução longa e múltiplos usuários concorrentes. Num cenário comum de produto no Brasil, com times enxutos e pressão por custo, esse tipo de boundary ajuda a reduzir o esforço de separar estados manualmente entre workers, filas e contêineres, sem depender apenas de disciplina de aplicação.
Por que microVM muda a conversa
MicroVM não é um detalhe cosmético. Ao separar CPU, memória e filesystem por sessão, o runtime torna mais difícil que um erro de uma sessão contamine outra. Para quem está desenhando agentes com acesso a consultas internas, arquivos temporários ou ferramentas de automação, isso é uma camada adicional de contenção. Fonte oficial
Esta seção descreve capacidades do AgentCore Runtime publicadas nas páginas oficiais citadas. APIs e comportamentos de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Policy no boundary: o agente pede, a política decide
A mudança mais relevante para governança é que a autorização passa a acontecer no boundary entre o agente e as tools. O Gateway do AgentCore intercepta a interação, avalia a request contra policies e só então libera a ação. É a diferença entre confiar na instrução natural da aplicação e aplicar uma regra explícita antes da execução. Policy in Amazon Bedrock AgentCore
O uso de Cedar também traz um modelo mental previsível: default deny, com permit e forbid definidos na policy. Na prática, isso favorece uma postura conservadora por padrão, útil quando o agente pode chamar ferramentas que alteram dados, acionam integrações ou manipulam recursos sensíveis. Entendendo Cedar no AgentCore
Governança com semântica explícita
Em arquitetura de agentes, confiar só no prompt é pedir para o controle morar no lugar errado. A política no boundary tira essa responsabilidade do texto do modelo e coloca numa camada verificável. Assim, ações como leitura, escrita, refund, criação de item ou execução de comando podem ser condicionadas a atributos do principal, do recurso ou da operação solicitada. Guia introdutório de policy
Lifecycle settings: governança operacional também conta
Além de autorização e isolamento, o runtime traz controles de ciclo de vida. A documentação cita, por exemplo, o parâmetro idleRuntimeSessionTimeout, com valor padrão de 900 segundos, para encerrar recursos quando a sessão fica ociosa. Isso é governança em um sentido bem prático: limitar custo, fechar superfícies abertas e reduzir o tempo de exposição do estado. Lifecycle settings do runtime
Esse tipo de ajuste faz diferença em equipes brasileiras que precisam equilibrar experimentação com orçamento. Em muitos produtos SaaS no Brasil, o orçamento de nuvem ainda é apertado e sensível ao câmbio; ter timeout operacional explícito evita que sessões esquecidas virem custo invisível em moeda forte.
Dados e estado: BYO filesystem e session storage
Governança também passa por onde os dados do agente ficam. O runtime passou a suportar filesystem trazido pelo usuário, com integração com S3 Files e EFS, montado por sessão. A novidade é relevante porque traz persistência e acesso a arquivos dentro de uma fronteira mais controlada, sem exigir cópia manual para fora do sandbox. Anúncio oficial
Outro avanço é o managed session storage em preview, que persiste o estado do filesystem para que a mesma sessão possa ser retomada com o mesmo identificador. Isso é útil para agentes que precisam manter contexto de trabalho ao longo do tempo, sem transferir o estado para um mecanismo improvisado na aplicação. Anúncio oficial
O ganho de governança aqui é concreto: em vez de espalhar arquivos temporários, checkpoints e artefatos entre serviços, o estado passa a ter um ponto mais claro de administração. Para casos com dados sensíveis, isso também facilita alinhar retenção, acesso e descarte com exigências internas e com a LGPD, já que o ciclo do dado fica mais explícito dentro da arquitetura.
Por que importa pro dev brasileiro
No contexto brasileiro, essa combinação pesa por três motivos concretos. Primeiro, a LGPD exige disciplina maior com dados pessoais, retenção e finalidade, então qualquer camada de isolamento e política em runtime ajuda a reduzir o risco de exposição indevida. Segundo, times no Brasil frequentemente operam com estruturas menores e precisam de controles que diminuam dependência de revisão manual constante. Terceiro, o custo de nuvem em BRL sofre com câmbio e com decisões de região; por isso, sessões ociosas, estado mal administrado e cópias desnecessárias de dados aparecem rápido na conta. LGPD
Em um cenário assim, governance em runtime não é luxo de plataforma grande. É a diferença entre um agente que vira experimento isolado e um agente que pode entrar em produção com fronteiras mais claras para segurança, custo e auditoria.
Conclusão
O refinamento mais importante do AWS Bedrock AgentCore não é apenas adicionar recursos; é aproximar governança do ponto onde a ação acontece. MicroVM por sessão, policy no gateway e lifecycle settings formam uma malha que ajuda a tratar agentes como sistemas executores, não como caixas-pretas soltas na aplicação. Se o seu caso envolve ferramentas que alteram dados, arquivos ou integrações internas, esse é exatamente o tipo de boundary que vale revisar agora.
Como passo prático, abra a documentação de getting started de policy e compare uma tool crítica da sua arquitetura com uma regra Cedar de allow/deny; em seguida, revise o timeout de sessão ociosa para caber no seu perfil real de uso.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
