A instalação do OpenClaw é fácil, e esse é o problema. Ferramenta poderosa e fácil de instalar produz muita instância no ar e pouca instância bem configurada. Foi assim que dezenas de milhares delas ficaram vulneráveis em março de 2026.
Então este tutorial tem uma ordem incomum: as três primeiras etapas são de contenção, não de uso. Se você quiser pular direto para “como faço ele trabalhar”, entenda que está pulando a parte que evita a manchete.
Passo 1: escolher uma máquina descartável
A primeira decisão, e ela é sobre onde, não sobre como.
O OpenClaw executa comandos com as permissões que tiver. Isso significa que a máquina onde ele roda é a fronteira do dano possível. Se ele estiver no servidor que hospeda o seu site, o banco de produção ou os arquivos da empresa, o dano possível inclui tudo isso.
Use uma instância separada. Um VPS de entrada custa poucos reais por mês, e é a diferença entre um incidente contido e um incidente sério. Se você pensou em aproveitar um servidor que já tem, a resposta é não aproveitar. Dimensionamento em hospedagem.
Enquanto estiver aprendendo, vale ainda mais restrição: máquina sem credencial de nada importante, sem acesso a dado real, sem chave de produção guardada. Você vai querer testar o que o agente faz, e testar com rede é melhor.
Passo 2: fechar a porta antes de abrir o programa
Este é o passo mais importante do tutorial e o mais fácil de pular.
O gateway WebSocket do OpenClaw escuta na porta 18789. Se essa porta estiver alcançável pela internet, você está na configuração exata do incidente mais grave já registrado no projeto: era suficiente que a vítima abrisse uma página maliciosa para que um atacante obtivesse controle total do agente, com execução de comando e acesso a arquivos, sem autenticação.
O que fazer, em ordem:
Não publique a porta. Se estiver em container, não mapeie a porta para a interface pública. Bind local apenas.
Acesse por caminho autenticado. Rede privada, VPN ou túnel. A regra é: o gateway responde para você e para mais ninguém.
Teste de fora. Não confie na configuração, verifique. De outra rede, ou de um celular no 4G, tente alcançar a porta no IP do servidor. Se responder, está exposto e isso é a única coisa que importa até ser corrigido.
Esse teste leva um minuto e é a diferença entre achar que está seguro e estar.
Passo 3: instalar, com a versão mais recente
Só agora. A instalação em si é por container ou pelo script oficial do projeto, e é a parte rápida.
Uma regra que vale mais aqui do que na média: instale a versão atual, não a que o tutorial que você está seguindo usava. O projeto trocou de nome duas vezes, de Clawdbot para Moltbot e depois para OpenClaw, e há muito material antigo circulando. Material de antes de 2026 pode ensinar configuração que hoje é insegura, e nesse caso o desatualizado não é só inconveniente.
Passo 4: conectar o modelo
O OpenClaw não pensa por conta própria: ele orquestra um modelo de linguagem que você conecta, por chave de API de um provedor externo ou apontando para um modelo local.
Duas observações práticas:
A chave de API é uma credencial de gasto. Ela permite consumir tokens na sua conta. Guarde como senha, e considere um limite de gasto no provedor, porque agente autônomo em laço consome mais rápido do que você percebe.
Comece com o mais simples. A escolha de modelo é reversível e afeta custo, capacidade e privacidade. Não vale otimizar isso antes de saber como você vai usar a ferramenta. A conta está em preços.
Passo 5: permissão mínima, ampliando só quando doer
A tentação é dar acesso amplo para “não ficar travando”. É o oposto do que fazer.
Cada permissão concedida define o alcance de dois problemas: o erro do agente e o invasor que tomar controle dele. Um agente que só pode ler uma pasta e rodar dois comandos é útil e limitado. Um agente com acesso irrestrito é útil e ilimitado, inclusive para quem não é você.
O caminho que funciona é começar restrito e ampliar quando uma tarefa real falhar por falta de permissão. Assim cada ampliação tem justificativa concreta, em vez de ser preventiva.
Passo 6: só agora, a primeira tarefa
Com a máquina isolada, a porta fechada, a versão atual, o modelo conectado e as permissões restritas, você está pronto para usar.
Comece com algo verificável e sem consequência: pedir para listar arquivos de uma pasta, resumir o conteúdo de um documento, checar se um serviço está no ar. O objetivo dessas primeiras tarefas não é produtividade, é calibrar a sua confiança: você precisa ver como ele interpreta instrução ambígua antes de deixá-lo mexer em algo que importa.
Preste atenção especial em uma coisa: o que ele faz quando não entende. Agente que pede esclarecimento é seguro. Agente que assume e executa exige que você seja mais explícito nas instruções, e saber de qual tipo é o seu muda como você vai escrever os pedidos.
Passo 7: montar a rotina de atualização
Se você chegou até aqui, a parte difícil terminou. Esta é a parte que dura.
Defina uma rotina, não uma intenção. Acompanhar os avisos de segurança do repositório do projeto, verificar versão nova periodicamente, e uma checagem mensal de que a porta do gateway continua fechada, porque mudança de configuração de rede acontece.
O histórico de nove CVEs em quatro dias, uma com pontuação 9.9, mostra que a janela entre a divulgação de uma falha e a exploração dela é curta. Instância que fica dois meses sem atualização não está com dívida técnica, está com risco ativo.
Se ler isso te fez concluir que você não vai manter essa rotina, essa é uma conclusão útil e respeitável. A resposta certa nesse caso não é instalar de qualquer jeito: é a versão gerenciada, que comparo em hospedagem.
Checklist final, para conferir antes de usar em algo que importa
Vale rodar esta lista de olho antes de dar ao agente qualquer tarefa com consequência. Cada item é uma pergunta com resposta sim ou não.
- A máquina é dedicada, sem dado de produção e sem credencial importante?
- A porta 18789 está inalcançável da internet, testado de outra rede?
- A versão instalada é a atual do projeto, não a do tutorial que você seguiu?
- As permissões estão restritas ao que a tarefa exige, e não amplas por precaução?
- Existe limite de gasto configurado no provedor do modelo?
- Existe backup do que estiver nessa máquina, caso o agente erre?
- Existe rotina definida de acompanhamento de atualização, com data e não com intenção?
Sete perguntas. Se alguma resposta for não, esse é o próximo passo, e ele vem antes de usar.
Onde ir depois
O julgamento completo sobre a ferramenta, com segurança como eixo, está no review. O dimensionamento de servidor e a decisão entre auto-hospedar e gerenciado, em hospedagem. A conta com o custo do modelo, em preços. Outras abordagens de agente, em alternativas.