Os modelos de código alucinam nomes de pacotes inexistentes de forma previsível (19,7% do código, e 43% dos nomes se repetem), o que permite a um atacante registrá-los antes com payload malicioso. A defesa: verificar que todo pacote sugerido pela IA exista e seja legítimo antes de instalá-lo.
Imagine que você pede a um assistente para trazer um parafuso de uma loja de ferragens, e em vez de admitir que não sabe qual, ele inventa o nome de uma marca que soa perfeitamente plausível: «Parafusos Kraften M8». Você, confiante, vai pedir. E acontece que alguém, antecipando-se exatamente a essa invenção, já abriu uma loja com esse nome e encheu a caixa com explosivos. Isso, transposto para o software, tem nome desde 2025: slopsquatting. Sua IA inventa uma biblioteca que não existe, e um atacante a registra antes de você para colocar código malicioso ali. É o vetor de ataque de cadeia de suprimentos mais elegante e silencioso que a era da programação assistida trouxe, e quase ninguém na sua equipe sabe que ele existe.
A alucinação deixou de ser uma piada e virou uma superfície de ataque
Durante anos tratamos as alucinações da IA como uma anedota engraçada: o modelo inventa uma citação, um dado, uma data. Chato, mas inofensivo. Com o código, a alucinação muda de natureza. Quando um modelo escreve `import requestz` em vez de `requests`, ou inventa um `pandas-utils-pro` que jamais existiu, ele não está soltando uma piada: está assinando um cheque que outro pode descontar. Porque, diferente de uma citação falsa, um nome de pacote é um endereço. E endereços podem ser ocupados. No dia em que a alucinação teve um endereço postal registrável no npm ou no PyPI, deixou de ser um erro de estilo para virar uma porta.
O dado duro: quase 1 em cada 5 trechos de código sugeria um pacote fantasma
Um estudo apresentado na USENIX Security 2025 mediu isso em escala industrial: 2,23 milhões de amostras de código geradas por 16 modelos diferentes. O resultado é o que você deveria ter colado no monitor: 19,7% das amostras incluía pelo menos um pacote alucinado — um que simplesmente não existe. E o viés por família de modelo é brutal: os modelos open-source inventaram pacotes 21,7% das vezes, contra 5,2% dos comerciais. Traduzindo: quase uma em cada cinco vezes que um modelo estende a mão com uma dependência, ele está estendendo uma que não existe. Multiplique isso pelos milhões de `pip install` e `npm install` que rodam por dia sob a fé cega do «se a IA escreveu, deve existir», e você tem a superfície de ataque.
O verdadeiramente perigoso não é que ele invente: é que ele invente SEMPRE A MESMA COISA
Se as alucinações fossem ruído aleatório, o ataque seria inviável: um atacante teria que registrar milhões de nomes ao acaso para acertar um. A descoberta que transforma isso num problema real é outra: 43% dos nomes alucinados reaparecem em todas as execuções. Não é ruído, é uma assinatura. O modelo, diante do mesmo prompt, tende a inventar o mesmo nome falso repetidas vezes. Isso é ouro para o atacante: basta observar o que o modelo inventa, ficar com os nomes que se repetem, registrá-los com um payload malicioso, e esperar. Ele não precisa hackear nada. Você montou a armadilha para ele, e o seu próprio agente a instala com as permissões do seu build. Seth Larson, da Python Software Foundation, batizou o padrão: slopsquatting — o primo do typosquatting, mas onde o erro não é do seu dedo, é do seu modelo.
Por que a programação por agentes multiplica o risco em vez de contê-lo
Um desenvolvedor humano que vê `import fastapi-turbo` numa sugestão costuma levantar uma sobrancelha: «isso existe?». Um agente autônomo não levanta sobrancelhas. Você disse «faça funcionar», ele tropeça num import que falha, e o reflexo treinado dele é resolver: executa o `install`, e se o pacote existe (porque o atacante o registrou), instala sem atrito e segue. O loop que torna a programação agêntica mágica — tentar, falhar, corrigir, seguir — é exatamente o que pula a única barreira que nos protegia: a dúvida humana. Quanto mais autônomo o agente, menos olhos entre a alucinação e o `install`. Autonomia sem verificação não é velocidade, é velocidade rumo ao precipício com os faróis apagados.
A lição: na era da IA, confiar num nome é uma decisão de segurança
O modelo mental que você pode levar e compartilhar é este: um nome de pacote sugerido por uma IA não é um fato, é uma hipótese. E toda hipótese que vai executar código com as permissões do seu build merece ser verificada antes, não depois. A ação concreta cabe numa frase: antes de instalar qualquer dependência que um modelo sugeriu, confirme que o pacote existe de verdade, que é o que você acha que é, e que não nasceu na semana passada com zero histórico. Um lockfile com hashes fixados, uma allowlist de dependências, e uma olhada de dois segundos em «este pacote tem anos e downloads ou apareceu na terça?» desativam por completo esse ataque. Não é preciso um firewall de IA: é preciso parar de tratar a saída do modelo como escritura sagrada. A mesma disciplina, aliás, que separa uma demo de um produto — disso falamos na matemática dos 27%.
Como nós enxergamos isso
Na NeuralOS partimos de um axioma incômodo: a IA é um colaborador brilhante e um mentiroso ocasional, e é preciso projetar para as duas coisas ao mesmo tempo. Por isso pensamos a segurança não como uma camada colada no fim, mas como o chão sobre o qual se constrói. Algumas peças desse chão já são tangíveis: os segredos são redigidos por valor em cada log, e as credenciais vivem num Vault criptografado por-tenant que nunca é exposto ao modelo. Outras são direção declarada, não promessa cumprida: nessa mesma linha criamos e demos de presente o Sentinel, um guardião de segurança de código aberto que caça o bug antes de ele chegar à produção. Nós não podemos evitar que um modelo alucine um nome — ninguém pode, é física do sistema. O que sim perseguimos, peça por peça e com honestidade sobre o que já existe e o que ainda é caminho, é erguer o fosso entre essa alucinação e o seu build: que a dúvida que um agente já não tem, a plataforma vá tendo por você. Porque na era de construir com IA sem ser programador, sua vantagem não é confiar mais rápido: é que a verificação não dependa só da sua boa-fé.