Boas práticas de segurança do OpenClaw

A documentação do OpenClaw publica uma configuração base reforçada: uma configuração do Gateway pronta para copiar e colar, que mantém uma implantação privada, pareada e com ferramentas restritas, e uma configuração base segura mais curta para quem só quer as três primeiras linhas. Este post é essa configuração explicada chave por chave, por que cada linha está ali e quais das decisões continuam valendo em um host gerenciado, onde a infraestrutura é de outra pessoa.

O Gateway: local, loopback, token

O modo local e o bind loopback mantêm o Gateway fora da rede; a autenticação por token, com um token longo e aleatório, protege todo cliente, até os locais, porque o modo de autenticação padrão é token mesmo para binds em loopback. A documentação dá um número real para a porta, 18789, e um aviso real sobre a alternativa: definir a autenticação como none permite que qualquer processo local se conecte.

Os canais: pareamento e menções

• Política de mensagens diretas pairing em todos os canais: remetentes desconhecidos esperam a sua aprovação, e a aprovação é por canal.
• Grupos exigem menção por padrão, então o agente lê uma sala sem responder a cada linha.
• Um número separado para canais baseados em telefone, para que as conversas pessoais continuem privadas e o número do bot fique com a automação.
• Escopo de mensagens diretas por peer de cada canal, para que a sessão de um remetente não vaze para a de outro.

As ferramentas: um perfil, uma lista de bloqueio e nenhuma válvula de escape

A configuração base reforçada parte do perfil de ferramentas messaging e nega de cara quatro grupos: automação, runtime, o sistema de arquivos e a criação de outras sessões ou o envio de mensagens a elas. O acesso ao sistema de arquivos fica restrito ao espaço de trabalho, exec é negado e definido como ask always, elevated é desativado, a visibilidade de sessões fica limitada às do próprio agente, e o acesso de agente para agente fica desligado. A documentação diz para reativar uma ferramenta quando você precisar dela, de forma deliberada, em vez de começar aberto e fechar depois. Uma regra é embutida e não pode ser removida por configuração: remetentes que não são o proprietário nunca recebem as ferramentas cron ou gateway.

Trate esses controles como defesa em profundidade que reduz a capacidade direta de quem faz a solicitação, não como isolamento entre múltiplos usuários hostis.

O que a configuração base não faz

• Ela não sanitiza conteúdo: controles com escopo no solicitante limitam o que um remetente pode fazer, não o que uma página web ou um e-mail pode dizer ao modelo.
• Ela não isola usuários locais hostis: para isso, a documentação diz para rodar Gateways separados sob usuários ou hosts separados do sistema operacional, ou usar sandbox.
• Ela não escolhe o nível do seu modelo, que a página sobre prompt injection trata como um controle de segurança por si só.

Prompt injection e o OpenClaw cobre o lado do conteúdo, e sandboxing, política de ferramentas e elevated, o lado de onde as ferramentas rodam; a configuração base é o lado de quem pode fazer o quê, e os três foram feitos para se somar.

Na Diali

As linhas do Gateway são nossas: ele nunca fica na internet, a instância não tem portas públicas e tem acesso de saída apenas à web pública, nunca à nossa rede interna, ao servidor de metadados da nuvem ou a outros clientes, e o token nunca sai do cofre. As linhas dos canais e das ferramentas são suas, no painel, porque quem pode mandar mensagens ao assistente e o que ele pode executar são questões de política, não de infraestrutura. A segurança na Diali é a página sobre a fronteira; o OpenClaw hospedado na Diali, sobre o assistente.

• Local, loopback, token: o Gateway não é um servidor.
• Pareamento, menções, um número separado: os canais têm controle de acesso.
• Um perfil, uma lista de bloqueio, sem elevated: as ferramentas são o menor conjunto que faz o trabalho.