O sandbox do OpenClaw é opt-in: por padrão as ferramentas rodam no host. Ligue agents.defaults.sandbox (Docker default) com scope: agent e workspaceAccess: none; evite shared; feche o alçapão tools.elevated (executa FORA do container) e gere sub-agentes com sandbox: require. Em VPS: portas do Docker furam o UFW — regras em DOCKER-USER. Sandbox contém prompt injection, não a resolve: camadas = sandbox + aprovação humana + allowlists + modelo forte.
- Sandbox desligado é o padrão de fábrica — para operador único confiável; skills de terceiros pedem isolamento.
- 3 decisões: scope (agent/session, evitar shared), workspaceAccess (none/ro/rw) e binds (symlink malicioso falha fechado).
- tools.elevated executa FORA do sandbox — o alçapão que anula tudo; padrão: desligado.
- Sub-agentes com sandbox: require falham rápido em vez de herdar o host.
- Docker fura UFW: firewall de VPS vai na chain DOCKER-USER + scan externo de validação.
- Exec approval não entende semanticamente todo interpretador — a fronteira forte é o container.
Tem um detalhe da arquitetura de segurança do OpenClaw que surpreende todo mundo: o sandbox vem DESLIGADO por padrão. No modelo de fábrica — pensado pra um único operador confiável — as ferramentas do agente rodam direto no host. Funciona, até o dia em que uma skill de terceiro, uma página maliciosa ou um e-mail com instruções escondidas convence o agente a rodar o comando errado. A doc oficial é honesta: prompt injection “não está resolvido”, e a fronteira dura não é o prompt — é o isolamento. Este guia liga essa fronteira.
O que o sandbox faz (e o que não faz)
Com agents.defaults.sandbox ativo, as ferramentas que executam código passam a rodar dentro de um container (Docker é o backend padrão) em vez do host. O agente continua igual — quem muda de casa é o shell, o filesystem e o estrago possível. Duas abordagens se complementam: rodar o Gateway inteiro em Docker (fronteira de container pra tudo) ou manter o Gateway no host e isolar só as ferramentas — o caminho mais comum.
As 3 decisões de configuração
- Escopo —
scope: "agent"(padrão): um container por agente."session": um por sessão, isolamento máximo."shared": um container pra todos — a doc manda evitar, porque permite acesso cruzado entre agentes. - Acesso ao workspace —
workspaceAccess: "none"(padrão): as ferramentas trabalham num workspace descartável em~/.openclaw/sandboxes, sem ver seus arquivos."ro": monta o workspace só-leitura (edição/patch desabilitados)."rw": monta com escrita — só quando o fluxo realmente edita arquivos seus. - Binds extras — montagens adicionais são validadas contra caminhos canônicos: truque de symlink apontando pra
/etcou diretório de credenciais falha fechado. Segurança pensada por quem já viu container escapar.
⚠️ O alçapão que anula tudo: tools.elevated
Existe uma saída de emergência deliberada: tools.elevated executa comandos FORA do sandbox, direto no host. É útil pra manutenção — e é exatamente o que um ataque quer alcançar. Regra prática: enabled: false por padrão; se precisar, allowFrom cirúrgico (só você, só no canal admin). E sub-agentes: se o fluxo deve permanecer isolado, gere-os com sandbox: "require" — falha na hora se o filho tentar nascer fora do container, em vez de herdar silenciosamente o host.
Ligando na prática
O desenho recomendado pra quem opera um agente com skills de terceiros: Gateway no host, sandbox ativo com scope: "agent" e workspaceAccess: "none", elevated desligado, e — do runbook de hardening da série — exec.ask: "always" pra ações sensíveis. Perfis prontos da doc: agente público sem filesystem/shell (workspaceAccess: "none" + denies), agente leitor ("ro") e agente de confiança total (mode: "off" — o padrão de fábrica, agora uma escolha consciente e não um acidente).
Rodando em VPS com Docker, um lembrete que a doc oficial faz questão de dar: portas publicadas pelo Docker furam o UFW (passam pela chain própria do Docker) — as regras de firewall precisam ir em DOCKER-USER, e depois valide de fora com um scan de portas. Detalhe que separa tutorial de operação real.
Os limites (honestidade oficial)
A própria doc reconhece: as aprovações de exec “não modelam semanticamente todo caminho de interpretador” — um python -c criativo pode dizer uma coisa e fazer outra. Por isso a recomendação final é em camadas: sandbox para a fronteira forte, aprovação humana pro que é irreversível, allowlists pra identidade, e modelo forte e recente no volante. Isolamento não substitui critério; multiplica o valor dele.
Fontes: docs.openclaw.ai — security & sandboxing · prática da nossa operação self-hosted
Perguntas frequentes
O sandbox do OpenClaw vem ativado por padrão?
Não — é opt-in. O modelo de fábrica assume um único operador confiável e roda as ferramentas direto no host. Quem instala skills de terceiros ou expõe o bot a mensagens de fora deve ligar o sandbox (agents.defaults.sandbox, Docker por padrão).
Sandbox resolve prompt injection?
Não resolve — contém. A doc oficial é explícita: injection não está resolvido e o prompt não é fronteira de segurança. O sandbox limita o que um agente manipulado consegue alcançar: o estrago fica confinado ao container e ao workspace descartável.
O que é o tools.elevated e por que é perigoso?
É a saída de emergência que executa comandos fora do sandbox, direto no host. Útil pra manutenção, mas anula o isolamento — mantenha desligado ou com allowFrom restrito a você mesmo, e gere sub-agentes com sandbox: require.
Docker no VPS: por que meu firewall não bloqueia as portas do container?
Porque portas publicadas pelo Docker passam pela chain de forwarding do próprio Docker, ignorando o UFW. As regras precisam ir na chain DOCKER-USER — e valide de fora com um scan de portas depois.
