Resposta rápida

Hardening oficial do OpenClaw em 3 níveis: rode 'openclaw security audit –deep' antes de tudo; Nível 1 (10 min): loopback + token fail-closed, Tailscale Serve pra remoto, dmPolicy pairing, permissões 600/700; Nível 2 (30 min): baseline endurecido oficial — dmScope per-channel-peer, tools.profile messaging, exec deny/ask-always, requireMention, número separado; Nível 3: sandbox Docker opt-in, elevated off, mDNS minimal, caça a flags 'dangerously*'. Filosofia: Identity → Scope → Model. Incidente: Conter → Rotacionar → Auditar.

openclaw security audit –deep –fix é o auditor oficial embutido — rode antes e depois.
Falha típica não é exploit: é 'mandaram mensagem e o bot obedeceu' — identidade primeiro.
Auth do Gateway é fail-closed por default: sem token válido, WebSocket recusado.
Acesso remoto oficial = Tailscale Serve (Gateway segue em loopback); Funnel público, evitar.
dmPolicy pairing: código expira em 1h, máx 3 pendentes por canal.
Sandbox é opt-in (Docker default) — e tools.elevated escapa dele: mantenha desligado.
Prompt não é fronteira: enforcement duro = policy + sandbox + allowlist + modelo forte.
Incidente: Conter → Rotacionar token (4 passos) → Auditar.

Auditoria oficialopenclaw security audit [–deep|–fix]

Default de redeloopback + token (fail-closed), porta 18789

Remoto seguroTailscale Serve (nunca 0.0.0.0 sem auth)

DMspairing — código expira em 1h, 3 pendentes máx

Permissõesopenclaw.json 600 · ~/.openclaw 700

Filosofia oficialIdentity → Scope → Model

IncidenteConter → Rotacionar → Auditar

A documentação de segurança do OpenClaw tem uma frase que vale o guia inteiro: “a maioria das falhas não são exploits sofisticados — são ‘alguém mandou mensagem pro bot e o bot obedeceu'”. A filosofia oficial é Identity → Scope → Model: primeiro controle QUEM fala com o agente, depois ONDE ele pode agir, e por último assuma que o modelo pode ser manipulado — e limite o estrago. Este runbook aplica isso em três níveis, com os comandos exatos.

Antes de tudo: rode a auditoria oficial

O OpenClaw traz um auditor de segurança embutido que quase ninguém conhece:

openclaw security audit          # varredura padrão
openclaw security audit --deep   # varredura profunda
openclaw security audit --fix    # corrige um conjunto seguro de findings

O --fix é conservador de propósito: converte políticas de grupo abertas em allowlists, restaura a redação de dados sensíveis nos logs e aperta permissões de arquivos de config. Rode ANTES e DEPOIS de cada nível abaixo — os findings têm até ordem oficial de prioridade (exposição pública primeiro, permissões de arquivo depois, plugins e modelo por último).

Nível 1 — Básico (10 minutos, elimina 80% do risco)

Gateway em loopback com token — o default já é bind: "loopback" e auth fail-closed (sem token válido, o WebSocket é recusado). Confirme que ninguém “abriu” isso: gateway.mode: "local", bind: "loopback", auth.mode: "token" com token longo. Perdeu o token? openclaw doctor --generate-gateway-token.
Nunca 0.0.0.0 sem auth. Pra acesso remoto, o caminho oficial é Tailscale Serve (mantém o Gateway em loopback). Funnel — que expõe publicamente — a própria doc manda evitar pra controle de browser.
DMs em modo pareamento — dmPolicy: "pairing" (default): desconhecido que manda mensagem recebe um código que expira em 1h, com máximo de 3 pendentes por canal. Aprove com openclaw pairing approve <canal> <código>. Nunca use "open" num bot com ferramentas.
Permissões de arquivo — ~/.openclaw/openclaw.json em 600, diretório em 700. O openclaw doctor avisa e corrige. As credenciais dos canais (WhatsApp etc.) moram todas em ~/.openclaw/credentials/ — o disco É a fronteira de confiança.

Nível 2 — Operador (30 minutos, o baseline endurecido oficial)

A doc traz um “hardened baseline” copy/paste. Os pontos que mais importam:

Escopo de sessão por pessoa: session.dmScope: "per-channel-peer" — cada contato tem sessão isolada; um interlocutor não herda o contexto do outro (pense: cliente vendo conversa de outro cliente).
Perfil de ferramentas mínimo: tools.profile: "messaging" + negar grupos pesados ("group:automation", "group:fs", sessions_spawn…) + fs.workspaceOnly: true.
Shell no modo pergunta: tools.exec.security: "deny" e exec.ask: "always" — o agente propõe o comando, você aprova. O default de operador único é permissivo (full sem ask); mude se o bot recebe mensagem de terceiros.
Grupos só com menção: requireMention: true em todos os grupos de WhatsApp — o agente ignora conversa que não é com ele.
Número separado: recomendação oficial literal — rode o bot num número de telefone próprio, não no seu pessoal.

Nível 3 — Paranoico (sandbox e além)

Sandbox é opt-in — ligue. agents.defaults.sandbox roda as ferramentas em container (Docker é o backend default), com escopo por agente ou por sessão e workspace none/ro/rw. Symlink pra fora dos binds permitidos falha fechado.
Cuidado com o alçapão: tools.elevated executa FORA do sandbox — mantenha enabled: false ou allowFrom cirúrgico.
mDNS discreto: o Gateway se anuncia na rede local (porta 5353); discovery.mdns.mode: "minimal" ou "off" (o modo full expõe até caminho de CLI e porta SSH).
Caça às flags perigosas: qualquer chave com dangerously* no config é dívida de segurança rastreada pela auditoria — se você não lembra por que ligou, desligue.
Modelo forte é config de segurança: a doc é explícita — não rode agente com ferramentas em modelo fraco/antigo; injection “não está resolvido”, e o enforcement duro vem de policy + sandbox + allowlist, nunca do prompt.

Se algo der errado: o protocolo de incidente

Ordem oficial: Conter → Rotacionar → Auditar. Rotação de token em 4 passos: gera secret novo → reinicia o Gateway → atualiza os clientes remotos → confirma que o token velho não conecta. E vulnerabilidade no projeto se reporta em security@openclaw.ai — não no grupo do Telegram.

Este runbook cobre o Gateway; a visão geral de riscos (skills maliciosas, permissões de celular, o caso McAfee) está no nosso guia “OpenClaw é seguro?” da mesma série — e o diário completo da nossa operação self-hosted vem aí.

Fontes: docs.openclaw.ai/gateway/security (modelo de ameaça, baseline e checklist oficiais) · prática da nossa operação

Perguntas frequentes

O OpenClaw tem auditoria de segurança embutida?

Sim: openclaw security audit (com –deep para varredura profunda e –fix para correções seguras). Os findings saem com prioridade oficial: exposição pública primeiro, depois DMs/grupos abertos, permissões de arquivo, plugins e modelo.

Posso acessar meu Gateway de fora de casa com segurança?

Sim — pelo caminho oficial: Tailscale Serve, que mantém o Gateway em loopback e encapsula o acesso na sua rede privada. O que a doc manda evitar: bind em 0.0.0.0, exposição pública (Funnel) e qualquer acesso sem auth por token.

O que é o modelo Identity → Scope → Model?

A postura oficial de segurança do OpenClaw: primeiro controle QUEM fala com o bot (pairing, allowlists), depois ONDE ele age (tools, filesystem, exec), e por fim assuma que o modelo pode ser manipulado por prompt injection — e limite o raio de dano com sandbox e políticas, não com instruções no prompt.

Sandbox vem ligado por padrão?

Não — é opt-in. agents.defaults.sandbox roda as ferramentas em container Docker com escopo por agente ou sessão. Atenção ao tools.elevated: ele executa FORA do sandbox e deve ficar desligado ou com allowFrom restrito.

Guardrails no prompt do sistema protegem contra prompt injection?

Não como fronteira dura. A doc é explícita: injection não está resolvido e instruções de prompt são orientação suave — o enforcement real vem de tool policy, aprovação de exec, sandbox e allowlists. E use modelo forte e recente em qualquer agente com ferramentas.