Agent Sandboxing

O sandboxing de agentes consiste em executar as ações de um agente de IA, como comandos de shell, código gerado, edições de ficheiros e navegação na Web, num ambiente isolado que limita os ficheiros, redes, credenciais e recursos computacionais a que essas ações podem aceder. Um agente baseado num grande modelo de linguagem (LLM) escolhe cada comando a partir do texto que leu, e esse texto pode estar errado ou ser malicioso. O sandbox impõe os seus limites no sistema operativo ou no hipervisor, mantendo-os mesmo quando o modelo segue uma injeção de prompt oculta numa página Web ou num README, ou simplesmente comete um erro.

Porque é que os agentes precisam de sandboxes#

A invocação de funções e utilização de ferramentas transforma o texto de um modelo em ações reais, pelo que um agente capaz de executar comandos de shell também pode apagar ficheiros, ler chaves SSH ou carregar código-fonte. A folha de referência de segurança de agentes de IA da OWASP inclui entre as práticas a evitar permitir que agentes executem código arbitrário sem sandboxing, e o OWASP Top 10 for Agentic Applications, publicado em dezembro de 2025, identifica a execução inesperada de código como um dos dez principais riscos dos sistemas agênticos. Os sandboxes também tornam os agentes mais fáceis de usar: pedir a uma pessoa que aprove cada comando provoca fadiga de aprovação, e a Anthropic descobriu que o sandboxing do Claude Code reduziu os pedidos de permissão em 84% na sua utilização interna, porque os comandos que permanecem dentro dos limites já não precisam de pedir autorização.

O que um sandbox restringe#

Um sandbox para um agente controla normalmente cinco aspetos:

• Sistema de ficheiros: O agente vê um espaço de trabalho temporário ou um único repositório, muitas vezes numa imagem base só de leitura, e não pode ler credenciais, perfis de navegador nem outros projetos.
• Rede: O tráfego de saída é bloqueado ou encaminhado através de um proxy que permite apenas domínios listados, como um registo de pacotes, para que um agente sequestrado não possa enviar dados para o servidor de um atacante.
• Credenciais: Os segredos permanecem fora do sandbox ou são fornecidos como tokens de curta duração limitados a uma tarefa, seguindo o princípio do menor privilégio da segurança dos dados.
• Computação: Os limites de tempo de CPU, memória, número de processos e tempo de execução impedem ciclos descontrolados e bombas de bifurcação.
• Chamadas de sistema: Filtros como o seccomp bloqueiam interfaces do kernel de que as ferramentas do agente nunca precisam.

A força do isolamento depende da localização do limite. Os contentores Docker partilham o kernel do anfitrião, pelo que uma exploração do kernel pode escapar deles. O gVisor acrescenta um kernel em espaço de utilizador que interceta as chamadas de sistema de cada contentor, e microVMs como o Firecracker, criado pela AWS para o Lambda, dão a cada sandbox o seu próprio kernel mínimo, arrancando em menos de 125 ms e com menos de 5 MiB de sobrecarga de memória. Os interpretadores de código alojados e os agentes de programação na nuvem executam normalmente cada tarefa num contentor ou microVM novo, que é destruído depois. Nas máquinas dos desenvolvedores, o sandbox do Claude Code usa o Seatbelt no macOS e o bubblewrap no Linux, permite que os comandos de shell escrevam apenas no diretório de trabalho e num diretório temporário, e encaminha o tráfego de rede através de um proxy que verifica cada anfitrião com uma lista de permissões.

O sandbox é uma camada do arnês do agente, o software que executa as chamadas de ferramentas do modelo. O arnês verifica cada ação proposta face à política, executa as ações permitidas dentro do sandbox e interrompe o processo para pedir a uma pessoa que aprove ações irreversíveis, como pagamentos, implementações ou mensagens enviadas para fora da organização:

Sandboxing de código gerado#

Os agentes que escrevem e executam código, desde assistentes de análise de dados a ferramentas de programação agêntica, precisam dos limites mais rigorosos, porque o código gerado pode fazer tudo o que o interpretador permite. A camada mais interna é o isolamento normal de processos, que a biblioteca padrão do Python pode demonstrar: este script executa código escrito pelo modelo num diretório descartável, com um ambiente vazio e um limite de tempo de CPU definido através do módulo resource (Linux e macOS).

import os
import resource
import subprocess
import sys
import tempfile

os.environ["API_KEY"] = "sk-live-123"  # Um segredo guardado pelo próprio processo do agente

# Código escrito pelo modelo: lê o ambiente e depois entra num ciclo infinito
generated = "import os\nprint('API_KEY =', os.environ.get('API_KEY'), flush=True)\nwhile True: pass"


def limit_cpu():
    """Stop the child process after 2 seconds of CPU time."""
    resource.setrlimit(resource.RLIMIT_CPU, (2, 2))


# Executa-o em modo isolado, num diretório descartável e com um ambiente vazio
cmd = [sys.executable, "-I", "-c", generated]
with tempfile.TemporaryDirectory() as workspace:
    proc = subprocess.run(cmd, cwd=workspace, env={}, capture_output=True, text=True, preexec_fn=limit_cpu)

print(proc.stdout.strip())
print("exit code:", proc.returncode)

O processo filho imprime API_KEY = None, porque começa com um ambiente vazio e não consegue ver o segredo do processo principal, e termina com o código -24, o que significa que o kernel o encerrou com SIGXCPU quando o ciclo infinito atingiu o limite de CPU de 2 segundos. Um contentor ou uma microVM acrescenta a este processo os limites do sistema de ficheiros e da rede.

Isolamento de agentes e controlos relacionados#

• Proteções de IA: Classificadores e regras que filtram entradas, saídas ou ações propostas antes de serem executadas. O sandbox contém as consequências de uma ação depois de uma proteção a deixar passar.
• Permissões: O controlo de acesso determina que ferramentas e recursos um agente pode usar. O sandboxing aplica essas decisões ao nível do sistema operativo, abaixo de qualquer verificação que o modelo pudesse contornar com conversa.
• Contentorização: Empacotar software e dependências para permitir uma implementação reproduzível. Um contentor funciona como sandbox quando é executado sem privilégios, com montagens restritas e regras de tráfego de saída.
• Sandboxes de teste: Cópias não destinadas a produção de um sistema, onde o software é experimentado com segurança. Os sandboxes de agentes envolvem todas as ações de um agente, tanto em produção como durante o desenvolvimento.

Onde são usados os sandboxes de agentes#

• Agentes de programação: Cada tarefa recebe um contentor ou uma máquina virtual novos com um único repositório, onde o agente instala dependências, executa testes e devolve um diff para revisão humana.
• Agentes que usam computadores: Os agentes que controlam um computador de secretária ou navegador através de capturas de ecrã e cliques são executados numa máquina virtual com contas próprias, pois qualquer página que vejam pode conter instruções dirigidas a eles.
• Interpretadores de código: Os assistentes que analisam folhas de cálculo ou imagens carregadas executam o seu código Python num sandbox por sessão, muitas vezes sem acesso à Internet.
• Servidores MCP e competências de agentes: As ferramentas de terceiros e os scripts de competências são executados com as credenciais do utilizador, pelo que os anfitriões cuidadosos iniciam servidores e scripts locais dentro dos mesmos limites que o shell do agente.

As plataformas de agentes alojadas aplicam os mesmos limites aos seus próprios fluxos de trabalho. Os agentes da Ultralytics Platform, que encadeiam a deteção YOLO26, modelos de visão e linguagem e blocos de alertas, limitam cada execução experimental partilhada a 60 segundos, 20 imagens de entrada e 20 chamadas a modelos ou fornecedores; o respetivo bloco Webhook publica apenas em URLs HTTPS públicas, não segue redirecionamentos e termina a execução após 5 segundos.