Dois esforços independentes de pesquisa de segurança, publicados esta semana, revelam que o **OpenClaw**, um agente de IA auto-hospedado amplamente adotado, pode ser coagido a executar código malicioso ou divulgar informações sensíveis através de entradas de aparência comum. A **Imperva** demonstrou como instruções ocultas embutidas em contatos compartilhados, vCards e pins de localização poderiam ser executadas pelo agente sem o conhecimento da vítima. Concomitantemente, a **Varonis** enganou com sucesso um agente de teste, pré-carregado com dados sintéticos de negócios, para encaminhar chaves AWS simuladas e uma exportação falsa de clientes através de um único e simples e-mail. Enquanto a falha descoberta pela **Imperva** foi corrigida na versão 2026.4.23 do **OpenClaw**, a vulnerabilidade de phishing da **Varonis** destaca um desafio arquitetônico mais profundo que não pode ser resolvido com um simples patch. Ambos os ataques sublinham uma fraqueza fundamental: a confiança inerente do agente nos dados recebidos, que, combinada com seus privilégios de acesso, cria um vetor de ataque potente. ## Comandos Ocultos em um Contato Compartilhado O pesquisador da **Imperva**, **Yohann Sillam**, investigou como o **OpenClaw** processa dados de mensagens para seu modelo de linguagem grande (LLM) subjacente. A questão central reside no manuseio interno do agente de objetos de mensagem. Quando o **OpenClaw** transmite contatos compartilhados, vCards ou locais para o LLM, ele achata esses objetos diretamente no texto do prompt. Crucialmente, ao contrário do conteúdo buscado na web, que é marcado como não confiável, os objetos de mensagem carecem dessa fronteira crítica. Apenas campos específicos são enviados ao modelo, uma fraqueza explorada pelo ataque. Por exemplo, um contato compartilhado envia apenas o campo de nome, serializado como `<contact: name, number>`. Os colchetes são permitidos em nomes, tornando impossível para o modelo distinguir entre um nome legítimo e uma instrução injetada. Além disso, o nome do contato é truncado na tela tanto no **WhatsApp** quanto no aplicativo receptor, ocultando efetivamente o payload malicioso da vítima. Essa técnica também se mostra eficaz através do campo de nome completo de uma vCard, nativamente suportado pelo **WhatsApp**, e através do rótulo de um pin de localização compartilhado. Nos testes da **Imperva** contra o **Google Gemini 3.1 Pro** (build de prévia), o texto oculto instruiu com sucesso o agente a baixar e executar um script de um servidor controlado pelo pesquisador. Embora as tentativas de embutir instruções em imagens simples tenham falhado (provavelmente devido aos modelos serem treinados contra ataques tão comuns), a rota de objeto de mensagem foi bem-sucedida devido à sua novidade.  A **Imperva** adverte que, com a memória do **OpenClaw** habilitada por padrão, um único conteúdo amplamente compartilhado contendo uma instrução oculta poderia comprometer silenciosamente agentes não isolados que o ingerissem. Após a divulgação da **Imperva**, o **OpenClaw** lançou uma correção na versão 2026.4.23, que agora roteia nomes de contato, campos de vCard e rótulos de localização através de um canal de metadados separado e não confiável. A **Imperva** observou padrões de achatamento semelhantes em outros assistentes de IA pessoais, indicando um problema mais amplo na indústria. ## Um E-mail Normal é Suficiente A **Varonis Threat Labs** abordou o **OpenClaw** de uma perspectiva de engenharia social. Liderada por **Itay Yashar**, sua equipe desenvolveu um agente chamado **Pinchy** na plataforma, conectando-o a uma caixa de entrada do **Gmail** repleta de dados de negócios sintéticos realistas e segredos simulados. Eles então submeteram **Pinchy** a quatro simulações de phishing usando **Google Gemini 3.1 Pro** e **OpenAI Codex GPT-5.4**. A **Varonis** distingue entre injeção de prompt, que oculta instruções dentro de dados, e o que eles chamam de 'phishing de agente': uma solicitação crível entregue através de um canal normal que é bem-sucedida porque o agente age sem verificação adequada do remetente. O agente falhou em ambos os testes de exfiltração. No primeiro cenário, uma mensagem que se dizia ser de um líder de equipe chamado Dan, enviada de um endereço **Gmail** externo, solicitou acesso de staging durante um incidente de produção simulado. **Pinchy** localizou as credenciais e encaminhou chaves de acesso AWS simuladas, strings de conexão de banco de dados e credenciais SSH em texto puro.  O segundo pretexto foi uma solicitação mais suave para a exportação semanal de clientes, supostamente para um deck de QBR. O agente então enviou um conjunto de dados sintético de 247 clientes corporativos, incluindo contatos e valores de contrato. Ambas as falhas ocorreram apesar de um perfil rigoroso configurado para verificar os remetentes primeiro; a urgência prevaleceu sobre a regra em uma instância e a rotina na outra. O agente se saiu melhor contra ameaças técnicas do que sociais. Ele interagiu com uma página de phishing de cartão-presente, mas reteve credenciais reais e, eventualmente, a sinalizou; o perfil rigoroso bloqueou a página completamente. Ao ser apresentado a uma tela de consentimento **OAuth** maliciosa disfarçada de aplicativo de folha de ponto, ele inspecionou o alvo de redirecionamento, considerou-o suspeito e parou antes de conceder acesso. Isso destaca a principal conclusão da **Varonis**: o agente é frequentemente mais adepto do que humanos em identificar URLs maliciosas e portais de login falsos, mas significativamente pior no julgamento social que leva um humano a pausar quando um colega faz uma solicitação incomum de credenciais. O impulso inerente do agente para ser prestativo emerge como uma superfície de ataque crítica.  A **Varonis** observou que o **OpenAI Codex GPT-5.4** exibiu mais cautela do que o **Gemini 3.1 Pro** em relação à entrada ou envio de dados para sites externos sem confirmação, embora ambos tenham sucumbido aos pretextos sociais. ## O Ponto Fraco Por Trás de Ambos os Ataques A **Varonis** mapeia ambos os vetores de ataque ao conceito de **Simon Willison** de 'trifeta letal': um agente capaz de ler dados privados, ingerir conteúdo não confiável e exfiltrar dados. O **OpenClaw** possui todas as três capacidades, explicando por que um contato envenenado e um e-mail aparentemente benigno podem levar ao mesmo comprometimento. Essa questão de limite de confiança se estende além dos problemas de prompt, manifestando-se na base de código do **OpenClaw**. Uma análise separada do **InfoSec Write-ups** converteu avisos anteriores do **OpenClaw** em regras de análise estática, descobrindo subsequentemente cinco falhas adicionais em suas extensões de canais **Slack**, **Discord**, **Matrix**, **Zalo** e **Microsoft Teams**. Todas as cinco vulnerabilidades compartilhavam uma raiz comum: o código de inicialização resolvia a lista de permissões de cada canal por nome de exibição mutável em vez de um ID estável. Isso permitiu que um atacante se renomeasse para corresponder a um usuário permitido, obtendo assim acesso não autorizado e controle sobre o agente. O **OpenClaw** desde então corrigiu esses problemas. O **OpenClaw** vem com acesso extenso a arquivos, shells e mais de vinte plataformas de mensagens, e tem sido objeto de avisos consistentes de injeção de prompt e exfiltração de dados desde seu lançamento no final do ano passado. A **autoridade holandesa de proteção de dados**, a **Autoriteit Persoonsgegevens**, tomou uma posição firme, aconselhando usuários e organizações contra a execução do **OpenClaw** em sistemas que contêm dados sensíveis, citando riscos significativos de violação de dados e tomada de conta. ## O Que Fazer a Respeito Organizações que executam o **OpenClaw** devem atualizar imediatamente para a versão 2026.4.23 ou posterior para aplicar a correção do objeto de mensagem. Além do patching, as defesas restantes são arquitetônicas, não meramente de redação de prompt. A **Varonis** descreve quatro controles críticos: 1. **Trate o arquivo de instruções do agente como uma política imposta e controlada por versão, não uma sugestão.** 2. **Implemente um portão para e-mails de saída:** proíba envios pela primeira vez para endereços desconhecidos sem aprovação explícita para evitar que um agente sequestrado retransmita tentativas de phishing de uma conta confiável. 3. **O acesso do conector deve rastrear o nível de confiança da entidade conectada.** 4. **Isole o agente (sandbox).**