Em 14 de setembro de 2026, a AWS publicou o case da Abnormal AI, empresa de segurança comportamental que protege mais de 25% das companhias listadas na Fortune 500. A companhia colocou em produção o Amazon Bedrock AgentCore Code Interpreter para dar suporte aos agentes que fazem detecção de ameaças em e-mails em tempo real.
O sistema já opera processando bilhões de mensagens e executando código gerado por agentes nessa mesma escala. O objetivo é barrar ameaças ainda no fluxo, antes de elas chegarem à caixa de entrada do usuário.
O anúncio foi feito no blog de machine learning da AWS, que descreveu a arquitetura, as decisões de sandbox e os aprendizados práticos do projeto.
Uma pipeline de três camadas
A operação da Abnormal AI organiza a defesa em três camadas de detecção. A primeira aplica heurísticas e roda na casa dos bilhões de mensagens por dia.
A segunda emprega modelos de machine learning e filtra milhões de mensagens diárias que passaram pelo primeiro corte.
A terceira é a camada de agentes inline, que contam com o Code Interpreter para investigar os casos mais complexos. Nessa faixa, apenas o raciocínio semântico de um modelo de linguagem não basta para chegar a uma resposta.
Segundo a AWS, esse desenho reflete um padrão arquitetural recorrente. Agentes em produção precisam de um espaço de rascunho de computação, onde possam rodar comandos, agregar dados, verificar hipóteses e retornar resultados.
O recurso não serve só para tarefas de programação. Ele atende agregação de dados, análise, verificação e qualquer fluxo em que a geração de linguagem precise ser complementada por cálculo real.
Como funcionam as sessões efêmeras
O Code Interpreter é um runtime serverless gerenciado que executa código sob demanda. Cada sessão roda em uma MicroVM efêmera, com tempo de vida configurável entre 15 minutos (valor padrão) e até 8 horas para tarefas longas.
As sessões ficam isoladas em sandboxes com separação no nível do sistema operacional do host. O desenho evita a divulgação inadvertida de informações entre execuções.
Em rede, o serviço pode ser configurado em modo de VPC ou com acesso à internet pública. Para arquivos, a API aceita até 100 MB enviados diretamente, mas é possível conectar o Amazon S3 quando o volume de dados é maior.
Os ambientes já vêm com runtimes de Python e Node.js e bibliotecas comuns de visualização, estatística e processamento de dados. Há ainda observabilidade embutida: logs enviados ao Amazon CloudWatch e ao AWS CloudTrail.
A AWS aponta que o Code Interpreter é exposto como API. Ele não impõe um fluxo de trabalho ao agente nem exige substituir a infraestrutura já existente.
Para equipes que já têm agentes rodando, a integração é direta: o recurso funciona como uma caixa onde o agente executa comandos, envia arquivos e busca resultados.
Por que um modelo de linguagem precisa calcular
A justificativa para usar um interpretador de código ao lado de um LLM aparece em tarefas que não se resolvem por geração de texto. Contar quantos e-mails de phishing foram detectados na última hora exige computação, não coerência semântica.
Transformar dados brutos em gráficos, PDFs ou relatórios estruturados também pede execução. Validar a saída do próprio agente, com testes unitários, linting e testes de integração, depende de um ambiente onde o código realmente execute.
"Praticamente qualquer agente, esteja ele escrevendo código ou não, precisa de um sandbox de interpretador de código que permita efetivamente processar dados e chegar a respostas", afirma Shrivu Shankar, vice-presidente de Estratégia de IA da Abnormal AI, citado no material da AWS.
O contexto de uma empresa ai-native
O case também expõe como a Abnormal AI desenvolve software. Hoje, 80% das mudanças de código da empresa são construídas com apoio de algum agente.
Outros 40% são feitos de ponta a ponta por um agente em segundo plano, ou seja, totalmente gerados por IA, não apenas assistidos por ela.
O uso do Code Interpreter na detecção de ameaças é a aplicação dessa mesma abordagem ao runtime de produção.
Para quem constrói agentes, o recado é direto: separação de sessões, limites de tempo configuráveis, tratamento de arquivos e logs integrados são decisões de projeto que definem se a adoção escala. A AWS descreve o caso como um exemplo de arquitetura em que o sandbox é infraestrutura, e não um detalhe de implementação.
