Eine Studie aus 40.000 Durchläufen zeigt, dass Menschen jede dritte Bedrohung übersehen, wenn sie Befehle von KI-Agenten genehmigen

Die weitverbreitete Annahme, dass ein Mensch, der jeden Befehl überprüft, die KI-Programmierer unter Kontrolle halten kann, steht auf dem Prüfstand. Eine neue Analyse von mehr als 40.000 Spielsitzungen und über 409.000 einzelnen Genehmigungs- oder Ablehnungsentscheidungen ergab, dass menschliche Prüfer etwa jeden dritten böswilligen Befehl von KI-Agenten übersehen haben, was dringende Fragen darüber aufwirft, ob „Human-in-the-Loop“ überhaupt eine zuverlässige Sicherheitsgrenze ist.

Die Ergebnisse stammen aus einem browserbasierten Spiel, das von Alex Wauters entwickelt wurde, einem ehemaligen Personalingenieur bei Uber, der über Entwicklersicherheit bei Scale Einige Befehle sind Routinebefehle, wie zum Beispiel „git status“ oder „npm test“. Bei anderen handelt es sich um sorgfältig getarnte Versuche, Zugangsdaten auszuspionieren, Hintertüren zu installieren oder Geheimnisse an Remote-Server zu senden. Nachdem Wauters die Statistikverfolgung hinzugefügt hatte, sammelte er genügend Daten, um ein detailliertes Bild davon zu zeichnen, wo menschliches Urteilsvermögen erfolgreich ist und, was häufiger vorkommt, scheitert. Weitere Informationen zur breiteren Abdeckung der KI-Branche finden Sie in dieser Studie, die als eines der bisher datenreichsten Experimente gilt.

Die gefährlichsten Befehle waren am schwersten zu fangen

Das auffälligste Ergebnis der Studie ist, dass offensichtlich destruktive Befehle wie „rm -rf“ für kritische Verzeichnisse zuverlässig abgefangen wurden. Die Bedrohungen, denen es tatsächlich gelang, Zugangsdaten zu stehlen, wurden fast dreimal so oft übersehen. Der am häufigsten übersehene Befehl im gesamten Spiel war „npm runanalysieren“, der von 64,7 Prozent der Spieler genehmigt wurde, obwohl das Verlaufsprotokoll des Agenten eindeutig zeigte, dass das zugrunde liegende Skript manipuliert wurde, um Anmeldeinformationen an einen externen Server weiterzuleiten.

Das Problem ist struktureller Natur. Befehle wie „npm run“ führen jedes Skript aus, das in der Datei „package.json“ eines Projekts definiert ist. Bei diesem Skript könnte es sich um einen legitimen Bundle-Analysator oder um bösartigen Code handeln, der von einer früheren Dateibearbeitung, die der Agent geändert hat, eingeschleust wurde. Um sicher zu sein, müsste ein Entwickler jede geänderte Datei vor der Genehmigung prüfen, was den Geschwindigkeitsvorteil, den KI-Codierungstools bieten sollen, zunichte macht.

Bei drei solchen getarnten Payload-Befehlen im Spiel lag die Fehlschlagsrate bei 52,5 Prozent, verglichen mit 28,4 Prozent bei allen anderen Angriffen zur Ausschleusung von Zugangsdaten. Das Verstecken einer Nutzlast hinter einem bekannten Skriptnamen verdoppelte die Erfolgsquote ungefähr, selbst wenn die Nutzlast im Verlaufsprotokoll sichtbar war, das direkt über der Berechtigungsaufforderung angezeigt wurde.

Erlaubnismüdigkeit untergräbt mit der Zeit die Wachsamkeit

Anthropic hat zuvor eingeräumt, dass die Berechtigungsmüdigkeit bei seinem Produkt Claude Code ein echtes Phänomen ist, und festgestellt, dass je mehr Genehmigungen ein Benutzer sieht, desto weniger Aufmerksamkeit schenkt er jeder einzelnen Genehmigung. Die Scale-X-Daten stützen dieses Anliegen empirisch. Während der ersten paar Befehle jeder Sitzung, während sich die Spieler aufwärmten, verringerten sich die Fehlerquoten, stiegen dann aber gegen Ende stetig an, was entweder auf Ermüdung oder den zunehmenden Druck einer tickenden Uhr zurückzuführen war.

Dieses Muster spiegelt die Dynamik der realen Welt wider. Entwickler, die unter Zeitdruck mit der Auslieferung von Funktionen rennen, stehen vor dem gleichen Anreiz, schnell auf „Genehmigen“ zu klicken, und die schiere Menge an Routinebefehlen führt zu einem Nadel-im-Heuhaufen-Problem, bei dem echte Bedrohungen statistisch gesehen selten sind. Das Ergebnis ist ein System, das Benutzern beibringt, alles abzustempeln.

Die andere Seite: Übermäßiges Blockieren verlangsamt alles

Die Studie dokumentierte auch den umgekehrten Fehlermodus. Mehrere wirklich harmlose Befehle wurden routinemäßig von vorsichtigen Spielern blockiert, darunter Standard-Build- und Testaufrufe. Dieses übermäßige Blockieren verlangsamt den Wirkstoff und erhöht paradoxerweise das langfristige Risiko. Wenn Benutzer wiederholt aufgefordert werden, Befehle zu genehmigen, die sich als harmlos herausstellen, untergräbt der Lärm ihre Bereitschaft, künftige Eingabeaufforderungen genau zu prüfen, und drängt sie schließlich zu kompletten Umgehungen oder Modi zur automatischen Genehmigung, die eine menschliche Überprüfung vollständig ausschließen.

Funktionen wie der Auto-Modus von Anthropic versuchen, dies zu mildern, indem sie automatisch ermitteln, ob ein Befehl sicher ist, bevor sie den Benutzer dazu auffordern. Doch wie die Daten der Studie zu getarnten Nutzlasten zeigen, reichen selbst sichtbare Befehlsinhalte nicht aus, damit Menschen unter Druck verlässliche Urteile fällen können.

Fehlender Kontext ist das Kernproblem

Ein Befehl, „cat ~/.zshrc“, erwies sich als der umstrittenste im gesamten Spiel und wurde von 45,9 Prozent der Spieler genehmigt. Der Befehl ist harmlos für Entwickler, die keine Geheimnisse in ihrem Shell-Profil behalten, aber er legt API-Schlüssel für die vielen offen, die dort Anmeldeinformationen exportieren. Das Risiko hängt vollständig von einer Systemkonfiguration ab, die der Agent nicht sehen kann und an die sich der Prüfer möglicherweise nicht erinnert.

Mehrere andere Befehle lösten aus dem gleichen Grund ähnliche Kontroversen im Hacker News-Diskussionsthread aus. Das grundlegende Problem besteht darin, dass Entwickler aufgefordert werden, Sicherheitsurteile zu fällen, ohne einen vollständigen Überblick darüber zu haben, welche Dateien geändert wurden, was der Agent in vorherigen Schritten getan hat und was die aktuelle Konfiguration des Systems enthält. Wie ein Kommentator feststellte, ist die Aufforderung an Benutzer, Befehle zu validieren, die ohne Kontext mehrdeutig sind, kein starker Schutz.

Was kommt als nächstes für die Agentensicherheit?

Wauters argumentiert, dass die Lösung nicht in besseren Menschen, sondern in besseren Werkzeugen liegt. Das Sandboxing von Agenten, damit diese nicht direkt auf Anmeldeinformationen zugreifen können, eine strikte Kontextisolierung und strukturelle Beschränkungen dessen, was Agenten ohne erhöhte Berechtigungen tun können, sind allesamt erfolgversprechender, als sich auf menschliche Wachsamkeit zu verlassen. Solange diese Sicherheitsvorkehrungen nicht getroffen sind, bleibt es riskant, Agenten weitreichende Berechtigungen zu erteilen, unabhängig davon, ob ein Mensch nominell auf dem Laufenden ist.

Bei der Studie handelt es sich nicht um eine von Experten begutachtete wissenschaftliche Arbeit, und Wauters erkennt ihre Grenzen an. Das Spiel warnte die Spieler vor Bedrohungen und übte künstlichen Zeitdruck aus, der möglicherweise nicht perfekt die realen Entwicklungsumgebungen widerspiegelt. Aber die zentrale Erkenntnis, dass geschulte menschliche Prüfer unter Druck ein Drittel der absichtlich getarnten Angriffe übersehen, sollte jedem Team, das KI-Programmierungsagenten einsetzt, Anlass geben, sein Sicherheitsmodell zu überdenken.

Für Entwickler, die heute mit KI-Agenten bauen, besteht die praktische Erkenntnis darin, davon auszugehen, dass der Human-in-the-Loop irgendwann scheitern wird. Gestalten Sie Ihre Agentenberechtigungen und Ihr Sandboxing so, dass eine verpasste Genehmigung nicht auf einen durchgesickerten AWS-Schlüssel oder eine kompromittierte Build-Pipeline zurückzuführen ist. Die Daten deuten darauf hin, dass es sich nicht auszahlt, die menschliche Überprüfung als Ihre primäre Verteidigung zu betrachten.

Bleiben Sie der KI immer einen Schritt voraus

Die Sicherheitslandschaft für KI-Agenten entwickelt sich rasant weiter. Bleiben Sie über die neuesten KI-Entwicklungen und aktuelle Forschungsergebnisse auf dem Laufenden.

Weitere KI-Neuigkeiten lesen →