Como já comentamos em uma postagem anterior, o desenvolvimento de produtos de software modernos é praticamente impossível sem o uso de componentes de código aberto. Mas, nos últimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o código de uma empresa mais rapidamente do que são corrigidas; segundo, os dados são incompletos e pouco confiáveis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, não basta simplesmente verificar os números de versão e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger políticas de download de software, proteções para assistentes de IA e todo o pipeline de criação de software.

Um conjunto confiável de componentes de código aberto

A principal característica de uma solução é impedir o uso de código vulnerável e malicioso. As seguintes medidas devem ser implementadas:

• Ter um repositório interno de artefatos. A fonte única de componentes para desenvolvimento interno precisa ser um repositório unificado no qual os componentes são admitidos somente após uma série de verificações.
• Fazer uma triagem rigorosa dos componentes. Isso inclui verificações de versões conhecidas do componente, versões vulneráveis e maliciosas conhecidas, data de publicação, histórico de atividades e reputação do pacote e de seus autores. É obrigatório verificar todo o conteúdo do pacote, incluindo instruções de compilação, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingestão, use verificadores de código aberto especializados ou uma solução de segurança abrangente de carga de trabalho na nuvem.
• Fixar versões de dependências. Os processos de compilação, as ferramentas de IA e os desenvolvedores não devem usar modelos (como “o mais recente”) ao especificar versões. As compilações do projeto precisam ser baseadas em versões verificadas. Ao mesmo tempo, as dependências com versões fixas devem ser atualizadas com frequência para as versões verificadas mais recentes que mantêm a compatibilidade e não contêm vulnerabilidades conhecidas. Isso reduz significativamente o risco de ataques à cadeia de suprimentos por meio do comprometimento de um pacote conhecido.

Aperfeiçoamento dos dados de vulnerabilidades

Para identificar vulnerabilidades com mais eficácia e priorizá-las de forma adequada, uma organização precisa estabelecer vários processos de TI e segurança:

• Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organização, isso é necessário para enriquecer as informações combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de inteligência de vulnerabilidades comercial no qual os dados já estão agregados e enriquecidos. Em ambos os casos, também vale a pena monitorar os feeds de inteligência de ameaças para rastrear tendências de exploração reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades específicas. A Kaspersky fornece um feed de dados especializado especificamente focado em componentes de código aberto.
• Análise detalhada da composição do software. As ferramentas especializadas de análise de composição de software (SCA) permitem o mapeamento correto da cadeia de dependências no código-fonte aberto para realizar o inventário completo das bibliotecas que estão sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes íntegros também são úteis para enriquecer o registro de artefatos.
• Identificação do abandonware. Mesmo que um componente não apresente vulnerabilidades formais e o encerramento do suporte ainda não tenha sido declarado oficialmente, o processo de verificação deve sinalizar os componentes que não receberam atualizações há mais de um ano. Isso garante uma análise separada e uma possível substituição, assim como ocorre com os componentes em EOL (fim da vida útil).

Proteção do código e dos agentes de IA

As atividades dos sistemas de IA usados na codificação devem ser agrupadas em um conjunto abrangente de medidas de segurança: desde a filtragem de dados de entrada até o treinamento do usuário:

• Restrições de recomendações de dependências. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confiável. Se eles não contiverem as ferramentas corretas, o modelo deve acionar uma solicitação para incluir a dependência no registro em vez de extrair algo do PyPI que apenas corresponda à descrição.
• Filtragem das saídas do modelo. Apesar dessas restrições, tudo o que for gerado pelo modelo também deve ser verificado para garantir que o código de IA não contenha dependências desatualizadas, sem suporte, vulneráveis ou inventadas. Essa verificação deve ser integrada diretamente no processo de aceitação do código ou no estágio de preparação da compilação. Ela não substitui o processo de análise estática tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI/CD.
• Treinamento do desenvolvedor. As equipes de TI e de segurança devem estar extremamente familiarizadas com as características dos sistemas de IA, seus princípios operacionais e erros comuns. Para conseguir isso, os funcionários devem completar um curso de treinamento especializado, adaptados às suas funções específicas.

Remoção sistemática de componentes em EOL

Se os sistemas de uma empresa utilizarem componentes de código aberto desatualizados, deve-se adotar uma abordagem sistemática e consistente para lidar com as vulnerabilidades. Existem três métodos principais para fazer isso:

• Migração. Este é o método mais complexo e caro para uma organização, pois envolve a substituição total de um componente, seguida pela adaptação, reescrita ou substituição dos aplicativos construídos sobre ele. Decidir sobre uma migração é muito mais difícil quando se exige uma revisão geral de todo o código interno. Isso costuma afetar os componentes principais: é impossível migrar facilmente do Node.js 14 ou do Python 2.
• Suporte de longo prazo (LTS). Existe um mercado de serviços de suporte dedicado para projetos legados de larga escala. Às vezes, isso envolve uma bifurcação do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades específicas em versões mais antigas e sem suporte. A transição para o LTS geralmente exige custos de suporte contínuos, mas, em muitos casos, isso ainda pode ser mais econômico do que uma migração completa.
• Controles compensatórios. Com base nos resultados de análises detalhadas, é possível criar um conjunto de medidas de segurança abrangentes para mitigar o risco de exploração das vulnerabilidades de um produto legado. Tanto a eficácia quanto a viabilidade econômica dessa abordagem dependem da função do software na organização.

Os departamentos de segurança, TI e negócios devem trabalhar juntos para escolher um desses três métodos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.

Gerenciamento de vulnerabilidades de código aberto baseado em risco

Todos os métodos listados acima reduzem o volume de softwares e componentes vulneráveis que entram na organização, o que simplifica a detecção e a correção de falhas. Apesar disso, é impossível eliminar todos os defeitos: o número de aplicativos e componentes está crescendo muito rápido.

Portanto, é essencial priorizar as vulnerabilidades com base nos riscos reais que elas representam. O modelo de avaliação de risco deve ser expandido para considerar as características do código aberto, além de responder às seguintes perguntas:

• A ramificação do código vulnerável é realmente executada no ambiente da organização? Deve-se realizar uma análise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de código defeituosos nunca são realmente executados na implementação específica da organização, fazendo com que seja impossível explorar a vulnerabilidade. Certas soluções de SCA podem realizar esta análise. Esse mesmo processo permite avaliar um cenário alternativo: o que acontece se os procedimentos ou componentes vulneráveis forem removidos completamente do projeto? Às vezes, esse método de remediação é surpreendentemente indolor.
• O defeito está sendo explorado em ataques reais? Há um PoC disponível? As respostas a essas perguntas fazem parte de estruturas de priorização padrão, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de inteligência.
• A atividade de criminosos cibernéticos foi relatada nesse registro de dependência ou em componentes relacionados e semelhantes? Estes são fatores adicionais para a priorização.

A consideração desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.

A transparência nunca sai de moda

O padrão de segurança para softwares de código aberto só vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentarão pressões regulatórias que exigem segurança cibernética documentada e verificável nos seus sistemas. De acordo com as estimativas dos especialistas da Sonatype, 90% das empresas em todo o mundo já se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transparência “o pilar fundamental da segurança da cadeia de suprimento de software”.

Ao controlar o uso de componentes e aplicativos de código aberto, enriquecer a inteligência contra ameaças e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organizações podem introduzir as inovações que tanto desejam, ao mesmo tempo em que atingem o padrão elevado definido por reguladores e clientes.

Até bem pouco tempo, somente as empresas especializadas em software e as gigantes em tecnologia precisavam se preocupar com as vulnerabilidades de código aberto e os ataques direcionados contra a cadeia de suprimentos. Porém, os tempos mudaram. Hoje, até mesmo as pequenas empresas estão mantendo suas próprias lojas de desenvolvimento, e isso torna o problema significativo para todo mundo. De maneira ininterrupta, as equipes internas de TI das empresas estão ocupadas escrevendo código, configurando integrações e automatizando fluxos de trabalho, mesmo que o negócio principal não tenha absolutamente nada a ver com software. É o que a eficiência empresarial moderna exige. No entanto, como consequência disso, surge uma nova geração de vulnerabilidades de software, o tipo muito mais complicado de corrigir do que apenas instalar a atualização mais recente do Windows.

O desenvolvimento de software moderno é inseparável dos componentes de código aberto. Porém, os riscos associados proliferaram nos últimos anos, além de terem aumentado em variedade e sofisticação. Estamos testemunhado a injeção de código malicioso em repositórios populares, dados de vulnerabilidade fragmentados e com falhas, o uso sistemático de componentes desatualizados e vulneráveis e as cadeias de dependência cada vez mais complexas.

A escassez de dados de vulnerabilidade para código aberto

Mesmo que sua organização tenha um processo de gerenciamento de vulnerabilidades sólido para software comercial de terceiros, é possível constatar que o código aberto requer uma revisão completa desse processo. Os bancos de dados públicos mais usados geralmente são incompletos, imprecisos ou simplesmente lentos para obter atualizações quando se trata de código aberto. Isso transforma a priorização de vulnerabilidades em um jogo de adivinhação. Por mais automação que possa existir, ela será inútil se os dados de referência estiverem cheios de falhas.

De acordo com os dados da Sonatype, cerca de 65% das vulnerabilidades de código aberto atribuídas a um CVE ID não possuem uma pontuação de vulnerabilidade (CVSS) no NVD, a base de conhecimento de vulnerabilidades mais usada. Dessas vulnerabilidades não pontuadas, quase 46% seriam classificadas como alta, se analisadas adequadamente.

Mesmo quando uma pontuação CVSS está disponível, fontes diferentes estão de acordo apenas no que se refere à gravidade em cerca de 55% das vezes. Um banco de dados pode sinalizar uma vulnerabilidade como crítica, enquanto outro recebe uma pontuação média para ela. Metadados mais detalhados, como as versões de pacotes afetadas, também costumam estar repletos de erros e inconsistências. Seus verificadores de vulnerabilidades que comparam versões de software acabam gerando falsos positivos ou fornecendo falsamente um atestado de integridade.

O déficit nos dados de vulnerabilidade está crescendo e o processo de geração de relatórios está ficando mais lento. Nos últimos cinco anos, o número total de CVEs dobrou, mas o número de CVEs sem uma pontuação de gravidade explodiu por um fator de 37. De acordo com a Tenable, até 2025, o código de exploração de prova de conceito (PoC) esteve normalmente disponível dentro de uma semana após a descoberta de uma vulnerabilidade, mas obter a mesma vulnerabilidade listada no NVD levou em média 15 dias. Os processos de aprimoramento, como atribuir uma pontuação CVSS, são ainda mais lentos, a Sonatype no mesmo estudo estima que o tempo médio para atribuir uma pontuação CVSS é de 41 dias, com alguns defeitos permanecendo sem classificação por até um ano.

O problema do código aberto legado

Bibliotecas, aplicativos e serviços que não são mais mantidos, que foram abandonados ou que atingiram seu fim de vida útil (EOL), podem ser encontrados em 5 a 15% dos projetos corporativos, de acordo com a HeroDevs. Em cinco registros populares de código aberto, há pelo menos 81 mil pacotes que contêm vulnerabilidades conhecidas, mas pertencem a versões desatualizadas e sem suporte. Esses pacotes nunca verão os patches oficiais. Essa “bagagem legada” é responsável por cerca de 10% dos pacotes no Maven Central e no PyPI, e impressionantes 25% no npm.

Usar esse tipo de código aberto quebra o ciclo de vida padrão do gerenciamento de patches: não é possível atualizar, automática ou manualmente, uma dependência que não é mais compatível. Além disso, quando as versões EOL são omitidas dos boletins de vulnerabilidades oficiais, os verificadores de segurança podem categorizá-las como “não afetadas” por um defeito e ignorá-las.

Um excelente exemplo disso é o Log4Shell, a vulnerabilidade crítica (CVSS 10) na popular biblioteca Log4j descoberta em 2021. A versão vulnerável foi responsável por 40 milhões dos 300 milhões de downloads do Log4j em 2025. É importante ressaltar que estamos falando de uma das vulnerabilidades mais infames e amplamente relatadas da história, uma que foi ativamente explorada, corrigida pelo desenvolvedor e tratada em todos os principais produtos derivados. A situação para os defeitos menos divulgados é significativamente pior.

Para agravar esse problema, existe a lacuna de visibilidade. Muitas organizações não têm as ferramentas necessárias para mapear uma árvore de dependências completa ou obter visibilidade total dos pacotes e versões específicos integrados em sua pilha de software. Desse modo, os componentes desatualizados geralmente permanecem invisíveis e nunca entram na fila de correção.

Malware em registros de código aberto

Os ataques que envolvem pacotes de código aberto infectados ou inerentemente maliciosos se tornaram uma das ameaças de crescimento mais rápida para a cadeia de fornecimento de software. De acordo com pesquisadores da Kaspersky, aproximadamente 14 mil pacotes maliciosos foram descobertos em registros populares até o final de 2024, um aumento de 48% a cada ano. A Sonatype relatou um aumento ainda mais explosivo ao longo de 2025 e detectou mais de 450 mil pacotes maliciosos.

A motivação por trás desses ataques varia muito: roubo de criptomoedas, coleta de credenciais de desenvolvedor, espionagem industrial, obtenção de acesso à infraestrutura por meio de pipelines de CI/CD ou comprometimento de servidores públicos para hospedar campanhas de spam e phishing. Essas táticas são empregadas tanto por grupos APT de espionagem quanto por criminosos virtuais motivados financeiramente. É cada vez mais comum a violação de um pacote de código aberto ser apenas o primeiro passo de uma violação corporativa em vários estágios.

Cenários de ataque comuns incluem comprometer as credenciais de um mantenedor de pacote de código aberto legítimo, publicar uma biblioteca “útil” com código malicioso integrado ou publicar uma biblioteca maliciosa com um nome quase idêntico a um popular. Uma tendência particularmente alarmante em 2025 foi o aumento de ataques automatizados semelhantes a worms. O exemplo mais notório é a campanha Shai-Hulud. Nesse caso, o código malicioso roubou os tokens do GitHub e npm e continuou infectando novos pacotes, eventualmente se espalhando para mais de 700 pacotes npm e dezenas de milhares de repositórios. Ele vazou segredos de CI/CD e chaves de acesso à nuvem para o domínio público no processo.

Embora esse cenário não esteja tecnicamente relacionado a vulnerabilidades, as ferramentas de segurança e as políticas necessárias para seu gerenciamento são as mesmas usadas para o gerenciamento de vulnerabilidades.

Como os agentes de IA aumentam os riscos do uso de código aberto

A integração apressada e onipresente de agentes de IA no desenvolvimento de software aumenta significativamente a velocidade do desenvolvedor, mas também amplifica qualquer erro. Sem supervisão rigorosa e proteções claramente definidas, o código gerado por IA fica excepcionalmente vulnerável. A pesquisa mostra que 45% do código gerado por IA contém falhas da lista OWASP Top 10, enquanto 20% dos aplicativos orientados por IA implementados abrigam erros de configuração perigosos. Isso acontece porque os modelos de IA são treinados em grandes conjuntos de dados que incluem grandes volumes de código desatualizado, demonstrativo ou puramente educacional. Esses problemas sistêmicos ressurgem quando um modelo de IA decide quais componentes de código aberto devem ser incluídos em um projeto. O modelo costuma não saber quais versões do pacote existem no momento, nem quais foram sinalizadas como vulneráveis. Em vez disso, ele sugere uma versão de dependência extraída de seus dados de treinamento, que, provavelmente, estará obsoleta. Em alguns casos, os modelos tentam chamar versões inexistentes ou bibliotecas totalmente alucinadas. Isso abre a porta para ataques de confusão de dependência.

Em 2025, mesmo os principais LLMs recomendaram versões de dependência incorretas, simplesmente inventando uma resposta, em 27% dos casos.

A IA pode simplesmente corrigir tudo?

É uma ideia simples e tentadora: basta apontar um agente de IA para sua base de código para que ele procure e corrija todas as vulnerabilidades. Infelizmente, a IA não pode resolver totalmente esse problema. Os obstáculos fundamentais que discutimos prejudicam os agentes de IA tanto quanto os desenvolvedores humanos. Se os dados de vulnerabilidade estiverem ausentes ou não forem confiáveis, em vez de encontrar vulnerabilidades conhecidas, será necessário redescobrir tudo do zero. Esse processo consome muitos recursos e requer conhecimento de nicho que permanece fora do alcance da maioria das empresas.

Além disso, se uma vulnerabilidade for descoberta em um componente obsoleto ou sem suporte, um agente de IA não poderá “corrigir automaticamente” a vulnerabilidade. Ainda será preciso desenvolver patches personalizados ou executar uma migração complexa. Se uma falha estiver profundamente oculta em uma cadeia de dependências, é provável que a IA ignore isso completamente.

O que fazer?

Para minimizar os riscos descritos acima, será necessário expandir o processo de gerenciamento de vulnerabilidades para incluir políticas de download de pacotes de código aberto, regras operacionais do assistente de IA e o processo de compilação do software. Isso inclui:

• usar uma solução abrangente de segurança de carga de trabalho na nuvem;
• verificar pacotes de código aberto usados no processo de desenvolvimento de software com feeds de inteligência de ameaças para componentes de código aberto;
• considerar medidas de segurança para proteger o código de IA e os agentes de IA;
• remover sistematicamente os componentes de código aberto obsoletos.

É possível ler mais detalhes sobre o gerenciamento de vulnerabilidades em código aberto em uma postagem de blog dedicada.

É provável que todos já tenham ouvido falar do OpenClaw, anteriormente conhecido como “Clawdbot” ou “Moltbot”, o assistente de IA de código aberto que pode ser implementado localmente em uma máquina. Ele se conecta a plataformas de bate-papo populares como WhatsApp, Telegram, Signal, Discord e Slack, o que permite aceitar comandos do proprietário e acessar todo o sistema de arquivos local. Ele tem acesso ao calendário, e-mail e navegador do proprietário, podendo até mesmo executar comandos do SO por meio do shell.

Do ponto de vista da segurança, essa descrição por si só já é suficiente para deixar qualquer pessoa com os cabelos em pé. Mas quando as pessoas tentam usar o assistente em um ambiente corporativo, a ansiedade rapidamente se transforma na certeza de um caos iminente. Alguns especialistas já consideram o OpenClaw como a maior ameaça interna de 2026. Os problemas com o OpenClaw cobrem todo o espectro dos riscos destacados na recente lista OWASP Top 10 for Agentic Applications.

O OpenClaw permite conectar qualquer LLM local ou baseada em nuvem e usar várias integrações com serviços adicionais. No seu núcleo, há um gateway que aceita comandos por aplicativos de bate-papo ou por uma interface web e os encaminha para os agentes de IA adequados. A iteração inicial (Clawdbot), de novembro de 2025, apresentou gargalos de segurança significativos após sua popularização viral em janeiro de 2026. Em uma única semana, várias vulnerabilidades críticas foram divulgadas, surgiram habilidades maliciosas no diretório e vazaram segredos do Moltbook (basicamente um “Reddit para bots”). Para completar, a Anthropic exigiu que o projeto mudasse de nome para evitar violação da marca “Claude”, e o nome da conta no X foi sequestrado para promover golpes de criptomoedas.

Problemas conhecidos do OpenClaw

Embora o desenvolvedor do projeto pareça reconhecer a importância da segurança, como este é um projeto de hobby, não há recursos dedicados ao gerenciamento de vulnerabilidades nem a outros elementos essenciais de segurança do produto.

Vulnerabilidades do OpenClaw

Entre as vulnerabilidades conhecidas no OpenClaw, a mais perigosa é a CVE-2026-25253 (CVSS 8.8). Ela leva a um comprometimento total do gateway, permitindo que um invasor execute comandos arbitrários. Para piorar a situação, é assustadoramente fácil de explorá-la: se o agente visitar o site de um invasor ou se o usuário clicar em um link malicioso, o token de autenticação principal será vazado. Com esse token em mãos, o invasor tem controle administrativo total sobre o gateway. Essa vulnerabilidade foi corrigida na versão 2026.1.29.

Além disso, duas vulnerabilidades perigosas de injeção de comando (CVE-2026-24763 e CVE-2026-25157) foram descobertas.

Padrões e recursos inseguros

Uma série de configurações padrão e peculiaridades de implementação tornam o ataque ao gateway muito fácil:

• A autenticação é desativada por padrão, portanto, o gateway pode ser acessado pela Internet.
• O servidor aceita conexões WebSocket sem verificar a origem.
• A confiança das conexões localhost é implícita, o que é um desastre prestes a acontecer caso o host esteja executando um proxy reverso.
• Várias ferramentas, inclusive algumas perigosas, estão acessíveis no Modo Visitante.
• Os parâmetros de configuração críticos vazam pela rede local por meio de mensagens de difusão mDNS.

Segredos em texto simples

A configuração, a “memória” e os registros de bate-papo do OpenClaw armazenam chaves de API, senhas e outras credenciais para LLMs e serviços de integração em texto simples. Esta é uma ameaça crítica, pois versões dos malwares de roubo de informações RedLine e Lumma já foram identificadas com caminhos de arquivo do OpenClaw adicionados às suas listas de itens a roubar. Além disso, o malware de roubo de informações Vidar foi pego roubando segredos do OpenClaw.

Habilidades maliciosas

A funcionalidade do OpenClaw pode ser expandida com “habilidades” disponíveis no repositório do ClawHub. Como qualquer pessoa pode carregar uma habilidade, não demorou para que agentes de ameaças começassem a embutir o malware de roubo de informações AMOS macOS em seus envios. Em pouco tempo, o número de habilidades maliciosas chegou à casa das centenas. Isso levou os desenvolvedores a assinar rapidamente um acordo com o VirusTotal para garantir que todas as habilidades enviadas sejam verificadas em bancos de dados de malware e também passem por análise de código e conteúdo via LLMs. Dito isto, os autores são muito claros: não é uma solução milagrosa.

Falhas estruturais no agente de IA OpenClaw

As vulnerabilidades podem ser corrigidas e as configurações podem ser reforçadas, mas alguns dos problemas do OpenClaw são intrínsecos ao seu design. O produto combina vários recursos críticos que, quando agrupados, são muito perigosos:

• O OpenClaw tem acesso privilegiado a dados confidenciais na máquina host e às contas pessoais do proprietário.
• O assistente está totalmente receptivo a dados não confiáveis: ele recebe mensagens por meio de aplicativos de bate-papo e e-mail, acessa páginas da Web de forma autônoma etc.
• Ele sofre com a incapacidade inerente dos LLMs de separar comandos de dados de forma confiável, tornando possível a injeção de prompt.
• O agente salva as principais conclusões e artefatos das suas tarefas para guiar ações futuras. Isso significa que uma única injeção bem-sucedida pode envenenar a memória do agente, influenciando seu comportamento a longo prazo.
• O OpenClaw pode se comunicar com o mundo exterior, enviando e-mails, fazendo chamadas de API e usando outros métodos para exfiltrar dados internos.

Vale notar que, embora o OpenClaw seja um exemplo particularmente extremo, essa lista de “Cinco fatores aterrorizantes” é característica de quase todos os agentes de IA multifuncionais.

Riscos do OpenClaw para as organizações

Se um funcionário instalar um agente como esse em um dispositivo corporativo e conectá-lo a um conjunto básico de serviços (como Slack e SharePoint), a combinação de execução autônoma de comandos, amplo acesso ao sistema de arquivos e permissões OAuth excessivas cria um terreno fértil para o comprometimento profundo da rede. Na verdade, o hábito do bot de acumular segredos e tokens não criptografados em um só lugar é um desastre prestes a acontecer, ainda que o próprio agente de IA nunca seja comprometido.

Além disso, essas configurações violam os requisitos regulamentares em vários países e setores, ocasionando possíveis multas e falhas de auditoria. Os requisitos regulatórios atuais, como os da Lei de IA da UE ou da Estrutura de gerenciamento de risco de IA do NIST, exigem explicitamente controle de acesso rigoroso para agentes de IA. A abordagem de configuração do OpenClaw claramente deixa a desejar nesse quesito.

Mas o verdadeiro problema é que, mesmo que os funcionários sejam proibidos de instalar esse software em máquinas de trabalho, o OpenClaw pode ir parar nos seus dispositivos pessoais. Isso também cria riscos específicos para toda a organização:

• Os dispositivos de uso pessoal costumam armazenar acessos do trabalho, como chaves de VPN e tokens de navegador para ferramentas e e-mails da empresa. Eles podem ser sequestrados para obter acesso inicial à infraestrutura da empresa.
• Controlar o agente por aplicativos de bate-papo significa que não só os funcionários se tornam alvos de engenharia social, mas também seus agentes de IA, tornando reais invasões de contas de IA ou personificação do usuário em bate-papos com colegas (entre outros golpes). Mesmo que o trabalho seja discutido apenas ocasionalmente em bate-papos pessoais, as informações ali estão prontas para serem exploradas.
• Se um agente de IA em um dispositivo pessoal estiver conectado a qualquer serviço corporativo (e-mail, mensagens, armazenamento de arquivos), os invasores podem manipular o agente para desviar dados, e essa atividade seria extremamente difícil de ser detectada pelos sistemas de monitoramento corporativos.

Como detectar o OpenClaw

Dependendo dos recursos de monitoramento e resposta da equipe do SOC, eles podem rastrear tentativas de conexão do gateway do OpenClaw em dispositivos pessoais ou na nuvem. Além disso, uma combinação específica de sinais de alerta pode indicar a presença do OpenClaw em um dispositivo corporativo:

• Procure os diretórios ~/.openclaw/, ~/clawd/ ou ~/.clawdbot nas máquinas host.
• Verifique a rede com ferramentas internas ou públicas, como o Shodan, para identificar as impressões digitais HTML dos painéis de controle do Clawdbot.
• Monitore o tráfego de WebSocket nas portas 3000 e 18789.
• Fique atento às mensagens de difusão de mDNS na porta 5353 (especificamente openclaw-gw.tcp).
• Preste atenção a tentativas de autenticação incomuns em serviços corporativos, como novos registros de ID de aplicativo, eventos de consentimento OAuth ou strings de User-Agent típicas do Node.js e de outros agentes do usuário não padrão.
• Procure padrões de acesso típicos de coleta automatizada de dados: leitura de grandes volumes (por exemplo, raspar todos os arquivos ou e-mails) ou varredura de diretórios em intervalos fixos fora do horário do expediente.

Controlando o comportamento da Shadow AI

Um conjunto de práticas de higiene de segurança pode reduzir muito a pegada de Shadow IT e Shadow AI, tornando muito mais difícil implementar o OpenClaw em uma organização:

• Use a lista de permissões em nível de host para garantir que apenas aplicativos aprovados e integrações na nuvem sejam instalados. Implemente uma lista fechada de complementos verificados para produtos que oferecem extensibilidade (como extensões do Chrome, plugins do VS Code ou habilidades do OpenClaw).
• Faça uma avaliação de segurança completa de todos os produtos ou serviços, inclusive dos agentes de IA, antes de permitir que eles se conectem aos recursos corporativos.
• Aplique aos agentes de IA os mesmos requisitos de segurança rigorosos aplicados aos servidores de uso público que processam dados corporativos confidenciais.
• Implemente o princípio de privilégio mínimo para todos os usuários e outras identidades.
• Não conceda privilégios administrativos sem que haja uma necessidade comercial crítica. Exija que todos os usuários com permissões elevadas as usem apenas ao executar tarefas específicas, em vez de trabalhar com contas privilegiadas o tempo todo.
• Configure os serviços corporativos para que as integrações técnicas (como aplicativos que solicitam acesso pelo OAuth) recebam apenas as permissões mínimas.
• Faça auditorias periódicas de integrações, tokens OAuth e permissões concedidas a aplicativos de terceiros. Analise a necessidade disso com os proprietários de empresas, revogue proativamente permissões excessivas e elimine integrações obsoletas.

Implementação segura de agentes de IA

Se uma organização permitir agentes de IA de forma experimental (por exemplo, em testes de desenvolvimento ou pilotos de eficiência) ou liberar casos de uso específicos para a equipe, então medidas robustas de monitoramento, logs e controle de acesso devem ser implementadas:

• Implemente os agentes em uma sub-rede isolada com regras estritas de entrada e saída, limitando a comunicação apenas aos hosts confiáveis necessários para a tarefa.
• Use tokens de acesso de curta duração com um escopo de privilégios muito limitado. Nunca entregue a um agente tokens que concedam acesso aos servidores ou serviços principais da empresa. O ideal é criar contas de serviço exclusivas para cada teste individual.
• Mantenha as ferramentas perigosas e os conjuntos de dados que não são relevantes para o trabalho específico. Para implementações experimentais, a prática recomendada é testar o agente usando dados puramente sintéticos que imitam a estrutura de dados de produção reais.
• Configure o registro detalhado das ações do agente. Isso deve incluir registros de eventos, parâmetros de linha de comando e artefatos da cadeia de raciocínio associados a cada comando executado.
• Configure o SIEM para sinalizar atividades anormais do agente. As mesmas técnicas e regras usadas para detectar ataques LotL são aplicáveis aqui, embora sejam necessários esforços adicionais para definir quais são as atividades normais de um agente específico.
• Se servidores MCP e habilidades de agente adicionais forem usados, verifique-os com as ferramentas de segurança emergentes para essas tarefas, como o skill-scanner, mcp-scanner ou o mcp-scan. Várias empresas já lançaram ferramentas de código aberto para auditar a segurança das configurações durante testes do OpenClaw.

Políticas corporativas e treinamento de funcionários

A proibição total de todas as ferramentas de IA é um caminho simples, mas que quase nunca é produtivo. Os funcionários geralmente encontram soluções alternativas, empurrando o problema para as sombras e dificultando ainda mais o seu controle. Em vez disso, é melhor encontrar um equilíbrio sensato entre produtividade e segurança.

Implemente políticas transparentes para o uso de agentes de IA. Defina quais categorias de dados podem ser processadas por serviços externos de IA e quais estão estritamente proibidas. Os funcionários precisam entender por que algo é proibido. Uma política de “sim, mas com ressalvas” é sempre melhor recebida do que um “não” geral.

Use exemplos do mundo real nos treinamentos. Avisos abstratos sobre “riscos de vazamento” tendem a não ser levados a sério. É melhor demonstrar como um agente com acesso ao e-mail consegue encaminhar mensagens confidenciais só porque um e-mail de entrada aleatório solicitou. Quando a ameaça parece real, a motivação para seguir as regras também cresce. O ideal é que os funcionários façam um curso rápido sobre segurança de IA.

Ofereça alternativas seguras. Se os funcionários precisarem de um assistente de IA, forneça uma ferramenta aprovada com gerenciamento centralizado, logs e controle de acesso OAuth.