O marketplace de skills do seu agente é uma cadeia de malware

Novecentas skills maliciosas. Aproximadamente uma em cada cinco no marketplace de onde os agentes as instalam. Um typosquat, disfarçado de dependência popular, chegou a 8 mil downloads antes de ser detectado. Vinha num zip protegido por senha; ao descompactar, um blob em base64 decodificava para um script bash que rodava com os privilégios que o agente tinha.

Esse é o estado atual do marketplace de skills de agentes, segundo um resumo do O’Reilly Radar que cita um alerta da Bitdefender. O padrão importa mais que qualquer produto nomeado: um canal de distribuição pensado para conveniência virou canal de distribuição de malware, e a maioria dos times que roda agentes em produção ainda mantém controles desatualizados para essa realidade.

Skill é dependência com um problema extra de confiança

Um pacote de skill parece uma coisa pequena e útil: um conjunto de instruções e código que o agente instala para executar bem uma tarefa. Times adicionam skills como desenvolvedores adicionam pacotes npm, buscando um nome, lendo a descrição por cima e instalando. Poucos leem o código. Menos ainda verificam o que ele faz em tempo de execução.

Esse hábito já era arriscado para registros de pacotes convencionais. Para skills de agente é pior, porque a skill não fica parada no disco esperando ser importada. Ela entra no contexto do modelo e, com frequência, executa com as próprias credenciais do agente: acesso a arquivos, chaves de API, conexões com banco de dados. Uma skill maliciosa não precisa de um exploit sofisticado de cadeia de suprimentos. Precisa de um nome plausível, uma demonstração funcional e uma carga que só dispara depois que a confiança já foi estabelecida.

O typosquat de 8 mil downloads seguiu exatamente esse roteiro. Um nome de dependência falso, parecido o suficiente com o real para passar numa olhada rápida. Um zip protegido por senha, o que já é um sinal (skills legítimas normalmente deixam o conteúdo visível para scanners estáticos). Dentro, uma string em base64 que decodificava para um comando bash. Nada nessa cadeia exigiu técnica inédita. Exigiu um agente e um humano que confiaram na listagem do marketplace mais do que deveriam.

O problema de exposição agrava o quadro

O risco do marketplace não existe isolado. O mesmo resumo aponta milhares de instâncias de agentes visíveis na internet pública, expostas por um gateway configurado para escutar na interface errada. Um agente que deveria ser acessível apenas pela rede interna estava acessível de qualquer lugar.

Juntando as duas descobertas, o quadro fica mais claro. Uma skill maliciosa dá a um atacante execução de código dentro do contexto do agente. Um gateway mal configurado dá ao mesmo atacante uma porta de entrada pública para agentes que nunca deveriam estar alcançáveis. Nenhum dos dois problemas é exótico. Ambos são o tipo de detalhe operacional que fica de lado quando um time corre para lançar uma funcionalidade de agente.

Por que transcrições não são prova de segurança

O instinto, quando alguém pergunta “o agente fez algo que não devia?”, é abrir a transcrição da conversa e ler. Esse instinto está errado, e errado de uma forma específica que importa para o risco de marketplace.

Um modelo pode alucinar conformidade. Pode resumir suas próprias ações de forma imprecisa, omitir um passo ou descrever um resultado que não corresponde ao que de fato foi executado. Transcrições registram apenas o que o modelo disse que fez, filtrado pelo próprio relato dele; o registro do que a camada de execução realmente rodou fica em outro lugar.

A correção é sem glamour: logs de negação escritos na camada de execução, abaixo do modelo, onde uma chamada de ferramenta foi permitida ou não, sem narração do modelo no meio. Se uma skill tenta abrir uma conexão de rede fora do escopo concedido, ou ler uma credencial fora do escopo declarado, o log de negação registra a tentativa independente do que a transcrição diz que aconteceu, seguindo o mesmo princípio que sempre valeu para firewalls e políticas de IAM. Aplicar esse princípio de forma consistente à execução de skills de agente ainda é exceção, e esse é o ponto que os números do marketplace expõem.

Allow-list vale mais que confiança por padrão

O segundo controle é mais concreto: allow-listing no estilo toolsDeny e skillsAllowed, em que o agente só pode chamar skills que um humano vetou e aprovou explicitamente, em vez de qualquer skill disponível no marketplace. Isso inverte o padrão atual. A maioria das configurações de agente hoje começa permissiva (qualquer skill publicada é instalável) e depende de o time notar algo errado depois do fato. Allow-listing começa restritivo e exige um ato deliberado para adicionar qualquer coisa.

É uma recomendação para tratar a instalação de skill como uma organização de engenharia madura trata uma dependência nova: versão fixada, uma etapa de revisão, e um registro de quem aprovou o quê. O número de 20% de pacotes maliciosos é motivo para parar de tratar “está no marketplace” como substituto de revisão.

Determinístico primeiro, agente depois, humano por último

Para qualquer saída que toque dado regulado, dinheiro ou decisão voltada ao cliente, a ordem importa tanto quanto os controles. Código determinístico deve cuidar das partes do trabalho que têm uma única resposta correta: validação, cálculo, formatação, qualquer coisa com especificação testável. O trabalho do agente é lidar com as partes que exigem julgamento ou linguagem, e sua saída deve ser verificada, não presumida correta, antes de seguir adiante. Um humano aprova o resultado antes de ele ser publicado.

Essa sequência (determinístico, depois verificação, depois aprovação humana) é a resposta direta ao risco de marketplace. Mesmo uma skill comprometida que passe pelo allow-list e execute algo inesperado fica impedida de corromper silenciosamente uma saída regulada, porque tudo que o agente produz chega ao cliente ou ao livro-razão só depois de uma checagem independente do relato que o próprio agente faz de si mesmo.

O que fazer agora

Audite todas as skills que seus agentes têm acesso hoje com uma pergunta simples: quem revisou isso, e quando. Se a resposta for ninguém, remova da allow-list até que alguém revise. Ative o registro de negação na camada de execução antes de precisar dele, não depois que um incidente forçar a questão. E confirme que os gateways dos seus agentes estão vinculados à interface pretendida, e não à que por padrão fica aberta para a internet.

---

Fontes

• O’Reilly Radar. “Don’t Neglect the Operational Groundwork.” Julho de 2026.

A Victorino ajuda times a auditar as skills que seus agentes executam e a aplicar controles na camada de execução: contato@victorino.com.br | www.victorino.com.br