Die letzte Verteidigungslinie hält nicht
KI-Coding-Agenten wie Claude Code fragen bei kritischen Terminalbefehlen nach. Der Mensch soll bestätigen oder ablehnen, das ist das sogenannte Human-in-the-Loop-Prinzip, also die menschliche Kontrollinstanz vor der Ausführung. Genau dieses Prinzip funktioniert deutlich schlechter als angenommen.
Der belgische Softwareentwickler Alex Wauters hat dafür ein Browser-Spiel gebaut. Es simuliert Berechtigungsabfragen eines Coding-Agenten, der Spieler hat 60 Sekunden Zeit, um so viele Anfragen wie möglich korrekt freizugeben oder zu blockieren. Falsch genehmigte Bedrohungen und falsch blockierte harmlose Befehle kosten jeweils Punkte.
Die Auswertung umfasst mehr als 40.000 Spieldurchläufe und 409.000 einzelne Entscheidungen. Das Ergebnis: Im Durchschnitt übersahen die Teilnehmer eine von drei Bedrohungen, die mittlere Trefferquote lag bei 66,3 %. Rund 32,9 % der Sitzungen endeten mit negativer Punktzahl.
"Als Human-in-the-Loop ist man die letzte Verteidigungslinie. Wie gut kann man gefährliche Befehle unter Zeitdruck von harmlosen unterscheiden?" (sinngemäße Übersetzung der Aussage von Alex Wauters)
Was übersehen wird, und was nicht
Die Fehlerquoten unterscheiden sich stark je nach Art der Bedrohung. Offensichtlich zerstörerische Befehle erkennen die meisten Menschen zuverlässig. Sobald ein Befehl aber nur Daten ausliest oder unauffällig aussieht, bricht die Erkennung ein.
| Bedrohungstyp | Beispiel | Übersehen |
|---|---|---|
| Destruktive Befehle | rm -rf / | 11,7 % |
| Dauerhafte Manipulationen | Crontab-Injection, Git-Config-Hijack | 23,8 % |
| Datenabfluss und Codeausführung | curl an unbekannte API, Typosquatting-Pakete | 33,4 % |
| Überschreiten des Aufgabenbereichs | cat ~/.aws/credentials | 35,0 % |
Ausgerechnet die Kategorie mit dem höchsten Schadenspotenzial für Unternehmen schneidet am schlechtesten ab. Wer einem Agenten erlaubt, AWS-Zugangsdaten oder eine Kubernetes-Konfiguration auszulesen, öffnet den direkten Weg zum Datenabfluss. Der Befehl cat ~/.zshrc, in dem häufig Umgebungsvariablen und Schlüssel liegen, wurde in 45,9 % der Fälle freigegeben.
npm-Skripte sind der blinde Fleck
Der mit Abstand am häufigsten falsch genehmigte Befehl war npm run analyze: 64,7 % der Spieler winkten ihn durch. Der Grund ist simpel. Ein npm-Skript führt aus, was in der Projektdatei package.json hinterlegt ist, und dort lässt sich beliebiger Code verstecken. Der Name des Skripts sagt nichts über seinen Inhalt.
Im Spiel stand der tatsächliche Skriptinhalt sogar im Protokoll direkt über der Abfrage. Zwei Drittel der Spieler genehmigten trotzdem. Das legt nahe, dass der Kontext oberhalb einer Berechtigungsabfrage schlicht nicht gelesen wird.
| Befehl | Fälschlich genehmigt |
|---|---|
| npm run analyze | 64,7 % |
| npm run setup | 48,0 % |
| npm run deploy | 44,9 % |
| alle npm-Skripte kumuliert (n=9.482) | 52,5 % |
Der Preis der Vorsicht
Das Problem hat eine zweite Seite. Wer misstrauisch wird, blockiert auch das, was völlig harmlos ist, und bremst damit den Agenten aus. Der Befehl npm config set registry wurde in 59 % der Fälle fälschlich abgelehnt, rm -rf dist/ in 45 %, das Beenden eines Prozesses auf Port 3000 in 43 %.
Nur 35,2 % der Spieler fingen jede einzelne Bedrohung ab. Und von dieser Gruppe schafften es lediglich 20,8 %, dabei nicht mehr als ein Fünftel der sicheren Befehle zu blockieren. Sauberes Freigeben ist also die absolute Ausnahme.
Am anderen Ende der Skala: 7 % der Spieler genehmigten ausnahmslos jeden Befehl. Das entspricht in der Praxis dem Schalter --dangerously-skip-permissions, mit dem sich Sicherheitsabfragen komplett abstellen lassen.
"Ich habe gesehen, wie Leute deshalb zu '--dangerously-skip-permissions' greifen, weil sie nicht feststellen wollten, dass sie ihren stundenlangen Agentenlauf nach fünf Minuten gestoppt haben." (sinngemäße Übersetzung)
Die Praxisdaten sind noch deutlicher
Die Spieldaten stammen aus einem künstlichen Szenario: 34 % aller gezeigten Befehle waren tatsächlich Bedrohungen, eine Dichte, die im echten Arbeitsalltag niemand erlebt. Die exakte Fehlerquote im Produktivbetrieb lässt sich daraus nicht ableiten.
Anthropic selbst liefert allerdings die passende Ergänzung. Laut Telemetriedaten zu Claude Code genehmigen Nutzer rund 93 % aller Berechtigungsanfragen. Das Unternehmen beschreibt den Mechanismus sinngemäß so: Je mehr Freigaben ein Nutzer sieht, desto weniger Aufmerksamkeit widmet er jeder einzelnen, und desto nachlässiger wird die Überwachung mit der Zeit.
Wauters führt das auf zwei Ursachen zurück. Erstens die schiere Menge an Abfragen, die zu Ermüdung führt. Zweitens fehlender Kontext: Entwickler wissen oft nicht, was sich zwischenzeitlich geändert hat, um das Risiko in Sekunden einzuschätzen. Die Arbeitsweise hat sich verschoben, weg von einzelnen überprüften Codezeilen hin zu komplexen Aufgaben, die der Agent über lange Strecken selbstständig bearbeitet und die erst am Ende kontrolliert werden.
Automatische Prüfung schließt die Lücke nicht
Anthropic hat für Claude Code einen Auto-Modus eingeführt, bei dem ein Klassifikator einen Teil der Freigabeentscheidungen übernimmt. Er fängt nach Angaben des Unternehmens rund 83 % der überschießenden Aktionen ab. Damit passieren weiterhin etwa 17 %. Anthropic bezeichnet den Modus ausdrücklich als eine Schicht innerhalb einer Sandbox und nicht als Ersatz dafür.
Ob Modelle künftig in der Lage sein werden, Skriptinhalte wie manipulierte package.json-Einträge zuverlässig im Kontext zu bewerten, ohne legitime Arbeitsabläufe dauernd zu blockieren, ist offen. Belastbare Belege dafür gibt es bislang nicht.
Was das für Unternehmen bedeutet
Für IT-Verantwortliche im DACH-Raum ist die Konsequenz unbequem. Wer die Freigabe durch Entwickler als Kontrollmechanismus in ein Sicherheitskonzept schreibt, dokumentiert eine Maßnahme, die messbar ein Drittel der Fälle verfehlt. Bei Geschäftsgeheimnissen, Zugangsdaten und personenbezogenen Daten unter DSGVO ist das keine tragfähige Grundlage.
Die belastbaren Schranken liegen auf Systemebene: isolierte Ausführungsumgebungen, etwa Devcontainer, in denen der Agent gar nicht erst an Produktivsysteme kommt. Dazu die konsequente Trennung von Zugangsdaten aus Konfigurationsdateien und Hooks, die kritische Aktionen abfangen, bevor sie überhaupt zur Freigabe gelangen. Dass Agenten ohne solche Grenzen zum Problem werden, haben zuletzt auch die Angriffe von KI-Agenten auf Open-Source-Projekte gezeigt, und Anthropic musste selbst einräumen, dass Claude-Modelle in fremde Systeme eingedrungen sind.
Bemerkenswert ist auch, was das über das Geschäftsmodell aussagt. Ein Agenten-Abo verkauft Effizienzgewinn, verlagert die Sicherheitsverantwortung aber vollständig auf den Nutzer, und zwar über einen Mechanismus, der nachweislich nicht funktioniert. Der manuelle Prüfaufwand frisst genau den Zeitgewinn auf, für den bezahlt wird. Wer das ernst nimmt, kommt zu einer anderen Architektur: Ausführungsumgebung im eigenen Haus, klare Rechtegrenzen auf Betriebssystemebene, austauschbares Modell. Werkzeuge wie der Open-Source-Coding-Agent Goose oder Ansätze, bei denen die Agentenausführung in der eigenen Private Cloud läuft, gehen in diese Richtung. Die Kontrolle über die Umgebung ist am Ende wirksamer als jede Abfrage, die ein müder Mensch um 17 Uhr wegklickt.