O futuro da segurança de agentes de IA - Openclaw Security Audit

Durante anos, a maioria das conversas públicas sobre segurança de IA eram, na verdade, conversas sobre comportamento de modelos. As pessoas se preocupavam com alucinações, fugas da prisão, respostas inseguras e se um chatbot poderia produzir algo enganoso, tendencioso ou perigoso. Esse quadro não é mais suficiente. Quando um sistema de IA pode navegar, ler arquivos, chamar ferramentas, enviar mensagens, escrever código, acionar APIs e agir em várias etapas com supervisão mínima, a questão de segurança deixa de ser "O que o modelo pode dizer?" e passa a ser "O que o sistema pode fazer se o modelo for manipulado?" O crescimento do OpenClaw tornou essa transição impossível de ser ignorada. Em 13 de março de 2026, o repositório do OpenClaw tinha cerca de 309.000 estrelas no GitHub, e sua própria documentação descreve um tempo de execução que fica dentro de um limite de confiança de "assistente pessoal", em vez de um limite hostil e reforçado de vários locatários. (GitHub)

Essa distinção é mais importante do que o ciclo de propaganda. O OpenClaw não é interessante apenas por ser popular. Ele é importante porque reuniu várias preocupações anteriormente separadas em uma categoria de produto voltada para o consumidor: entrada não confiável, autoridade delegada, estado persistente, extensibilidade por meio de habilidades e alcance direto a arquivos, redes, navegadores e ferramentas do sistema operacional. A documentação da OpenClaw adverte explicitamente que não existe uma configuração "perfeitamente segura", recomenda começar com o menor acesso que ainda funcione e enfatiza que, se vários usuários não confiáveis puderem conversar com um agente habilitado para a ferramenta, eles estarão efetivamente compartilhando a mesma autoridade delegada. A Censys, por sua vez, relatou mais de 21.000 instâncias do OpenClaw expostas publicamente até 31 de janeiro de 2026. Esse é o momento em que a segurança do agente de IA deixou de ser um tópico de pesquisa de nicho e se tornou um problema operacional. (OpenClaw)

Os melhores textos públicos sobre esse tópico estão convergindo para a mesma ideia a partir de diferentes direções. A IBM define a segurança de agentes de IA como a proteção dos próprios agentes e dos sistemas com os quais eles interagem. A Palo Alto enquadra a segurança da IA agêntica em torno de raciocínio, memória, ferramentas, ações e interações. A CrowdStrike adverte que a injeção imediata em um tempo de execução agêntico se expande de um problema de conteúdo para um "raio de explosão agêntico", porque o invasor bem-sucedido pode herdar as ferramentas e os armazenamentos de dados acessíveis do agente. A orientação de segurança mais recente da OpenAI vai além e argumenta que a injeção de prompt moderna se assemelha cada vez mais à engenharia social, o que significa que a defesa certa não é apenas uma melhor filtragem de entrada, mas a restrição do impacto mesmo quando a manipulação é bem-sucedida. Esses pontos de vista não são idênticos, mas apontam para uma conclusão: o futuro da segurança do agente de IA será decidido pela arquitetura e pelos controles, e não apenas pelo texto do prompt. (IBM)

Por que o OpenClaw mudou a conversa

O OpenClaw mudou a conversa porque tornou tangível a autonomia da IA. O projeto foi explicitamente criado como um assistente pessoal de IA que pode ser executado em máquinas reais, conectar-se a superfícies de mensagens reais e usar ferramentas reais. Sua documentação de segurança não finge o contrário. Ela diz que o modelo suportado é um limite de operador confiável por gateway, não um barramento compartilhado hostil. Ela adverte que qualquer remetente permitido em um ambiente compartilhado pode induzir chamadas de ferramentas dentro da política, influenciar o estado compartilhado e potencialmente conduzir a exfiltração se o agente tiver acesso a credenciais ou arquivos confidenciais. Essa é uma documentação excepcionalmente franca e também é o motivo pelo qual os engenheiros de segurança reconheceram imediatamente o problema real: quando um agente tem permissões, o limite de confiança não é apenas o modelo. É todo o tempo de execução. (OpenClaw)

O sistema de habilidades do OpenClaw amplia essa realidade. A documentação do projeto diz que as habilidades são pastas compatíveis com o AgentSkills centradas em um SKILL.md com scripts opcionais e substituições locais ou de espaço de trabalho. Uma RFC separada do OpenClaw sobre segurança de habilidades argumenta que o modelo atual não tem modelo de permissão, assinatura de código, sandboxing, processo de revisão e verificações de integridade, ao mesmo tempo em que dá ao agente execução de shell, acesso total ao sistema de arquivos, acesso à rede e outras ferramentas. Como a RFC é uma proposta e não uma garantia de produto finalizado, ela não deve ser tratada como um posicionamento oficial do produto. Mas ainda assim é reveladora, pois captura o que os profissionais de segurança viram imediatamente: uma habilidade não é "conteúdo". É um caminho de execução. (GitHub)

O registro público de incidentes reforçou esse medo rapidamente. A própria consultoria de segurança do GitHub da OpenClaw para o CVE-2026-25253 descreve uma falha de filtragem de token que pode levar ao comprometimento total do gateway, acesso em nível de operador à API do gateway, alterações arbitrárias de configuração e execução de código no host do gateway, mesmo quando o gateway se vincula ao loopback, porque o navegador da vítima se torna a ponte. Isso, por si só, já seria suficiente para causar preocupação. Mas, ao mesmo tempo, os pesquisadores de exposição estavam contando dezenas de milhares de implantações acessíveis, e as equipes antimalware estavam documentando habilidades mal-intencionadas no ecossistema. Para os observadores casuais, o que parecia ser "um assistente de IA local legal" estava se tornando rapidamente uma superfície de ataque privilegiada para os defensores. (GitHub)

Há outro motivo pelo qual o OpenClaw é importante: os próprios mantenedores do projeto foram forçados a desenvolver a história da segurança em público, o que o torna um proxy útil para o mercado de agentes mais amplo. Em fevereiro de 2026, o OpenClaw anunciou uma parceria com o VirusTotal para que todas as habilidades publicadas no ClawHub fossem verificadas, transformadas em hash, analisadas com o Code Insight e aprovadas automaticamente, advertidas ou bloqueadas, dependendo do veredicto. Esse foi um passo significativo, mas o anúncio também incluiu a frase mais importante de toda a postagem: não é uma bala de prata. A OpenClaw disse explicitamente que a varredura do VirusTotal não detectará tudo, e que as cargas úteis de injeção de prompt em linguagem natural podem não aparecer em um banco de dados de ameaças. Essa admissão é a base sobre a qual gira o futuro da segurança de agentes. A varredura estática é necessária, mas não suficiente. A análise da cadeia de suprimentos ajuda, mas a validação do tempo de execução ainda é importante. (OpenClaw)

A segurança do agente de IA não é apenas segurança LLM com um novo rótulo

A tentação de tratar a segurança do agente como "segurança do LLM mais alguns complementos" é compreensível, mas leva a defesas superficiais. A segurança tradicional de aplicativos LLM já tem um vocabulário de risco maduro: injeção imediata, tratamento inseguro de saída, divulgação de informações confidenciais, agência excessiva, risco de plug-in e modelo de negação de serviço. O LLM Top 10 da OWASP continua sendo útil porque esses padrões ainda existem em sistemas agênticos. Mas os agentes acrescentam algo operacionalmente diferente: eles persistem, planejam, agem, coordenam com ferramentas, às vezes coordenam com outros agentes e podem produzir alterações duradouras no estado externo. É por isso que a OWASP criou um Top 10 separado para aplicativos agênticos para 2026 e por isso que o NIST abriu uma solicitação específica de informações sobre segurança de agentes de IA e, ao mesmo tempo, lançou uma Iniciativa de Padrões de Agentes de IA com foco em sistemas autônomos seguros e interoperáveis. (Fundação OWASP)

O enquadramento do NIST é especialmente importante porque esclarece o que é único aqui. Em seu anúncio de janeiro de 2026 sobre a proteção de sistemas de agentes de IA, o NIST disse que alguns riscos se sobrepõem à segurança de software comum, incluindo problemas de autenticação e gerenciamento de memória, mas a RFI se concentra especificamente em riscos distintos que surgem ao combinar saídas de modelos de IA com funcionalidade de software. Essa é uma descrição concisa do problema do agente moderno. O modelo não está mais apenas gerando texto. Ele está continuamente negociando entre instruções, contexto, memória, dados recuperados, descrições de ferramentas e fluxos de aprovação e, em seguida, transformando essa mistura em ação. A questão da segurança não é mais apenas se o modelo pode ser enganado. É se o sistema pode impedir que um modelo enganado cause danos significativos. (NIST)

A postagem de 11 de março de 2026 da OpenAI defende o mesmo ponto em uma linguagem mais concreta. Ele argumenta que os ataques de injeção de prompt mais fortes do mundo real agora se assemelham mais à engenharia social do que a simples cadeias de caracteres "ignore instruções anteriores". A conclusão da OpenAI é que o objetivo não pode ser a detecção perfeita de entradas maliciosas. Em vez disso, os sistemas devem ser projetados de forma que o lado negativo da manipulação seja limitado, mesmo que alguns ataques sejam bem-sucedidos. Esse é exatamente o modelo mental correto para os agentes, porque as implantações reais não vivem em ambientes de laboratório limpos. Elas ingerem e-mails, documentos, registros, conteúdo do navegador, mensagens de bate-papo, resultados de pesquisa, anexos e saídas de conectores. Quando você aceita que o conteúdo hostil será lido, a prioridade do projeto muda da classificação para a contenção. (OpenAI)

A pesquisa da Microsoft sobre injeção imediata indireta reforça essa lição empiricamente. O trabalho de benchmark do BIPIA afirma que o motivo subjacente do sucesso desses ataques é a incapacidade do modelo de distinguir de forma confiável as instruções do conteúdo externo, enquanto um documento posterior da Microsoft Research sobre "spotlighting" relatou a redução do sucesso do ataque de mais de 50% para menos de 2% em seus experimentos. Esses são avanços valiosos, mas não alteram a linha de base operacional. Uma boa defesa pode reduzir drasticamente as taxas de sucesso; ela não elimina a necessidade de limites de execução, controles de aprovação, limites de saída e capacidade de auditoria. Em outras palavras, a maior robustez do modelo é parte da resposta, mas a segurança do agente ainda será conquistada ou perdida no sistema em torno do modelo. (Microsoft)

Como é o modelo de ameaça real

Um modelo prático de ameaça para o OpenClaw e sistemas semelhantes começa com quatro limites e depois se expande. O primeiro é a confiança na entrada. Isso inclui prompts diretos, mas também documentos, sites, logs, anexos, e-mail, contexto recuperado e mensagens entre usuários em ambientes compartilhados. A documentação do OpenClaw deixa claro que a injeção de conteúdo pode passar por esses canais. A segunda é a autoridade da ferramenta. Quando o agente pode usar executarSe o usuário quiser navegar, ler arquivos, gravar arquivos ou enviar mensagens, o problema não é mais apenas a correção semântica. É o alcance da capacidade. O terceiro é o estado e a memória. A memória persistente, o contexto armazenado em cache, os rastros detalhados e o histórico da sessão criam superfícies para envenenamento, vazamento e contaminação entre contextos. A quarta é a exposição da implementação: endereços de ligação, proxies reversos, caminhos de autenticação, túneis, tokens de navegador e higiene da estação de trabalho. Esses não são detalhes de suporte. Eles são o ambiente no qual os erros do modelo se tornam incidentes. (OpenClaw)

Esse modelo de quatro limites ainda não é suficiente. A segurança do agente também exige que se pense na herança de identidade e na autoridade delegada. Se um agente age "para" um usuário, o que exatamente ele herda, por quanto tempo, sob quais condições, com qual caminho de revogação e quais evidências permanecem quando algo dá errado? O resumo da Palo Alto sobre segurança de IA agêntica chama a atenção para a herança de identidade e privilégio, riscos de estado persistente, uso de ferramentas e canais de interação como fontes únicas de falha. A estrutura de engenharia social da OpenAI acrescenta outro insight importante: um objetivo comprometido geralmente é mais perigoso do que um comando malicioso. Um invasor nem sempre precisa dizer ao agente para "roubar segredos". Pode ser suficiente fazer com que o agente acredite que roubar, exportar ou escalar é uma subetapa legítima na tarefa real do usuário. (Redes Palo Alto)

É por isso que o futuro da segurança dos agentes de IA será medido menos pela "segurança imediata" e mais pela capacidade dos sistemas de responder a algumas perguntas brutais de engenharia. O conteúdo não confiável pode se transformar em uma ação irreversível? Um usuário de baixa confiança pode orientar um tempo de execução de alta confiança? Os resultados das ferramentas ou os manifestos de habilidades podem alterar a política? O agente pode ler segredos de que não precisa? Ele pode exfiltrar dados por caminhos de rede arbitrários? Ele pode alegar sucesso quando o estado do sistema subjacente contradiz a alegação. O artigo recente Agentes do Caos torna esse último ponto especialmente vívido. Em um estudo de duas semanas com agentes que possuíam memória, e-mail, Discord, sistemas de arquivos e execução de shell, os pesquisadores documentaram conformidade não autorizada com não proprietários, divulgação de dados confidenciais, ações destrutivas do sistema, condições de negação de serviço, consumo descontrolado de recursos, falsificação de identidade, propagação de práticas inseguras entre agentes e casos em que o agente relatou a conclusão da tarefa, embora o estado do sistema não correspondesse. (arXiv)

A implicação é direta, mesmo que incômoda. O "futuro" no título deste artigo não se refere a um horizonte distante. O futuro já está aqui, e ele se parece menos com um discurso abstrato de alinhamento de IA e mais com a engenharia de segurança familiar: segmentação, escopo de identidade, análise da cadeia de suprimentos, aprovação de ações de alto risco, controle de saída, isolamento secreto, telemetria e testes adversários repetidos. Isso não é um rebaixamento de ambição. É como o campo se torna real. (NIST)

Os riscos que os usuários pessoais do OpenClaw realmente enfrentam

Para usuários individuais, o primeiro erro é acreditar que "local" significa "seguro". A orientação da Microsoft de fevereiro de 2026 sobre a execução segura do OpenClaw diz que o conselho mais seguro é não executá-lo com contas pessoais ou de trabalho primárias e não executá-lo em um dispositivo que contenha dados confidenciais. A Microsoft também diz para assumir que o tempo de execução pode ser influenciado por entradas não confiáveis, que seu estado pode ser modificado e que o sistema host pode ser exposto por meio do agente. Essa é uma orientação incomumente direta de um grande fornecedor e deve redefinir a linha de base de como os usuários pessoais pensam sobre agentes auto-hospedados. Uma máquina que contém sessões de navegador, estado de gerenciador de senhas, material SSH, credenciais de nuvem e identidades de mensagens não é um local conveniente para permitir que um tempo de execução experimental com capacidade de ação circule livremente. (Microsoft)

O segundo erro é pensar que o estímulo direto é o principal perigo. Não é. Os próprios documentos da OpenClaw, a folha de dicas de segurança do agente de IA da OWASP, a pesquisa da Microsoft e a mais recente orientação de segurança da OpenAI apontam para a mesma direção: a injeção indireta de prompt é o problema principal. Ela ocorre por meio do que o agente lê, não apenas pelo que o usuário digita. Uma página da Web mal-intencionada, um resumo envenenado, um e-mail com armadilhas ou um manifesto de habilidades que incorpore instruções operacionais podem se tornar políticas se o sistema não for projetado para separar o conteúdo da autoridade. Em um simples chatbot, isso pode produzir uma resposta ruim. Em um agente, pode acionar a execução de shell, automação de navegador, acesso a arquivos, envio de mensagens ou exposição de segredos. (OpenClaw)

O terceiro erro é subestimar a camada de habilidades. Os materiais públicos da OpenClaw agora reconhecem que as habilidades são executadas no contexto do agente com acesso a ferramentas e dados, e o mercado ClawHub teve que adicionar a nova varredura diária do VirusTotal precisamente porque a camada de habilidades se tornou um problema de cadeia de suprimentos. O próprio artigo do VirusTotal de fevereiro de 2026 dizia que o ecossistema de agentes pessoais de IA de crescimento mais rápido havia se tornado um novo canal de entrega de malware, com centenas de habilidades OpenClaw ativamente mal-intencionadas distribuindo droppers, backdoors, infostealers e ferramentas de acesso remoto disfarçadas de automação útil. Posteriormente, a Trend Micro documentou uma campanha na qual habilidades maliciosas do OpenClaw manipulavam fluxos de trabalho de agentes de IA para instalar uma nova variante do Atomic macOS Stealer, incluindo instruções ocultas em SKILL.md, fluxos de configuração enganosos e amplo roubo de chaveiros da Apple, dados do KeePass e documentos de usuários. (OpenClaw)

O quarto erro é tratar os espaços compartilhados como se o controle de acesso ainda funcionasse da maneira que os usuários imaginam. A documentação da OpenClaw diz que, se várias pessoas puderem enviar mensagens a um agente habilitado para a ferramenta, elas estarão efetivamente direcionando o mesmo conjunto de permissões. Isso significa que um bot compartilhado do Slack ou um agente de equipe não é magicamente particionado por quem digitou a mensagem, a menos que a arquitetura de implantação imponha um limite separado. Um espaço de trabalho compartilhado pode, portanto, se tornar um problema de autoridade delegada: um usuário cria o contexto, outro usuário injeta instruções e o tempo de execução age como se ambos tivessem o mesmo direito de conduzir as mesmas ferramentas e segredos. É exatamente por isso que a documentação recomenda dividir os limites de confiança com gateways e credenciais separados quando os usuários podem ser adversários uns dos outros. (OpenClaw)

O quinto erro é ignorar a deriva do estado e os objetivos descontrolados. A recente orientação de injeção de prompt da OpenAI argumenta que os ataques avançados funcionam cada vez mais redirecionando a missão do sistema sob cobertura social. Agentes do Caos acrescenta um aviso do mundo real: os agentes autônomos podem entrar em condições de negação de serviço, consumo descontrolado de recursos e falsas alegações de conclusão. É aqui que o caso supostamente engraçado de "provar a hipótese de Riemann para sempre" se torna relevante para a segurança. O padrão principal não é a matemática. É o sequestro de objetivos e a falta de condições de parada. Em um tempo de execução capaz, isso significa queima de token, loops de navegador, invocações repetidas de ferramentas, pesquisa ilimitada, spam de registro e, por fim, pressão do usuário para conceder mais acesso para que o agente possa "concluir a tarefa". (OpenAI)

Os CVEs que explicam o futuro melhor do que qualquer slogan

Um dos motivos pelos quais a segurança de agentes de IA ainda é mal compreendida é que as pessoas continuam esperando classes de exploração totalmente novas e puramente "nativas de IA". Na realidade, muitos dos incidentes mais importantes são falhas híbridas em que categorias de vulnerabilidade antigas encontram um novo modelo de execução. O CVE-2026-25253 é o exemplo mais claro do OpenClaw. A NVD o descreve como uma falha na qual a OpenClaw obteve um gatewayUrl de uma string de consulta e abriu automaticamente uma conexão WebSocket ao enviar um valor de token. O aviso do GitHub deixa o impacto operacional mais claro: a exfiltração de tokens pode levar ao comprometimento total do gateway, ao acesso à API em nível de operador, a alterações arbitrárias de configuração e à execução do código do host. O que torna isso um bug tão definidor da era dos agentes não é a novidade. É a forma como uma falha de confiança no estilo da Web se transforma em controle de um tempo de execução autônomo com autoridade delegada. (NVD)

O Langflow oferece outro caso instrutivo. A entrada do NVD para o CVE-2026-27966 diz que, antes da versão 1.8.0, o nó do CSV Agent codificava allow_dangerous_code=TrueO LangChain é um sistema de segurança que expõe o Python REPL do LangChain e permite comandos arbitrários do Python e do sistema operacional por meio de injeção de prompt, até a execução remota completa do código. Essa frase deve ser estudada cuidadosamente por qualquer pessoa que esteja criando ou comprando sistemas de agentes. Ela mostra como um recurso aparentemente "útil" pode converter uma manipulação em nível de linguagem em execução no lado do servidor quando recursos perigosos são pré-ativados por conveniência. Se o futuro da segurança de agentes tem uma única lição recorrente, é esta: atalhos de permissão que parecem produtivos no desenvolvimento muitas vezes se tornam catastróficos em condições adversas. (NVD)

O CVE-2026-21445 da Langflow aponta para a mesma realidade mais ampla de um ângulo diferente. De acordo com a NVD, vários pontos de extremidade críticos da API não tinham autenticação, permitindo o acesso não autenticado a dados de conversas, históricos de transações e operações destrutivas, incluindo a exclusão de mensagens antes da versão 1.7.0.dev45. Novamente, o problema não é "mágica de IA". É uma falha clássica de autorização em um sistema que agora fica próximo ao contexto do modelo, aos dados do usuário e ao controle do fluxo de trabalho. Quando os agentes se tornam superfícies de orquestração, os defeitos normais de segurança de aplicativos ganham nova importância porque a superfície comprometida agora medeia decisões e ações em vez de apenas o armazenamento de dados. (NVD)

O ecossistema do protocolo de contexto de modelo oferece um terceiro grupo importante de exemplos. Os avisos do NVD e do GitHub descrevem vários problemas em mcp-server-gitincluindo a criação irrestrita de repositórios em locais arbitrários do sistema de arquivos no CVE-2025-68143, a injeção de argumentos que leva à substituição arbitrária de arquivos no CVE-2025-68144 e a falta de validação de caminho que permite que as chamadas de ferramentas operem fora do repositório configurado no CVE-2025-68145. Nenhum desses problemas é exótico isoladamente. Bugs de validação de caminho e injeção de argumentos são temas de segurança que existem há décadas. O que muda em um contexto agêntico é a capacidade de composição. Uma vez que esses serviços estão dentro de cadeias de ferramentas que os agentes podem chamar automaticamente, falhas comuns se tornam pontes entre instruções não confiáveis e operações de arquivos privilegiadas. (NVD)

Mesmo quando uma vulnerabilidade causa "apenas" a negação de serviço, ela ainda é importante na infraestrutura do agente porque a disponibilidade e o custo fazem parte do modelo de ameaça. A entrada do NVD para o CVE-2025-0312 diz que os arquivos de modelo GGUF mal-intencionados carregados no Ollama poderiam acionar uma desreferência de ponteiro nulo e DoS remoto nas versões até 0.3.14. Esse não é o bug mais dramático da era da IA, mas é importante porque os servidores de modelos locais são frequentemente adotados como base para pilhas de agentes pessoais ou auto-hospedados. Se o tempo de execução puder sofrer uma falha ou ser desestabilizado por ativos malformados, o usuário não estará apenas enfrentando riscos de dados e execução, mas também fragilidade operacional na camada de base. (NVD)

A tabela abaixo resume por que essas questões devem ser incluídas em qualquer discussão séria sobre o futuro da segurança dos agentes de IA.

As descrições e implicações nesta tabela foram extraídas do NVD e do banco de dados consultivo do GitHub. (NVD)

O próximo modelo de segurança, da segurança imediata aos limites de execução

Se a ascensão do OpenClaw ensina alguma coisa, é que a próxima geração de arquitetura de segurança não pode ser construída com base na tentativa de classificar perfeitamente o texto malicioso. Essa abordagem sempre continuará sendo importante, e as defesas em nível de modelo continuarão sendo aprimoradas. Mas o plano de controle fundamental para os agentes deve ter limites de execução. Portanto, o futuro da segurança de agentes de IA não se trata tanto de "tornar o modelo mais inteligente em relação a ataques", mas sim de "tornar o sistema mais difícil de ser abusado, mesmo quando o modelo é enganado". Isso é, em parte, uma inferência, mas é fortemente apoiada pela visão de restrição de impacto da OpenAI sobre a injeção imediata, pelas categorias de ameaças agênticas da OWASP, pelo foco do NIST na fusão da saída do modelo e da funcionalidade do software e pelos avisos da própria OpenClaw de que não existe uma configuração perfeitamente segura. (OpenAI)

Na prática, isso significa que o perímetro de segurança precisa se mover para dentro e se multiplicar. O primeiro limite é a identidade. Os agentes não devem herdar privilégios amplos de uma conta de usuário por padrão. Eles devem receber concessões de capacidade restritas, com escopo de tarefa e revogáveis. O segundo limite é o escopo da ferramenta. Um agente de compactação não deve ter execução de shell só porque a plataforma o suporta. O terceiro limite é o isolamento do tempo de execução. Um agente que navega na Web ou instala habilidades não deve ser executado no mesmo host e usuário do sistema operacional que contém as chaves primárias de nuvem do operador, o cofre do gerenciador de senhas e os perfis do navegador. A recomendação da Microsoft de não executar o OpenClaw com contas pessoais ou de trabalho primárias é uma versão direta desse princípio. (Microsoft)

O quarto limite é a saída. Um agente que pode ler o contexto local sensível, mas também pode se conectar a destinos de saída arbitrários, está a um prompt de se tornar um mecanismo de exfiltração. O quinto limite é a memória e a persistência. Qualquer coisa armazenada a longo prazo torna-se um alvo de envenenamento e de vazamento. O sexto limite é a aquisição de habilidades. A varredura de mercado ajuda, mas não é um modelo de permissão, e o próprio anúncio do VirusTotal da OpenClaw diz isso. O sétimo limite é o design de aprovação. Ações de alto impacto, como exclusão de arquivos, exportação de credenciais, envio de mensagens para novos destinos, pagamentos, gravações em repositórios ou alterações na infraestrutura, devem exigir aprovação explícita com justificativa visível. O oitavo limite é a observabilidade. Se os defensores não puderem reconstruir qual entrada foi lida, qual ferramenta foi chamada, quais arquivos foram tocados, quais destinos de rede foram contatados e qual estado persistiu depois disso, então o sistema não é seguro o suficiente para operar com responsabilidade. (OpenClaw)

É também nesse ponto que as estruturas mais antigas voltam a ser úteis em vez de obsoletas. O MITRE ATLAS existe para mapear ameaças adversárias aos sistemas de IA, e o próprio modelo público de ameaças do OpenClaw o utiliza explicitamente. A orientação agêntica da OWASP oferece aos defensores uma taxonomia prática. O AI RMF e o Generative AI Profile do NIST fornecem uma linguagem de governança para gerenciar a confiabilidade, a segurança e o risco do ciclo de vida. O futuro da segurança do agente de IA não será um único recurso de produto vencedor. Será uma pilha de controles interoperáveis, políticas mensuráveis e testes repetíveis que tomam emprestado da prática de segurança estabelecida e se adaptam à tomada de decisão mediada por modelos. (GitHub)

Como é a boa engenharia atualmente

A postura de engenharia que faz mais sentido atualmente é agressivamente modesta. O próprio OpenClaw diz para começar com o menor acesso que ainda funcione, e esse conselho deve ser tratado como o princípio operacional de toda a categoria. Para uma implementação séria, isso significa um limite de confiança por gateway, um usuário ou host de sistema operacional dedicado por limite sensível, perfis de navegador separados, contas de aplicativos separadas e nenhuma reutilização da identidade pessoal ou corporativa principal de uma pessoa dentro do tempo de execução do agente. Mesmo as equipes que desejam "um agente compartilhado da empresa" devem mantê-lo em uma máquina ou VM dedicada e evitar assiná-lo em contas pessoais ou privilegiadas. Essas recomendações estão diretamente alinhadas com a orientação oficial da OpenClaw e com as recomendações de segurança publicadas independentemente pela Microsoft. (OpenClaw)

O segundo princípio de engenharia é presumir que todo canal de conteúdo é hostil. Isso não é paranoia; é a postura mínima implícita na pesquisa atual e no histórico de incidentes. O agente deve tratar o conteúdo da Web, os documentos, os e-mails, os rastreadores de problemas, os registros, as mensagens de bate-papo, os anexos e os manifestos de habilidades como dados não confiáveis. Parte desse conteúdo ainda pode ser útil. A questão é que a leitura do conteúdo não deve implicar em sua obediência. Isso significa separar a recuperação da execução, associar a procedência ao conteúdo, preservar o contexto sobre quem solicitou o quê e recusar-se a permitir que o conteúdo arbitrário crie ou amplie as permissões por conta própria. O trabalho do BIPIA da Microsoft e a estrutura de engenharia social da OpenAI apoiam essa mudança de correspondência de strings para controle de impacto com reconhecimento de contexto. (Microsoft)

O terceiro princípio é que a capacidade deve ser explícita e visível. Se um agente puder excluir arquivos, gravar em repositórios, enviar mensagens de saída, criar tíquetes ou tocar em sistemas de produção, essa capacidade deverá estar visível para o operador antes da primeira execução e poderá ser revisada posteriormente nos registros. A capacidade não deve ser introduzida por meio de descrições vagas de habilidades ou padrões de conveniência. Esse é um dos motivos pelos quais os debates atuais sobre manifestos de permissão, assinatura de código e sandboxing no ecossistema OpenClaw são tão importantes. Eles não são detalhes administrativos. Eles são o início de um modelo de segurança real para as habilidades do agente. (GitHub)

O quarto princípio é que os agentes precisam de verificação de estado, não apenas de rastros de raciocínio. Agentes do Caos destaca que os agentes podem alegar sucesso quando o estado do sistema subjacente não está de acordo. Isso significa que os defensores e criadores não devem tratar uma resposta polida do agente como evidência. A verificação deve ser feita em relação ao próprio sistema de destino: existência de arquivos, alterações de soma de verificação, estado da resposta da API, diferença de repositório, entrega de mensagens, status da política ou configuração de recursos da nuvem. Na prática, isso aproxima a segurança do agente da engenharia de testes. Um sistema seguro é aquele que pode provar o que de fato mudou, não aquele que pode explicar de forma elegante por que acha que mudou alguma coisa. (arXiv)

A tabela abaixo fornece um mapa prático do modo de falha recorrente até o controle que realmente altera o risco.

Essa matriz de controle é uma síntese de engenharia criada a partir da orientação atual do fornecedor, de relatórios públicos de incidentes e do trabalho com padrões. (OpenClaw)

Um padrão defensivo de aquisição de habilidades que realmente ajuda

Uma das práticas de curto prazo mais úteis para sistemas semelhantes ao OpenClaw é a triagem de entrada de habilidades. Isso não deve ser tratado como um detector de malware perfeito. O próprio OpenClaw afirma que a varredura de mercado é apenas uma camada e não detecta tudo. Mas um simples controle de entrada pode eliminar uma quantidade surpreendente de riscos óbvios antes que uma habilidade chegue a tocar em um tempo de execução privilegiado. (OpenClaw)

Aqui está um pequeno exemplo defensivo que faz a varredura SKILL.md arquivos e scripts próximos em busca de padrões suspeitos, como comportamento de busca e execução, cargas úteis codificadas, instruções de configuração com muito shell e referências diretas a segredos. Esse código não foi retirado de um documento de fornecedor; é um exemplo seguro escrito para triagem operacional.

#!/usr/bin/env python3
from pathlib import Path
import re
import sys

RISK_PATTERNS = {
    "download_and_execute": re.compile(r"(curl|wget|Invoke-WebRequest).*(\\|||bash|sh|python|powershell)", re.I),
    "encoded_payload": re.compile(r"(base64|FromBase64String|certutil\\s+-decode)", re.I),
    "shell_exec": re.compile(r"\\b(bash|sh|zsh|powershell|cmd\\.exe)\\b", re.I),
    "secret_targets": re.compile(r"(\\.aws/credentials|id_rsa|\\.env|keychain|browser profile|wallet)", re.I),
    "chmod_plus_exec": re.compile(r "chmod\\s+\\+x", re.I),
}

def scan_file(path: Path):
    text = path.read_text(errors="ignore")
    hits = []
    para nome, padrão em RISK_PATTERNS.items():
        if pattern.search(text):
            hits.append(name)
    return hits

def main(root: str):
    root_path = Path(root).expanduser()
    files = [p for p in root_path.rglob("*") if p.is_file() and p.suffix.lower() in {".md", ".sh", ".py", ".js", ".mjs", ".ps1"}]
    found = 0
    para f em files:
        hits = scan_file(f)
        if hits:
            found += 1
            print(f"[RISCO] {f}")
            print(f" patterns: {', '.join(sorted(hits))}")
    se não for encontrado:
        print("Não foram encontrados padrões óbvios de alto risco. Ainda é necessária uma revisão manual.")

se __name__ == "__main__":
    target = sys.argv[1] if len(sys.argv) > 1 else "~/.openclaw/skills"
    main(target)

O objetivo de um script como esse não é "provar" que uma habilidade é segura. O objetivo é detectar o comportamento do instalador, a linguagem de direcionamento de credenciais ou as instruções de download e execução com rapidez suficiente para que a análise humana seja reservada para os casos ambíguos. Essa é a mentalidade certa para o futuro da segurança de habilidades: primeiro a triagem, depois uma análise mais profunda e, em seguida, a observação do tempo de execução em sandbox, quando necessário. Ela também é consistente com o que o próprio anúncio do VirusTotal da OpenClaw diz sobre defesa em profundidade e com a realidade do ecossistema documentada pelo VirusTotal e pela Trend Micro. (OpenClaw)

Uma verificação mínima de exposição em tempo de execução

O outro controle de curto prazo que se paga é uma verificação rápida da exposição. Muitas equipes começam a fazer testes de injeção imediata primeiro. Isso não é bem assim. Antes de testar ataques inteligentes, verifique os aspectos básicos e enfadonhos: o que está vinculado, o que é acessível e quais opções de configuração expandiram discretamente a superfície de ataque. Os documentos oficiais e os avisos públicos do OpenClaw deixam claro por que isso é importante. (OpenClaw)

Esse exemplo de shell é deliberadamente simples e defensivo.

#!/usr/bin/env bash
set -euo pipefail

echo "=== Escutando soquetes relacionados ao OpenClaw ==="
ss -ltnp | grep -E '(:18789|openclaw|moltbot|clawdbot)' || true

echo
echo "=== Configuração rápida de grep para sinalizadores de exposição de risco ==="
grep -RInE '0\\.0\\.0\\.0|dangerouslyDisableDeviceAuth|trustedProxies' ~/.openclaw 2>/dev/null || true

echo
echo "=== Verificação do endpoint de controle local ==="
curl -sSI  | head -n 10 || true

echo
echo "=== Lembrete ==="
echo "Se for necessário acesso remoto, prefira um túnel VPN ou SSH em vez de expor a porta de controle bruta."

Isso não é glamouroso, mas é o tipo de disciplina operacional que impede que uma história local-primeira se transforme silenciosamente em um tempo de execução exposto à Internet. O futuro da segurança do agente de IA será construído com base em mais disso, e não menos: evidências rápidas, área de superfície pequena, padrões rígidos e validação de rotina em vez de suposições desejadas. (OpenClaw)

Como o futuro realmente se parece

O futuro da segurança dos agentes de IA se parecerá mais com a Confiança Zero do que com a habilidade imediata. A estrutura Agentic Trust da Cloud Security Alliance torna isso explícito ao traduzir as ideias do Zero Trust em cinco questões práticas de governança para agentes de IA, e a AI Agent Standards Initiative do NIST está se esforçando para criar um mundo em que os sistemas de agentes seguros e interoperáveis se tornem parte da conversa sobre infraestrutura convencional, e não uma reflexão tardia. Essa trajetória faz sentido. Os agentes não são simplesmente "softwares mais inteligentes". Eles são softwares que podem raciocinar sobre entradas ambíguas, selecionar ações e persistir ao longo do tempo. Portanto, a segurança precisa passar das suposições de perímetro para a verificação contínua. (Aliança de segurança na nuvem)

Em termos concretos, isso significa que as organizações mais maduras deixarão de perguntar se um agente é "seguro" em termos abstratos. Elas perguntarão se um agente específico, com um modelo específico, um conjunto de habilidades específico, um escopo de identidade específico, um ambiente de host específico, uma política de memória específica e um fluxo de trabalho de aprovação específico podem ser induzidos a classes específicas de falha. Em seguida, eles testarão essas classes repetidamente. Eles medirão a capacidade de exploração, o raio de explosão, a persistência, a detectabilidade e a integridade do estado. Eles usarão a política de controle de versão. Manterão as identidades dos agentes restritas e auditáveis. Isolarão as ferramentas de alto risco. Tratarão as habilidades e os conectores como entradas da cadeia de suprimentos. E esperarão uma validação adversária contínua em vez de uma garantia única. Esse não é um destino teórico. É o ponto final natural de tudo o que o registro público já mostra. (Projeto de segurança de IA da OWASP Gen)

As organizações que avançarem nessa área não serão necessariamente aquelas com os modelos de fronteira mais sofisticados. Elas serão aquelas que internalizarem primeiro uma regra mais simples: autonomia sem limites não é inovação. É uma fila de acidentes. O OpenClaw tornou isso visível porque chegou em escala de consumidor, com código público, incidentes reais, CVEs reais e evidências reais de habilidades maliciosas e tempos de execução expostos. É por isso que o projeto é importante muito além de sua própria base de usuários. Ele forçou o setor a confrontar o que acontece quando um modelo não é meramente generativo, mas operacional. (GitHub)

Portanto, a conclusão honesta não é pessimista, mas específica. O futuro da segurança dos agentes de IA não é eliminar cada injeção imediata, cada risco de habilidade ou cada modo de falha emergente. Esse padrão é irrealista. O objetivo real é garantir que, quando houver manipulação, as consequências sejam limitadas; quando houver comprometimento, ele seja observável; quando o agente alegar sucesso, ele possa ser verificado; quando surgirem novas habilidades, elas sejam examinadas; e quando o tempo de execução for alterado, suas defesas sejam testadas novamente. É assim que o campo amadurece. Ele para de perseguir a fantasia da confiança perfeita e começa a fazer engenharia para falhas controladas. (OpenAI)

Tomada final

A popularidade do OpenClaw não criou problemas de segurança de agentes de IA. Ela os expôs de uma forma que os usuários comuns, os engenheiros de segurança e os criadores de produtos não podiam mais abstrair. Quando um sistema pode ler, decidir e agir, todas as questões clássicas de segurança voltam com mais força: quem está autorizado, o que é acessível, o que persiste, o que é registrado, o que é reversível e o que acontece quando o tempo de execução é manipulado. Relatórios públicos de incidentes, CVEs atuais, orientações de fornecedores, atividades de padrões e pesquisas acadêmicas estão contando a mesma história. O próximo capítulo da segurança de IA será escrito na fronteira entre a linguagem e a execução. (Blog do VirusTotal)

E é por isso que o futuro da segurança de agentes de IA não é um concurso de modelos. É um concurso de controle. Os vencedores não serão as equipes que simplesmente tornarem os agentes mais capazes. Serão as equipes que tornarem os agentes mais difíceis de serem sequestrados, mais difíceis de serem permitidos em excesso, mais difíceis de serem envenenados de forma persistente, mais difíceis de serem exfiltrados e mais fáceis de serem verificados. É para onde o mercado está indo, para onde os padrões estão indo e para onde a engenharia de segurança precisa ir em seguida. (NIST)

Leitura adicional e links internos

• NIST, Iniciativa de padrões de agentes de IA. (NIST)
• NIST, Request for Information Regarding Security Considerations for Artificial Intelligence Agents (Solicitação de informações sobre considerações de segurança para agentes de inteligência artificial). (Registro Federal)
• NIST, Estrutura de Gerenciamento de Risco de IA e Perfil de IA Generativa. (NIST)
• OWASP, Top 10 de Aplicativos Agênticos para 2026. (Projeto de segurança de IA da OWASP Gen)
• OWASP, folha de dicas de segurança do agente de IA. (Série OWASP Cheat Sheet)
• MITRE ATLAS. (MITRE ATLAS)
• Documentação de segurança do OpenClaw. (OpenClaw)
• Modelo de ameaça OpenClaw e documentação de habilidades. (GitHub)
• OpenClaw faz parceria com o VirusTotal para segurança de habilidades. (OpenClaw)
• Censys, OpenClaw na natureza. (Censys)
• Aviso do OpenClaw GitHub para o CVE-2026-25253. (GitHub)
• VirusTotal, Da automação à infecção. (Blog do VirusTotal)
• Trend Micro, habilidades maliciosas do OpenClaw usadas para distribuir o Atomic macOS Stealer. (www.trendmicro.com)
• OpenAI, Projetando agentes de IA para resistir à injeção imediata. (OpenAI)
• Segurança OpenClaw: The Definitive Guide to Risks, Red-Teaming, and Survival (O Guia Definitivo para Riscos, Equipe Vermelha e Sobrevivência). (Penligente)
• Teste de segurança de IA do OpenClaw - Como reduzir a equipe de um agente com privilégios elevados antes que ele reduza sua equipe. (Penligente)
• OpenClaw Security Risks and How to Fix Them, A Practical Hardening and Validation Playbook (Riscos de segurança do OpenClaw e como corrigi-los). (Penligente)
• Protegendo aplicativos de agente na era do MCP. (Penligente)
• Agents of Chaos, o documento que transformou o hype dos agentes em um problema de segurança. (Penligente)