Como executar o OpenClaw com segurança em um VPS

O que é o OpenClaw e por que deve ser protegido primeiro

O OpenClaw é um agente de IA autoalojado. Você o executa no seu próprio servidor, conecta-o a um modelo de linguagem de grande escala e ele pode executar comandos shell, controlar um navegador, ler e gravar os seus ficheiros e agir sobre as mensagens que você lhe envia a partir de aplicações de chat. Esse alcance é o objetivo principal da ferramenta e também constitui todo o risco. Um agente que pode executar qualquer comando é tão seguro quanto o sistema onde é executado e os limites que você coloca à sua volta.

Dois factos definem o tom deste guia. Primeiro, o OpenClaw foi concebido para ser protegido por você. O seu modelo de segurança atribui ao operador a responsabilidade por políticas restritivas para as ferramentas, sandboxing e permissões cuidadosas, em vez de fornecer predefinições seguras. Segundo, o projeto já teve um incidente de segurança grave: em março de 2026, foram divulgados nove problemas de segurança num período de quatro dias, incluindo uma falha crítica de elevação de privilégios, CVE-2026-32922, com classificação de 9.9 em 10. Nenhum destes factos significa que você deva evitar o OpenClaw. Significam que não deve executá-lo da forma mais descuidada, e este guia apresenta a forma cuidadosa. Essa forma cuidadosa inclui decidir antecipadamente o que o agente pode fazer sem pedir confirmação, uma escolha que o Claude Code explicita com os seus modos de permissão, em que um servidor diante do qual você não está merece uma configuração mais restritiva do que o portátil que você está a acompanhar.

Também há boas notícias. O OpenClaw já toma uma decisão segura por você: o seu gateway, o único processo que controla tudo, escuta por predefinição no endereço de loopback, pelo que não fica acessível a partir da Internet a menos que você o exponha deliberadamente. A maior parte do trabalho abaixo consiste em mantê-lo assim e limitar o impacto caso algo corra mal.

Dê ao OpenClaw um utilizador próprio sem privilégios

Nunca execute um agente como root. Se o OpenClaw for executado como root e algo correr mal, seja devido a um bug, a uma instrução incorreta ou a uma CVE como a mencionada acima, os danos não terão limite. Crie um utilizador de sistema dedicado, sem shell de início de sessão e sem sudo, e execute o agente com esse utilizador:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Tudo o que pertence ao OpenClaw fica em /opt/openclaw, com esse utilizador como proprietário. Este é o passo mais importante. É o mesmo princípio abordado em executar serviços como utilizador sem privilégios: o utilizador com que um agente é executado define o limite dos danos que ele pode causar.

Instalar o OpenClaw

O OpenClaw é distribuído como um pacote npm. Instale primeiro o Node.js se o servidor ainda não o tiver. Instale o pacote globalmente. Isto coloca o binário openclaw no PATH de todos os utilizadores. Em seguida, execute a configuração inicial, uma única vez:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Executar a configuração como o utilizador openclaw faz com que a configuração do agente seja guardada no diretório pessoal desse utilizador, /opt/openclaw, e não no diretório pessoal de root. O projeto também disponibiliza um instalador curl -fsSL https://openclaw.ai/install.sh | bash que faz a mesma instalação com um único comando. Não use a flag --install-daemon durante a configuração inicial. Essa flag registaria o próprio serviço do OpenClaw, enquanto a unidade systemd reforçada criada abaixo é mais restritiva.

Mantenha o gateway no loopback, atrás de uma firewall

O gateway faz bind a 127.0.0.1 por predefinição. Deixe-o assim. Quase nunca existe uma razão para publicar essa porta na internet. Fazer isso dá a qualquer pessoa que a encontre um ponto de entrada remoto para um processo que executa comandos.

Coloque uma firewall com política padrão de negar à frente do servidor, para que nada fique exposto por acidente:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Evite aqui duas armadilhas. Uma firewall que cobre apenas IPv4 pode deixar o mesmo serviço totalmente aberto em IPv6. Esta é exatamente a falha da firewall IPv6 que apanha tantas pessoas. Se precisar de aceder ao gateway a partir do portátil, não abra a porta. Aceda através de uma VPN ou de um túnel SSH. Assim, o agente nunca fica à escuta na internet aberta.

Isole os segredos

O OpenClaw precisa de uma chave de API para o modelo de linguagem ao qual se liga. Essa chave pode gastar o seu dinheiro e, através do agente, agir em seu nome. Trate-a como uma palavra-passe. Mantenha-a fora do ficheiro da unidade e de qualquer repositório. Coloque-a num ficheiro que apenas o utilizador do OpenClaw possa ler:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

A unidade systemd carrega esse ficheiro com EnvironmentFile. Assim, a chave chega ao processo sem ficar numa linha de comandos, num log ou no histórico da shell. O mesmo padrão aplica-se a todos os segredos do servidor: uma auditoria de hardening do Vaultwarden self-hosted concentra-se no token de administrador e no ficheiro de backup, e não na encriptação, porque são as permissões do ficheiro que determinam efetivamente quem pode ler um segredo armazenado.

Execute como um serviço systemd protegido

Executar o agente através do systemd fornece reinícios automáticos, logs organizados através de journalctl e, sobretudo, um conjunto de opções de sandboxing ao nível do kernel que reduz o que o processo pode aceder, mesmo que seja comprometido. As opções mais importantes para um agente são NoNewPrivileges, para que nunca possa obter novos privilégios, ProtectSystem=strict, para tornar o sistema de ficheiros somente leitura, exceto nos locais onde permitir escritas, PrivateTmp, para criar o seu próprio diretório temporário isolado, e ProtectHome, para impedir o acesso aos diretórios pessoais.

Gere aqui uma unidade completa e protegida. Depois, copie-a para /etc/systemd/system/openclaw.service:

A unidade inicia openclaw gateway, o processo de longa duração que controla o agente. Se which openclaw apresentar um caminho diferente no seu servidor, ajuste ExecStart para corresponder. O guia completo destas diretivas e de daemon-reload e enable --now está em executar um programa como um serviço systemd. Depois de colar a unidade, o resumo é:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Reforce também a porta de entrada

Uma máquina com um agente só é tão segura quanto o servidor que a aloja. São necessárias mais duas camadas para concluir a proteção. Configure o SSH para aceitar apenas autenticação por chave e desative o início de sessão de root, conforme explicado em Reforço do SSH num VPS, para impedir ataques de força bruta à conta usada para administrar a máquina. Depois, adicione Fail2ban para bloquear os scanners que atacam todas as portas públicas. Nenhuma destas medidas altera diretamente o OpenClaw, mas ambas eliminam os caminhos que um atacante usaria para chegar até ele.

Mantenha-o atualizado de forma intencional

As divulgações de março de 2026 são o argumento mais claro possível para manter o sistema atualizado. Uma falha de escalada de privilégios num agente é muito mais grave do que numa aplicação Web comum, porque o agente já executa comandos. Monitorize os releases do projeto, aplique rapidamente as atualizações de segurança e trate uma atualização do OpenClaw como manutenção de rotina, em vez de a adiar.

Para compreender o que está efetivamente a proteger, a arquitetura de um agente ao estilo do OpenClaw explica os vários componentes, e criar o seu próprio agente de IA num VPS descreve a estrutura geral de qualquer agente. Se acabar por executar um segundo agente em paralelo, lembre-se de que duas sessões do Claude Code num único VPS podem passar trabalho entre si, pelo que cada uma precisa da sua própria conta e dos seus próprios limites, em vez de herdar os seus.

FAQ

É seguro executar o OpenClaw numa VPS pública?

Pode ser, se aplicar medidas de proteção. O OpenClaw é poderoso por conceção: executa comandos shell e controla um browser, por isso uma configuração descuidada é realmente perigosa. O projeto já teve uma CVE crítica (CVE-2026-32922 em março de 2026). O modelo de segurança pressupõe que o operador imponha os limites. Execute-o com um utilizador sem privilégios, mantenha o gateway em loopback atrás de uma firewall com política default-deny, isole as respetivas chaves de API e execute-o como um serviço systemd protegido.

Devo expor o gateway do OpenClaw à internet?

Não. Por predefinição, o gateway faz bind a loopback, e deve mantê-lo assim. É o único processo que controla o agente, por isso um gateway exposto cria um caminho remoto para um componente que executa comandos como função principal. Se precisar de aceder a ele remotamente, use uma VPN ou um túnel SSH em vez de abrir a porta.

Com que utilizador o OpenClaw deve ser executado?

Com um utilizador de sistema dedicado, sem shell de login e sem sudo, nunca root. Se o agente for comprometido, a conta do utilizador limita a extensão dos danos. Por isso, essa conta deve ser proprietária apenas dos seus próprios ficheiros num diretório como /opt/openclaw e de mais nada.

Como mantenho seguras as chaves de API do OpenClaw?

Guarde-as num ficheiro legível apenas pelo utilizador do OpenClaw (modo 600) e carregue-as no serviço com o EnvironmentFile do systemd. Mantenha a chave fora do ficheiro da unidade, do histórico da shell e de qualquer repositório git. Faça a rotação da chave se suspeitar que foi divulgada.