Sicherheit von KI-Agenten-Konfigurationen ist Lieferkettensicherheit

Am 29. April 2026 meldeten Sicherheitsteams kompromittierte Pakete im SAP-Ökosystem, bei denen es nicht bei Zugangsdiebstahl blieb. Die Mini-Shai-Hulud-Kampagne verankerte außerdem Persistenz in Entwicklerkonfigurationen: Claude Code-Hooks, VS Code-Aufgaben und Repository-Ablaufdateien.¹²³

Dieses Detail verschiebt die Prüfgrenze. Ein vergiftetes Paket muss nicht installiert bleiben, wenn es einen Startbefehl in einer Datei hinterlassen kann, der Entwickler vertrauen. Das Entfernen der Abhängigkeit beseitigt möglicherweise den ersten Auslöser. Die Agenten- oder Editor-Konfiguration kann den nächsten Auslöser am Leben halten.

KI-Agenten-Konfiguration ist ausführbare Software. Behandeln Sie jeden Hook, jede Aufgabe, jede MCP-Serverdefinition, jede Agentenfähigkeit, jedes Plugin, jedes Paketskript und jede Ablaufdatei als Teil der Softwarelieferkette, weil diese Dateien bestimmen können, welcher Code ausgeführt wird, bevor ein Mensch den Diff gelesen hat.

Kurzfassung

Mini Shai-Hulud zeigte einen praktikablen Weg von der Installation einer Abhängigkeit zur Persistenz in Entwicklerwerkzeugen. Sicherheitsforscher berichteten von bösartigen npm-Paketen, die während der Installation Lifecycle-Skripte nutzten, Entwickler- und CI-Zugangsdaten abgriffen und .claude/settings.json- sowie .vscode/tasks.json-Dateien schrieben, um Code später erneut über vertrauenswürdige Entwickleroberflächen auszuführen.¹²⁴ Die offiziellen Dokumentationen bestätigen, dass diese Flächen echte Ausführungsbefugnisse haben: Claude Code-Hooks führen Lifecycle-Befehle aus, Command-Hooks laufen mit den Berechtigungen des Benutzers, und VS Code-Aufgaben mit folderOpen können beim Öffnen eines Ordners starten, nachdem der Benutzer automatische Aufgaben für diesen Ordner erlaubt hat.⁵⁶

Die Lehre lautet nicht: „Schalten Sie Agenten ab.“ Sie ist präziser: Agentenkonfiguration gehört in die Abhängigkeitsprüfung, Codeprüfung, Vorfallreaktion und Freigabegrenzen. Punktverzeichnisse, die früher wie lokale Präferenzen wirkten, liegen nun auf dem Ausführungspfad. Eine ernsthafte KI-Engineering-Praxis braucht Konfigurations-Diffs, Hook-Prüfungen, Aufgabenprüfungen, Tokens mit minimalen Rechten und Audits der Startflächen.

Zentrale Erkenntnisse

Für Entwickler: - Prüfen Sie .claude/settings.json, .vscode/tasks.json, .github/workflows/*, package.json-Skripte, MCP-Konfigurationen sowie Manifeste für Agenten-Plugins oder Agentenfähigkeiten, bevor Sie einem Repository vertrauen. - Behandeln Sie neue Start-Hooks und Aufgaben beim Öffnen von Ordnern wie neue ausführbare Dateien. - Entfernen Sie nach einer verdächtigen Installation Persistenzdateien und rotieren Sie Zugangsdaten. Das Entfernen des Pakets allein beweist keine Bereinigung.

Für Sicherheitsteams: - Nehmen Sie Agentenkonfigurationsdateien in Lieferkettenerkennung, CODEOWNERS, Secret-Reaktion und Vorfallabgrenzung auf. - Markieren Sie jeden PR, der Startausführung, weitreichende Shell-Befehle, undurchsichtige heruntergeladene Binärdateien oder versteckte Nutzlasten in Punktverzeichnissen ergänzt. - Bevorzugen Sie kurzlebige Veröffentlichungszugangsdaten und schreibgeschützte Installationszugänge. Langlebige Schreib-Tokens bleiben Treibstoff für Würmer.

Für Entwickler von Agentenplattformen: - Machen Sie Ausführungsflächen sichtbar, prüfbar und erklärbar. - Trennen Sie Hooks zum Laden von Kontext von Hooks, die Befehle ausführen. - Geben Sie Benutzern eine vollwertige Audit-Ansicht für Startaktionen, externe Netzwerkaufrufe und geänderte Konfigurationen.

Was Mini Shai-Hulud verändert hat

Lieferkettenangriffe auf Paketmanager folgen bereits einem vertrauten Muster. Ein vertrauenswürdiges Paket erhält eine bösartige Version. Ein Installationsskript wird ausgeführt. Die Nutzlast stiehlt Tokens. Registry-Takedown oder Versionsrollback kommen erst, nachdem bereits einige Entwickler und CI-Jobs die schädliche Version installiert haben.

Mini Shai-Hulud fügte einen stärker agentenspezifischen Schritt hinzu. Berichte von Endor Labs, Wiz, Socket, StepSecurity und der Cloud Security Alliance beschreiben im Kern dasselbe Bild: Kompromittierte Pakete im SAP-Entwicklerökosystem nutzten npm-Ausführung während der Installation, sammelten GitHub-, npm-, Cloud- und CI-Zugangsdaten und erzeugten Persistenz über Konfigurationen von Entwicklerwerkzeugen.¹²³⁴⁷

Wiz dokumentierte einen Ausweichpfad, bei dem Dateien in Repositories abgelegt wurden, sodass spätere Öffnungen in Claude Code oder VS Code die Ausführung erneut auslösen konnten.² Endor Labs beschrieb einen Claude Code-SessionStart-Hook und eine VS Code-Aufgabe mit runOn: "folderOpen".¹ Sockets Kampagnentracker führt Persistenz über .claude/settings.json und .vscode/tasks.json neben Kompromittierungen von npm- und PyPI-Paketen auf.³

Die genaue Nutzlast gehört in Vorfallberichte, nicht in einen allgemeinen Engineering-Artikel. Die dauerhafte Lehre gehört hierher:

Das Ziel verschob sich von einer einzelnen Paketversion zur Entwicklerumgebung rund um das Paket.

Konfigurationsdateien wurden zu Startprogrammen

Die Hook-Referenz von Claude Code sagt, dass Hooks benutzerdefinierte Shell-Befehle, HTTP-Endpunkte oder LLM-Prompts sind, die bei Lifecycle-Ereignissen automatisch ausgeführt werden.⁵ Dieselbe Dokumentation erklärt, dass SessionStart beim Starten oder Fortsetzen einer Sitzung in Claude Code läuft, und der Sicherheitsabschnitt warnt, dass Command-Hooks mit den vollen Berechtigungen des Benutzers ausgeführt werden.⁵

Die Aufgabendokumentation von VS Code liefert eine weitere Ausführungsfläche. Eine Aufgabe kann runOn auf folderOpen setzen; VS Code führt diese Aufgabe dann aus, wenn der entsprechende Ordner geöffnet wird, nachdem der Benutzer automatische Aufgaben für diesen Ordner erlaubt hat.⁶ Diese Zustimmung ist wichtig. Sie senkt das Risiko gegenüber stiller Ausführung auf jeder Maschine. Harmlos wird die Datei dadurch nicht. Ein vertrauenswürdiges Repository, ein müder Entwickler, ein zuvor erlaubter Workspace oder eine Organisationsrichtlinie können eine Konfigurationsänderung weiterhin in Codeausführung verwandeln.

npm bildet die Brücke während der Installation. Die npm-Skriptdokumentation listet preinstall, install und postinstall unter den Lifecycle-Skripten für npm ci und npm install auf; im Abschnitt zu Best Practices schreibt npm, Autoren sollten preinstall- oder install-Skripte fast nie explizit setzen, außer für die Kompilierung auf Zielarchitekturen.⁸

Aus diesen drei Fakten entsteht die Angriffskette:

1. Ein Installationsskript läuft während der Installation einer Abhängigkeit.
2. Das Skript schreibt oder patcht die Konfiguration von Entwicklerwerkzeugen.
3. Der Editor oder Agent führt später die konfigurierte Startaktion aus.
4. Der Entwickler vertraut der Werkzeugoberfläche, weil Prompt oder UI wie normale Arbeit aussehen.

Gefährlich ist nicht eine einzelne Funktion. Installationsskripte, Hooks, Aufgaben und Abläufe unterstützen legitime Automatisierung. Gefährlich ist die Weitergabe von Vertrauen. Eine Paketinstallation sollte nicht stillschweigend festlegen dürfen, was jede künftige Agentensitzung oder jedes künftige Öffnen eines Ordners ausführt.

Die Prüfgrenze ist falsch gesetzt

Die meisten Codeprüfungsgewohnheiten behandeln Quelldateien als Hauptartefakt und Konfigurationsdateien als Beiwerk. Diese Gewohnheit versagt, sobald Konfigurationsdateien Befehle ausführen.

Ein neuer Hook sollte dieselbe Prüfung erhalten wie ein neues Shell-Skript. Eine neue Aufgabe sollte dieselbe Prüfung erhalten wie eine neue Binärdatei. Ein neuer MCP-Server sollte dieselbe Prüfung erhalten wie eine neue Netzwerkintegration. Ein neues Package-Lifecycle-Skript sollte dieselbe Prüfung erhalten wie neuer Code, der vor den Tests läuft.

Nutzen Sie eine Prüftabelle:

Ausführungszeitschutz für werkzeuggestützte Agenten argumentierte, dass Durchsetzung an die Tool-Aufrufgrenze gehört. Mini Shai-Hulud verschiebt denselben Standard eine Ebene nach vorn. Auch die Startgrenze braucht Durchsetzung.

Startbefugnis braucht minimale Rechte

Teams wenden das Prinzip minimaler Rechte bereits auf API-Schlüssel an. Für Agentenkonfiguration gilt dieselbe Regel.

Claude Code trennt Hook-Ereignisse wie PreToolUse, PostToolUse und SessionStart.⁵ Diese Trennung sollte Richtlinien prägen. Ein Hook, der statischen Kontext lädt, sollte keinen Shell-Zugriff brauchen. Ein Hook, der einen Befehl validiert, sollte keinen Netzwerkzugriff brauchen. Ein Hook, der lokale Metadaten aufzeichnet, sollte keine Zugangsdaten brauchen.

Dieselbe Regel gilt für VS Code-Aufgaben und CI-Abläufe:

Die npm-Dokumentation zu Trusted Publishing erklärt, warum kurzlebige Zugangsdaten wichtig sind. Trusted Publishing nutzt OIDC, damit Paketveröffentlichung ohne langlebige npm-Tokens möglich ist; npm empfiehlt, traditionelle tokenbasierte Veröffentlichung zu verbieten, nachdem Trusted Publishers konfiguriert wurden.⁹ Für die Installation privater Abhängigkeiten empfiehlt npm außerdem schreibgeschützte granulare Zugriffstokens, wenn die Veröffentlichung über OIDC läuft.⁹

Diese Empfehlung beseitigt Risiken in Abläufen nicht. Ein kompromittierter Ablauf kann weiterhin Schaden anrichten, wenn er zu viele Befugnisse hat. Die Lehre lautet, beide Seiten zu verkleinern: kurzlebige Zugangsdaten und enge Abläufe.

Behandeln Sie Agentenkonfiguration als Abhängigkeit

Abhängigkeitsprüfung fragt normalerweise, welche Paketversionen sich geändert haben. Prüfung im Agentenzeitalter sollte fragen, welche Ausführungsflächen sich geändert haben.

Bevor Sie ein Abhängigkeitsupdate, eine Plugin-Installation, generierte Konfiguration oder Template-Änderung akzeptieren, prüfen Sie:

Es geht nicht um Paranoia. Es geht um korrekte Einordnung. Eine Hook-Datei kann wie Konfiguration aussehen, verhält sich aber wie Code. Eine Aufgabendatei kann wie Editor-Setup aussehen, kann aber eine Shell starten. Ein Ablauf kann wie Release-Installation wirken, kann aber Zugangsdaten erreichen.

KI-Agentensicherheit beginnt mit kleiner Software formulierte ein verwandtes Argument aus Designsicht: Engere Werkzeuge bieten weniger Orte, an denen sich Fehler verstecken können. Die Sicherheitsversion lautet: Engere Konfiguration bietet weniger Orte, an denen sich Persistenz verstecken kann.

Eine sichere Konfigurationsprüfung

Eine defensive Prüfung muss verdächtigen Code nicht ausführen. Beginnen Sie mit schreibgeschützter Inspektion:

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

Diese Befehle beweisen nicht, dass eine Maschine sauber ist. Sie geben Prüfern einen ersten Blick auf die Flächen, die Konfiguration am ehesten in Ausführung verwandeln. Wenn bereits eine verdächtige Installation stattgefunden hat, wechseln Sie in die Vorfallreaktion, statt ein sauberes Suchergebnis als Sicherheit zu behandeln.

Wiederherstellung braucht eine Konfigurationsprüfung

Die Vorfallreaktion bei einer kompromittierten Abhängigkeit darf nicht beim Deinstallieren des Pakets enden.

Nutzen Sie eine Wiederherstellungssequenz:

1. Ermitteln Sie, ob die betroffene Paketversion auf einer Entwicklermaschine oder einem CI-Runner installiert wurde.
2. Frieren Sie diese Umgebung ein, bevor sie weitere Arbeit ausführt.
3. Prüfen Sie Startkonfigurationsdateien im Repository sowie Agenten- oder Editor-Konfiguration im Home-Verzeichnis.
4. Entfernen Sie verdächtige Hooks, Aufgaben, Abläufe, generierte Nutzlastdateien und unerwartete Branches.
5. Rotieren Sie alle Zugangsdaten, die dem betroffenen Prozess zugänglich waren, einschließlich Package-Tokens, GitHub-Tokens, Cloud-Schlüsseln, SSH-Schlüsseln und CI-Secrets.
6. Prüfen Sie Paket-Publisher-Zugriff und Repository-Schreibzugriff.
7. Untersuchen Sie Ablaufprotokolle auf Secret-Offenlegung und unerwartete ausgehende Aufrufe.
8. Bauen Sie die Umgebung aus einem sauberen Checkout und einem bekanntermaßen guten Abhängigkeitssatz neu auf.

Die Actions-Sicherheitshinweise von GitHub stützen die Zugangsdaten-Seite dieser Reaktion: minimale Rechte für GitHub Actions-Tokens verwenden, offengelegte Secrets rotieren, den Umgang mit Secrets auditieren und erwägen, vor Jobs mit Zugriff auf Environment-Secrets eine Prüfung zu verlangen.¹⁰ GitHub empfiehlt außerdem CODEOWNERS für Dateien unter .github/workflows, damit Änderungen dort die Freigabe bestimmter Prüfer benötigen.¹⁰

Nehmen Sie Agentenkonfiguration in denselben Governance-Pfad auf. Wenn .github/workflows/* eine Code-Owner-Prüfung verdient, weil es Secrets berühren kann, verdienen .claude/settings.json und .vscode/tasks.json eine Prüfung, weil sie Befehle in der Nähe von Secrets ausführen können.

Was Agentenplattformen bauen sollten

Agentenplattformen und Editoren können den Prüfaufwand senken, indem sie Startbefugnisse ausdrücklich sichtbar machen.

Nützliche Produktflächen:

Diese Flächen sollten nicht davon abhängen, dass das Modell eine JSON-Datei liest und ein Urteil fällt. Die Ausführungsumgebung sollte die Befugnis direkt offenlegen. Benutzer sollten klar erkennen können, ob etwas „Kontext aus README lädt“ oder „beim Sitzungsstart einen Shell-Befehl ausführt“.

MCP-Tools brauchen Autorisierung auf Aktionsebene argumentierte, dass Bearer-Token-Validierung zu Prüfungen pro Tool, Rolle und Aktion führen muss. Agentenkonfiguration braucht dieselbe Form: Jede Startaktion sollte erklären, welche Befugnis sie benötigt, und die Ausführungsumgebung sollte die kleinste tragfähige Menge durchsetzen.

Eine praktische lokale Richtlinie

Teams können mit einer kleinen Richtliniendatei beginnen, noch bevor Plattformen die Oberfläche verbessern:

Gute Richtlinien benennen die Datei und die Befugnis. Vage Regeln wie „Vorsicht mit Agenten-Tools“ überstehen echte Arbeit nicht. Klare Regeln wie „kein SessionStart-Command-Hook ohne Eigentümerprüfung“ geben Prüfern etwas Durchsetzbares.

FAQ

Gehört KI-Agenten-Konfiguration wirklich zur Lieferkette?

Ja. Lieferkettenrisiko folgt Ausführung und Vertrauen, nicht der Dateiendung. Wenn eine Paketinstallation, ein Plugin, ein Template oder eine Repository-Änderung Agentenkonfiguration verändern kann, die später Befehle ausführt, liegt diese Konfiguration innerhalb der Lieferkette.

Sollten Teams Claude Code-Hooks oder VS Code-Aufgaben verbieten?

Nein. Hooks und Aufgaben unterstützen legitime Automatisierung. Teams sollten sie prüfen, begrenzen und protokollieren. Ein Hook, der Kontext lädt, und ein Start-Hook, der eine Shell ausführt, sollten nicht dasselbe Vertrauen erhalten.

Fragt VS Code, bevor Aufgaben beim Öffnen eines Ordners ausgeführt werden?

Die VS Code-Dokumentation sagt, dass VS Code beim ersten Öffnen eines Ordners mit einer folderOpen-Aufgabe fragt, ob automatische Aufgaben für diesen Ordner erlaubt werden sollen.⁶ Diese Nachfrage hilft, aber die Aufgabe verdient weiterhin Codeprüfung, weil die Zustimmung die Datei in einen Ausführungspfad verwandelt.

Löst npm Trusted Publishing Paketkompromittierungen?

Nein. Trusted Publishing senkt das Risiko langlebiger npm-Schreib-Tokens durch kurzlebige OIDC-basierte Zugangsdaten.⁹ Teams brauchen weiterhin Prüfung von Abläufen, minimale Rechte, Paketüberwachung und Vorfallreaktion für kompromittierte Repositories oder bösartige Installationsskripte.

Was sollte ich nach einer verdächtigen Installation zuerst auditieren?

Prüfen Sie Installationsskripte, Agenten- und Editor-Startkonfiguration, Dateien unter .github/workflows, unerwartete Dateien in Punktverzeichnissen, neue Branches und Zugangsdaten, die dem betroffenen Prozess offenstanden. Rotieren Sie danach Zugangsdaten aus der betroffenen Umgebung.

Schluss

KI-Coding-Agenten machen Konfiguration mächtiger. Sie machen Konfiguration auch gefährlicher.

Die richtige Antwort ist keine Angst vor Automatisierung. Die richtige Antwort ist Ehrlichkeit darüber, wo Ausführung stattfindet. Wenn eine Datei einen Befehl ausführen, Daten abrufen, Secrets lesen, Pakete veröffentlichen oder Agentenverhalten ändern kann, gehört sie in den Prüfpfad.

Agentenkonfiguration hat diese Grenze überschritten. Behandeln Sie sie wie Code.

Quellen