Halluzinierte und verwechselbare Paketnamen: eine Abhängigkeit prüfen, bevor ein Agent sie installiert

Ziel

Verhindern, dass ein Agent ein Paket installiert, dessen Namen er aus dem Gedächtnis erzeugt hat, ohne zu bestätigen, dass der Name zu dem gemeinten Projekt gehört.

Voraussetzungen

Registry-Zugriff (PyPI, npm oder eine andere) aus einer Sandbox; die Möglichkeit, vor der Installation innezuhalten und nachzufragen.

Schritte

1. Jeden vom Modell vorgeschlagenen Paketnamen als Behauptung behandeln. Das Paper „We Have a Package for You!" (Spracklen et al.) untersuchte Paket-Halluzination in von LLMs generiertem Code und stellte fest, dass Modelle Pakete empfehlen, die nicht existieren; eine angreifende Partei, die einen solchen Namen registriert, erhält die Installationen.
2. Den Namen vor der Installation gegen die Registry auflösen. Existiert er nicht, nicht nach „der nächsten Übereinstimmung" suchen — stattdessen zur Dokumentation der tatsächlich benötigten Bibliothek zurückkehren.
3. Existiert er, die Identität bestätigen: Die eigene Dokumentation oder das Repository des Projekts nennt genau dieses Paket; der Repository-Link in den Registry-Metadaten verweist zurück auf dieses Projekt.
4. Auf Anzeichen für ein gesquattetes oder verwechselbares Paket prüfen: sehr aktueller Erstveröffentlichungstermin, nur eine einzige Veröffentlichung, sehr wenige Downloads im Vergleich zu dem Namen, dem es ähnelt, ein Name, der eine Bearbeitung von einem populären Paket entfernt ist, eine von einem anderen Projekt kopierte Beschreibung.
5. Prüfen, was bei der Installation ausgeführt wird. npm startet Lifecycle-Skripte wie preinstall und postinstall während npm install; die Installation mit --ignore-scripts (npms Einstellung ignore-scripts dafür) verhindert das, auf Kosten von Paketen, die tatsächlich einen Build-Schritt benötigen und dadurch beschädigt werden. Für Python Wheels bevorzugen (--only-binary), damit kein Build-Code ausgeführt wird.
6. Die bestätigte Version und den Hash in der Lock-Datei festschreiben, damit spätere Läufe nicht zu einem anderen Artefakt abdriften können.
7. Das Prüfergebnis mit Paket, Version und Identitätsnachweis in der Änderungsbeschreibung festhalten.

Erwartetes Ergebnis

Kein Paket gelangt allein aufgrund eines vom Modell erzeugten Namens in ein Projekt; Verwechslungen werden erkannt, bevor deren Installationsskripte laufen.

Grenzen und Prüfbasis

Ein legitimes Paket kann über das Konto seines eigenen Maintainers kompromittiert werden; Identitätsprüfungen erkennen das nicht. Download-Zahlen können künstlich erhöht sein. Die im Paper genannten Raten hängen von den dort getesteten Modellen und Prompts ab und werden hier nicht wiedergegeben.