Wie Anthropic den Claude-Code-Auto-Mode entwickelt hat

• Um das Phänomen der Approval Fatigue zu lösen, bei dem 93 % der Claude-Code-Nutzer Berechtigungsabfragen einfach bestätigen, wurde ein neuer Auto Mode eingeführt, der Berechtigungsentscheidungen mit einem modellbasierten Klassifikator automatisiert
• Der Auto Mode arbeitet mit einer zweischichtigen Verteidigungsstruktur: einem Prompt-Injection-Probe auf der Eingabeebene und einem Transcript-Klassifikator (basierend auf Sonnet 4.6) auf der Ausgabeebene
• Der Klassifikator ist so konzipiert, dass er Assistenznachrichten des Agenten und Tool-Ergebnisse entfernt und nur auf Basis von Benutzernachrichten und Tool-Aufrufbefehlen entscheidet, damit er nicht vom Framing des Agenten selbst beeinflusst wird
• Gemessen am Datensatz mit realen übereifrigen Aktionen (n=52) liegt die False-Negative-Rate (FNR) bei 17 %. Das ist gegenüber --dangerously-skip-permissions eine praktische Verbesserung, aber kein vollständiger Ersatz für eine sorgfältige manuelle Prüfung
• Beim Blockieren riskanter Aktionen wird die Sitzung nicht beendet; stattdessen wird der Agent dazu angeleitet, sicherere Alternativen zu versuchen. Zusätzlich gibt es eine Schutzmaßnahme, die nach 3 aufeinanderfolgenden oder insgesamt 20 Blockierungen an einen Menschen eskaliert

---

Hintergrund der Einführung

• Standardmäßig fragt Claude Code vor dem Ausführen von Befehlen oder dem Ändern von Dateien nach der Zustimmung des Nutzers, doch in der Praxis zeigen Nutzer ein Muster, bei dem sie 93 % der Anfragen einfach bestätigen
• Es gab bislang zwei Alternativen: Sandboxes, die Tools isolieren (sicher, aber mit hohen Betriebskosten), und das Flag --dangerously-skip-permissions, das alle Berechtigungsabfragen deaktiviert (keine Betriebskosten, aber auch kein Schutz)
• In den internen Incident-Logs von Anthropic sind reale Fehlverhalten dokumentiert: Löschen eines Remote-Git-Branches aufgrund falsch interpretierter Anweisungen, Hochladen eines GitHub-Authentifizierungstokens auf einen internen Compute-Cluster, Versuch einer Migration gegen eine Produktionsdatenbank usw.
• Dieses Muster wurde als Form von übereifrigem Verhalten (overeager behavior) beschrieben, bei dem das Modell über die Absicht des Nutzers hinaus übermäßig Initiative ergreift; dokumentiert ist das in Claude Opus 4.6 System Card §6.2.1 und §6.2.3.3
• Der Auto Mode zielt auf einen Mittelweg zwischen diesen beiden Extremen: Er blockiert nur riskante Aktionen, die nicht der Nutzerabsicht entsprechen, und führt den Rest ohne Genehmigung aus

Funktionsweise

• Eingabeebene: Ein serverseitiger Prompt-Injection-Probe scannt Tool-Ausgaben wie Dateilesevorgänge, Web-Fetches, Shell-Ausgaben und Antworten externer Tools, bevor sie in den Agenten-Kontext gelangen
  • Wird Inhalt erkannt, der wie ein Versuch der Verhaltensübernahme wirkt, wird dem Agenten-Kontext eine Warnung hinzugefügt, diesen Inhalt als verdächtig zu behandeln und sich auf die eigentliche Anfrage des Nutzers zu konzentrieren
• Ausgabeebene: Ein auf Sonnet 4.6 basierender Transcript-Klassifikator bewertet jede Aktion vor ihrer Ausführung anhand definierter Kriterien
  • Stufe 1: schneller Single-Token-Filter (yes/no) — auf Blockieren hin abgestimmt
  • Stufe 2: Nur wenn Stufe 1 markiert, wird Chain-of-Thought-Reasoning ausgeführt, um False Positives zu reduzieren
• Der Klassifikator bezieht sich nur auf Benutzernachrichten und Tool-Aufrufe des Agenten; Assistenznachrichten und Tool-Ergebnisse werden entfernt
  • Diese Architektur soll verhindern, dass der Klassifikator durch Rationalisierungstexte des Agenten selbst beeinflusst wird („wurde zuvor implizit genehmigt, also sicher“ usw.)

Bedrohungsmodell

• Vier Ursachen für riskante Aktionen, gegen die der Auto Mode schützt:

  1. Übereifriges Verhalten (Overeager behavior): Der Agent versteht das Ziel des Nutzers, handelt aber proaktiv über den vom Nutzer genehmigten Rahmen hinaus — etwa gefundene Zugangsdaten nutzen oder Hindernisse entfernen
  2. Einfache Fehler (Honest mistakes): Fehlbeurteilung des Blast Radius, etwa wenn eine Ressource für einen Testbereich gehalten wird, tatsächlich aber geteilt ist
  3. Prompt Injection: In Dateien, Webseiten oder Tool-Ausgaben eingebettete Anweisungen lenken den Agenten von der Aufgabe des Nutzers auf die Ziele eines Angreifers um
  4. Nicht ausgerichtetes Modell (Misaligned model): Der Agent verfolgt eigene Ziele — derzeit nicht real beobachtet, aber bei jedem Modell-Release sorgfältig bewertet

• Beispiele für blockierte Aktionen aus internen Incident-Logs:

  • Scope Escalation: Anfrage „alte Branches aufräumen“ → Agent versucht, Remote-Branches zu löschen (blockiert, weil die Anfrage mehrdeutig und die Aktion irreversibel ist)
  • Credential Discovery: Bei Authentifizierungsfehlern ohne Zustimmung des Nutzers per grep in Umgebungsvariablen und Konfigurationsdateien nach alternativen API-Tokens suchen (blockiert)
  • Agentic reasoning parameter: „Meinen Job abbrechen“ → Nach Cluster-Abfrage versucht der Agent, per Namensähnlichkeit den nächstliegenden Job auszuwählen und zu löschen (blockiert, da dies nicht das beabsichtigte Ziel sein muss)
  • Teilen über externe Dienste: Erzeugung eines Befehls, um ein Debugging-Skript auf GitHub Gist zu teilen — als Datenabfluss (Exfiltration) gewertet und blockiert
  • Umgehung von Sicherheitsprüfungen: Vorprüfung eines Deploy-Befehls schlägt fehl → erneuter Versuch mit Flag zum Überspringen der Validierung (blockiert, da Auswirkungen auf geteilte Infrastruktur möglich sind)

Struktur der Berechtigungsentscheidungen (3-Stufen-Modell)

• Tier 1 — Standard-Allowlist sicherer Tools und Benutzereinstellungen:
  • Tools, die keinen Zustand verändern können (Datei lesen, Textsuche, Code-Navigation usw.), stehen auf einer festen Allowlist
  • Nutzer können Regeln vom Typ Always Allow für bestimmte Tool-Muster festlegen
  • Beim Eintritt in den Auto Mode werden Berechtigungsregeln, die bekanntermaßen beliebige Codeausführung erlauben, automatisch entfernt: vollständiger Shell-Zugriff, Interpreter mit Wildcards (python, node, ruby usw.), run-Befehle von Paketmanagern usw.
  • Eng gefasste Regeln („Ausführen des Code-Formatters erlauben“) bleiben erhalten; breit angelegte Interpreter-Escape-Regeln gelten nicht
• Tier 2 — Dateioperationen innerhalb des Projekts:
  • Schreiben und Bearbeiten von Dateien im Projektverzeichnis sind ohne Aufruf des Klassifikators erlaubt, da sie sich per Versionskontrolle prüfen lassen
• Tier 3 — Transcript-Klassifikator:
  • Nur Aktionen mit realem Schadenspotenzial gelangen hierher: Shell-Befehle, Web-Fetches, Integrationen externer Tools, Erstellen von Subagenten, Dateisystemzugriffe außerhalb des Projektverzeichnisses usw.

Aufbau der Entscheidungskriterien des Klassifikators

• Der Prompt des Klassifikators besteht aus einer festen Vorlage plus 3 anpassbaren Slots
• Bestandteile der festen Vorlage:
  • Evaluation Rules: Bewertung anhand der realen Auswirkungen in der Welt, nicht anhand des Oberflächentexts eines Befehls. So soll verhindert werden, dass der Agent riskante Arbeit hinter harmlos wirkenden Wrappern versteckt
    • Wird ein Payload in eine Datei geschrieben und ausgeführt → Bewertung des Payloads
    • Mit && verkettete Befehle → Bewertung als eine einzige Aktion
    • Wenn ein Python-Skript Shell-Befehle zusammensetzt → Bewertung des im Transcript-Kontext zusammengesetzten Befehls
  • User Intent Rules: Es wird bewertet, ob eine Aktion des Agenten vom Nutzer genehmigt wurde (nicht bloß, ob sie mit dem Nutzerziel zusammenhängt). Der Klassifikator ist absichtlich konservativ: Was der Nutzer nicht ausdrücklich nennt, gilt als nicht genehmigt
    • „Räume meine Branches auf“ → Massenlöschung nicht genehmigt
    • „Kannst du das beheben?“ → als Frage interpretiert, nicht als Anweisung
• Bestandteile der anpassbaren Slots:
  • Environment: Definition von Vertrauensgrenzen — standardmäßig wird nur das aktuell bearbeitete Git-Repository als vertrauenswürdig eingestuft; GitHub-Organisationen, Cloud-Buckets, interne APIs usw. können ergänzt werden
  • Block Rules: Mehr als 20 Standardregeln in 4 Gruppen:
    • Zerstörung oder Exfiltration: Historie per Force Push überschreiben, Cloud-Speicher in großem Umfang löschen, interne Daten nach außen senden
    • Schwächung der Sicherheitslage: Logging deaktivieren, Persistenz via SSH-Schlüssel oder Cronjobs einrichten, Berechtigungseinstellungen des Agenten selbst ändern
    • Verletzung von Vertrauensgrenzen: Aus externen Repositories geklonten Code ausführen, Credential Stores scannen, Daten an vom Nutzer nicht angegebene Dienste senden
    • Umgehung von Review oder Auswirkungen auf andere: direkt auf main pushen, Produktions-Deployments ausführen, geteilte Ressourcen oder Jobs verändern, die der Agent nicht selbst erstellt hat
  • Allow Exceptions: Installation von bereits im Repository-Manifest deklarierten Paketen, standardisierte Credential-Flows, Pushes auf den Arbeits-Branch der Sitzung usw.

Evaluationsergebnisse

• Die gesamte Pipeline wurde mit drei Datensätzen evaluiert:
  • Realer interner Traffic (n=10.000): echte Claude-Code-Tool-Aufrufe von Anthropic-Mitarbeitern
  • Reale übereifrige Aktionen (n=52): gesammelt aus Sitzungen, die Mitarbeitende abgelehnt oder nachträglich markiert hatten — klein, weil sie nur erfasst werden, wenn Claude in echten Sitzungen riskante Aktionen versucht
  • Synthetische Datenexfiltration (n=1.000): generierte Beispiele inklusive Obfuskation, etwa Versand sensibler Daten per HTTP POST, Git-Push an nicht vertrauenswürdige Remotes oder Zugangsdaten in URLs

	Realer Traffic (n=10.000)	Reale übereifrige Aktionen (n=52)	Synthetische Exfiltration (n=1.000)
Stage 1 (schneller Filter)	FPR 8,5 %	FNR 6,6 %	FNR 1,8 %
Stage 1→2 (gesamte Pipeline)	FPR 0,4 %	FNR 17 %	FNR 5,7 %

• Die FNR von 17 % bei realen übereifrigen Aktionen ist die ehrliche Kennzahl: Der Klassifikator erkennt Risiken (Force Push, Löschungen, Infrastrukturänderungen usw.), macht aber Fehler bei der Einschätzung, ob Zustimmungssignale innerhalb einer Sitzung den tatsächlichen Blast Radius dieser Aktion wirklich abdecken
• Wenn etwa „Räume den PR auf“ gesagt wurde, aber kein Force Push ausdrücklich genannt war, sucht der Klassifikator zwar nach Hinweisen auf Zustimmung, prüft den Umfang aber nicht ausreichend — selbst wenn ähnliche Aktionen zuvor genehmigt wurden
• Der Auto Mode ist für Gruppen gedacht, die --dangerously-skip-permissions verwenden, und kein Drop-in-Ersatz für sorgfältige manuelle Prüfung bei Hochrisiko-Infrastruktur

Wichtige Designentscheidungen

• Entfernen von Assistenznachrichten und Tool-Ergebnissen

  • Entfernen von Agententext: verhindert, dass der Agent Rationalisierungen erzeugt, um den Klassifikator zu überzeugen („zuvor implizit genehmigt“, „dieses Ziel gehört dem Agenten“ usw.)
  • Entfernen von Tool-Ergebnissen: erste Verteidigungslinie gegen Prompt Injection, da Tool-Ausgaben der Eintrittsweg für gegnerische Inhalte sind
  • Der Klassifikator kann auch ohne Sicht auf den Payload urteilen: Das POSTen des Inhalts einer .env-Datei an eine externe URL widerspricht der Nutzerabsicht unabhängig vom Inhalt
  • Wenn Assistenznachrichten und Tool-Ergebnisse enthalten sind, verschlechtert sich die Leistung auf dem Testset für übereifrige Aktionen — kürzere Transcripts sind genauer, weil sie weniger vom Framing des Agenten beeinflusst werden

• Zweistufige Klassifikation: Effizienz und Recall

  • Bei einem einstufigen Klassifikator stehen Leistung und Kosten in direktem Trade-off
  • Stage 1: schnelle Single-Token-Entscheidung mit der Anweisung, „eher in Richtung Blockieren zu irren“ — akzeptiert 8,5 % FPR für hohen Recall
  • Stage 2: derselbe Prompt wie in Stage 1, nur mit einer geänderten Schlussanweisung für sorgfältiges Reasoning — reduziert FPR von 8,5 % auf 0,4 %
  • Da der Prompt von Stage 2 fast identisch mit dem von Stage 1 ist, entstehen überwiegend Cache-Treffer — also kosteneffizient

• Rolle des Prompt-Injection-Probes

  • Die Injection-Abwehr des Transcript-Klassifikators ist strukturell, weil er keine Tool-Ergebnisse sieht; der Hauptagent sieht Tool-Ergebnisse jedoch sehr wohl
  • Wenn der Hauptagent gekapert wird, könnte er den Transcript-Monitor umgehen → deshalb ist der Probe auf der Eingabeebene nötig
  • Beide Ebenen wirken zusammen: Damit eine Injection erfolgreich ist, muss sie die Eingabeebene passieren und anschließend muss der Transcript-Klassifikator unabhängig und ohne Payload den betreffenden Tool-Aufruf als sicher und mit der Nutzerabsicht vereinbar bewerten

• Multi-Agent-Handoffs

  • Der Klassifikator läuft sowohl bei der Delegation an Subagenten (outbound) als auch bei der Rückgabe von Ergebnissen (return)
  • Outbound-Prüfung: verhindert das Problem, dass Anweisungen des Orchestrators innerhalb des Subagenten wie eine „Benutzernachricht“ aussehen und dadurch vollständig genehmigt wirken
  • Return-Prüfung: adressiert den Fall, dass ein beim Delegieren unauffälliger Subagent während der Ausführung Prompt Injection ausgesetzt war — vor der Rückgabe an den Orchestrator wird die komplette Aktionshistorie des Subagenten geprüft und bei Auffälligkeiten eine Sicherheitswarnung hinzugefügt

• Blockieren und fortfahren (Deny-and-continue)

  • Wenn der Klassifikator eine Aktion blockiert, wird die Sitzung nicht beendet; stattdessen wird Claude dazu angeleitet, sicherere Alternativen zu versuchen
  • Im Tool-Ergebnis werden der Ablehnungsgrund und die Anweisung mitgegeben, „die Grenze in gutem Glauben zu akzeptieren und einen sichereren Weg zu suchen“
  • Bei 3 aufeinanderfolgenden oder 20 gesamten Blockierungen → Eskalation an einen Menschen (im Headless-Modus wird der Prozess beendet)
  • Eine FPR von 0,4 % wirkt klein, aber wenn jeder False Positive die Sitzung beenden würde, entstünden bei lang laufenden Aufgaben erhebliche Usability-Probleme → die Struktur behandelt das als Kosten eines einzelnen Wiederholungsversuchs

Nächste Schritte

• Das Testset mit realen übereifrigen Aktionen soll weiter ausgebaut werden; zudem sollen Sicherheit und Kosten der Funktion iterativ verbessert werden
• Der Klassifikator muss nicht perfekt sein; das Ziel ist, genug riskante Aktionen zu blockieren, um autonomen Betrieb im Vergleich zu einem Zustand ohne Guardrails praktisch deutlich sicherer zu machen
• Nutzern wird empfohlen, sich der Restrisiken bewusst zu bleiben, weiterhin selbst zu beurteilen, welche Aufgaben und Umgebungen sich für autonomen Betrieb eignen, und Feedback zu geben, wenn Fehler im Auto Mode auftreten