AWS Bedrock AgentCore em 2026: segurança, rede e sessão

TL;DR

O runtime do Amazon Bedrock AgentCore evoluiu em 2026 em três frentes que impactam diretamente a arquitetura: execução de comandos dentro da sessão, persistência gerenciada de filesystem em preview e novas opções de compute persistente. Na prática, isso amplia a superfície operacional do agente, mas também exige controles mais rígidos de acesso, observabilidade e desenho de estado.

O que mudou no runtime em 2026

O ponto mais sensível da atualização é a chegada de uma API para executar comandos de shell dentro de uma sessão ativa, chamada InvokeAgentRuntimeCommand. A própria AWS descreve essa capacidade como streaming de saída em tempo real e retorno de exit code, o que aproxima o agente de um fluxo de automação mais determinístico.

Em paralelo, a AWS anunciou managed session storage em preview para persistir estado de filesystem entre ciclos de stop e resume. Isso muda o papel da sessão: além de carregar contexto conversacional, ela agora pode carregar artefatos gerados ao longo da execução.

Para completar o pacote, a documentação do runtime continua descrevendo o isolamento por microVM dedicada por sessão, com estados como Active e Idle. E a AWS também passou a falar em runtime instances como compute persistente para cargas que não cabem bem no modelo mais efêmero.

Segurança: a nova superfície não é só o agente, é o runtime

Quando um runtime passa a aceitar comandos de shell, a fronteira de segurança sai do “o que o modelo responde” e entra no “o que a sessão pode executar”. Isso pede IAM mais granulado, revisão de permissões por função e separação clara entre invocar o agente e autorizar comandos dentro do ambiente de execução.

O próprio ecossistema do AgentCore já expõe ações específicas no CLI, incluindo bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:InvokeAgentRuntimeForUser e bedrock-agentcore:InvokeAgentRuntimeCommand. Isso é um sinal importante de maturidade operacional: o acesso ao runtime deixou de ser monolítico e passou a exigir desenho explícito de privilégio mínimo.

Na prática, o time precisa tratar esses comandos como faria com qualquer plano de execução dentro de infraestrutura gerenciada. Se um agente puder consultar dados, escrever arquivos e acionar comandos no mesmo ciclo, o risco não está só em prompt injection; está também em escalonamento indevido de permissões, vazamento de credenciais e execução de ações fora do escopo previsto.

O que observar na política de acesso

• Separar permissões de leitura, execução e operação administrativa.
• Restringir qualquer uso de comando a papéis humanos ou fluxos muito específicos.
• Auditar qual identidade de usuário está associada a cada sessão quando houver invocação “for user”.
• Registrar saída, exit code e contexto da chamada para rastreabilidade.

Rede e isolamento: o que a microVM resolve e o que ela não resolve

O modelo de isolamento por microVM dedicada por sessão é relevante porque reduz a chance de vazamento entre sessões por construção. A documentação oficial descreve o runtime com isolamento de CPU, memória e filesystem, o que ajuda a conter impactos laterais entre workloads diferentes da plataforma.

Mas isolamento de microVM não substitui política de rede. Uma sessão isolada ainda pode abrir caminhos indevidos se a aplicação deixar egress livre para destinos que não fazem parte do fluxo do agente. Para arquitetura de produção, isso significa revisar endpoints, dependências externas e qualquer ponte com serviços internos antes de assumir que o isolamento do runtime cobre tudo.

Essa distinção é especialmente importante em empresas brasileiras que precisam conciliar requisitos técnicos com compliance. Em cenários sujeitos à LGPD, por exemplo, o desenho de rede e de retenção de artefatos precisa acompanhar o ciclo de vida da sessão, porque persistência de estado e armazenamento temporário podem carregar dados pessoais ou dados derivados de negócio que exigem cuidado adicional.

Comportamento de sessão: persistência muda a forma de pensar estado

Antes da novidade de session storage, muitos fluxos dependiam de lógica própria de checkpoint para salvar progresso, intermediários e artefatos. Com o managed session storage, parte desse trabalho passa a ser gerenciado pela plataforma, com a intenção de manter o filesystem do agente entre stop e resume dentro dos limites documentados.

Isso muda o desenho de agentes que geram arquivos temporários, fazem análise incremental ou precisam retomar uma etapa sem reconstruir tudo do zero. O ganho está na redução de código de cola, mas o custo é arquitetural: agora você precisa decidir com clareza o que deve persistir, por quanto tempo e sob qual política de descarte.

Também faz diferença operacional saber que a sessão não é sinônimo de “estado eterno”. O runtime continua tendo limites e transições, e isso afeta tarefas longas, jobs em background e qualquer estratégia que tente usar a sessão como armazenamento genérico. Em outras palavras: persistência gerenciada não elimina governança; ela só desloca a responsabilidade para uma camada mais próxima da plataforma.

Quando isso ajuda de verdade

• Gerar artefatos intermediários e retomá-los depois sem reprocessar tudo.
• Executar workflows com etapas de validação, correção e reexecução.
• Reduzir lógica manual de checkpoint em agentes com múltiplos passos.

Runtime instances: compute persistente para outro perfil de workload

O anúncio de runtime instances indica que a própria AWS está acomodando mais de um estilo de execução para agentes. Há workloads que se beneficiam de continuidade de compute, e há outras que funcionam melhor em ciclos mais curtos e isolados.

Para o arquiteto, isso significa abandonar a ideia de um único modelo ideal de execução. Se o agente mantém contexto, estado de filesystem e necessidade de retomada, o custo de desligar e religar tudo pode ficar alto demais. Em contrapartida, compute mais persistente aumenta a necessidade de observabilidade, controle de capacidade e disciplina no descarte de estado antigo.

Esse é um ponto onde a equipe técnica costuma ganhar ao medir antes de decidir. Em vez de adotar o modelo mais estável por intuição, vale comparar latência percebida, tempo de retomada e consumo de recursos no fluxo real. O runtime está abrindo espaço para essa decisão, mas não substitui a medição.

Por que isso importa pro dev brasileiro

No contexto brasileiro, essa atualização conversa diretamente com duas pressões comuns: orçamento em BRL e exigência de conformidade. Quando um time precisa justificar custo em dólar, qualquer aumento de persistência ou de execução contínua precisa ser traduzido em impacto real no produto, especialmente em empresas que operam com margens mais apertadas ou com variação cambial relevante.

Além disso, a LGPD impõe atenção redobrada ao ciclo de dados pessoais e ao propósito do processamento. Se um agente persistir arquivos, logs ou saídas de execução na sessão, o time precisa saber exatamente onde esses dados ficam, por quanto tempo permanecem e quem pode acessá-los. Isso não é detalhe de infra; é parte da governança do produto.

Em muitas equipes brasileiras, o caminho até produção passa por times pequenos, com boa parte da engenharia acumulando função de plataforma, segurança e aplicação ao mesmo tempo. Nesse cenário, a divisão clara entre invocar agente, executar comando e manter estado persistente ajuda a reduzir improviso e torna a operação mais auditável.

Como eu olharia isso antes de colocar em produção

Minha leitura é que o update de 2026 transforma o AgentCore Runtime em algo mais próximo de uma plataforma de execução controlada do que de um simples invocador de agentes. Isso é bom para casos de uso mais ricos, mas também eleva o custo de fazer “na pressa”.

O caminho mais seguro é tratar a sessão como fronteira explícita, revisar permissões por ação, certificar que a rede só alcança o necessário e definir o que pode ou não persistir no filesystem do agente. Se o seu fluxo usa dados sensíveis, a revisão precisa acontecer antes do primeiro teste com usuário real, não depois.

Conclusão

O update do runtime do Amazon Bedrock AgentCore em 2026 amplia a capacidade operacional dos agentes, mas também aumenta a responsabilidade do time em segurança, rede e gestão de sessão. Execução de comandos, storage persistente e compute mais estável são avanços úteis, desde que venham acompanhados de IAM restritivo, observabilidade e política clara de dados.

Se você quer validar isso no seu cenário, abra a documentação oficial do runtime, compare as permissões do CLI e desenhe uma matriz simples com três colunas: o que executa, o que persiste e o que pode sair da rede. Em até uma hora, você consegue aplicar essa revisão ao seu agente atual e identificar o primeiro ajuste de segurança que deve entrar no backlog.

Conteúdos da DIO para quem quer aprofundar

• AWS - Agentes de IA em Campo — trilha prática para criar soluções com Amazon Bedrock, Agentes e projetos aplicados em cloud.
• Bradesco - Agentes de IA do Zero a Prática — caminho hands-on para entender agentes, automação e integrações com Python, CrewAI e MCP.
• Formação DevOps Fundamentals — base para pensar observabilidade, entrega e operação contínua em workloads de cloud.

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