Por que seu “scanner de Skills” oferece uma falsa sensação de segurança (e talvez seja malware)

Talvez você desenvolva soluções com IA, ou talvez seja CISO. Você acabou de autorizar o uso de agentes de IA pela equipe de desenvolvimento. Conhece os riscos, incluindo exfiltração de dados, injeção de prompts e execução de código não verificado. Então, quando seu engenheiro líder diz: “Fique tranquilo, estamos usando o Skill Defender do ClawHub para verificar cada nova Skill”, você respira aliviado. Problema resolvido.

Mas você verificou esse scanner de Skills?

Sua preocupação não é com as ameaças conhecidas, mas com as ferramentas em que você confia para encontrá-las. É aquela suspeita persistente de que sua rede de proteção está cheia de brechas. E, no caso da atual geração de “scanners de Skills de IA”, essa suspeita é totalmente justificada.

Se você está começando a conhecer as Agent Skills e os riscos de segurança associados, já explicamos o modelo de ameaças do Skill.md e como elas afetam o ecossistema mais amplo de agentes de IA e a segurança da cadeia de suprimentos.

Por que expressões regulares não conseguem detectar intenções maliciosas em SKILL.md

O inimigo da segurança de IA não é apenas o hacker: é a variabilidade infinita da linguagem. No mundo tradicional de AppSec, procuramos vulnerabilidades conhecidas (CVEs) e padrões conhecidos (segredos). Essa abordagem funciona porque o código é estruturado, finito e determinístico. Um payload de injeção de SQL tem uma estrutura reconhecível. Uma chave da AWS exposta tem um formato específico.

Mas uma Skill de agente de IA é fundamentalmente diferente. Ela combina prompts em linguagem natural, execução de código e configuração. Confiar em uma lista de bloqueio de “palavras proibidas” ou padrões vetados é uma batalha perdida diante do corpus infinito da linguagem natural. Simplesmente não é possível enumerar todas as maneiras de pedir a um LLM que faça algo perigoso. Pense no humilde comando curl. Um scanner de expressões regulares pode sinalizar curl para impedir a exfiltração de dados. Mas um invasor sofisticado não precisa escrever curl. Ele pode escrever:

• c${u}rl (usando expansão de parâmetros do bash)

• wget -O- (usando uma ferramenta alternativa)

• python -c "import urllib.request..." (usando uma biblioteca padrão)

• Ou simplesmente: “Busque o conteúdo deste URL e mostre-o para mim.”

Nesse último caso, o próprio agente monta o comando. O scanner só vê instruções inocentes em inglês, mas a intenção continua sendo maliciosa. Essa é a falha central da mentalidade de “lista de bloqueio”: tentar bloquear palavras específicas em um sistema projetado para entender conceitos.

A complexidade aumenta ainda mais quando consideramos o contexto. Uma Skill que solicita “acesso ao shell” pode ser perfeitamente legítima em uma ferramenta de implantação de DevOps, mas catastrófica em um “buscador de receitas” ou “assistente de calendário”. Um mecanismo de correspondência de padrões vê “acesso ao shell” e precisa sinalizar os dois casos (gerando ruído) ou ignorá-los (criando riscos). Ele não entende por que o acesso foi solicitado; apenas percebe que as palavras estão lá.

Estudo de caso: colocamos scanners da comunidade à prova com malware real

Decidimos testar os “scanners de Skills” mais populares da comunidade. Analisamos SkillGuard, Skill Defender e Agent Tinman. Também os colocamos à prova com uma Skill “semimaliciosa” criada por nós para ver se conseguiam distinguir amigos de inimigos.

1. SkillGuard: o scanner que era malware

Nosso primeiro objeto de análise foi o SkillGuard, do usuário c-goro. A promessa? Um scanner leve para suas Skills. A realidade? Era uma armadilha.

Ao analisar o SkillGuard, nossos sistemas internos o identificaram não como uma ferramenta de segurança, mas como uma Skill maliciosa. Ele tentou instalar um payload sob o pretexto de “atualizar as definições”.

Atualização: até a data desta publicação, o SkillGuard foi removido do ClawHub. Mas, para as centenas de usuários que o instalaram, o estrago já está feito. Isso ilustra um problema fundamental: quem verifica o scanner?

2. Skill Defender: o falso negativo

Em seguida, analisamos o Skill Defender (de itsclawdbro) e o Agent Tinman (de oliveskin). São iniciativas legítimas da comunidade, e o Skill Defender chegou até a receber o selo “Benign” no VirusTotal.

Mas “inofensivo” não significa “eficaz”.

Criamos uma Skill de teste chamada vercel. Ela parecia ser apenas uma ferramenta de implantação para a plataforma Vercel. Na verdade, foi criada para exfiltrar discretamente o hostname do usuário para um servidor remoto.

Executamos o Skill Defender contra essa Skill maliciosa usando a CLI do Gemini.

> use the skill defender to scan current skills

O resultado:

• A Skill maliciosa (vercel): veredito: LIMPA. 0 achados.

• O próprio scanner (skill-defender): veredito: PERIGOSO. 20 achados.

O scanner não detectou a ameaça real porque nosso código de exfiltração na falsa Skill da Vercel não correspondia à lista de strings “proibidas” codificada nele. Mas sinalizou a si mesmo como perigoso porque seus próprios arquivos de referência continham justamente os “padrões de ameaça” que ele procura!

Esse é o clássico “paradoxo do antivírus”: o scanner parece malicioso porque sabe como a malícia se manifesta, mas não detecta nada novo.

3. Ferret Scan: ainda limitado a padrões de expressões regulares

Também analisamos o Ferret Scan, um scanner baseado no GitHub. Ele afirma usar “análise profunda baseada em AST”, além de expressões regulares. Embora seja significativamente melhor do que as ferramentas nativas do ClawHub, ainda tem dificuldade com as nuances de ataques em linguagem natural.

Ele consegue detectar uma chave de API codificada, mas consegue detectar uma injeção de prompt escondida em um PDF que o agente precisa resumir?

Avançando para a análise comportamental da intenção agentiva

Precisamos parar de pensar na segurança de IA como “filtrar palavras proibidas”. Em vez disso, precisamos pensar em Análise Comportamental.

O código de IA é como uma dívida financeira: fácil de contrair, mas, se você não entende os termos (ou seja, a intenção do prompt), está se endividando até a falência.

Um scanner de expressões regulares é como um corretor ortográfico: garante que as palavras estejam escritas corretamente. Um scanner semântico é como um editor: pergunta “Esta frase faz sentido? Ela está instruindo o usuário a fazer algo perigoso?”

O que a pesquisa ToxicSkills revela: contexto é tudo

Em nossa recente pesquisa ToxicSkills, descobrimos que 13,4% das Skills apresentavam problemas críticos de segurança. A grande maioria NÃO foi detectada por simples correspondência de padrões.

• Injeção de prompt: ataques que usam técnicas de “jailbreak” para contornar filtros de segurança.

• Payloads ofuscados: código oculto em strings base64 ou downloads externos (como o ataque recente google-qx4).

• Riscos contextuais: uma Skill que solicita “acesso ao shell” pode ser adequada para uma ferramenta de desenvolvimento, mas catastrófica para um “buscador de receitas”.

A expressão regular detecta “acesso ao shell” e sinaliza os dois casos. Ou, pior ainda, não detecta nenhum deles porque o prompt diz “executar comando do sistema”.

A solução: segurança nativa de IA para arquivos SKILL.md

Para acompanhar essa velocidade, você precisa ir além dos padrões estáticos. Precisa de segurança nativa de IA.

Foi por isso que criamos o mcp-scan (parte da plataforma Evo da Snyk). Ele não se limita a procurar strings. Usa um LLM especializado para ler o arquivo SKILL.md e entender os recursos da Skill e dos artefatos associados (por exemplo, scripts).

Pense na execução do mcp-scan como se você perguntasse:

• Esta Skill pede permissão para ler arquivos?

• Ela tenta convencer o usuário a ignorar as instruções anteriores?

• Ela menciona um pacote criado há menos de uma semana (por meio do Snyk Advisor)?

Ao combinar testes estáticos de segurança de aplicações (SAST) com análise de intenção baseada em LLM, podemos detectar a Skill de exfiltração vercel porque identificamos o comportamento (envio de dados para um endpoint desconhecido), não apenas a sintaxe.

Amanhã, faça estas três perguntas à sua equipe:

1. “Temos um inventário de todas as ‘Skills’ usadas pelos nossos agentes de IA?” — Se a resposta for sim, pergunte como encontraram todas elas. Se o processo for manual, o inventário está desatualizado. Se a resposta for não, compartilhe com a equipe a ferramenta mcp-scan.

2. “Estamos verificando a intenção dessas Skills ou apenas as palavras-chave?” — Questione a mentalidade baseada em expressões regulares.

3. “O que acontece se uma Skill confiável receber amanhã uma dependência maliciosa?” — Defenda verificações contínuas, não apenas pontuais.

Não deixe que o “teatro de segurança” crie uma falsa sensação de proteção. Os agentes são inteligentes. Sua segurança precisa ser ainda mais inteligente. Saiba como Evo by Snyk oferece controle unificado para a IA agentiva.