Nomes de pacotes alucinados ou parecidos: verificar uma dependência antes de o agente instalá-la

Objetivo

Impedir que um agente instale um pacote cujo nome ele produziu de memória sem confirmar que esse nome pertence ao projeto que ele tinha em mente.

Pré-requisitos

Acesso ao registro (PyPI, npm ou outro) a partir de um sandbox; capacidade de parar e pedir confirmação antes da instalação.

Passos

1. Trate todo nome de pacote sugerido pelo modelo como uma afirmação a ser verificada. O artigo "We Have a Package for You!" (Spracklen et al.) estudou a alucinação de pacotes em código gerado por LLMs e constatou que os modelos recomendam pacotes que não existem; um atacante que registre um desses nomes passa a receber as instalações.
2. Consulte o nome no registro antes de instalar. Se ele não existir, não procure "a correspondência mais próxima": volte à documentação da biblioteca de que você realmente precisa.
3. Se existir, confirme a identidade: a documentação ou o repositório do próprio projeto cita exatamente esse pacote, e o link do repositório nos metadados do registro aponta de volta para esse projeto.
4. Procure sinais de um pacote registrado por squatting ou parecido com outro: primeira versão muito recente, uma única versão publicada, número de downloads muito baixo em comparação com o nome que ele imita, nome a uma única edição de distância de um pacote popular, descrição copiada de outro projeto.
5. Inspecione o que é executado durante a instalação. O npm executa scripts de ciclo de vida, como preinstall e postinstall, durante o npm install; instalar com --ignore-scripts (a configuração ignore-scripts do npm) impede isso, ao custo de quebrar pacotes que realmente precisam de uma etapa de build. Em Python, prefira wheels (--only-binary), para que nenhum código de build seja executado.
6. Fixe a versão e o hash confirmados no arquivo de lock, para que execuções posteriores não passem a usar outro artefato.
7. Relate o resultado da verificação na descrição da alteração, com o pacote, a versão e as evidências de identidade.

Resultado esperado

Nenhum pacote entra em um projeto apenas porque o modelo gerou o nome; pacotes parecidos são detectados antes de seus scripts de instalação serem executados.

Limites e base de verificação

Um pacote legítimo pode ser comprometido pela conta do próprio mantenedor; a verificação de identidade não detecta isso. As contagens de downloads podem ser infladas. As taxas do artigo dependem dos modelos e dos prompts testados e não são reproduzidas aqui.