Pacotes inventados por IA: como evitar dependências falsas

Pacotes inventados por IA: como evitar dependências falsas

Sim, assistentes de IA às vezes sugerem pacotes que não existem, porque geram nomes que soam plausíveis sem consultar o registro oficial. O risco é que alguém registre esse nome com código malicioso, e a próxima pessoa que instalar a sugestão receba o ataque. A defesa exige disciplina, não ferramentas sofisticadas: nenhuma dependência sugerida por IA entra no projeto sem verificar existência, origem e necessidade real.

Principais pontos

• Modelos de linguagem produzem texto provável, não texto verificado. Um nome de pacote pode parecer correto e não existir.
• Se o nome não existe, qualquer pessoa pode criá-lo no registro público. Um atacante só precisa adivinhar quais nomes a IA costuma inventar.
• Pacotes podem executar código no momento da instalação, então o dano pode acontecer antes de qualquer teste.
• A verificação cabe em poucos minutos: confirmar existência, histórico, repositório, mantenedores e necessidade, e só então instalar.
• Regras de equipe (lockfile, revisão de mudanças em dependências, lista de pacotes aprovados) reduzem o risco mais do que confiar na atenção individual.

Por que a IA sugere pacotes que não existem?

Um modelo de linguagem completa padrões. Quando você pede uma integração com determinado serviço em Python ou JavaScript, ele combina o que aprendeu sobre convenções de nomes: prefixos comuns, sufixos como "client", "sdk" ou "utils", o nome da marca. O resultado costuma ser um nome coerente com o ecossistema, mas que nunca foi publicado.

Isso não é um defeito raro de um modelo específico. É consequência de como a geração funciona, e por isso vale tratar como comportamento esperado, não como acidente. A lista de riscos para aplicações com modelos de linguagem do OWASP inclui cadeia de suprimentos e confiança excessiva em saídas incorretas, e esse problema fica exatamente na interseção dos dois.

O mesmo vale para versões e funções. A IA pode indicar uma versão que nunca saiu ou um método que o pacote real não tem. O pacote existir não prova que a sugestão está certa, mas a ausência dele é o caso mais perigoso.

Como um nome inventado vira um ataque?

O mecanismo, em linhas gerais, tem quatro passos. Observação: o que segue descreve o mecanismo de forma geral, como hipótese de ameaça plausível, não como relato de um incidente específico.

• Alguém pergunta a modelos de IA como resolver tarefas comuns de programação e anota os nomes de pacotes que não existem nos registros públicos.
• Essa pessoa registra os nomes mais recorrentes no registro público (npm, PyPI e similares), muitas vezes com uma descrição convincente.
• O pacote contém código malicioso, que pode rodar durante a instalação ou ser importado depois pelo projeto.
• Um desenvolvedor, ou um agente de código que instala dependências sozinho, recebe a mesma sugestão da IA, roda o comando de instalação e traz o pacote para dentro da empresa.

O ponto crítico é que o nome passa a existir. A verificação mais óbvia, "o pacote existe?", deixa de ser suficiente. Antes do registro, o comando falharia com erro de pacote não encontrado e alertaria o usuário. Depois do registro, a instalação funciona e dá a impressão de que tudo certo.

Há dois primos desse problema que merecem ficar no radar. O primeiro é o typosquatting, que explora erros de digitação em nomes de pacotes reais. O segundo é a confusão de dependências, em que um nome interno da empresa também é publicado no registro público. Os controles abaixo ajudam nos três casos.

Quais sinais mostram que um pacote é suspeito?

Nenhum sinal isolado prova que um pacote é malicioso, e pacotes legítimos novos também existem. Mas a combinação de vários merece parar antes de instalar:

• Data de criação muito recente em relação à função que ele promete cumprir.
• Poucas versões publicadas, um único mantenedor e nenhum histórico visível de uso.
• Ausência de link para repositório de código ou link que aponta para um projeto sem relação com o pacote.
• Documentação genérica, copiada ou praticamente vazia.
• Nome quase igual ao de um pacote conhecido, com letra trocada ou sufixo extra.
• Scripts de instalação ou de pós-instalação sem explicação razoável para o que o pacote faz.
• Divergência entre o que a IA descreveu (funções, exemplos) e o que a documentação real mostra.

Para a equipe de negócio, a leitura prática é: quanto mais um pacote tem cara de recém-criado, vazio e sem origem rastreável, menos ele merece entrar em um sistema que toca dados de clientes.

Passo a passo para verificar uma dependência antes de instalar

Este roteiro serve para qualquer pessoa que desenvolve na empresa, inclusive quem usa IA para gerar código sem ser da área técnica. Ele não substitui uma análise de segurança formal, mas elimina a maior parte do risco de pacotes inventados.

• Pare antes de executar. Copie o nome do pacote da resposta da IA, mas não rode o comando de instalação ainda.
• Confirme no registro oficial. Busque o nome diretamente no site do registro (npm ou PyPI, por exemplo), não por um link que a IA tenha fornecido.
• Procure a origem na documentação do serviço. Se o pacote promete integrar uma ferramenta de terceiros, abra a documentação oficial dessa ferramenta e veja qual biblioteca ela recomenda. Se o nome da IA não aparece lá, desconfie.
• Olhe o histórico. Veja data de criação, número de versões, últimas atualizações, mantenedores e se o repositório de código está ligado e ativo.
• Leia o que roda na instalação. Verifique se há scripts de instalação ou pós-instalação e o que eles fazem. Se não entender, peça revisão a alguém de segurança ou desenvolvimento.
• Pergunte se precisa mesmo. Muitas vezes a função pode ser feita com a biblioteca padrão da linguagem ou com uma dependência que o projeto já usa.
• Instale em ambiente isolado. Use um contêiner ou uma máquina descartável, sem credenciais, antes de levar a dependência ao projeto principal.
• Registre a decisão. Fixe a versão no arquivo de bloqueio (lockfile), anote por que a dependência entrou e quem aprovou.

Se o pacote não passa em qualquer um desses passos, a resposta correta é não instalar e voltar à IA com uma pergunta melhor, por exemplo: "qual biblioteca oficial do fornecedor X faz isso, com link para a documentação?". Depois, confirme o link por conta própria.

Cenário ilustrativo: a integração que "já tinha biblioteca pronta"

Cenário ilustrativo: uma empresa de médio porte quer enviar dados de pedidos de um sistema interno para uma plataforma de pagamentos. Um analista, sem formação em segurança, pede a um assistente de IA o código de integração. A resposta traz um exemplo bem escrito, que começa instalando um pacote com o nome da plataforma seguido de "helper".

O analista roda o comando e a instalação funciona. O código parece rodar nos testes locais, e a equipe segue em frente. Meses depois, uma revisão de dependências percebe que o pacote não aparece na documentação oficial da plataforma, tem um único mantenedor e foi criado em data próxima à do primeiro uso na empresa.

O problema não foi falta de competência. Foi a ausência de uma regra simples: dependência nova exige verificação na fonte oficial e aprovação de outra pessoa. Com essa regra, o analista teria encontrado, na documentação da plataforma, a biblioteca realmente mantida pelo fornecedor e o pacote inventado nunca teria entrado.

Que regras a equipe deve adotar para não depender da atenção de cada pessoa?

Verificação manual funciona, mas cansa e falha em dia corrido. Regras de processo carregam parte do peso:

• Mantenha lockfile versionado e use instalação a partir dele em produção e em integração contínua, para que ninguém instale versões diferentes das aprovadas.
• Exija revisão em toda alteração de arquivos de dependências, como package.json, requirements ou equivalentes, com o mesmo cuidado dado a código novo.
• Mantenha uma lista curta de pacotes aprovados para tarefas recorrentes e consulte-a antes de pedir sugestões à IA.
• Use ferramentas de auditoria de dependências do próprio ecossistema para avisar sobre vulnerabilidades conhecidas. Elas ajudam, mas não detectam pacote malicioso novo e recém-publicado.
• Considere um espelho ou proxy interno de pacotes, quando a escala da equipe justificar, para controlar de onde as dependências vêm.
• Defina em política escrita o que pode ser feito com assistentes de IA no código da empresa. O artigo sobre política de uso de ChatGPT na empresa ajuda a organizar essa conversa.

O cuidado precisa ser maior quando um agente de código instala dependências por conta própria. Nesse caso, limite o que o agente pode executar, exija aprovação humana para comandos de instalação e rode-o em ambiente sem acesso a segredos. As permissões de ferramentas e de servidores conectados podem ser definidas por escopo, como mostra o guia para configurar MCP no Claude Code. Textos externos que o agente lê também podem tentar induzi-lo a instalar algo, tema tratado em prompt injection em agentes de IA.

Outro hábito útil é não tratar código gerado como código revisado. Testes ajudam, mas só se forem confiáveis, o que o texto sobre testes gerados por IA explora. Um teste que passa não prova que a dependência é legítima.

Como aplicar mapear, limitar, pilotar e transferir

O método que usamos em projetos de IA se encaixa bem neste risco, sem exigir nada especial. Primeiro, mapear: levantar onde a IA já escreve ou sugere código na empresa, quais registros de pacotes são usados e quem pode instalar dependências. Depois, limitar: definir lista de pacotes aprovados, revisão obrigatória em arquivos de dependências e ambiente isolado para testes.

Em seguida, pilotar: aplicar o roteiro de verificação em um projeto real, observar o que travou e ajustar. Por fim, transferir: entregar a regra documentada para a equipe, com responsável definido, e decidir se amplia, ajusta ou interrompe. O quadro de gestão de risco do NIST para IA oferece vocabulário útil para essa documentação, mesmo que a empresa não adote o quadro por completo.

Perguntas frequentes

A IA sempre inventa pacotes? Não. Em muitos casos ela sugere pacotes reais e populares, mas não há como saber de antemão quando vai errar. Por isso a verificação deve ser rotina, e não reação a uma suspeita.

Basta o pacote existir no registro para ser seguro? Não. Existir apenas mostra que alguém publicou o nome, e o próprio ataque descrito aqui depende disso. Confirme a origem na documentação do serviço, o histórico do pacote, o repositório e os scripts de instalação.

Um antivírus ou uma auditoria automática resolve? Ajuda, mas não basta. Ferramentas de auditoria costumam apontar vulnerabilidades já conhecidas e podem não reconhecer um pacote malicioso recém-publicado. Elas funcionam melhor combinadas com revisão humana e lockfile.

O que fazer se já instalamos um pacote que não conseguimos verificar? Trate como incidente potencial. Remova a dependência, revise o que foi executado naquele ambiente, troque credenciais que estiveram expostas e consulte quem cuida da segurança. Se houver dados pessoais envolvidos, avalie com o encarregado de dados as obrigações da LGPD e as orientações da ANPD.

Fontes

• OWASP: Top 10 for LLM Applications
• NIST: AI Risk Management Framework
• ANPD: Autoridade Nacional de Proteção de Dados