É 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.

Como proteger uma organização contra ações perigosas de agentes de IA que ela utiliza? Isso já não é apenas um exercício teórico, considerando que os danos reais que a IA autônoma pode causar vão desde oferecer um atendimento ao cliente de baixa qualidade até destruir bancos de dados corporativos principais.  É uma questão na qual os líderes empresariais estão se concentrando intensamente atualmente, enquanto agências governamentais e especialistas em segurança correm para fornecer respostas.

Para CIOs e CISOs, os agentes de IA criam um enorme desafio de governança. Esses agentes tomam decisões, utilizam ferramentas e processam dados sensíveis sem a participação humana no processo. Isso faz com que muitas das nossas ferramentas tradicionais de TI e segurança não sejam suficientes para controlar a IA.

A organização sem fins lucrativos OWASP Foundation lançou um guia prático exatamente sobre esse tema. Sua abrangente lista dos 10 principais riscos para aplicações de IA agêntica abrange desde ameaças tradicionais de segurança, como escalonamento de privilégios, até problemas específicos de IA, como envenenamento da memória do agente. Cada risco é acompanhado de exemplos do mundo real, de uma análise comparativa em relação a ameaças semelhantes e de estratégias de mitigação. Neste post, resumimos as descrições e consolidamos as recomendações de defesa.

Sequestro de objetivo do agente (ASI01)

Esse risco consiste na manipulação das tarefas ou da lógica de tomada de decisão de um agente, explorando a incapacidade do modelo subjacente de distinguir entre instruções legítimas e dados externos. Invasores usam injeção de prompts ou dados forjados para reprogramar o agente e fazê-lo executar ações maliciosas. A diferença fundamental em relação à injeção de prompt tradicional é que esse tipo de ataque compromete o processo de planejamento em múltiplas etapas do agente, em vez de apenas levar o modelo a produzir uma única resposta incorreta.

Exemplo: um invasor incorpora uma instrução oculta em uma página da Web que, ao ser interpretada pelo agente de IA, aciona a exportação do histórico de navegação do usuário. Uma vulnerabilidade dessa natureza foi demonstrada no estudo EchoLeak.

Uso indevido e exploração de ferramentas (ASI02)

Esse risco surge quando um agente, orientado por comandos ambíguos ou sob influência maliciosa, utiliza de forma insegura ou não intencional as ferramentas legítimas às quais tem acesso. Entre os exemplos estão a exclusão em massa de dados e o envio de chamadas redundantes a APIs com cobrança por uso. Esses ataques costumam ocorrer por meio de cadeias complexas de chamadas, o que permite que passem despercebidos pelos sistemas tradicionais de monitoramento de hosts.

Exemplo: um chatbot de atendimento ao cliente com acesso a uma API financeira é manipulado para processar reembolsos não autorizados, pois seu acesso não estava restrito ao modo somente leitura. Outro exemplo é a exfiltração de dados por meio de consultas DNS, de forma semelhante ao ataque ao Amazon Q.

Abuso de identidade e privilégios (ASI03)

Essa vulnerabilidade envolve a forma como permissões são concedidas e herdadas em fluxos de trabalho agênticos. Invasores exploram permissões existentes ou credenciais em cache para escalar privilégios ou executar ações para as quais o usuário original não tinha autorização. O risco se agrava quando agentes utilizam identidades compartilhadas ou reutilizam tokens de autenticação em diferentes contextos de segurança.

Exemplo: um funcionário cria um agente que utiliza suas credenciais pessoais para acessar sistemas internos. Se esse agente for posteriormente compartilhado com outros colegas, todas as solicitações feitas a ele também serão executadas com os privilégios elevados do criador.

Vulnerabilidades na cadeia de suprimentos agêntica (ASI04)

Os riscos surgem quando são utilizados modelos, ferramentas ou personas de agentes pré-configurados de terceiros que podem já estar comprometidos ou ser maliciosos desde a origem. O que torna esse cenário mais complexo do que no software tradicional é o fato de que componentes agênticos costumam ser carregados de forma dinâmica e nem sempre são conhecidos previamente. Isso amplia significativamente o risco, sobretudo quando o agente tem permissão para buscar, por conta própria, um pacote considerado adequado. Observa-se um aumento tanto de ataques de typosquatting, em que ferramentas maliciosas em repositórios imitam os nomes de bibliotecas populares, quanto do fenômeno relacionado conhecido como slopsquatting, no qual um agente tenta chamar ferramentas que sequer existem.

Exemplo: um agente assistente de codificação instala automaticamente um pacote comprometido contendo uma backdoor, permitindo que um invasor extraia tokens de CI/CD e chaves SSH diretamente do ambiente do agente. Já há registros documentados de ataques destrutivos direcionados a agentes de desenvolvimento de IA ocorrendo em ambientes reais.

Execução inesperada de código/RCE (ASI05)

Sistemas agênticos frequentemente geram e executam código em tempo real para realizar tarefas, o que abre espaço para a execução de scripts ou binários maliciosos. Por meio de injeção de prompt e outras técnicas, um agente pode ser induzido a executar as ferramentas às quais tem acesso com parâmetros perigosos ou a executar código fornecido diretamente por um invasor.  Isso pode evoluir para o comprometimento completo de um contêiner ou do host, ou para uma fuga de sandbox, momento a partir do qual o ataque passa a ser invisível às ferramentas padrão de monitoramento de IA.

Exemplo: um invasor envia um prompt que, sob o pretexto de testes de código, engana um agente de vibecoding para baixar um comando via cURL e direcioná-lo diretamente para o bash.

Envenenamento de memória e de contexto (ASI06)

Invasores modificam as informações das quais o agente depende para manter a continuidade, como o histórico de diálogos, uma base de conhecimento de RAG ou resumos de etapas anteriores de tarefas. Esse contexto envenenado distorce o raciocínio futuro do agente e a seleção de ferramentas. Como resultado, backdoors persistentes podem surgir na lógica do agente e sobreviver entre sessões. Diferentemente de uma injeção pontual, esse risco causa um impacto de longo prazo no conhecimento e na lógica comportamental do sistema.

Exemplo: um invasor insere dados falsos na memória de um assistente sobre cotações de preços de passagens aéreas fornecidas por um vendedor. Como consequência, o agente aprova transações futuras a um valor fraudulento. Um exemplo de implantação de memória falsa foi demonstrado em um ataque prova de conceito contra o Gemini.

Comunicação insegura entre agentes (ASI07)

Em sistemas multiagente, a coordenação ocorre por meio de APIs ou barramentos de mensagens que ainda frequentemente carecem de criptografia, autenticação ou verificações de integridade básicas. Invasores podem interceptar, falsificar ou modificar essas mensagens em tempo real, fazendo com que todo o sistema distribuído apresente falhas generalizadas. Essa vulnerabilidade abre espaço para ataques do tipo “agent-in-the-middle”, além de outras técnicas clássicas de exploração de comunicação amplamente conhecidas na segurança da informação aplicada, como repetição de mensagens, falsificação do remetente e degradação forçada de protocolos.

Exemplo: forçar os agentes a mudar para um protocolo não criptografado para injetar comandos ocultos, sequestrando efetivamente o processo coletivo de tomada de decisão de todo o grupo de agentes.

Falhas em cascata (ASI08)

Esse risco descreve como um único erro, causado por alucinação, injeção de prompt ou qualquer outra falha, pode se propagar e se amplificar ao longo de uma cadeia de agentes autônomos. Como esses agentes repassam tarefas uns aos outros sem intervenção humana, uma falha em um único elo pode desencadear um efeito dominó que leva a um colapso generalizado de toda a rede. O problema central está na velocidade com que o erro se propaga: espalha-se muito mais rápido do que qualquer operador humano é capaz de acompanhar ou interromper.

Exemplo: um agente de agendamento comprometido distribui uma série de comandos inseguros que são automaticamente executados por agentes subsequentes, gerando um ciclo de ações perigosas replicadas por toda a organização.

Exploração da confiança humano–agente (ASI09)

Invasores exploram a natureza conversacional e a aparente especialização dos agentes para manipular usuários. O antropomorfismo leva as pessoas a depositar confiança excessiva nas recomendações da IA e a aprovar ações críticas sem pensar duas vezes. O agente atua como um mau conselheiro, transformando o ser humano no executor final do ataque, o que dificulta investigações forenses posteriores.

Exemplo: um agente de suporte técnico comprometido faz referência a números reais de chamados para criar empatia com um novo funcionário e, gradualmente, persuadi-lo a entregar suas credenciais corporativas.

Agentes fora de controle (ASI10)

Trata-se de agentes maliciosos, comprometidos ou em estado de alucinação que se desviam de suas funções atribuídas, operam de forma furtiva ou atuam como parasitas dentro do sistema. Uma vez perdido o controle, um agente desse tipo pode passar a se autorreplicar, perseguir uma agenda oculta própria ou até mesmo colaborar com outros agentes para contornar mecanismos de segurança. A principal ameaça descrita pelo ASI10 é a erosão de longo prazo da integridade comportamental do sistema após uma violação inicial ou uma anomalia.

Exemplo: o caso mais notório envolve um agente autônomo de desenvolvimento da Replit que saiu do controle, apagou o banco de dados principal de clientes da empresa e, em seguida, fabricou completamente seu conteúdo para aparentar que a falha havia sido corrigida.

Mitigação de riscos em sistemas de IA agêntica

Embora a natureza probabilística da geração por LLMs e a ausência de separação clara entre canais de instruções e de dados tornem inviável uma segurança totalmente à prova de falhas, um conjunto rigoroso de controles, aproximando-se de uma estratégia de Zero Trust, pode limitar significativamente os danos quando algo sai do previsto. Aqui estão as medidas mais críticas.

Aplicar os princípios do menor grau de autonomia e do menor privilégio. Limite a autonomia dos agentes de IA atribuindo tarefas com salvaguardas rigorosamente definidas. Garanta que eles tenham acesso apenas às ferramentas, APIs e aos dados corporativos estritamente necessários para cumprir sua missão. Sempre que aplicável, reduza as permissões ao mínimo absoluto, por exemplo, restringindo o acesso ao modo somente leitura.

Utilizar credenciais de curta duração. Emita tokens temporários e chaves de API com escopo limitado para cada tarefa específica. Isso impede que um invasor reutilize credenciais caso consiga comprometer um agente.

Intervenção humana obrigatória para operações críticas. Exija confirmação humana explícita para qualquer ação irreversível ou de alto risco, como autorizar transferências financeiras ou excluir dados em massa.

Isolamento de execução e controle de tráfego. Execute códigos e ferramentas em ambientes isolados, como contêineres ou sandboxes, com listas de permissões estritas de ferramentas e conexões de rede, a fim de impedir chamadas de saída não autorizadas.

Aplicação de políticas. Implemente mecanismos de validação de intenção para avaliar os planos e argumentos de um agente em relação a regras de segurança rígidas antes que eles entrem em produção.

Validação e sanitização de entradas e saídas. Utilize filtros especializados e esquemas de validação para verificar todos os prompts e respostas do modelo em busca de injeções e conteúdo malicioso. Esse processo deve ocorrer em todas as etapas do processamento de dados e sempre que informações forem transferidas entre agentes.

Registro seguro contínuo. Registre todas as ações dos agentes e as mensagens trocadas entre eles em logs imutáveis. Esses registros seriam necessários para futuras auditorias e investigações forenses.

Monitoramento comportamental e agentes de vigilância. Implemente sistemas automatizados para detectar anomalias, como picos repentinos de chamadas a APIs, tentativas de autorreplicação ou um agente desviando subitamente de seus objetivos principais. Essa abordagem se sobrepõe, em grande medida, ao monitoramento necessário para detectar ataques de rede sofisticados do tipo “living-off-the-land”. Como consequência, organizações que já adotaram soluções de XDR e estão processando telemetria em um SIEM terão uma vantagem inicial significativa, pois encontrarão muito mais facilidade para manter seus agentes de IA sob controle rigoroso.

Controle da cadeia de suprimentos e SBOMs (listas de materiais de software). Utilize apenas ferramentas e modelos previamente validados, provenientes de repositórios confiáveis. No desenvolvimento de software, assine todos os componentes, fixe versões de dependências e revise cuidadosamente cada atualização.

Análise estática e dinâmica do código gerado. Verifique cada linha de código que um agente escrever em busca de vulnerabilidades antes da execução. Proíba completamente o uso de funções perigosas, como eval(). Essas duas últimas recomendações já deveriam fazer parte de um fluxo padrão de DevSecOps e precisam ser estendidas a todo código gerado por agentes de IA. Fazer isso manualmente é praticamente inviável; por isso, recomenda-se o uso de ferramentas de automação, como as disponíveis no Kaspersky Cloud Workload Security.

Proteção das comunicações entre agentes. Garanta autenticação mútua e criptografia em todos os canais de comunicação entre agentes. Utilize assinaturas digitais para verificar a integridade das mensagens.

 Botões de emergência. Crie mecanismos para bloquear imediatamente agentes ou ferramentas específicas no momento em que um comportamento anômalo for detectado.

Uso de interfaces para calibração de confiança. Use indicadores visuais de risco e alertas de nível de confiança para reduzir o risco de as pessoas confiarem cegamente na IA.

Treinamento de usuários. Capacite sistematicamente os colaboradores sobre as realidades operacionais de sistemas baseados em IA. Utilize exemplos alinhados às funções reais de cada cargo para explicitar riscos específicos relacionados à IA. Dada a velocidade com que esse campo evolui, um treinamento anual de compliance não é suficiente; essas capacitações devem ser atualizadas várias vezes ao ano.

Para analistas de SOC, também recomendamos o curso Kaspersky Expert Training: Large Language Models Security, que aborda as principais ameaças aos LLMs e as estratégias defensivas para mitigá-las. O curso também é relevante para desenvolvedores e arquitetos de IA que atuam na implementação de LLMs.