Guia de Agent Sandbox: como executar código de IA com segurança

Na primavera de 2025, pesquisadores de segurança fizeram um experimento: testaram os 16 AI Agents públicos da turma Spring da YCombinator. O resultado? Sete foram comprometidos. Alguns vazaram dados de usuários, outros permitiram execução remota de código e um deles simplesmente apagou o banco de dados.

Esse é o preço de permitir que um AI Agent execute código. Você dá liberdade, e ele pode abrir um enorme problema.

Todo mundo usa IA para escrever código, executar scripts e processar dados. Mas você já parou para pensar se é seguro rodar diretamente no servidor um código gerado por um modelo de linguagem? E se ele executar um rm -rf / ou enviar silenciosamente suas credenciais da AWS para um servidor externo? Quando você perceber, será tarde demais.

É para isso que existe o Agent Sandbox.

A maior diferença entre um AI Agent e uma aplicação tradicional não é a capacidade de conversar nem de entender instruções, mas a capacidade de escrever e executar código por conta própria.

Imagine este cenário: você pede a um Agent de análise de dados que processe 1 GB de dados de vendas. Ele escreve um código Python para ler os dados, analisá-los e gerar gráficos. O código foi inteiramente produzido pelo modelo, sem passar por sua revisão. Em seguida, começa a rodar.

Há vários riscos graves nisso:

Execução arbitrária de código. Modelos de linguagem não entendem limites de segurança. Eles usam funções como os.system() e subprocess.run() sempre que julgarem necessário, sem considerar as consequências. Um prompt cuidadosamente elaborado pode fazer o Agent executar qualquer comando do sistema.

Ataques de esgotamento de recursos. O código escrito pelo Agent não tem consciência do consumo de recursos. Um loop infinito pode ocupar toda a CPU, e uma recursão sem fim pode esgotar a memória. Seu servidor simplesmente para.

Acesso indevido ao sistema de arquivos. Se você não restringir os caminhos acessíveis, o Agent poderá ler o disco inteiro e gravar qualquer arquivo. Configurações, credenciais e dados de usuários ficam ao alcance dele.

Vazamento de dados pela rede. Um código pode esconder uma requisição HTTP que envia informações confidenciais ao servidor de um invasor sem que você perceba.

Em 2025, a OWASP publicou seu Top 10 de ameaças à segurança de AI Agents. Em primeiro lugar estava a “manipulação da interação com ferramentas do Agent”. Em termos simples, um invasor pode usar prompt injection ou outros métodos para fazer o Agent chamar ferramentas de uma forma diferente da esperada.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Já existem casos reais de ataques:

• Vulnerabilidade RCE no Langflow: a Horizon3 descobriu uma falha de execução remota de código que permitia executar comandos arbitrários no servidor por meio de entradas maliciosas.
• Vulnerabilidade de execução automática no Cursor: pesquisadores descobriram que o Cursor executava automaticamente determinados comandos MCP, que poderiam ser acionados por um prompt malicioso.
• Banco de dados apagado no Replit: um código gerado por IA excluiu acidentalmente todo o banco de dados.

O sandbox não é opcional. Ele faz parte da infraestrutura de uma aplicação com AI Agents. Assim como você não colocaria um servidor na internet sem firewall, não deveria permitir que uma IA execute código sem um sandbox.

O valor central de um sandbox se resume a três pontos: isolamento — manter o código de risco dentro de uma área controlada; limitação — impor limites de CPU, memória, rede e acesso a arquivos; auditoria — registrar o que foi feito para permitir investigação em caso de incidente.

Comparação das principais tecnologias de sandbox

Agora que já sabemos por que um sandbox é necessário, qual tecnologia usar? Hoje, o mercado trabalha principalmente com três abordagens: contêineres (Docker), gVisor e microVMs Firecracker.

Veja primeiro uma comparação rápida:

Contêiner Docker: rápido, mas não seguro o bastante

Docker é a opção mais comum. Inicializa rapidamente, consome poucos recursos e tem um ecossistema maduro. O problema é que os contêineres Docker compartilham o kernel com o host.

O que isso significa? Embora os processos dentro do contêiner sejam isolados por namespaces, um invasor que explore uma vulnerabilidade do kernel pode romper a fronteira do contêiner e obter privilégios de root no host.

Várias vulnerabilidades de escape de contêiner foram divulgadas em 2024. Para códigos não confiáveis gerados por IA, a barreira de segurança do Docker não é suficiente.

gVisor: um “kernel simulado” no espaço do usuário

O gVisor é um projeto de código aberto do Google com uma abordagem interessante: em vez de usar diretamente o kernel do host, ele implementa um “kernel simulado” no espaço do usuário, chamado Sentry.

Quando um programa dentro do contêiner faz uma chamada de sistema, o gVisor a intercepta e deixa o Sentry processá-la. O Sentry permite apenas operações seguras e rejeita as perigosas. Assim, mesmo que o código tente causar danos, ele não consegue alcançar o kernel real.

Uma vantagem do gVisor é a boa compatibilidade: a maioria das imagens Docker funciona diretamente. A desvantagem é alguma perda de desempenho, em torno de 10% a 20%, além da falta de suporte a determinadas chamadas de sistema específicas.

O GKE (Google Kubernetes Engine) oferece suporte nativo ao gVisor. Basta adicionar runtimeClassName: gvisor à configuração do Pod.

Firecracker: isolamento real em nível de hardware

Firecracker é uma tecnologia de microVM de código aberto da AWS. Cada sandbox funciona como uma pequena máquina virtual com seu próprio kernel independente.

O que isso significa? Mesmo que um invasor obtenha privilégios de root dentro do sandbox e explore uma vulnerabilidade do kernel, continuará preso a uma máquina virtual, sem afetar o host.

O Firecracker inicializa em 100 a 800 milissegundos e consome bem menos recursos do que uma máquina virtual tradicional: uma microVM precisa de apenas 128 MB de memória no mínimo.

Serviços profissionais de sandbox para execução de código por IA, como E2B e AWS Bedrock AgentCore, usam Firecracker por baixo dos panos.

Estrutura de decisão

Como escolher? Use esta árvore de decisão simples:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

1. É apenas para desenvolvimento e testes locais? Docker é suficiente e prático.
2. Será implantado em produção?
   • Requisitos moderados de segurança e prioridade para desempenho → gVisor
   • Requisitos elevados de segurança e conformidade → Firecracker
3. Você não quer administrar a infraestrutura? Use diretamente um serviço gerenciado, como E2B ou Bedrock AgentCore.

Na prática: como montar um sandbox de desenvolvimento local

Depois da teoria, vamos montar um ambiente. A solução será: FastAPI + Jupyter Kernel + contêiner gVisor.

Por que essa combinação?

• O FastAPI oferece uma interface HTTP simples, pela qual o AI Agent envia solicitações de execução de código via REST API.
• O Jupyter Kernel oferece um ambiente interativo para execução de Python, com persistência de variáveis.
• O contêiner gVisor fornece isolamento seguro e impede que códigos maliciosos afetem o host.

Etapa 1: escreva o serviço FastAPI

Crie um arquivo main.py:

# main.py
import asyncio
from contextlib import asynccontextmanager
from fastapi import FastAPI, HTTPException
from jupyter_client.manager import AsyncKernelManager
from pydantic import BaseModel

app = FastAPI()

class CodeRequest(BaseModel):
    code: str

class ExecutionResult(BaseModel):
    output: str

@asynccontextmanager
async def kernel_client():
    """Gerencia o ciclo de vida do Jupyter Kernel"""
    km = AsyncKernelManager(kernel_name="python3")
    await km.start_kernel()
    kc = km.client()
    kc.start_channels()
    await kc.wait_for_ready()
    try:
        yield kc
    finally:
        kc.stop_channels()
        await km.shutdown_kernel()

async def execute_code(code: str, timeout: int = 30) -> str:
    """Executa o código e retorna o resultado"""
    async with kernel_client() as kc:
        msg_id = kc.execute(code)
        try:
            while True:
                reply = await asyncio.wait_for(
                    kc.get_iopub_msg(),
                    timeout=timeout
                )
                if reply["parent_header"]["msg_id"] != msg_id:
                    continue
                msg_type = reply["msg_type"]
                if msg_type == "stream":
                    return reply["content"]["text"]
                elif msg_type == "error":
                    return f"Error: {reply['content']['evalue']}"
                elif msg_type == "status" and reply["content"]["execution_state"] == "idle":
                    break
        except asyncio.TimeoutError:
            return "Error: Execution timed out"
    return ""

@app.post("/execute", response_model=ExecutionResult)
async def execute(request: CodeRequest):
    """Endpoint para execução de código"""
    try:
        output = await execute_code(request.code)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))
    return ExecutionResult(output=output)

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

A lógica central do código é esta: sempre que uma solicitação de execução chega, ele inicia um Jupyter Kernel independente, executa o código, retorna o resultado e encerra o Kernel.

Etapa 2: escreva o Dockerfile

FROM jupyter/base-notebook:latest

WORKDIR /app

COPY main.py /app/main.py
COPY requirements.txt /app/requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

# Execute como usuário não root (prática recomendada de segurança)
USER jovyan

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Observe o USER jovyan: essa é uma prática de segurança. Ao executar o contêiner como usuário não root, mesmo que o código escape, os privilégios obtidos serão limitados.

Etapa 3: implante no GKE (com gVisor ativado)

Se você usa GKE, basta adicionar uma linha à configuração do Pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor  # Essencial: ativa o gVisor
      containers:
      - name: sandbox
        image: your-registry/agent-sandbox:latest
        ports:
        - containerPort: 8000
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"

Pronto: seu ambiente de execução de código já está rodando em um sandbox gVisor.

Etapa 4: adicione restrições de segurança

A configuração acima ainda não está completa. Em produção, adicione pelo menos estas restrições:

# Política de rede: permite acesso somente às APIs necessárias
# Sistema de arquivos somente leitura
securityContext:
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

# Define o tempo limite de execução
# O parâmetro timeout já foi adicionado ao código FastAPI

Avançado: implantação em cluster Kubernetes

Se sua aplicação de AI Agent precisa operar em grande escala, um único contêiner não será suficiente. Nesse caso, você pode usar o controlador Agent Sandbox do Kubernetes.

Em 2025, o Google disponibilizou como código aberto o projeto Agent Sandbox, que oferece uma API declarativa para gerenciamento de sandboxes.

Conceitos centrais da CRD de Sandbox

O Agent Sandbox define alguns recursos personalizados:

• Sandbox: uma instância individual de sandbox, com identidade estável, armazenamento persistente e gerenciamento do ciclo de vida.
• SandboxTemplate: um modelo de sandbox que define uma configuração padronizada.
• SandboxClaim: uma solicitação de instância de sandbox criada sob demanda.

Exemplo de configuração simples de Sandbox:

apiVersion: sandbox.k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor
      containers:
      - name: executor
        image: python:3.11-slim
        command: ["sleep", "infinity"]
      # Armazenamento persistente
      volumes:
      - name: workspace
        emptyDir: {}
      # Limites de recursos
      resources:
        limits:
          memory: "1Gi"
          cpu: "1"

Gerenciamento do ciclo de vida

Um dos destaques do Agent Sandbox é o suporte a pausa e retomada:

# Pausa o sandbox (libera a CPU e a maior parte da memória)
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":true}}'

# Retoma o sandbox
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":false}}'

Isso é especialmente útil para AI Agents executados de forma intermitente: sem tarefas, você pausa o ambiente e praticamente não consome recursos; quando uma tarefa chega, retoma em poucos segundos.

Pool pré-aquecido

Para reduzir ainda mais a latência de inicialização, o Agent Sandbox oferece um “pool pré-aquecido”: vários sandboxes são criados antecipadamente em estado pausado e ativados quando necessário.

Essa técnica reduz o tempo de “inicialização a frio” do sandbox de segundos para milissegundos.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Recomendações de serviços gerenciados

Se você não quer cuidar da infraestrutura, um serviço gerenciado é uma boa opção. Estas são as principais alternativas atuais:

E2B: código aberto e nuvem gerenciada

E2B é um serviço de sandbox para execução de código projetado especificamente para AI Agents. Ele oferece duas versões:

• E2B Cloud: use diretamente o serviço em nuvem, com cobrança por uso.
• E2B on AWS: implante a versão de código aberto em sua própria conta AWS.

O E2B usa Firecracker internamente, garantindo um bom nível de segurança. Seu SDK é simples:

from e2b import Sandbox

# Cria o sandbox
sandbox = Sandbox()

# Executa o código
result = sandbox.run_code("print('Hello, World!')")

# Encerra o sandbox
sandbox.close()

O E2B on AWS é especialmente indicado para empresas com requisitos de soberania de dados: todas as informações permanecem em sua própria conta, sem depender de terceiros.

AWS Bedrock AgentCore

Em 2025, a AWS lançou o Bedrock AgentCore, voltado à execução de código e à operação de navegadores por AI Agents.

O Code Interpreter oferece runtimes Python, JavaScript e TypeScript. Cada sessão é executada em uma microVM independente e aceita o processamento de arquivos de até 5 GB.

O Browser Tool permite que um AI Agent opere o navegador: abra páginas, preencha formulários e clique em botões. É especialmente útil para Agents que precisam coletar dados de sites ou operar aplicações SaaS.

O modelo de cobrança também é razoável: você paga pelo tempo real de uso de vCPU e memória, não pelo tempo em que a instância fica ligada. Quando a execução termina, os recursos são liberados e não há desperdício.

Recomendações de escolha

Conclusão

Depois de tudo isso, a ideia central cabe em uma frase: segurança não é opcional; ela faz parte da infraestrutura de uma aplicação com AI Agents.

Em termos de escolha técnica:

• Para equipes pequenas e validação rápida, Docker ou gVisor são suficientes.
• Para aplicações empresariais com requisitos rigorosos de segurança, use Firecracker ou um serviço gerenciado.
• Se você já usa Kubernetes, adote diretamente o controlador Agent Sandbox.

Independentemente da escolha, comece com testes locais. Escreva a configuração mais simples possível com FastAPI e Docker, coloque-a para rodar e depois avance para o reforço de segurança e a implantação em produção.

Lembre-se: quanto antes você adicionar o sandbox, melhor. Não espere um incidente de segurança para corrigir o problema, pois o custo será muito maior.