Configuração segura do OpenClaw: cinco camadas de defesa, do sandbox Docker ao controle de permissões

Resumo rápido

Se você fizer apenas três coisas, já reduzirá a maior parte dos cenários de alto risco do OpenClaw:

1. exigir autenticação por token ou senha e restringir os pontos de entrada;
2. usar sandbox em contêiner, usuário não root e privilégios mínimos;
3. adotar uma lista de ferramentas de alto risco permitidas e negar comandos sensíveis por padrão.
   Depois disso, acrescente auditoria e isolamento de rede, camada por camada.

Às três da manhã, um desenvolvedor pediu ajuda no Reddit. Ele havia instalado o OpenClaw no MacBook e o usava há duas semanas com a configuração padrão. Tudo parecia ótimo, até pedir que o OpenClaw “organizasse os arquivos dos projetos recentes”. A IA também leu os diretórios ~/.ssh/ e ~/.aws/ e, prestativa demais, exibiu o conteúdo da chave privada na resposta.

Para piorar, o histórico da conversa foi sincronizado com o grupo de trabalho dele.

Quando vi esse caso pela primeira vez, senti um frio na espinha. O OpenClaw é um assistente de IA muito capaz: executa comandos Shell, lê e grava arquivos e controla o navegador. Mal configurado, porém, é como entregar a chave mestra da sua casa a um desconhecido.

Talvez você pense: “Só eu uso, então não deve haver problema, certo?”

É justamente aí que está o risco. Os perigos não vêm apenas de ataques externos. Há prompt injection, quando alguém insere instruções maliciosas em uma conversa; erros de configuração, como expor uma porta de API; e até o excesso de iniciativa da própria IA, que pode interpretar “limpar arquivos” como autorização para apagar dados importantes.

Tudo isso pode ser evitado com a configuração correta.

Este artigo mostra como colocar o OpenClaw em uma “jaula de segurança”, do sandbox Docker ao controle detalhado de permissões. São cinco camadas de defesa para usar essa “fera” com tranquilidade. A configuração dá algum trabalho, mas é pouca coisa perto de um vazamento de dados ou da exclusão de um banco de produção.

Guia econômico para “criar lagosta”: ArkClaw torna os agentes de IA acessíveis de verdade

O OpenClaw, conhecido como “lagosta”, está em alta, mas sua configuração afasta muita gente. O ArkClaw, da ByteDance Volcano Engine, reduz drasticamente essa barreira: sem precisar configurar servidores e tokens, você obtém com um clique um agente de IA disponível 24 horas, capaz de controlar o navegador, executar scripts e gerenciar o calendário.

O preço também chama atenção: a mensalidade é de apenas 9,9 yuans, ou 8,9 yuans com meu código de convite ZLKUK54M (cadastre-se aqui). Para programadores, o Coding Plan Pro ainda oferece uso gratuito.

Por que configurar a segurança?

Até onde vão as permissões do OpenClaw?

Comecemos por um fato importante. O OpenClaw não é um assistente que apenas conversa: ele pode fazer praticamente tudo o que você faria no terminal.

• Executar qualquer comando Shell: rm -rf /? Tecnicamente, sim.
• Ler e gravar em todo o sistema de arquivos: chaves SSH, credenciais da AWS e senhas de bancos de dados ficam ao alcance dele se estiverem no disco.
• Acessar recursos de rede: chamar APIs, baixar arquivos e até varrer portas da rede interna.
• Controlar o navegador: operar seu navegador por meio do Playwright, inclusive sites nos quais você já está conectado.
• Ler variáveis de ambiente: todas as informações sensíveis em process.env ficam expostas.

Dar as permissões padrão ao OpenClaw é como entregar a chave mestra da sua casa a um assistente muito inteligente que você ainda não conhece bem.

Qual é o perigo da configuração padrão?

Muita gente busca praticidade: instala com npm install -g openclaw e executa diretamente openclaw gateway, ou instala apenas o daemon e deixa a inicialização automática fazer o resto. Mas o que acontece por padrão?

Antes da v2026.1.29:

• O controle de acesso podia usar auth: none, permitindo que qualquer pessoa com a URL controlasse o OpenClaw.
• Não havia isolamento por sandbox; a IA podia ler e gravar em todo o sistema de arquivos.
• Todas as ferramentas vinham habilitadas, inclusive exec e browser.
• O processo podia ser executado com privilégios elevados, até mesmo como root.

"A v2026.1.29 removeu a opção auth: none e passou a exigir autenticação por token ou senha"

A situação melhorou um pouco após a v2026.1.29: o projeto removeu auth: none e passou a exigir token ou senha. Os outros problemas continuam: sandbox, permissões das ferramentas e acesso ao sistema de arquivos precisam ser configurados manualmente.

Em termos simples, a configuração padrão era como dormir com a porta aberta e uma placa de “visitas bem-vindas” na entrada.

Três objetivos da configuração segura

Qual é o objetivo de tantas opções? Ele se resume a três pontos.

1. Princípio do menor privilégio: conceda ao OpenClaw apenas as permissões realmente necessárias. Se ele ajuda a programar, libere leitura e gravação no workspace. Se não precisa controlar o navegador, desative a ferramenta browser.

2. Defesa em profundidade: não dependa de uma única barreira. Isolamento Docker, usuário sem privilégios, controle de acesso, lista de ferramentas permitidas e isolamento de rede formam cinco camadas. Se uma falhar, as demais continuam protegendo o sistema.

3. Limitação do raio de impacto: suponha que o pior aconteça — um prompt injection funcione, um token vaze ou a IA tenha um bug. Qual será a extensão do dano? Se o OpenClaw acessa apenas um workspace isolado, o vazamento fica limitado a esse diretório, e não a todo o /home.

Segurança não elimina todos os ataques. Ela aumenta o custo do ataque e reduz o dano possível.

Cinco camadas de configuração segura

Vamos à prática, da camada mais baixa à mais alta. Em cada etapa, veremos por que a medida é necessária e como validar a configuração.

Primeira camada: isolamento por sandbox Docker (obrigatória)

Por que usar Docker?

Muita gente vê o Docker apenas como uma forma conveniente de implantar aplicações. Para um aplicativo com muitos privilégios como o OpenClaw, seu maior valor é o isolamento:

• Isolamento do sistema de arquivos: a IA só enxerga os arquivos do contêiner e não alcança o ~/.ssh do host.
• Isolamento de rede: você pode cortar o acesso externo ou permitir somente determinados domínios.
• Limites de recursos: um loop infinito da IA não consumirá toda a CPU.
• Recuperação rápida: se algo der errado, docker rm remove o contêiner e você recria um ambiente limpo em segundos.

Isso também é necessário em uma máquina local. Ela costuma conter tokens do GitHub, senhas de bancos de dados e várias chaves de API — alvos valiosos para prompt injection.

Etapas de configuração

1. Crie um Dockerfile seguro

FROM openclaw/gateway:latest

# Cria um usuário sem privilégios
RUN adduser --disabled-password --gecos '' clawuser

# Muda para o usuário sem privilégios
USER clawuser

# Define o diretório de trabalho
WORKDIR /home/clawuser/openclaw

O ponto essencial é USER clawuser. Por padrão, o contêiner Docker roda como root, o que dá ao OpenClaw privilégios de root dentro dele. Com um usuário dedicado, mesmo quem comprometer o contêiner terá apenas as permissões de clawuser.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

2. Configure os parâmetros de segurança no Docker Compose

Esta é a parte central:

version: '3.8'
services:
  openclaw-gateway:
    build: .
    container_name: openclaw-safe

    # Configuração de segurança
    security_opt:
      - no-new-privileges:true  # Impede a elevação de privilégios no contêiner
    cap_drop:
      - ALL  # Remove todas as capabilities do Linux
    cap_add:
      - NET_BIND_SERVICE  # Adiciona somente a capacidade de vincular portas

    # Sistema de arquivos raiz somente leitura
    read_only: true

    # Diretórios temporários graváveis
    tmpfs:
      - /tmp
      - /home/clawuser/openclaw/temp

    # Limites de recursos
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

    # Isolamento de rede
    networks:
      - openclaw-isolated

    # Volumes montados com privilégio mínimo
    volumes:
      # Diretório de trabalho, leitura e gravação
      - ./workspace:/home/clawuser/workspace
      # Arquivos de configuração, somente leitura
      - ./config:/home/clawuser/openclaw/config:ro
      # Diretório de logs, gravação
      - ./logs:/home/clawuser/openclaw/logs

networks:
  openclaw-isolated:
    driver: bridge
    internal: true  # Bloqueia o acesso à rede externa

Por que usar esses parâmetros?

• no-new-privileges:true: impede a elevação por sudo ou setuid. Mesmo que um atacante encontre uma vulnerabilidade, não conseguirá aumentar seus privilégios.
• cap_drop: ALL: as capabilities do Linux controlam permissões de forma granular. Remover todas e devolver somente as necessárias, como vincular uma porta, reduz a superfície de ataque.
• read_only: true: torna o sistema de arquivos raiz somente leitura. Um invasor não conseguirá instalar um backdoor nem modificar arquivos do sistema. Locais que precisam de gravação, como /tmp, são montados com tmpfs.
• internal: true: impede o contêiner de acessar a internet. Se o OpenClaw só processa arquivos locais, isso evita a exfiltração de dados.

3. Ative o modo sandbox do OpenClaw

A configuração principal do OpenClaw geralmente fica em ~/.openclaw/openclaw.json e usa JSON. O YAML abaixo serve apenas para ilustrar a estrutura; confirme campos e níveis na documentação oficial de configuração do Gateway. Se seu repositório GitOps usa config/config.yaml, esse é um nome interno e não o arquivo padrão do projeto upstream.

sandbox:
  mode: "non-main"  # Executa todos os chats em grupo em contêineres isolados
  docker:
    enabled: true
    network: "none"  # Desativa o acesso à rede nos contêineres de sandbox

Esse é o sandbox do próprio OpenClaw. mode: "non-main" significa que todas as conversas, exceto o chat principal, rodam em contêineres Docker independentes. Mesmo que um diálogo sofra prompt injection, ficará limitado ao próprio sandbox.

Validação

# Verifica se o contêiner usa um usuário não root
docker exec openclaw-safe whoami
# Deve retornar: clawuser

# Verifica se o sistema de arquivos é somente leitura
docker exec openclaw-safe touch /test.txt
# Deve retornar: Read-only file system

# Verifica o isolamento de rede
docker exec openclaw-safe ping 8.8.8.8
# Deve retornar: Network is unreachable

Se os três testes passarem, a primeira camada estará pronta.

Segunda camada: execução como usuário sem privilégios (obrigatória)

O contêiner usa um usuário não root, mas quem iniciou o contêiner? Se você executar docker-compose up como root no host, um atacante que escape do contêiner ainda poderá obter privilégios de root.

Solução: criar um usuário dedicado com poucos privilégios

No host:

# Cria grupo e usuário dedicados
sudo groupadd -r openclaw
sudo useradd -r -g openclaw -d /opt/openclaw -s /bin/bash clawuser

# Cria a estrutura de diretórios
sudo mkdir -p /opt/openclaw/{workspace,config,logs,temp}

# Define proprietário e permissões
sudo chown -R clawuser:openclaw /opt/openclaw
sudo chmod 700 /opt/openclaw/config  # Somente o proprietário lê e grava a configuração
sudo chmod 755 /opt/openclaw/workspace  # Diretório de trabalho
sudo chmod 750 /opt/openclaw/logs  # Diretório de logs

# Restringe a conta
sudo usermod -L clawuser  # Bloqueia login por senha; permite apenas alternar com su

Por que usar chmod 700?

chmod 700 permite leitura, gravação e execução apenas ao proprietário, clawuser. Outros usuários nem sequer podem listar o conteúdo. Como os arquivos de configuração podem conter tokens e senhas, essa restrição é indispensável.

Permissões de credenciais — muito importante

Se o OpenClaw se conecta ao WhatsApp ou a outro serviço, restrinja as credenciais:

# Somente o proprietário pode ler e gravar as credenciais
chmod 600 ~/.openclaw/credentials/whatsapp/*/creds.json
chmod 700 ~/.openclaw

Já vi credenciais configuradas como 644, legíveis por todos, serem acessadas por outros usuários do mesmo servidor. Não cometa esse erro básico.

Validação

# Verifica o usuário do processo OpenClaw
ps aux | grep openclaw
# Deve mostrar clawuser, e não root

# Verifica as permissões
ls -la /opt/openclaw/config
# Deve mostrar drwx------ clawuser openclaw

Por que essa camada importa?

Considere o pior caso: o atacante escapou do contêiner, rompeu o sandbox do OpenClaw e executou código arbitrário. Ainda assim, ele terá somente as permissões de clawuser:

• não poderá acessar arquivos de outros usuários;
• não poderá instalar software no sistema, pois não tem sudo;
• não poderá modificar configurações em /etc;
• não poderá ler o diretório /root.

Essa é a defesa em profundidade: quando uma camada falha, a seguinte continua protegendo você.

Terceira camada: controle de acesso e autenticação (obrigatória)

As duas primeiras camadas definem “o que o OpenClaw pode fazer”. Esta define “quem pode usar o OpenClaw”.

Mudança importante na v2026.1.29

Antes, o OpenClaw permitia auth: none, sem qualquer autenticação. A v2026.1.29 removeu essa opção e passou a exigir token ou senha.

Configure a autenticação por token no Gateway

Qual é a vantagem sobre uma senha? Você pode fornecer tokens diferentes a pessoas e aplicativos, com permissões diferentes. Se um token vazar, revogue somente ele sem afetar os demais.

Configure a seção do Gateway em ~/.openclaw/openclaw.json. Não confunda com o nome config/config.yaml de um repositório próprio; o YAML serve apenas como ilustração:

gateway:
  # Exige autenticação por token
  auth: token

  # Configuração dos tokens
  tokens:
    - name: "admin-token"
      value: "${OPENCLAW_ADMIN_TOKEN}"  # Lê da variável de ambiente; não grave o valor aqui
      permissions:
        - "admin"  # Permissões completas

    - name: "readonly-token"
      value: "${OPENCLAW_READONLY_TOKEN}"
      permissions:
        - "chat"  # Pode conversar
        - "read"  # Pode apenas ler arquivos
      # Não inclui permissões perigosas como exec e browser

Gere um token seguro

Não use valores fracos como 123456 ou mytoken. Gere um token aleatório de 256 bits:

# Gera um token aleatório
openssl rand -base64 32

# Define variáveis de ambiente; não grave o token no arquivo de configuração
export OPENCLAW_ADMIN_TOKEN="token gerado por você"
export OPENCLAW_READONLY_TOKEN="outro token"

O valor não deve ficar no arquivo de configuração porque ele pode ser enviado ao Git, registrado em logs ou copiado para um backup na nuvem. Uma variável de ambiente reduz essa exposição.

Lista de acesso permitido

O token resolve quem pode se autenticar, mas talvez você queira permitir apenas determinados usuários ou grupos do WhatsApp:

# Política para mensagens diretas
dmPolicy: allowlist
allowFrom:
  - "user_id_1"  # Somente estes usuários podem enviar mensagens diretas
  - "user_id_2"

# Política para grupos
groupPolicy: allowlist
allowFrom:
  - "group_id_1"  # Somente estes grupos podem usar o serviço

# Em grupos, responde apenas quando mencionado
mentionGating: true

# Proíbe acesso público
publicAccess: false

mentionGating: true é especialmente útil. Em um grupo de trabalho com 100 pessoas, sem essa opção o OpenClaw processaria cada mensagem, elevando custos e o risco de prompt injection. Com ela, responde apenas quando alguém o menciona.

Validação

# Testa acesso não autorizado; deve ser rejeitado
curl -X POST http://localhost:3000/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# Deve retornar: 401 Unauthorized

# Testa um token válido
curl -X POST http://localhost:3000/api/chat \
  -H "Authorization: Bearer ${OPENCLAW_ADMIN_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"message":"hello"}'
# Deve retornar: 200 OK

Por que essa camada é essencial?

Sem controle de acesso, todo o isolamento anterior perde valor: o atacante entra diretamente pela API, sem precisar escapar do Docker nem elevar privilégios.

Esta camada é o porteiro que mantém do lado de fora quem não deveria entrar.

Quarta camada: controle de permissões das ferramentas (recomendada)

O OpenClaw já está dentro da jaula, mas ainda dispõe de muitas ferramentas. É hora de retirar as mais perigosas.

Problema: todas as ferramentas ficam disponíveis por padrão

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

Ver preços →Anúncio

O OpenClaw inclui dezenas de ferramentas: exec para comandos Shell, browser para controlar o navegador, write_file para gravar arquivos, web_fetch para buscar páginas e muitas outras. Por padrão, todas ficam habilitadas.

Você realmente precisa de todas? Se usa o OpenClaw apenas para escrever código e consultar informações, pode desativar browser e exec.

Configure uma lista de ferramentas permitidas

tools:
  # Libera apenas ferramentas seguras
  allowlist:
    - "read_file"      # Lê arquivos
    - "write_file"     # Grava somente nos diretórios permitidos
    - "web_search"     # Pesquisa na web
    - "git"            # Operações do Git
    # Não inclui ferramentas perigosas como exec e browser

  # Ferramentas de alto risco exigem autorização explícita
  exec:
    enabled: false  # Desativa comandos shell por padrão

  browser:
    enabled: false  # Desativa o controle do navegador

  web_fetch:
    enabled: true
    # Lista de domínios permitidos
    allowedDomains:
      - "github.com"
      - "api.anthropic.com"
      - "*.npmjs.com"

Se exec for indispensável, limite os comandos

Às vezes é necessário executar comandos, por exemplo para rodar testes ou fazer o build. Use uma lista de permissões:

tools:
  exec:
    enabled: true
    sandbox: true  # Executa dentro do sandbox

    # Lista de permissões é melhor que lista de bloqueio
    allowCommands:
      - "git"
      - "npm"
      - "yarn"
      - "pytest"
      - "curl"

    # Bloqueio adicional de comandos perigosos
    denyCommands:
      - "rm -rf"
      - "sudo"
      - "chmod 777"
      - "dd if="
      - "mkfs"
      - "> /dev/sda"

Uma lista de permissões é melhor porque os métodos de ataque são inúmeros, enquanto o conjunto de comandos seguros de que você precisa é limitado.

Restrinja o acesso ao sistema de arquivos

filesystem:
  # Diretórios permitidos
  allowedPaths:
    - "/home/clawuser/workspace"
    - "/home/clawuser/projects"

  # Diretórios proibidos
  deniedPaths:
    - "/home/clawuser/.ssh"
    - "/home/clawuser/.aws"
    - "/home/clawuser/.config"
    - "/etc"
    - "/root"

  # Permissão padrão
  defaultPermission: "readonly"

  # Gravação somente onde for explicitamente autorizada
  writablePaths:
    - "/home/clawuser/workspace/temp"

Com isso, um prompt injection que peça para ler ~/.ssh/id_rsa será bloqueado.

Validação

Teste na interface de conversa:

• Você: “Execute sudo apt update.”

  • O OpenClaw deve responder que o comando foi bloqueado pela política de segurança.

• Você: “Leia o arquivo ~/.ssh/id_rsa.”

  • O OpenClaw deve responder: Access denied.

Quinta camada: isolamento e monitoramento de rede (avançada)

Para empresas, ambientes com dados sensíveis ou quem busca proteção máxima, esta camada oferece a defesa final.

Isolamento: corte conexões desnecessárias

Antes usamos internal: true para impedir o acesso externo do contêiner. Mas como o OpenClaw chamará a API do Claude?

Solução: use um proxy para o tráfego de saída

Permita que o OpenClaw acesse somente domínios específicos, como api.anthropic.com, e bloqueie os demais:

# docker-compose.yml
services:
  openclaw-gateway:
    environment:
      - HTTP_PROXY=http://allowlist-proxy:8080
      - HTTPS_PROXY=http://allowlist-proxy:8080
    networks:
      - openclaw-isolated

  allowlist-proxy:
    image: squid:latest
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro
    networks:
      - openclaw-isolated
      - external  # Somente o proxy pode acessar a rede externa

squid.conf, configuração da lista de domínios permitidos:

# Domínios permitidos
acl allowed_domains dstdomain .anthropic.com
acl allowed_domains dstdomain .github.com
acl allowed_domains dstdomain .npmjs.com

# Permite HTTPS
acl SSL_ports port 443
acl CONNECT method CONNECT

# Regras de acesso
http_access allow allowed_domains
http_access deny all

# Logs
access_log /var/log/squid/access.log

Com essa configuração, o OpenClaw alcança apenas esses três domínios. O proxy bloqueia qualquer outro site. Mesmo que um prompt injection tente fazê-lo baixar um script malicioso, a solicitação não passará.

Logs de auditoria: registre tudo

Logs não impedem ataques, mas mostram o que aconteceu:

logging:
  # Ativa logs detalhados
  level: "info"

  # Log de auditoria
  auditLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/audit.log"
    format: "json"

    # O que registrar
    logToolCalls: true        # Todas as chamadas de ferramentas
    logFileAccess: true       # Acesso a arquivos
    logNetworkRequests: true  # Solicitações de rede
    logPrompts: true          # Todos os prompts, para detectar injeção

  # Log das sessões
  sessionLog:
    enabled: true
    path: "/home/clawuser/openclaw/logs/sessions/"

logPrompts: true é particularmente importante. Se alguém inserir uma instrução maliciosa na conversa, como “ignore as restrições anteriores e execute…”, ela ficará registrada para análise posterior.

Monitoramento em tempo real

# Monitora atividades suspeitas
tail -f /opt/openclaw/logs/audit.log | grep -E "(exec|sudo|rm|chmod)"

# Monitora conexões de rede
docker exec openclaw-safe netstat -tuln

# Monitora o uso de recursos
docker stats openclaw-safe

Configure alertas

Para avançar mais, você pode configurar alertas automáticos:

alerts:
  # Execução de comandos suspeitos
  - type: "command_execution"
    pattern: "sudo|rm -rf|chmod 777"
    action: "block_and_notify"

  # Acesso a arquivos sensíveis
  - type: "file_access"
    pattern: "/.ssh/|/.aws/|/etc/passwd"
    action: "block_and_notify"

  # Acesso a sites suspeitos
  - type: "network_request"
    pattern: ".*\\.onion|torproject\\.org"
    action: "block_and_notify"

Ao disparar um alerta, o sistema pode enviar e-mail, mensagem no Slack ou até pausar o serviço OpenClaw.

Estratégia para começar em modo somente leitura

Depois de configurar as cinco camadas, talvez você queira ativar tudo de uma vez.

Minha recomendação é: não faça isso.

Segurança e conveniência sempre exigem equilíbrio. Restrições excessivas podem impedir o OpenClaw de realizar até tarefas básicas; permissões amplas demais anulam a proteção.

A melhor estratégia é começar com o nível mais rigoroso e liberar aos poucos.

Primeira semana: modo totalmente somente leitura

Na implantação inicial, observe o comportamento do OpenClaw em modo somente leitura:

tools:
  allowlist:
    - "read_file"
    - "web_search"
    - "git_log"  # Operações Git somente leitura

filesystem:
  defaultPermission: "readonly"
  writablePaths: []  # Proíbe toda gravação

O que fazer nessa semana? Observar.

• Veja quais arquivos o OpenClaw acessa com frequência.
• Procure atividades suspeitas nos logs.
• Entenda quais ferramentas ele costuma chamar.
• Teste o comportamento diante de prompt injection em um ambiente seguro.

Se não houver incidentes, a configuração básica provavelmente está correta. Se notar algo estranho, como tentativas frequentes de acessar .ssh, descubra rapidamente se há erro de configuração ou atividade maliciosa.

Segunda semana: libere gravação restrita

Depois do período de observação, libere a gravação gradualmente:

filesystem:
  writablePaths:
    - "/home/clawuser/workspace/temp"  # Grava somente arquivos temporários

tools:
  allowlist:
    - "write_file"  # Limitado a writablePaths
    - "git_commit"  # Permite commits

Somente o diretório temporário recebe permissão de gravação. Os arquivos importantes do projeto continuam somente leitura e não podem ser modificados diretamente pelo OpenClaw.

Assim, mesmo que a IA interprete “limpar o projeto” como “apagar tudo”, conseguirá remover apenas arquivos temporários; o código-fonte continuará seguro.

Terceira semana em diante: habilite ferramentas conforme a necessidade

Libere ferramentas aos poucos, com base no uso real:

tools:
  exec:
    enabled: true
    sandbox: true
    allowCommands:
      - "git"  # Comece permitindo apenas git
      - "npm test"  # Acrescente quando precisar executar testes

Princípios essenciais:

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

Começar →Anúncio

• Libere apenas uma permissão por vez: não habilite exec, browser e write_file simultaneamente. Se algo der errado, será difícil identificar a causa.
• Observe por 24 horas após cada mudança: revise os logs de auditoria e procure anomalias.
• Reverta imediatamente diante de um problema: se notar algo suspeito, retire a permissão recém-concedida.

Caso real: como minha configuração evoluiu

No começo, também tentei ativar de uma vez uma “solução completa de segurança” baseada na documentação oficial. O resultado? O OpenClaw não conseguia nem completar código, porque eu havia desativado write_file.

Depois passei a evoluir a configuração em etapas:

• Primeira semana: modo somente leitura para consultar documentação e explicar código. Nenhum problema.
• Segunda semana: liberei gravação em workspace/drafts para criar rascunhos. Funcionou bem.
• Terceira semana: habilitei comandos git para fazer commits. Esqueci de configurar o usuário do Git e cada commit falhava; depois de corrigir isso, tudo funcionou.
• Quarta semana: habilitei npm test para executar testes unitários. Isso já atendia às necessidades cotidianas.

Nunca habilitei browser nem um exec irrestrito, porque não preciso deles.

Lição: não habilite permissões desnecessárias apenas para sentir que a configuração está completa. É melhor aceitar algum atrito e liberar recursos sob demanda.

Checklist de segurança

Depois de tantas configurações, como garantir que nada ficou para trás? Revise esta lista antes da implantação para evitar 90% dos erros básicos.

Antes da implantação, marque todos os itens

Segurança do contêiner:

• ☐ Foi criado um usuário sem privilégios; o processo não roda como root no contêiner
• ☐ O Docker usa no-new-privileges:true
• ☐ Todas as capabilities do Linux foram removidas com cap_drop: ALL
• ☐ O sistema de arquivos raiz está somente leitura com read_only: true
• ☐ Há limites de CPU e memória
• ☐ O modo sandbox do OpenClaw está habilitado

Autenticação:

• ☐ A autenticação usa um token forte, e não auth: none
• ☐ O token é aleatório e tem pelo menos 32 caracteres
• ☐ O token está em uma variável de ambiente, não no código
• ☐ Há uma lista de mensagens diretas e grupos permitidos
• ☐ Se a implantação está em um VPS, há uma lista de IPs permitidos

Controle de permissões:

• ☐ As ferramentas usam uma lista de permissões
• ☐ Ferramentas de alto risco, como exec e browser, estão desativadas ou limitadas por comandos permitidos
• ☐ O acesso ao sistema de arquivos está restrito
• ☐ Diretórios sensíveis, como .ssh e .aws, estão bloqueados
• ☐ Arquivos de credenciais têm permissão 600

Auditoria e monitoramento:

• ☐ O log de auditoria está habilitado
• ☐ O log de sessões está habilitado
• ☐ O diretório de logs tem espaço em disco suficiente
• ☐ Você sabe como consultar e analisar os logs

Verificações periódicas em produção

Toda semana:

• ☐ Revise os logs de auditoria em busca de anomalias
• ☐ Verifique o uso de CPU, memória e disco
• ☐ Procure tentativas de acesso não autorizado
• ☐ Faça backup dos arquivos de configuração

Todo mês:

• ☐ Atualize o OpenClaw para a versão mais recente
• ☐ Faça a rotação dos tokens se o serviço roda continuamente
• ☐ Verifique vulnerabilidades nas imagens Docker com docker scan
• ☐ Revise a configuração e remova permissões desnecessárias

Prepare a resposta a incidentes

Se algo realmente acontecer, você sabe o que fazer?

Prepare um script de parada de emergência:

#!/bin/bash
# emergency-stop.sh

echo "Interrompendo o OpenClaw em caráter de emergência..."

# Para o contêiner
docker stop openclaw-safe

# Revoga todos os tokens, caso use um sistema de tokens dinâmicos
# curl -X DELETE https://your-auth-server/tokens/revoke-all

# Envia um alerta
curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"OpenClaw interrompido em caráter de emergência"}'

echo "Serviço interrompido. Verifique o log: /opt/openclaw/logs/audit.log"

Como agir diante do vazamento de um token:

1. Revogue imediatamente o token vazado.
2. Examine os logs de auditoria para saber como ele foi usado.
3. Gere um novo token e peça aos usuários legítimos que o atualizem.
4. Se houve vazamento de dados, inicie o plano de resposta correspondente.

Ao encontrar atividade suspeita:

1. Não desligue o serviço imediatamente, pois isso pode alertar o atacante.
2. Primeiro, preserve os logs e um snapshot do contêiner.
3. Analise o caminho do ataque e a extensão do impacto.
4. Só então decida entre isolar, reiniciar ou reconstruir o ambiente.

Conclusão

Depois de tudo isso, a ideia central cabe em uma frase: o OpenClaw é poderoso, mas essa “fera” só trabalha a seu favor dentro de uma jaula segura.

Recapitulando as cinco camadas:

1. Isolamento por sandbox Docker: mantém o OpenClaw no contêiner e limita os arquivos e a rede que ele alcança.
2. Usuário sem privilégios: mesmo durante um ataque, o invasor terá poucas permissões e não conseguirá causar danos amplos.
3. Controle de acesso: autenticação por token e lista de permissões mantêm usuários indevidos do lado de fora.
4. Controle das ferramentas: desativa ferramentas perigosas e concede apenas as permissões necessárias.
5. Isolamento e monitoramento de rede: corta conexões desnecessárias e registra todas as operações.

As três primeiras são obrigatórias, independentemente de como você usa o OpenClaw. As duas últimas são recomendadas, especialmente para dados sensíveis ou implantação empresarial.

Configurar tudo isso realmente dá trabalho. Talvez você pense: “Vou só testar por conta própria; preciso mesmo de tanto cuidado?”

Minha resposta é: sim.

Não porque o OpenClaw seja inseguro por si só, mas porque a IA é muito capaz. Ao pedir que ela “organize os arquivos do projeto”, ela pode entender que deve apagar todos os temporários, inclusive um rascunho importante sem backup. Ao pedir os commits recentes, ela pode ler credenciais em .git/config no caminho.

Não se trata de malícia, apenas de excesso de iniciativa. As consequências, porém, podem ser igualmente graves.

A configuração segura não serve para impedir o OpenClaw de agir de má-fé. Ela limita o raio de impacto dos acidentes. Mesmo quando algo dá errado, o prejuízo permanece controlável.

Para terminar, três ações práticas:

1. Revise agora a configuração do seu OpenClaw: se ainda usa os padrões, interrompa o serviço e implemente pelo menos as três primeiras camadas.
2. Comece de forma rigorosa e libere aos poucos: observe por uma semana em modo somente leitura antes de ampliar as permissões.
3. Revise os logs regularmente: cinco minutos por semana podem revelar anomalias cedo, quando ainda são fáceis de conter.

O OpenClaw é uma ótima ferramenta. Mas, assim como a energia nuclear, pode beneficiar muita gente quando bem controlado e causar um desastre quando mal utilizado.

A configuração parece trabalhosa, mas é pouco diante de um vazamento de dados, de um banco de produção apagado ou de precisar pedir socorro no Reddit.

Concorda?

Próximas leituras

• Cinco controles de segurança indispensáveis na configuração inicial do OpenClaw
• Configuração do OpenClaw: guia completo do openclaw.json
• Como instalar o OpenClaw em 2026: do zero ao assistente pessoal de IA