Ratgeber · KI-Agenten · · von Stefan Tsezarov
Gib deinem Agenten eine zweite Meinung, bevor er handelt
Du bittest deinen Coding-Agenten, einen Build zu reparieren. Er liest das README, sieht sich einen Issue-Thread an und findet einen Vorschlag:
Eine plausible Lösung. Eine kleine Änderung. Der Agent bereitet den Installationsbefehl vor.
Aber der fehlende Bindestrich ist wichtig. crossenv war ein echtes bösartiges Paket, 2017 aus npm entfernt, nachdem es beim Stehlen von Umgebungsvariablen erwischt wurde — dort, wo Entwickler oft Schlüssel und Tokens ablegen.
Der Austausch oben ist ein Beispiel. Das Paket war echt.
01Wenn ein Vorschlag zum Befehl wird
Coding-Agenten lesen viel Text, den du vielleicht nie siehst: Dokumentation, Issue-Kommentare, Webseiten und Fehlermeldungen. Dieser Kontext hilft ihnen beim Lösen von Problemen. Er kann sie aber auch zu einer schlechten Abhängigkeit lenken.
Ein Paket zu installieren verdient besondere Sorgfalt. npm-Pakete können Skripte enthalten, die bei der Installation laufen, sodass Code ausgeführt werden kann, bevor du ihn prüfen konntest.
Der Vor-Installations-Wächter von SaveSaveSaveSave fügt an dieser Stelle eine Prüfung hinzu. Bevor ein unterstützter Installationsbefehl läuft, schlägt er das Paket nach und wendet eine Richtlinie an, die du gewählt hast.
02Was passiert mit einer Installation?
Sieh dir drei Befehle an, die ein Agent vorschlagen könnte.
Ein Registry-Paket ohne Auffälligkeiten
npm install cross-env
Der Wächter lässt den Befehl weiterlaufen. Deine übliche Bestätigungsabfrage gilt weiterhin. Das heißt, die Prüfungen fanden keinen Einwand; es ist keine Garantie, dass das Paket sicher ist.
Ein als bösartig gemeldetes Paket
cd app && npm install --save-dev crossenv
Der Wächter verweigert den Befehl und sagt dem Agenten, warum. Er erkennt die Installation auch, wenn sie auf einen anderen Befehl folgt.
Code direkt von GitHub
npx github:someone/setup-script
Im Standardmodus bittet der Wächter um eine Prüfung durch einen Menschen. Eine Git-URL liegt außerhalb seiner Prüfungen der npm-Registry, er kann also nicht dieselbe Einschätzung liefern.
Unterstützt werden Installationen über npm, pnpm, yarn und bun sowie npx, npm ci, Befehlsketten mit && und Befehle in bash -c "…".
03Du wählst die Regeln
Die Prüfung liefert Belege: was sie geprüft hat, was sie gefunden hat und was sie nicht beurteilen konnte. Eine Richtlinie auf deinem Rechner entscheidet, was dann passiert.
Wähle einen von drei Modi:
| Modus | Als bösartig gemeldet | Vorsicht oder unzureichende Daten | Prüfung schlägt fehl oder Quelle liegt außerhalb der Registry |
|---|---|---|---|
| observe | Erlauben und melden | Erlauben | Erlauben |
| guard · Standard | Verweigern | Einen Menschen fragen | Einen Menschen fragen |
| strict | Verweigern | Verweigern | Verweigern |
Nutze observe, um zu sehen, wie sich der Wächter in deinem Arbeitsablauf verhält. Wähle guard, um bekannte bösartige Pakete zu blockieren und unklare Fälle zu prüfen. Wähle strict, wenn ein nicht eindeutiges Ergebnis die Installation stoppen soll.
Ein sauberes Ergebnis hebt nie eine Bestätigung auf, die dein Agent sonst bräuchte.
04In deinen Arbeitsablauf einbauen
Für Claude Code füge diesen Hook in die .claude/settings.json deines Projekts ein. Wenn die Datei schon Einstellungen enthält, führe den Hook mit ihnen zusammen.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "npx -y savesavesavesave@0.1.5 hook claude-code --mode observe"
}
]
}
]
}
}
Der Hook prüft vorgeschlagene Bash-Befehle. Befehle ohne erkannte Installation laufen durch.
Für einen anderen Agenten oder ein Skript setze den Wächter vor den Installationsbefehl:
npx savesavesavesave@0.1.5 guard --mode guard -- npm install some-package
Seine Exit-Codes sagen deiner Integration, wie es weitergeht:
0: erlauben1: Prüfung durch einen Menschen anfordern2: verweigern
Deine Integration muss diese Ergebnisse beachten.
Agenten mit MCP-Unterstützung können Prüfungen auch direkt anfordern. Anleitungen zur Einrichtung stehen auf der Seite Für Agenten.
Es braucht kein Konto und keinen API-Schlüssel. Die Beispiele legen eine Version fest, damit du eine bestimmte Version prüfen kannst, bevor du sie nutzt.
05Wisse, was die Prüfung abdeckt
Der Wächter liest Informationen, die die npm-Registry und OSV.dev veröffentlichen. Er lädt das Paket nicht herunter und führt es nicht aus, und er deckt derzeit npm-Pakete ab, keine Ökosysteme wie PyPI oder crates.io.
Daraus ergeben sich ein paar praktische Grenzen:
- Er prüft unterstützte Befehle, die er erhält. Installationen in Skriptdateien, nicht unterstützte Paketmanager oder heruntergeladene Binärdateien können außerhalb seines Blickfelds liegen. Strengere Einschränkungen brauchen Kontrollen über den Netzwerk- und Dateisystemzugriff des Agenten.
- Eine noch nicht gemeldete Bedrohung kann durchkommen. „Kein Einwand“ heißt, dass die verfügbaren Prüfungen kein bekanntes Risiko fanden.
- Der Hook muss laufen, damit die Richtlinie wirkt. Wenn du den strict-Modus nutzt, folge den Anweisungen im README des Pakets (Englisch), um Befehle zu blockieren, wenn der Hook selbst nicht startet.
Ein Coding-Agent kann einen Build schnell reparieren. Er kann aber auch schnell auf einen überzeugenden Vorschlag von jemandem reagieren, den du nicht kennst.
Bevor dieser Vorschlag Zugriff auf deinen Rechner bekommt, gib ihm eine zweite Meinung.
Dein nächster Schritt: Füge den Hook im observe-Modus hinzu, sieh dir seine Ergebnisse an und wähle die Richtlinie, die zu deinem Arbeitsablauf passt.