Sandbox Governado para Agentes de IA na AWS

Agentes de IA estão saindo do chat e passando para a execução. Eles não apenas respondem perguntas. Eles executam código, chamam ferramentas, leem repositórios, consultam sistemas internos, abrem tickets, analisam arquivos e tomam ações em fluxos de trabalho de negócio.

Isso muda o problema de arquitetura. Se um agente pode agir, ele precisa de um lugar governado para agir.

Para empresas que têm a AWS como plataforma principal, a pergunta não é apenas qual modelo usar. A pergunta mais difícil é onde a execução do agente acontece, o que ele pode alcançar, quais credenciais recebe, como as ferramentas são expostas, onde a aprovação humana é obrigatória e como cada ação é auditada.

Em outras palavras: agentes precisam de um perímetro. Modelos fornecem o raciocínio. Ferramentas criam o impacto. O sandbox define o raio de impacto.

O que é um sandbox governado para agentes de IA?

Um sandbox governado para agentes de IA é uma fronteira de execução controlada onde agentes podem executar código, chamar ferramentas aprovadas, acessar dados escopados e interagir com sistemas internos sob controles explícitos de identidade, rede, logs, política e aprovação.

Não é um template de prompt, um chatbot com outro nome ou um container com uma chave de API ampla. É um padrão operacional para decidir o que o agente pode fazer, quais ferramentas pode chamar, com qual identidade atua, quais caminhos de rede alcança, o que fica registrado e quando uma pessoa precisa aprovar a próxima etapa.

Para quem isso faz sentido

Bom encaixe	Provavelmente não é a primeira prioridade
Equipes que dão a agentes acesso a repositórios, logs de CI, arquivos, dados, tickets, APIs internas ou recursos AWS	Assistentes simples de chat que respondem perguntas sem executar ferramentas ou acessar dados privados
Times de plataforma, segurança e IA padronizando como múltiplos fluxos de agentes devem rodar na AWS	Experimentos isolados em que o agente não tem credenciais, caminho de escrita ou papel persistente no fluxo de trabalho
Organizações que precisam de auditoria, menor privilégio, conectividade privada e aprovação humana antes que agentes toquem ambientes críticos	Times que ainda estão avaliando se agentes têm valor de negócio suficiente para justificar execução controlada

Por que a atualização do Claude importa

A atualização de Managed Agents do Claude é um sinal de mercado importante porque separa o loop do agente da execução de ferramentas. A Anthropic descreve sandboxes controlados pelo cliente e conectividade MCP privada para que ferramentas executem dentro da infraestrutura controlada pelo cliente. O anúncio também indica que self-hosted sandboxes estão em beta público e MCP tunnels em research preview, então equipes devem tratar essas capacidades como infraestrutura emergente, não como padrão corporativo definitivo.

A lição para AWS é mais ampla do que Claude. Execução de agentes, acesso a ferramentas, identidade, observabilidade e aprovações precisam fazer parte do ambiente de cloud governado.

As seis camadas de controle

Camada	Pergunta a responder	Direção AWS
Runtime	Onde o agente roda, escala e para?	AgentCore Runtime, ECS, EKS, Fargate, Lambda ou runtime customizado
Ferramentas	Quais ações o agente pode chamar?	AgentCore Gateway, servidores MCP, API Gateway, Lambda, catálogos de ações aprovadas
Identidade	Em nome de quem o agente atua?	IAM, Identity Center, Cognito, AgentCore Identity e service roles escopadas
Rede	O que o runtime consegue alcançar?	VPC, sub-redes privadas, controle de saída de rede (egress), PrivateLink, security groups
Dados e segredos	Quais arquivos, bases e credenciais podem entrar no fluxo de trabalho?	Políticas de S3, Secrets Manager, KMS, credenciais temporárias, filesystems isolados
Evidência e aprovação	O que é registrado, avaliado, revisado e bloqueado?	CloudWatch, CloudTrail, OpenTelemetry, AgentCore Observability, avaliações, políticas e aprovações

O Amazon Bedrock AgentCore se encaixa nessa conversa porque a AWS o posiciona como uma plataforma agentic para criar, implantar, operar, monitorar e avaliar agentes com capacidades como Runtime, Gateway, Policy, Memory, Identity, Evaluations, Observability, Code Interpreter e Browser. O AgentCore Gateway pode expor APIs, funções Lambda e serviços existentes como ferramentas compatíveis com MCP. O AgentCore Code Interpreter oferece um ambiente sandbox para escrita e execução de código.

Qual padrão de sandbox se encaixa?

Padrão	Use quando	Pontos de atenção
AgentCore Runtime com AgentCore Gateway	Você quer deploy gerenciado de agentes, ferramentas compatíveis com MCP, integração de identidade, observabilidade e controles de política	Verifique disponibilidade regional, preço, quotas, maturidade do serviço e aderência ao seu framework e requisitos de residência de dados
AgentCore Code Interpreter	O agente precisa de execução controlada de código, análise, processamento de arquivos ou scripts gerados	Valide filesystem, modo de rede, instalação de pacotes, logs e isolamento contra o seu modelo de risco
Sandbox em ECS ou Fargate	Você precisa de containers customizados, controle de pacotes, imagens reproduzíveis e operações AWS familiares	Exige engenharia de plataforma para isolamento, ciclo de vida, identidade e saída de rede
Sandbox em EKS	Você já padroniza workloads em Kubernetes e precisa de isolamento ou políticas avançadas de plataforma	A complexidade operacional pode ser maior que o valor de um primeiro piloto
Ferramentas em Lambda	O agente só precisa de ações estreitas e determinísticas por funções aprovadas	Não é ideal para tarefas longas, stateful ou com muitas dependências
Padrão híbrido	Você quer um runtime de agente, mas ferramentas, sandboxes e aprovações governados separadamente	Tem mais partes móveis, mas costuma ser o modelo mais forte para fluxos de trabalho corporativos sensíveis

Demo de agente vs sistema governado

Demo de agente	Sistema governado de agentes
Roda no notebook de um desenvolvedor ou em um conector SaaS	Roda em um runtime aprovado na AWS
Usa credenciais amplas de usuário ou serviço	Usa credenciais escopadas, auditáveis e específicas para a finalidade
Chama ferramentas diretamente	Chama ações aprovadas por um gateway ou interface MCP
Tem alcance de rede pouco claro	Usa regras explícitas de VPC, PrivateLink, security groups e saída de rede
Registra apenas a resposta final	Registra chamadas de ferramentas, argumentos, aprovações, falhas e efeitos
Funciona para um experimento isolado	Vira um padrão reutilizável para vários fluxos de trabalho
Depende de confiar no modelo	Depende de arquitetura, política, logs e aprovação humana

Um primeiro piloto prático

Comece por um fluxo de trabalho, não por um programa de plataforma. Um bom candidato inicial é um agente de desenvolvimento que revisa falhas de CI, inspeciona um repositório, propõe uma correção, roda testes em sandbox e abre um pull request para revisão humana.

Recurso	Acesso necessário	Risco	Controle
Repositório Git	Leitura e escrita em branch	Alteração de código	Token escopado, política de branch e mudanças apenas via PR
Logs de CI	Leitura	Saída de build sensível	Role somente leitura, filtragem de logs e política de retenção
Registro de pacotes	Leitura e instalação	Exposição de supply chain	Registries aprovados, lockfiles e controle de saída de rede
Segredos	Idealmente nenhum	Vazamento de credenciais	Sem acesso direto; acesso intermediado apenas quando justificado
APIs internas	Ações limitadas	Efeitos de negócio	Gateway de ferramentas, operações permitidas e regras de aprovação
Filesystem do runtime	Arquivos temporários	Persistência ou exfiltração	Workspace efêmero, política de limpeza e logs de arquivos

MCP é uma interface, não um modelo de governança

MCP é útil porque dá aos agentes uma forma padronizada de descobrir e chamar ferramentas. Ele não decide, sozinho, se a ferramenta é segura, quem aprovou seu uso, qual identidade será usada, quais argumentos são permitidos ou como a ação será auditada.

Padrão	Risco	Controle recomendado
Agente recebe credenciais amplas e chama serviços diretamente	Exposição de credenciais, excesso de permissão e trilha de auditoria fraca	Evite em fluxos de trabalho de produção
Agente chama ferramentas MCP que encapsulam sistemas internos	As ferramentas ainda podem ser amplas demais ou mal registradas	Use ferramentas escopadas, schemas tipados, validação de argumentos e permissões por ferramenta
Agente chama ações aprovadas por um gateway governado	Exige mais desenho de arquitetura	Melhor padrão para fluxos de trabalho sensíveis: identidade explícita, política, logs, aprovações e modos de falha

Não entregue credenciais amplas ao agente. Exponha ações aprovadas por meio de uma interface controlada, com identidade escopada, trilha de auditoria e limites claros de permissão.

Modos de falha para desenhar desde o início

Modo de falha	Controle a desenhar
Prompt injection pede para o agente ignorar políticas ou vazar dados	Autorização por ferramenta, filtragem de saída, acesso escopado a dados e testes de avaliação
O agente escolhe a ferramenta errada ou argumentos errados	Schemas tipados, filtragem semântica de ferramentas, validação de argumentos e modos dry-run
O runtime herda permissões amplas de desenvolvedor	Service roles dedicadas, credenciais temporárias e permission boundaries
Código gerado alcança internet pública ou fontes de pacotes desconhecidas	Controle de saída de rede, registries aprovados, logs de rede e cache isolado de pacotes
O agente entra em loop, tenta novamente sem limite ou executa tarefas caras	Budgets, timeouts, limites de concorrência, circuit breakers e métricas de token e compute
Uma ferramenta altera produção sem revisão	Aprovação humana, mudanças apenas via PR, rollback e evidência no CloudTrail

O que validar antes da produção

• Quais roles o agente assume e quais recursos cada role pode tocar.
• Se as credenciais são temporárias, rotacionadas e auditáveis.
• Quais endpoints privados e públicos o runtime consegue alcançar.
• Como chamadas de ferramentas, argumentos, arquivos, prompts, saídas e aprovações são registrados.
• Onde há aprovação humana para escrita, deleção, movimentação financeira, dados de clientes ou registros regulados.
• Como falhas, loops, picos de custo, risco de pacotes e rollback são tratados.
• Quais dados podem entrar em prompts, ferramentas, logs, arquivos temporários e contextos de provedores de modelos.
• Se os serviços AWS escolhidos estão disponíveis nas Regiões exigidas. O FAQ do AgentCore lista a disponibilidade regional atual; equipes com requisitos de residência de dados no Brasil ou no Canadá devem verificar o encaixe antes de depender de uma capacidade gerenciada específica.
• Se preço, quotas, status de preview/beta e alegações de compliance foram checados na documentação atual da AWS e de cada fornecedor.

Como a Elevata ajuda

A Elevata ajuda empresas que usam AWS como plataforma principal a desenhar runtime, gateway de ferramentas, modelo de identidade, controles de rede, plano de observabilidade, pontos de aprovação e caminho de piloto antes que protótipos de agentes virem infraestrutura paralela.

Uma revisão prática de arquitetura deve produzir um fluxo de trabalho candidato, um mapa de acesso a recursos, uma recomendação de padrão de sandbox, um modelo de IAM e acesso a ferramentas, um plano de logs e evidências, um checklist de prontidão para produção e os riscos que precisam de revisão de segurança antes do lançamento.

Planejando um fluxo de trabalho de agentes na AWS? Agende uma revisão de arquitetura para agentes na AWS e traga um fluxo que você quer governar: agente de desenvolvimento, análise de dados, suporte, triagem de segurança, operações financeiras ou processos internos.

FAQ

Um sandbox de execução de código é suficiente para tornar agentes seguros?

Não. O isolamento de código é necessário, mas segurança em produção também depende de identidade escopada, acesso de rede restrito, interfaces aprovadas para ferramentas, gestão de segredos, logs de auditoria, aprovação humana para ações sensíveis, rollback e avaliações contínuas.

Devemos usar AgentCore ou construir com ECS, EKS, Fargate ou Lambda?

Use capacidades gerenciadas do AgentCore quando elas se encaixarem nos seus requisitos de região, framework, identidade, observabilidade e acesso a ferramentas. Use ECS, Fargate, EKS, Lambda ou um padrão híbrido quando precisar de imagens customizadas, controles padrão da sua plataforma ou ferramentas estreitas e determinísticas.

Onde o MCP entra?

MCP é uma interface útil para expor ferramentas a agentes. Ele deve ficar dentro de um modelo de governança que controla identidade, ações permitidas, validação de argumentos, logs, alcance de rede e aprovações.

Qual é o caso de uso inicial mais seguro?

Um agente de desenvolvimento que propõe mudanças via pull request costuma ser um bom piloto porque tem utilidade real, trilhas de auditoria claras, gates de revisão existentes e um caminho natural de rollback.