Skills de IA Maliciosas Ampliam o Risco de Segurança Empresarial

O Google News evidenciou um conflito marcante em torno da IA empresarial: os agentes ganham capacidades úteis por meio de skills, enquanto atacantes exploram essas mesmas extensões. Uma pesquisa recente identificou mais de 3.000 skills maliciosas entre quase 900.000 analisadas pela fornecedora de segurança ESET. A descoberta transforma um recurso conveniente de agentes em um problema de cadeia de suprimentos de software.

A preocupação vai além de um único marketplace ou campanha de malware. Skills de IA podem combinar instruções, scripts, documentação externa e acesso a sistemas sensíveis. Uma skill comprometida pode, portanto, influenciar tanto as decisões de um agente quanto as ferramentas que ele controla.

As empresas agora enfrentam um equilíbrio entre autonomia e controle. Ecossistemas abertos aceleram a experimentação, mas seus sinais de confiança continuam mais fracos do que os que cercam pacotes de software estabelecidos. Pesquisadores já demonstraram que a popularidade de repositórios, a aprovação de marketplaces e a varredura estática podem falhar simultaneamente.

O que o Google News Revelou Sobre Skills de IA Maliciosas

A mudança importante é a escala, não o primeiro surgimento de uma extensão maliciosa.

A pesquisa H1 2026 da ESET cobriu atividades de ameaças observadas de dezembro de 2025 a maio de 2026. A empresa afirmou ter analisado quase 900.000 skills de IA e encontrado dezenas de milhares de exemplos suspeitos. Mais de 3.000 foram classificadas como maliciosas.

Uma skill de IA é um pacote reutilizável que informa a um agente como concluir uma tarefa, usar ferramentas e lidar com informações relacionadas. Algumas skills contêm pouco mais do que instruções. Outras conectam o agente a scripts, serviços, arquivos, ferramentas de linha de comando ou recursos web em constante mudança.

A população analisada cresceu acentuadamente durante o período da pesquisa. Segundo reportagens baseadas nas descobertas, a ESET examinou cerca de 60.000 skills únicas em março e quase 900.000 em maio. As descobertas suspeitas aumentaram de cerca de 10.000 para mais de 25.000 nesse intervalo.

As descobertas maliciosas subiram de aproximadamente 600 para mais de 3.000. Esses números não comprovam que todos os repositórios tenham a mesma taxa de infecção. Eles mostram, porém, que as equipes de segurança enfrentam um volume crescente de comportamento de agentes de terceiros para avaliar.

O resumo público do relatório de ameaças da ESET descreve skills como pequenos componentes funcionais usados por agentes. A empresa encontrou instâncias maliciosas e suspeitas nos repositórios que examinou.

Os pesquisadores observaram capacidades associadas à execução de comandos, injeção de código, acesso a arquivos, carregamento de credenciais, ofuscação e downloads externos. Esses recursos não são automaticamente maliciosos. Eles se tornam perigosos quando o propósito declarado da skill não os justifica.

Uma skill legítima para desenvolvedores pode precisar de acesso ao shell para criar uma aplicação. Um assistente de documentos pode precisar de permissão para ler arquivos selecionados. A questão de segurança é se essas permissões permanecem limitadas, visíveis e vinculadas a uma finalidade comercial aprovada.

O malware tradicional costuma chegar como executável, anexo ou pacote comprometido. Skills de IA maliciosas acrescentam outro formato de distribuição. Instruções prejudiciais podem aparecer em linguagem comum que um agente trata como orientação operacional.

Esse design complica a detecção. Uma skill pode não conter um binário malicioso reconhecível quando é revisada. Em vez disso, ela pode direcionar o agente a uma página externa, obter novas instruções mais tarde ou usar indevidamente ferramentas legítimas já presentes.

O item do Google News importa porque conecta essas descobertas distintas em uma narrativa de risco empresarial. A ameaça já não se limita a agentes pessoais experimentais. Skills estão entrando em fluxos de trabalho usados por engenheiros, profissionais de marketing, analistas, designers e equipes de vendas.

Esses usuários podem instalar extensões sem tratar a ação como uma implantação de software. Um arquivo de texto curto parece menos perigoso do que um instalador de aplicativo. No entanto, o agente que lê esse arquivo pode já ter acesso a e-mail, armazenamento em nuvem, código-fonte ou conhecimento interno.

A diferença entre aparência e autoridade cria a tensão central. Skills muitas vezes parecem documentação, mas podem funcionar como lógica executável de fluxo de trabalho. As empresas não podem governá-las com segurança como se fossem prompts inofensivos.

Por que a Segurança de Agentes de IA Agora se Assemelha à Defesa da Cadeia de Suprimentos

Uma skill se torna uma dependência empresarial quando um agente depende dela para agir dentro dos sistemas da empresa.

A segurança da cadeia de suprimentos de software acompanha a origem dos componentes, quem os mantém, quais versões são implantadas e como as atualizações chegam à produção. Skills de IA maliciosas exigem muitos dos mesmos controles. Elas também introduzem riscos comportamentais que a varredura convencional de pacotes não foi projetada para interpretar.

Uma skill pode coordenar várias ferramentas confiáveis sem explorar uma vulnerabilidade de software. Ela pode instruir um agente a localizar uma credencial, transformar um arquivo e enviar o resultado para outro lugar. Cada chamada de ferramenta individual pode parecer legítima quando vista isoladamente.

O risco cresce com a autoridade do agente. Um assistente limitado à redação de texto apresenta uma exposição menor do que outro conectado a um shell, navegador, repositório de código e conta na nuvem. Agentes empresariais estão cada vez mais próximos do segundo modelo.

Isso cria um efeito multiplicador. A skill fornece instruções, enquanto o agente fornece permissões, raciocínio e execução. Um atacante não precisa incorporar todas as capacidades à extensão maliciosa.

O marketplace ClawHub da OpenClaw tornou-se um estudo de caso inicial. Pesquisadores documentaram skills maliciosas que visavam credenciais e ativos de criptomoedas. Algumas distribuíam malware estabelecido, enquanto outras manipulavam transações conduzidas por agentes.

A Unit 42 da Palo Alto Networks examinou a atividade do marketplace entre fevereiro e maio de 2026. Sua análise da cadeia de suprimentos identificou cinco skills maliciosas não bloqueadas após a introdução de novas medidas de triagem.

Duas distribuíam ladrões de informações para macOS conectados a infraestrutura de comando e controle. Outra usava arquivos inflados para contornar os limites dos scanners. Skills adicionais buscavam manipulação financeira por meio de comportamentos específicos de agentes autônomos.

A Unit 42 reportou as cinco skills ao ClawHub. O marketplace as removeu e baniu as contas associadas. A resposta reduziu a exposição imediata, mas não eliminou o problema subjacente de distribuição.

Descobertas anteriores já haviam levado o ClawHub a integrar VirusTotal e ClawScan. Esses serviços acrescentaram triagem proativa e análise em nível de código. A OpenClaw também anunciou trabalho com a Nvidia em análise e documentação de skills.

A sequência é instrutiva. Um marketplace adicionou defesas após o surgimento de campanhas maliciosas, mas pesquisadores continuaram encontrando skills evasivas. Isso se assemelha à disputa de longa data em torno de extensões de navegador, registros de pacotes e aplicativos móveis.

Skills de agentes acrescentam outra complicação porque seu conteúdo efetivo pode se estender além do artefato baixado. Uma skill local pode instruir o agente a ler documentação online. Essa página externa pode mudar sem alterar a skill revisada.

Por isso, as equipes de segurança não podem depender apenas de uma avaliação no momento da instalação. Um resultado seguro descreve o que um scanner observou em determinado momento. Ele não garante que todas as dependências permanecerão inalteradas.

O inventário empresarial também se torna mais difícil quando funcionários podem adicionar skills diretamente. Uma empresa pode aprovar uma plataforma de agentes sem saber quais extensões da comunidade os usuários instalam depois. Isso cria comportamento de IA paralela dentro de um produto oficialmente autorizado.

A distinção importa para a resposta a incidentes. Investigadores precisam saber qual skill foi executada, quais instruções ela carregou, quais ferramentas chamou e quais informações acessou. Logs comuns de aplicações podem não capturar essa cadeia completa.

As organizações já mantêm listas de materiais de software para sistemas selecionados. As implantações de agentes precisam de um registro relacionado, que cubra modelos, ferramentas, skills, fontes externas de instruções, permissões e versões. Sem esse mapa, as equipes de resposta não conseguem determinar a exposição de forma confiável.

Um registro interno pesquisável também pode apoiar investigações após a descoberta de uma extensão arriscada. Equipes que organizam evidências técnicas locais por meio de uma base de conhecimento de engenharia podem preservar decisões de revisão, responsabilidades e contexto de remediação.

Esse registro não substitui a segurança em tempo de execução. Ele ajuda a estabelecer quem aprovou uma dependência e por quê. A exigência maior continua sendo o controle contínuo sobre o que os agentes podem ler, invocar e transmitir.

A Principal Troca É Entre Autonomia do Agente e Controle Empresarial

Skills tornam os agentes mais capazes ao reduzir a supervisão repetida, o que também dá espaço para instruções maliciosas operarem.

Um agente empresarial se torna útil quando consegue concluir trabalhos de várias etapas. Ele pode coletar requisitos, inspecionar arquivos, consultar um serviço, gerar um artefato e entregar o resultado. Exigir aprovação após cada ação menor eliminaria grande parte desse valor.

Conceder ampla autonomia resolve o problema de usabilidade, mas amplia o potencial raio de impacto. Uma extensão comprometida pode reutilizar as mesmas conexões que tornam o agente produtivo. O atacante herda acesso indiretamente por meio do fluxo de trabalho autorizado do agente.

Isso não é simplesmente uma disputa entre plataformas abertas e fechadas. Um catálogo curado ainda pode distribuir um componente comprometido. Uma skill privada ainda pode se tornar perigosa após mudanças em seu repositório, na conta de seu mantenedor ou em uma dependência externa.

Marketplaces abertos aumentam a exposição porque a publicação e a instalação podem envolver pouco atrito. Eles também tornam possíveis a pesquisa, a remoção e a revisão pela comunidade. Restringir todos os agentes a skills desenvolvidas internamente reduziria alguns riscos, mas criaria novas cargas de manutenção.

A questão decisiva é se a autoridade segue o princípio do menor privilégio. Uma skill de landing page não deveria precisar de acesso irrestrito a chaves SSH ou credenciais de nuvem. Uma skill de resumo não deveria executar silenciosamente scripts de shell baixados.

Esse princípio soa familiar porque é familiar. O menor privilégio orienta a segurança de identidade e aplicações há décadas. Sistemas baseados em agentes tornam sua aplicação mais difícil porque um agente pode reunir várias ações individualmente permitidas em uma sequência insegura.

Skills também operam em uma camada semântica. Suas instruções descrevem objetivos e procedimentos em linguagem natural. Os controles de segurança tradicionais se destacam na identificação de padrões de código conhecidos, hashes de arquivos e indicadores de rede.

Eles são menos eficazes quando o comportamento perigoso é expresso como orientação operacional plausível. Uma instrução pode pedir ao agente que obtenha um pré-requisito, valide uma conta ou sincronize uma configuração. A intenção prejudicial só emerge do contexto.

A orientação da OWASP sobre skills de agentes separa essa camada comportamental da camada de conexão de ferramentas. As ferramentas definem as ações disponíveis, enquanto as skills organizam essas ações em fluxos de trabalho.

A OWASP identifica skills maliciosas, comprometimento da cadeia de suprimentos, privilégios excessivos, instruções externas não confiáveis, isolamento fraco e desvio de atualizações entre os principais riscos. Essa lista mostra por que um único scanner ou uma única política não pode cobrir todo o problema.

Uma arquitetura segura precisa de várias fronteiras. O marketplace deve estabelecer a procedência. A plataforma de agentes deve impor permissões. Os controles de runtime devem observar as ações, enquanto a organização deve manter inventário e propriedade.

A aprovação humana continua útil quando é aplicada a riscos significativos. O envio de um rascunho comum para uma pasta interna pode prosseguir automaticamente. O upload de arquivos confidenciais ou a alteração da infraestrutura de produção devem exigir uma autorização mais forte.

O desafio é evitar solicitações sem sentido. Os usuários aprovam rotineiramente pedidos que não entendem, especialmente quando as interrupções se tornam frequentes. Uma caixa de diálogo de aprovação não pode compensar permissões padrão excessivas ou alterações invisíveis em dependências.

Compradores corporativos também devem distinguir a utilidade de uma skill de sua confiabilidade. Popularidade indica adoção, não segurança. Uma grande quantidade de estrelas pode fornecer validação social, sem dizer nada sobre o comportamento atual de instruções externas.

A mesma cautela se aplica aos selos de marketplace. A aprovação pode confirmar que uma submissão passou por uma revisão. Ela não estabelece que os recursos vinculados, a propriedade do repositório ou os pacotes posteriores permanecerão estáveis.

Essa troca moldará a adoção empresarial. Equipes de segurança que bloqueiam todas as extensões levarão a experimentação para ambientes não gerenciados. Equipes que permitem instalação irrestrita criarão um grafo de dependências em expansão que não conseguem inspecionar.

O meio-termo viável é a autonomia governada. Os usuários podem acessar capacidades aprovadas, enquanto ações de alto risco permanecem isoladas e observáveis. As skills recebem permissões ligadas à sua finalidade, e não todas as permissões disponíveis ao agente anfitrião.

A autonomia governada também exige revogação. Quando uma skill se torna insegura, os administradores precisam localizar cada instalação, desativá-la, invalidar credenciais expostas e revisar atividades relacionadas. Uma simples remoção do marketplace é insuficiente.

Scanners Estáticos Estão Perdendo a Corrida pela Confiança

O alerta mais forte veio de uma skill de pesquisa aparentemente inofensiva que, segundo relatos, alcançou mais de 26.000 agentes após passar pelos scanners disponíveis.

Pesquisadores da AIR Security criaram uma skill chamada brand-landingpage. Ela parecia ajudar usuários não técnicos a criar uma landing page com a ferramenta de design Stitch, do Google. A skill oferecia funcionalidade genuína, o que tornava a proposta crível.

Os pesquisadores a enviaram para uma coleção popular de código aberto contendo 156 skills e cerca de 36.000 estrelas no GitHub. A contribuição foi aceita após vários dias. A AIR então promoveu a skill por meio de um anúncio no Instagram direcionado a profissionais de marketing, designers e vendedores.

A skill empacotada não continha inicialmente uma carga maliciosa óbvia. Em vez disso, ela direcionava os agentes para documentação de instalação em um domínio controlado pelos pesquisadores. Inicialmente, esse domínio redirecionava visitantes para o serviço legítimo Stitch.

Mais tarde, a AIR alterou as instruções externas. A página revisada dizia aos agentes para baixar e executar um script. No experimento, a carga coletava endereços de e-mail para que os usuários afetados pudessem ser notificados.

Os pesquisadores afirmaram que nenhum agente foi prejudicado. Também disseram que a técnica poderia ter alcançado conversas privadas e sistemas internos conectados. Esses impactos mais amplos eram resultados possíveis, não perdas documentadas do experimento.

O relato da AIR sobre o teste controlado da skill afirma que scanners da Cisco, Nvidia e skills.sh classificaram a submissão como segura. O resultado expôs uma limitação estrutural da revisão estática.

Um scanner pode inspecionar os arquivos atuais de uma skill e ainda assim não detectar conteúdo futuro hospedado em outro lugar. A documentação externa funciona como uma dependência mutável. Seu proprietário pode alterar as instruções depois que o marketplace e os usuários estabeleceram confiança.

Esse método se assemelha a atualizações maliciosas adiadas em ecossistemas de software estabelecidos. A diferença está na entrega. O invasor pode alterar linguagem comum que o agente posteriormente interpreta como orientação processual autorizada.

A análise estática ainda tem valor. Ela pode identificar código malicioso conhecido, comandos ofuscados, URLs suspeitas, permissões excessivas e dependências perigosas de pacotes. O erro é tratar uma única varredura limpa como uma decisão de confiança duradoura.

Os testes comportamentais acrescentam outra camada. Um sandbox pode executar a skill em um ambiente de agente restrito e observar tentativas de acesso a arquivos, downloads, comandos e comunicação de rede. Essa abordagem pode expor comportamentos ocultos por trás de texto plausível.

No entanto, o sandboxing também tem limites. Um invasor pode atrasar a ativação, reagir a sinais do ambiente ou fornecer instruções benignas a sistemas de análise conhecidos. Um teste também não consegue antecipar todas as interações entre uma skill e as ferramentas internas de uma empresa.

Por isso, o monitoramento contínuo importa após a instalação. Os sistemas de segurança precisam detectar quando uma skill entra em contato com um novo domínio, solicita dados mais amplos, altera seu padrão de execução ou invoca ferramentas fora de sua finalidade esperada.

A fixação de conteúdo pode reduzir a deriva das instruções externas. Uma empresa pode preservar a versão revisada da documentação ou exigir hashes criptográficos para componentes baixados. O agente não deve confiar automaticamente no que uma URL mutável fornecer posteriormente.

Os controles de rede oferecem outro ponto de verificação. Skills que não precisam de acesso à internet não devem recebê-lo. Outras podem ser limitadas a domínios, métodos e destinos aprovados.

A visibilidade em runtime deve se estender além do tráfego de rede. Os defensores precisam de um rastreio que conecte a solicitação do usuário, a skill selecionada, as instruções recuperadas, as decisões do modelo, as chamadas de ferramentas e a movimentação de dados resultante. Caso contrário, cada ação perde seu contexto comportamental.

O experimento da AIR não prova que toda skill popular seja insegura. Ele demonstra que sinais comuns de confiança podem convergir em uma conclusão falsa. Reputação, aceitação no marketplace e varredura apoiaram o mesmo artefato projetado de forma maliciosa.

Esse é o ângulo cético que os líderes empresariais devem manter. Fornecedores de segurança estão introduzindo scanners específicos para IA, mas nenhum scanner pode oferecer garantia permanente para fluxos de trabalho mutáveis. As alegações de produto devem ser avaliadas com base em testes reais de evasão e taxas transparentes de falha.

A cobertura do Google News pode ampliar a conscientização, mas conscientização não estabelece controle técnico. Os compradores precisam de evidências de que as plataformas de agentes conseguem restringir ações após uma skill passar pela revisão. Prevenção e contenção devem operar juntas.

Quem Sofre Pressão com a Expansão do Risco

Plataformas de agentes, fornecedores de segurança e compradores empresariais agora compartilham a responsabilidade por uma dependência que nenhum deles pode governar sozinho.

Os operadores de marketplace enfrentam a pressão mais imediata. Eles precisam equilibrar o rápido crescimento da comunidade com a verificação de publicadores, a revisão de artefatos, os controles de atualização e a resposta a incidentes. Mais atrito nas submissões pode desacelerar o crescimento, mas controles fracos prejudicam a confiança.

Os desenvolvedores de plataformas de agentes controlam o ambiente de execução. Eles decidem se as skills são executadas com permissões do host, dentro de contêineres ou por meio de ferramentas restritas. A arquitetura deles determina até onde uma instrução maliciosa pode chegar.

Os fornecedores de segurança enfrentam um teste diferente. Eles precisam identificar comportamentos nocivos expressos por código, linguagem natural, sites mutáveis e ferramentas administrativas legítimas. Os sinais existentes de endpoint e rede continuam valiosos, mas o contexto semântico se torna essencial.

As equipes de segurança corporativa não podem terceirizar todo o problema. Elas escolhem quais plataformas entram na organização e quais conexões essas plataformas recebem. Também determinam se os funcionários podem instalar skills da comunidade sem revisão.

Os desenvolvedores continuam sendo um grupo de alto risco porque agentes de programação frequentemente possuem acesso ao shell e a repositórios. Uma skill maliciosa poderia atacar código-fonte, credenciais de pacotes, chaves de assinatura, tokens de nuvem ou configurações de implantação.

Usuários não técnicos apresentam uma exposição diferente. Uma skill de marketing ou vendas pode acessar e-mail, registros de clientes, ativos de marca, anotações de reuniões e sistemas de conteúdo. Sua interface amigável pode ocultar a autoridade do agente subjacente.

As equipes de compras, portanto, precisam de perguntas que vão além da precisão do modelo. Elas devem perguntar como a plataforma descobre skills instaladas, registra versões, lida com instruções externas e separa ambientes de usuários.

Elas também precisam entender a revogação. Os administradores conseguem desativar uma skill em todos os endpoints? Conseguem identificar quais credenciais estavam disponíveis durante seu período de instalação?

As equipes de compliance se importarão com evidências. Se um agente transmitir informações de clientes por meio de uma skill não aprovada, a organização deverá reconstruir o que aconteceu. Uma transcrição genérica de chatbot pode não explicar cada chamada posterior de ferramenta.

Os responsáveis pela resposta a incidentes enfrentam exigências semelhantes. Eles precisam de logs imutáveis e de uma linha do tempo confiável. Também precisam saber se uma skill removida criou persistência em outro lugar, como um processo agendado ou uma configuração alterada.

As descobertas da Unit 42 ilustram essa questão. Pesquisadores observaram mecanismos de persistência associados à atividade maliciosa no marketplace. Remover a listagem visível não neutralizou automaticamente todas as cargas implantadas ou canais de comando.

As empresas devem tratar as credenciais de agentes como potencialmente expostas após uma instalação maliciosa confirmada. Isso significa revogar tokens relevantes, revisar a atividade de autenticação, verificar arquivos modificados e examinar conexões de saída.

O risco não está distribuído de maneira uniforme entre todas as implantações. Um agente de pesquisa isolado com dados sintéticos cria consequências limitadas. Um agente autônomo conectado a sistemas de produção cria um problema de controle muito maior.

Essa distinção deve orientar a política. As organizações podem classificar agentes e skills de acordo com os dados acessíveis, as ferramentas disponíveis, a autonomia, o alcance de rede e o impacto nos negócios. Combinações de maior risco recebem revisão e monitoramento mais rigorosos.

A pressão também alcança os programas de governança de IA. Muitos programas se concentram na seleção de modelos, nos termos de privacidade, na precisão das saídas e no uso aceitável. Skills de IA maliciosas introduzem dependências operacionais que se assemelham mais à segurança de aplicações do que à governança de modelos.

Os comitês de governança precisam de propriedade técnica, não apenas de princípios escritos. Alguém deve aprovar fontes de skills, manter o inventário, definir limites de permissão e responder quando uma dependência confiável muda.

A abordagem vencedora não dependerá de um único departamento. A engenharia de plataforma pode impor controles de implantação. A segurança pode monitorar o comportamento, enquanto os responsáveis de negócio definem tarefas aceitáveis e acesso a dados.

Sem essa coordenação, as organizações criarão dois caminhos insatisfatórios. Agentes aprovados permanecerão restritos demais para ajudar, enquanto os funcionários instalarão alternativas menos controladas. Ambos os resultados enfraquecem a supervisão empresarial.

Três Sinais Mostrarão se as Defesas Estão se Atualizando

A próxima fase será medida por meio de controles de marketplace, evidências empresariais de runtime e testes independentes de detecção.

O primeiro sinal é se os principais registros de skills adotam procedência verificável e versionamento imutável. Um marketplace deve identificar o publicador, preservar artefatos revisados e expor todas as alterações. As instruções externas também precisam de controles de inventário e integridade.

Se os registros implementarem essas medidas de forma ampla, os invasores enfrentarão mais atrito ao substituir conteúdo confiável. Isso fortaleceria a tese de que ecossistemas abertos de skills podem amadurecer sem abandonar contribuições da comunidade.

Se os registros continuarem dependendo de popularidade e varredura única, a avaliação de risco atual se tornará mais forte. Mais cargas adiadas e sequestros de dependências devem ser esperados à medida que skills valiosas acumulam usuários.

O segundo sinal é se as plataformas de agentes empresariais oferecem permissões aplicáveis no nível de habilidade. Os administradores precisam de limites para arquivos, ferramentas, credenciais, comandos e destinos de rede. Esses limites devem acompanhar a habilidade em cada implantação.

Rastros claros de execução são igualmente importantes. Um analista de segurança deve conseguir vincular uma ação à habilidade e às instruções externas que a causaram. Os registros devem resistir a adulterações locais e permitir pesquisas em toda a organização.

Se as plataformas fornecerem esses controles, uma habilidade maliciosa se tornará mais fácil de conter. Ela ainda poderá entrar no ambiente, mas sua capacidade de alcançar ativos não relacionados será reduzida. Isso enfraqueceria os cenários empresariais mais graves.

Se as plataformas expuserem cada habilidade à autoridade total do agente, o risco continuará concentrado no endpoint. Uma extensão negligenciada pode herdar acesso a muitos sistemas não relacionados.

O terceiro sinal é a realização de testes independentes contra ataques mutáveis e retardados. As avaliações de scanners devem incluir mudanças em instruções externas, redirecionamentos de domínios confiáveis, cargas maliciosas dormentes, tomadas de controle de repositórios e ferramentas legítimas usadas em sequências inseguras.

O experimento com 26.000 agentes forneceu um desses testes. As avaliações futuras precisam de métodos reproduzíveis, amostras transparentes e divulgações que diferenciem comportamento suspeito de malware confirmado.

Uma detecção consistente entre ferramentas independentes sugeriria que o mercado está desenvolvendo bases comuns de segurança. Grandes divergências mostrariam que os fornecedores ainda definem o comportamento malicioso de formas diferentes.

As organizações não devem esperar por padrões perfeitos. Elas podem começar inventariando as habilidades instaladas e associando cada uma a um responsável, origem, versão, permissões e dependências externas.

Elas podem isolar agentes com alta autoridade, limitar o acesso à rede e exigir aprovação para ações sensíveis. Também podem reexaminar as habilidades quando as dependências mudarem, e não apenas quando os usuários as instalarem pela primeira vez.

As equipes devem tratar habilidades removidas ou recém-sinalizadas como gatilhos de incidente. A resposta deve examinar credenciais, persistência, acesso a dados e comunicação de saída. Excluir a habilidade local é apenas o primeiro passo.

A atenção do Google News em torno de habilidades maliciosas de IA deve levar a uma pergunta prática: sua organização consegue explicar o que cada agente empresarial está autorizado a fazer? Se a resposta for incompleta, comece pelos agentes conectados a código, sistemas de nuvem, dados de clientes e comunicações internas. Mapeie suas habilidades, restrinja autoridades desnecessárias e preserve as evidências necessárias para investigar suas ações. A segurança de agentes de IA não dependerá de encontrar um único scanner perfeito. Ela dependerá da combinação de distribuição confiável, permissões limitadas, observação contínua e revogação rápida antes que uma extensão aparentemente útil se transforme em um incidente empresarial.