Sandbox para agentes que executam código: as cinco fronteiras que importam

Um agente que escreve e executa código é, do ponto de vista de segurança, uma máquina de execução remota de código com boas intenções.

O incômodo não é o modelo ser malicioso. É que o input dele não é seu. Um ticket de suporte, um arquivo enviado, um trecho de página raspada — qualquer um desses pode conter texto que altera o que o agente decide executar. Entre "o modelo é confiável" e "o que entra nele é confiável" existe um abismo, e a maior parte das arquiteturas de agente trata os dois como a mesma coisa.

A boa notícia é que o problema já tem solução conhecida. Executar código não confiável é algo que a indústria faz há décadas — CI, runners de concurso de programação, plataformas de notebook. Este artigo aplica esse repertório ao caso do agente, em cinco fronteiras concretas.

Nada aqui é exótico: é contenção padrão, aplicada num lugar onde muita gente ainda não aplica.

TL;DR

• O modelo de ameaça não é "o modelo virou hostil". É "a entrada do modelo foi controlada por outra pessoa".
• Cinco fronteiras: filesystem, rede, processo, credencial e tempo. Deixar uma aberta anula boa parte das outras.
• Egressa de rede deve ser negada por padrão, com allowlist explícita. É a fronteira mais esquecida.
• O contêiner do agente não deve conter nenhuma credencial que você não aceite perder.
• Limites de CPU, memória, PIDs e disco evitam que uma negação de serviço acidental derrube o host.
• Toda execução é registrada: o que rodou, o que tentou alcançar, o que produziu.
• Aprovação humana para operações irreversíveis não é fallback — é design.

O modelo de ameaça, escrito com precisão

Vale ser específico, porque generalidade aqui atrapalha.

Note que nenhuma linha diz "o modelo decidiu atacar". Todas são consequências de entrada não confiável, bug ou permissão excessiva — as mesmas três causas de sempre.

Fronteira 1: filesystem

A regra: tudo somente leitura, exceto um diretório efêmero.

CONTAINER_CONFIG = {
    "image": "agent-sandbox:3.12-slim",     # imagem fixa, sem gerenciador de pacote
    "read_only": True,                       # raiz imutável
    "tmpfs": {
        "/workspace": "size=256m,mode=1777,noexec",
        "/tmp": "size=64m,mode=1777,noexec",
    },
    "user": "65534:65534",                   # nobody, nunca root
    "cap_drop": ["ALL"],                     # nenhuma capability
    "security_opt": [
        "no-new-privileges:true",            # bloqueia escalada por setuid
        "seccomp=profiles/agent-seccomp.json",
    ],
}

Três detalhes que valem mais do que parecem.

noexec no tmpfs. Sem isso, o agente pode escrever um binário em /workspace e executá-lo, contornando qualquer restrição que você tenha aplicado ao interpretador.

no-new-privileges. Impede que um binário setuid dentro da imagem sirva de degrau para escalada.

Imagem sem gerenciador de pacotes. Se pip e apt não existem, "instalar uma dependência" deixa de ser um vetor. As bibliotecas permitidas entram na build, revisadas como qualquer outra dependência.

Um detalhe operacional que evita frustração: monte a entrada como somente leitura e colete a saída de um caminho específico. O agente não deve poder reescrever o próprio input.

volumes = {
    str(input_dir):  {"bind": "/input",  "mode": "ro"},
    str(output_dir): {"bind": "/output", "mode": "rw"},
}

Fronteira 2: rede — a mais esquecida

Esta é a fronteira que a maioria das implementações deixa aberta, e a que transforma um bug em incidente de dados.

Sem contenção de egressa, qualquer conteúdo que o agente processou pode ser enviado para fora em uma linha de código. O caminho não exige malícia do modelo: basta que o input contenha uma instrução convincente.

O padrão correto é network_mode: none para a maioria dos casos:

def sandbox_config(needs_network: bool = False) -> dict:
    base = {**CONTAINER_CONFIG}
    if not needs_network:
        base["network_mode"] = "none"        # o padrão
    else:
        base["network_mode"] = "agent-egress"  # rede com proxy e allowlist
    return base

Quando rede é genuinamente necessária, ela passa por um proxy com allowlist — e o allowlist é de domínios, não de "internet".

ALLOWED_HOSTS = {
    "pypi.org",
    "files.pythonhosted.org",
    "api.interno.empresa.com",
}

BLOCKED_CIDRS = [
    "169.254.169.254/32",   # metadata de instância cloud: sempre bloquear
    "10.0.0.0/8",           # rede interna
    "172.16.0.0/12",
    "192.168.0.0/16",
    "127.0.0.0/8",
]

O endereço 169.254.169.254 merece destaque próprio. É o endpoint de metadados das principais nuvens, e alcançá-lo de dentro de um contêiner costuma render credenciais de instância. Bloqueá-lo explicitamente é obrigatório, mesmo quando você acha que a rede já está restrita.

E resolva DNS no proxy, não no contêiner. Sem isso, exfiltração por consulta DNS continua possível mesmo com HTTP bloqueado.

Fronteira 3: processo e recursos

Limites de recurso protegem contra o caso mais provável de todos: código com bug.

RESOURCE_LIMITS = {
    "mem_limit": "512m",
    "memswap_limit": "512m",    # igual à memória: desabilita swap
    "nano_cpus": 1_000_000_000, # 1 CPU
    "pids_limit": 64,           # contém fork bomb
    "ulimits": [
        {"Name": "nofile", "Soft": 256, "Hard": 256},
        {"Name": "fsize", "Soft": 50_000_000, "Hard": 50_000_000},  # 50 MB
    ],
}

pids_limit é o que impede que um while True: fork() — trivial de gerar por acidente — consuma a tabela de processos do host. memswap_limit igual a mem_limit garante que o limite de memória seja real, e não contornado por swap.

E um timeout no nível do orquestrador, não apenas dentro do código:

import subprocess

def run_sandboxed(code: str, timeout_s: int = 30) -> ExecutionResult:
    container = docker.containers.run(
        **sandbox_config(), **RESOURCE_LIMITS,
        command=["python", "-I", "-S", "/input/script.py"],  # isolado, sem site
        detach=True,
    )
    try:
        status = container.wait(timeout=timeout_s)
        return ExecutionResult(
            exit_code=status["StatusCode"],
            stdout=container.logs(stdout=True, stderr=False)[:100_000],
            stderr=container.logs(stdout=False, stderr=True)[:100_000],
            timed_out=False,
        )
    except requests.exceptions.ReadTimeout:
        container.kill()
        return ExecutionResult(exit_code=-1, stdout=b"", stderr=b"", timed_out=True)
    finally:
        container.remove(force=True)          # nunca reutilize contêiner

Truncar stdout e stderr importa: um agente que imprime em loop pode encher o disco de logs do host, que é uma negação de serviço pela porta dos fundos.

E nunca reutilize contêiner entre execuções. Estado residual de uma execução visível na seguinte é um canal lateral gratuito.