Microsoft: não execute o OpenClaw em máquinas de trabalho comuns

Em 19 de fevereiro de 2026, a Equipe de Pesquisa de Segurança do Microsoft Defender publicou uma publicação intitulada "Executar o OpenClaw com segurança: identidade, isolamento e risco de runtime" e, nela, fez uma recomendação que o Orca AI Incident Archive não registra em nenhuma outra entrada: o OpenClaw "deve ser tratado como execução de código não confiável com credenciais persistentes" e "não é apropriado executá-lo em uma estação de trabalho pessoal ou corporativa padrão". O OpenClaw é um runtime de agente auto-hospedado — o usuário o instala em sua própria máquina, concede a ele contas e tokens e permite que ele instale habilidades de um registro público e atue sobre textos que lê de qualquer lugar. O argumento da Microsoft é arquitetural, não um relatório de bug: o runtime desloca o ponto de execução do código de aplicação estático para o conteúdo fornecido em tempo de execução, e os controles em torno de identidade, tratamento de entrada e privilégios não acompanharam essa mudança. A publicação não nomeia nenhum CVE, nenhuma campanha e nenhuma vítima, e não registra nenhum comprometimento. O registro completo está no Orca AI Incident Archive, onde é classificado como uma entrada de política marcante com grau de confiança A e nenhum dano real registrado.

O que a publicação disse, e o que não disse

A publicação leva cerca de doze minutos de leitura e não traz nenhum mecanismo de divulgação: nenhum identificador CVE, nenhuma faixa de versões afetadas, nenhuma build corrigida, nenhum indicador de comprometimento vinculado a uma implantação real. A Microsoft Defender Security Research lista Idan Hen como colaborador. O que ela traz, em vez disso, é um modelo de ameaça e uma regra de implantação, e é por isso que o arquivo a classifica como um registro de política, e não como um incidente — informações de severidade, grau de confiança A, nenhum dano real registrado, uma única data com precisão de dia.

O raciocínio é comprimido em um parágrafo de abertura. O OpenClaw "inclui controles de segurança integrados limitados", escreve a equipe, porque o runtime "pode ingerir texto não confiável, baixar e executar habilidades (ou seja, código) de fontes externas e realizar ações usando as credenciais atribuídas a ele". A consequência é declarada na mesma frase: isso "efetivamente desloca a fronteira de execução do código de aplicação estático para conteúdo fornecido dinamicamente e capacidades de terceiros, sem controles equivalentes em torno de identidade, tratamento de entrada ou escopo de privilégios".

Seguem-se três riscos, e vale a pena lê-los nas próprias palavras da Microsoft, porque a maior parte da cobertura que se seguiu parafraseou-os de forma vaga:

• "Credenciais e dados acessíveis podem ser expostos ou exfiltrados."

• "O estado persistente do agente, ou sua 'memória', pode ser modificado, fazendo com que ele siga instruções fornecidas pelo atacante ao longo do tempo."

• "O ambiente hospedeiro pode ser comprometido se o agente for induzido a recuperar e executar código malicioso."

Observe o que está ausente dessa lista. Não há falha explorada, nem função vulnerável, nem patch para distribuir. A Microsoft não está dizendo que o OpenClaw tem um bug de segurança; está dizendo que um programa que decide o que fazer em tempo de execução, a partir de texto que buscou, usando credenciais que lhe foram dadas, não pode ser tornado seguro por configuração em uma máquina que também contém o trabalho real do operador. A recomendação que se segue é correspondentemente direta — para a maioria dos ambientes, "a decisão apropriada pode ser não implantá-lo".

Duas cadeias de suprimentos, um ciclo de execução

O mecanismo descrito no post é a convergência do que ele chama de duas cadeias de suprimentos de um agente auto-hospedado: código não confiável, ou seja, habilidades e extensões, e instruções não confiáveis, ou seja, texto externo. A maioria dos softwares tem uma ou outra. Um gerenciador de pacotes baixa código não confiável, mas não lê a internet e decide o que executar em seguida; um modelo de chat lê texto não confiável, mas não consegue instalar nada. O OpenClaw faz as duas coisas em um único ciclo, e o ciclo é executado sob a própria identidade do usuário.

"Instalar uma skill é basicamente instalar código privilegiado", diz o post. As skills são "frequentemente descobertas e instaladas por meio do ClawHub, o registro público de skills do OpenClaw", e, em implantações permissivas, "o runtime pode ter permissão para executar o fluxo de instalação sem aprovação humana". A segunda cadeia de suprimentos é gerenciada pelo Moltbook, que o post descreve como uma plataforma e camada de identidade voltadas a agentes, onde os agentes publicam, leem e se autenticam por APIs — e, portanto, em sua formulação, "um fluxo de alto volume de conteúdo influenciável por atacantes que os agentes ingerem periodicamente". A compactação é o ponto: "Uma única postagem maliciosa pode, portanto, alcançar vários agentes."

O artigo então divide a fronteira de confiança em três componentes, que é a parte mais reutilizável de todo o documento: identidade, ou seja, os tokens que o agente usa para realizar trabalho em APIs de SaaS, repositórios, e-mail e planos de controle de nuvem; execução, ou seja, as ferramentas que ele pode executar e que alteram o estado, incluindo arquivos, shell, infraestrutura e mensagens; e persistência, ou seja, as formas pelas quais ele pode manter alterações entre execuções, por meio de tarefas, configuração e agendamentos. Um agente que tem os três não é uma aplicação com um prompt de permissão. É um principal.

A habilidade envenenada, em cinco etapas

A Microsoft fornece uma cadeia de comprometimento detalhada, rotulada como um cenário representativo e não como um relato de caso, e vale a pena percorrê-la porque seus últimos dois passos são os que derrotam as defesas comuns de endpoint. A publicação a precede com uma afirmação sobre o mundo exterior — "Relatos públicos documentaram o aparecimento de habilidades maliciosas em registros públicos" e, em alguns casos, "o conteúdo do registro tem sido malware direto empacotado como uma habilidade, em vez de uma imitação sutil" —, mas não nomeia nenhuma entrada de registro, campanha, ator ou vítima, portanto a cadeia se sustenta como um argumento de plausibilidade, não como uma reconstrução.

• Distribuição. Um atacante publica uma skill maliciosa no ClawHub, às vezes disfarçada de utilitário e às vezes abertamente maliciosa, e a promove por canais da comunidade; outras vezes ela é encontrada organicamente pela busca e instalada porque a instalação tem pouca fricção.

• Instalação. Um desenvolvedor ou o próprio agente inicia a instalação porque a habilidade parece relevante para a tarefa. Em uma implantação permissiva, nenhum humano a aprova.

• Acesso ao estado. O atacante visa tokens, credenciais em cache, dados de configuração e transcrições, além dos canais de instrução persistentes — arquivos de tarefas, ações agendadas, configuração de agentes — que orientam execuções futuras.

• Reutilização de privilégios. Com material de identidade válido, o atacante atua por meio de APIs e ferramentas padrão, e a atividade "muitas vezes se assemelha a automação legítima, a menos que controles robustos de monitoramento e registro estejam em vigor".

• Persistência por meio da configuração. O que resta é a mudança de configuração durável: "novos consentimentos OAuth, execuções agendadas, tarefas de agente modificadas ou ferramentas que permanecem permanentemente aprovadas."

O quinto passo traz a frase mais contundente da publicação, e a que melhor explica por que isto é um problema de política e não de malware: “O objetivo tem menos a ver com implantar malware e mais com manter controle de longo prazo sobre o caminho de automação.” Ferramentas de segurança que procuram um payload não encontrarão nada. O que elas teriam de detectar é uma concessão de consentimento, uma entrada cron ou uma ferramenta que foi silenciosamente deixada aprovada.

A postura mínima que a Microsoft aceitará

A Microsoft não deixa o leitor com um "não". Fornece um patamar mínimo para as organizações que decidem avaliar o runtime de qualquer forma, e esse patamar é mais rigoroso do que uma sandbox. O ambiente deve ser "uma máquina virtual dedicada ou um dispositivo físico separado que não seja utilizado para o trabalho diário", e deve ser tratado como descartável. As credenciais devem ser criadas exclusivamente para o propósito do agente, sem privilégios, e renovadas partindo do princípio de que já foram comprometidas. Apenas dados não sensíveis devem estar acessíveis. As instruções guardadas e o estado do agente devem ser revistos regularmente para detetar regras persistentes inesperadas, fontes recentemente consideradas fidedignas ou comportamentos que mudam entre execuções. E uma reconstrução deve ser um controlo esperado e não uma emergência: reinstalar regularmente e reconstruir imediatamente perante comportamentos anómalos.

Um detalhe no post é mais útil do que sua extensão sugere. Fazer backup de .openclaw/workspace/ captura o estado de trabalho do agente sem incluir credenciais; fazer backup de todo o diretório .openclaw/ é mais simples de restaurar, mas também captura tokens e credenciais, e o post alerta que isso pode ser inadequado se houver suspeita de que as credenciais foram comprometidas. Uma equipe que faz backup do diretório inteiro e chama isso de recuperação de desastres arquivou justamente o que o atacante queria.

A orientação também é um mapa do produto.

A segunda metade da publicação mapeia cada controle recomendado para um produto Microsoft: Microsoft Entra ID para privilégio mínimo e acesso condicional em identidades de agente, Microsoft Defender for Cloud Apps App Governance para inventário OAuth e desvio de consentimento, Microsoft Defender for Endpoint para o host do agente, Microsoft Defender XDR para correlação, Microsoft Purview para prevenção de perda de dados no endpoint, Microsoft Defender for Cloud para saída de rede e Microsoft Sentinel onde for necessária retenção mais longa ou automação. Essa é uma prática comum em um blog de segurança de fornecedor e também vale dizer claramente: o documento que recomenda que um runtime de agente de terceiros seja contido é publicado por uma empresa que vende a contenção.

O conteúdo de hunting é a parte que sobrevive a esse enquadramento, porque é específico. A publicação fornece consultas KQL nas tabelas do Defender XDR — DeviceProcessEvents, CloudProcessEvents, DeviceFileEvents, DeviceNetworkEvents e OAuthAppInfo — que procuram linhas de comando de processos e nomes de arquivos contendo "openclaw", "moltbot" ou "clawdbot", por clawhub install invocações com slugs de habilidades raros, por mudanças frequentes em pastas de extensões em endpoints de desenvolvedores, por novos aplicativos OAuth com altos privilégios, por serviços de escuta abertos por processos de agente e por runtimes de agente que iniciam cmd.exe, powershell.exe, pwsh.exe, bash, sh, curl ou wget. Independentemente do que se pense do mapeamento do produto, essas consultas podem ser executadas por qualquer cliente do Defender XDR no dia da publicação, e não pressupõem conhecimento prévio de quais hosts estão executando o runtime.

O que está estabelecido, e o que não está

Estabelecido e corroborado: a Microsoft publicou a postagem em 19 de fevereiro de 2026, e as citações acima são dela. O Cybernews noticiou o alerta em 23 de fevereiro de 2026, e o TechRadar, em 24 de fevereiro de 2026, ambos reformulando as duas frases centrais e a orientação de isolamento em vez de testá-las. Buscas repetidas não revelaram cobertura no The Register, no BleepingComputer, na Wired ou no TechCrunch, portanto a onda de imprensa em torno desta postagem foi pequena e derivativa; nenhuma parte independente publicou um teste da alegação arquitetural da Microsoft, e a corroboração disponível confirma o que a Microsoft disse, não se está certa.

A transmissão também introduziu um erro que vale a pena assinalar, porque mostra a rapidez com que um alerta de fornecedor sobre uma ferramenta de terceiros se transforma num alerta de fornecedor sobre a sua própria ferramenta. O relatório da Cybernews começa por descrever o OpenClaw como "o assistente de IA da Microsoft"; não é. O OpenClaw é um runtime auto-hospedado que os investigadores do Defender da Microsoft examinaram, e o próprio artigo estabelece a distinção de forma estrutural, contrastando runtimes auto-hospedados — em que "você é responsável pelo raio de impacto" e o host, os plugins e o estado local ficam todos dentro do limite de confiança — com assistentes geridos e plataformas de agentes, em que o runtime e as atualizações são geridos centralmente e os controlos se centram nos âmbitos de identidade, na governação de conectores e nos limites de dados.

Não está estabelecido: que qualquer organização específica tenha sido comprometida da forma descrita na publicação. A Microsoft afirma que relatos públicos documentaram habilidades maliciosas em registos públicos, mas a publicação não apresenta nome de campanha, contagem, data nem vítima, pelo que este registo não representa qualquer dano real. A recomendação também não é vinculativa. Nenhum regulador a emitiu, nenhum organismo de normalização a adotou e nada no registo mostra que um cliente, auditor ou seguradora a trate como requisito. É a opinião de um fornecedor sobre como os seus próprios clientes devem tratar uma ferramenta que não controla — invulgarmente categórica e inexequível.

O que a publicação muda é a forma da pergunta que uma equipe de segurança precisa responder. Antes de 19 de fevereiro de 2026, a decisão de executar o OpenClaw em um laptop de trabalho podia ser tratada como uma questão de configuração e aprovação de piloto. Depois disso, o argumento precisa ser construído diante de um documento que afirma que o design do próprio runtime, e não suas configurações, é o que coloca a máquina em risco — e que não oferece nenhuma versão para atualizar, nenhum patch para aplicar e nenhuma correção no roteiro. Seu remédio é um padrão de implantação: isolar o runtime, restringir o que ele pode alcançar, monitorá-lo continuamente e estar preparado para reconstruir sem demora.