Prompt Injection bei Coding-Agenten: Risiken und Schutz

Was Prompt Injection gegen einen Coding-Agent ist

Prompt Injection gegen einen Coding-Agent lässt sich einfach beschreiben: Text, den der Agent liest, wird als Anweisung behandelt, der der Agent folgt. Der Agent öffnet eine Datei, einen Kommentar in einem Pull Request, eine Webseite oder das Ergebnis eines Tool-Aufrufs. Alles kommt als dieselbe Art von Text wie Ihre eigene Anfrage an. Wenn ein Angreifer einen dieser Texte kontrolliert, schreibt er in Ihre Sitzung.

Diese Eigenschaft haben alle aktuellen Agent-Produkte. Das Modell empfängt eine Sequenz von Tokens. Ihre Anfrage, der System-Prompt, die Dateiinhalte und die Tool-Ergebnisse werden zusammengeführt, und das Modell sagt voraus, was als Nächstes kommt. Für ein Token gibt es kein Berechtigungsbit. Das Format enthält keine Information darüber, welchen Teil Sie autorisiert haben und welcher Teil aus der README-Datei eines Fremden stammt.

Diese Seite beschreibt das Bedrohungsmodell: Wie angreifergesteuerter Text einen Agenten erreicht, der auf einem Server läuft, was ein Angreifer an den einzelnen Punkten erreichen kann und welche Schutzmaßnahmen den Aufwand wert sind. Die Hinweise zur Eindämmung in unseren anderen Anleitungen sind erst sinnvoll, wenn Sie wissen, wovor Sie den Agenten abschirmen.

Warum das Modell Inhalte nicht von Anweisungen trennen kann

Training hilft, löst das Problem aber nicht. Aktuelle Modelle sind darauf trainiert, abgerufenen Text mit Misstrauen zu behandeln, und lehnen viele plumpen Versuche ab. Eine Ablehnung ist eine Wahrscheinlichkeit, keine Regel. Ein Angreifer kann den Text umformulieren, es erneut versuchen und ihn in einem Format verstecken, das niemand berücksichtigt hat. Die Anzahl der Formulierungen ist dabei nicht begrenzt.

Das OWASP-GenAI-Projekt führt dies als LLM01:2025 Prompt Injection und unterteilt es in zwei Arten. Bei einer direkten Injection verändert der eigene Prompt eines Benutzers das Verhalten des Modells. Bei einer indirekten Injection verändert externer Inhalt, etwa eine Website oder eine Datei, das Verhalten, während das Modell diesen Inhalt verarbeitet. Die indirekte Injection ist auf einem Server relevant, weil ein Agent deutlich mehr Text liest, als Sie eingeben.

Die erste systematische Untersuchung stammt von Greshake und Kollegen: Not what you've signed up for (2023). Ihre Schlussfolgerung ist der entscheidende Satz: Wenn eine Anwendung abgerufenen Text in ein Modell einspeist, das Tools aufrufen kann, kommt die Verarbeitung dieses Textes einer beliebigen Codeausführung nahe.

Die Bedingung, unter der Lesen zu einem Einbruch führt

Das Lesen schädlicher Texte verursacht allein noch keinen Schaden. Der Schaden benötigt einen Weg aus dem System.

Simon Willison bezeichnete diese Kombination im Juni 2025 als the lethal trifecta. Ein Agent, der Zugriff auf private Daten hat, nicht vertrauenswürdigen Inhalten ausgesetzt ist und Daten nach außen senden kann, lässt sich dazu bringen, die Daten über den dritten Faktor nach außen zu übertragen.

Ein Coding-Agent auf Ihrem VPS erfüllt alle diese Bedingungen bereits am ersten Tag. Zu den privaten Daten gehören Ihr Quellcode, Ihre .env-Datei, Ihre SSH-Schlüssel und Ihre Shell-Historie. Die nicht vertrauenswürdigen Inhalte umfassen jedes Repository, jede Seite und jedes Tool-Ergebnis, das der Agent liest. Der Ausgang kann git push, curl, npm publish, der Inhalt eines Pull Requests oder ein in Ihrem Terminal ausgegebener Link sein, den Sie anklicken.

Die zweite Bedingung können Sie nicht entfernen, weil das Lesen nicht vertrauenswürdiger Texte die Aufgabe ist, für die Sie den Agenten eingesetzt haben. Daher setzt jede praktikable Abwehr an den beiden anderen Bedingungen an.

Wo nicht vertrauenswürdiger Text einen Coding-Agent auf einem Server erreicht

Das Repository, in dem der Agent arbeitet

Jede Datei im Checkout ist eine Eingabe. Dazu gehören Quellcode-Kommentare, README.md, Änderungsprotokolle, Test-Fixtures, eingebundener Code von Drittanbietern und die Anweisungsdateien des Agents selbst: CLAUDE.md, AGENTS.md und deren Entsprechungen. Ein Agent, der eine Codebasis verstehen soll, liest diese Dateien, weil genau das von ihm verlangt wurde.

Ein Angreifer erhält dadurch Zugriff auf alle Personen, die das Repository klonen und einen Agent darauf ansetzen. Anweisungsdateien sind der direkteste Weg, weil sie ausdrücklich als Anweisungen gelesen werden sollen. Ein Pull Request, der vier nützliche Zeilen zu CLAUDE.md und eine Zeile hinzufügt, die den Agent umleitet, wird von einem menschlichen Reviewer leicht übersehen.

Issues, Pull Requests und Kommentare zur Code-Überprüfung

Alles, was eine fremde Person in Ihrem Tracker eingeben kann, erreicht den Agent, sobald Sie ihn mit der Triage beauftragen. Im Mai 2025 veröffentlichte Invariant Labs einen GitHub-MCP-Befund mit genau diesem Muster. Der Agent eines Entwicklers hatte Zugriff auf ein öffentliches Repository und auf private Repositories. Ein Angreifer erstellte ein Issue im öffentlichen Repository. Als der Entwickler den Agent aufforderte, offene Issues zu prüfen, las der Agent Inhalte aus privaten Repositories und schrieb sie in einen Pull Request im öffentlichen Repository.

Der Bericht beschreibt ein Architekturproblem und keinen Codefehler im MCP-Server. Der Agent verfügte über ein weitreichendes Zugriffstoken, las aus einem öffentlichen Posteingang und hatte Schreibberechtigungen. Im üblichen Sinn war nichts falsch konfiguriert. Deshalb lautet die Lösung Berechtigungsbegrenzung und nicht Fehlerbehebung.

Webseiten, die der Agent abruft

Dokumentation, Forenantworten, eine Herstellerseite oder ein Suchergebnis. Jeder dieser Inhalte kann Text enthalten, der für den Agent und nicht für Sie geschrieben wurde. In Text umgewandeltes HTML bietet einem Angreifer zusätzlichen Spielraum, weil auch Inhalte, die ein Browser nie anzeigt, das Modell erreichen.

Ein Angreifer erhält die Kontrolle in dem Moment, in dem der Agent am wenigsten überwacht wird. Niemand liest den vollständigen Text einer Seite, die der Agent bei einer Recherche abgerufen hat.

MCP-Toolausgabe

MCP (model context protocol) ist die übliche Methode, mit der Agents externe Tools anbinden. Ergebnisse werden als Text zurückgegeben und gelangen direkt in das Kontextfenster. Dabei gibt es zwei Angriffsflächen, nicht nur eine. Die von einem Tool zurückgegebenen Daten sind die offensichtliche Angriffsfläche. Die andere sind der Name und die Beschreibung des Tools selbst. Das Modell liest sie, um zu entscheiden, wann es das Tool aufruft. Ein Server, den Sie nicht kontrollieren, kann beides zwischen zwei Aufrufen ändern.

Ein Angreifer, der Text in der Ausgabe eines Tools platziert, erreicht damit jedes andere Tool, auf das der Agent Zugriff hat. So kann eine Injection in einem Tool mit geringem Schutzbedarf schließlich ein Tool mit hohem Schutzbedarf steuern.

CI-Logs, Buildausgabe und Metadaten von Abhängigkeiten

npm install gibt Text aus Paketen aus, die Sie nicht selbst geschrieben haben. Ein fehlgeschlagener Test gibt eine Assertion-Meldung aus einer Bibliothek aus. Ein Job-Log aus der kontinuierlichen Integration (CI) besteht aus Tausenden Zeilen von Drittanbieterausgaben. Wenn Sie einen Agent auffordern, einen fehlgeschlagenen Build zu reparieren, liest er all diese Inhalte.

Hier erhält ein Angreifer Zugriff auf die Build-Maschine. Sie enthält normalerweise Zugangsdaten für Deployments und Registry-Tokens und wird weniger aufmerksam überwacht als ein Laptop.

Was ein Angreifer tatsächlich erhält

Für vier Folgen sollten Sie Vorsorge treffen.

Diebstahl von Zugangsdaten. Alles, was der Agent-Prozess lesen kann, ist betroffen: Umgebungsvariablen, ~/.aws/credentials, ~/.ssh, ein gh-Token oder eine Docker-Konfigurationsdatei. Für die Übertragung nach außen ist curl nicht erforderlich. Ein Commit in einen Branch, die Beschreibung eines Pull Requests, ein in einer Registry veröffentlichtes Paket oder eine DNS-Abfrage für einen Namen, den der Angreifer kontrolliert, übertragen Daten vom System.

Codeänderungen, die Sie freigeben. Der Agent schreibt Code. Daher lässt sich am einfachsten erreichen, dass er eine unauffällig falsche Zeile schreibt. Das kann eine zusätzliche Abhängigkeit sein oder ein Logging-Aufruf, der ein Token in ein Log schreibt, das Sie an einen anderen Ort übertragen.

Persistenz. Eine einmal geschriebene Datei funktioniert ohne ein Modell weiter: ein Hook in .git/hooks, ein postinstall-Skript in package.json, eine an eine Shell-Startdatei angehängte Zeile oder eine zusätzliche Zeile in CLAUDE.md. Der nächste Befehl führt sie aus.

Bewegung innerhalb Ihres Netzwerks. Der Agent läuft dort, wo Sie ihn ausführen. Wenn dieses System eine Datenbank über Loopback, einen internen Administrationsdienst, den Metadatendienst Ihres Cloud-Anbieters oder einen anderen Host im privaten Netzwerk erreicht, gilt das auch für alles, was den Agenten steuert.

Auto-Approve-Modi entfernen die letzte Prüfung

Im Standardmodus fragt Claude Code nach, bevor ein Befehl ausgeführt oder eine Datei bearbeitet wird. Diese Abfrage ist die menschliche Prüfung zwischen jeder zuvor genannten Angriffsfläche und einer tatsächlichen Aktion. Modi, die die Abfrage entfernen, beseitigen auch diese Prüfung.

Die Dokumentation ist bei bypassPermissions eindeutig: Verwenden Sie es nur in isolierten Umgebungen wie Containern oder VMs, in denen Claude Code keinen Schaden anrichten kann. Der Auto-Modus ist weniger strikt. Er genehmigt Tool-Aufrufe automatisch und führt dabei Sicherheitsprüfungen im Hintergrund durch, die kontrollieren, ob die Aktionen mit Ihrer Anforderung übereinstimmen. Diese Prüfungen erkennen vieles. Sie beruhen jedoch weiterhin auf einer Modellbewertung der Modellausgabe. Betrachten Sie sie daher als Filter und nicht als Sicherheitsgrenze.

Ein Administrator kann beide Prüfungen entfernen. Setzen Sie permissions.disableBypassPermissionsMode oder permissions.disableAutoMode in einer Einstellungsdatei auf "disable" und legen Sie diese Datei in den verwalteten Einstellungen ab, damit ein ausgechecktes Projekt sie nicht überschreiben kann. Unser Leitfaden zu Claude Code Auto-Modus und Berechtigungsregeln erläutert, wo die einzelnen Regeln wirksam werden.

Abwehrmaßnahmen, geordnet nach ihrem Nutzen

Keine dieser Maßnahmen ist eine vollständige Lösung. Jede schränkt entweder ein, welche Daten der Agent besitzt, oder was er damit tun kann.

1. Eine Maschine, die Sie löschen und neu aufsetzen können. Dann kostet Sie ein kompromittiertes System eine Stunde statt eines Sicherheitsvorfalls.
2. Zugangsdaten, die von Ihren eigenen getrennt, auf ein Repository beschränkt und nur kurz gültig sind.
3. Keine langlebigen Secrets in der Umgebung, die die Befehle des Agents erben.
4. Durchsetzung von Regeln für ausgehenden Netzwerkverkehr und Dateizugriffe auf Betriebssystemebene. Diese Regeln gelten für jeden Prozess, den der Agent startet.
5. Aktivierte Bestätigungsabfragen für Schreibvorgänge und Netzwerkaufrufe.
6. Hooks als deterministische Rückfallebene für die konkreten Aktionen, die Sie benennen können.
7. Den Diff lesen, bevor Sie ihn mergen.

Die Reihenfolge ist wichtig. Die Punkte 1 bis 4 gelten auch dann, wenn das Modell vollständig unter der Kontrolle eines Angreifers steht. Die Punkte 5 bis 7 setzen voraus, dass ein Mensch aufmerksam bleibt. Genau das geschieht bei einem langen Agent-Lauf zunehmend nicht mehr.

Setzen Sie den Agent auf eine wegwerfbare Maschine

Ein VPS mit einem Checkout und einem einzigen eingeschränkten Token ist ein deutlich kleinerer Gewinn als ein Laptop mit Ihren Schlüsseln. Führen Sie den Agent als eigenen unprivilegierten Benutzer aus, nicht unter Ihrem Login-Konto und nicht als root. Unsere Anleitungen zu einer wegwerfbaren VM für Coding-Agents und zu Benutzern mit den geringsten erforderlichen Rechten auf einem VPS behandeln die Einrichtung. Claude Code sicher auf einem VPS ausführen beschreibt den täglichen Betrieb.

Entfernen Sie die Secrets aus der Umgebung

Eine Umgebungsvariable kann von jedem Kindprozess gelesen werden. Das bedeutet: auch von jedem Befehl, den der Agent ausführt. Die Sandbox von Claude Code kann benannte Variablen vor jedem Sandbox-Befehl entfernen. Unter Linux benötigt die Sandbox zunächst zwei Pakete:

sudo apt-get install bubblewrap socat

Dann in ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Ein Eintrag deny entfernt diese Variable, bevor jeder Sandbox-Befehl ausgeführt wird. allowedDomains enthält die Sandbox-Befehle für die von Ihnen angegebenen Hosts. Der Block credentials benötigt Claude Code v2.1.187 oder höher; geprüft im August 2026. Führen Sie /sandbox in einer Sitzung aus, um zu sehen, welche Ebenen aktiv sind und welche Abhängigkeiten fehlen. Die Entscheidung, welche Secrets auf diesem System überhaupt vorhanden sein müssen, ist der größere Teil der Aufgabe. Secrets außerhalb der Reichweite eines AI-Agents halten behandelt dieses Thema ausführlich.

Begrenzen Sie ausgehenden Netzwerkverkehr auf Betriebssystemebene

Eine Firewall-Regel berücksichtigt nicht, was das Modell entschieden hat. Führen Sie den Agent als dedizierten agent-Benutzer aus und verwerfen Sie anschließend, was dieser Benutzer sendet:

table inet agentcage {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ct state established,related accept
    meta skuid "agent" oif lo accept
    meta skuid "agent" counter drop
  }
}

Damit kann der Benutzer agent nur Loopback verwenden. Sein Netzwerkverkehr muss daher über einen Proxy auf demselben System laufen. Der Proxy enthält die Hostnamen-Allowlist. Wenn https_proxy auf diesen Proxy zeigt, sendet der Client eine CONNECT-Anfrage. Der Proxy führt die Namensauflösung durch. Der Agent benötigt daher kein eigenes ausgehendes DNS (Domain Name System). Prüfen Sie die Konfiguration mit sudo nft list ruleset. Beobachten Sie außerdem, wie der Zähler der Verwerfungsregel steigt, während der Agent versucht, ein neues Ziel zu erreichen.

Halten Sie eine zweite SSH-Sitzung offen, während Sie Firewall-Änderungen anwenden. Prüfen Sie außerdem, wie Ihre Container-Laufzeitumgebung mit diesen Regeln umgeht: Docker schreibt eigene Chains. Veröffentlichte Docker-Ports umgehen ufw beschreibt die dadurch entstehende Überraschung.

Hooks: Die Prüfung, die das Modell nicht umgehen kann

Berechtigungsregeln und Hooks werden von Claude Code durchgesetzt, nicht vom Modell. Die Dokumentation formuliert es eindeutig: Anweisungen in Ihrem Prompt oder in CLAUDE.md beeinflussen, was Claude versucht. Sie ändern nicht, was Claude Code erlaubt. Genau darin liegt der Nutzen dieser Unterscheidung. Eine Zeile in CLAUDE.md mit dem Inhalt "never run curl" ist eine Empfehlung, gegen die ein eingeschleuster Absatz argumentieren kann. Ein Hook ist ein Prozess, der einen Exit-Code zurückgibt.

Registrieren Sie einen PreToolUse-Hook in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/no-egress.sh"
          }
        ]
      }
    ]
  }
}

Der Hook erhält den Tool-Aufruf als JSON über die Standardeingabe. Der Exit-Code 2 blockiert den Aufruf und zeigt Claude den Grund aus der Standardfehlerausgabe. Der Exit-Code 0 lässt den Aufruf den normalen Berechtigungsablauf durchlaufen.

#!/usr/bin/env bash
# PreToolUse: stdin holds the tool call, exit 2 blocks it.
cmd=$(jq -r '.tool_input.command // ""')
if printf '%s' "$cmd" | grep -qE '(^|[;&|]|\s)(curl|wget|nc|ncat)(\s|$)'; then
  echo "Blocked: this repository does not allow outbound network commands." >&2
  exit 2
fi
exit 0

Nun zum entscheidenden Punkt: Dies ist eine Denylist für eine Shell-Zeichenkette. Denylists für Shell-Zeichenketten lassen sich umgehen. python3 -c öffnet einen Socket, ohne das Wort curl zu verwenden. Ein Ziel make deploy verbirgt denselben Aufruf noch eine Ebene tiefer. Schreiben Sie Hooks für die Fehler, die Sie benennen können. Verankern Sie die Grenze, auf die Sie tatsächlich angewiesen sind, im Kernel oder im Netzwerk.

Berechtigungsregeln mit deny haben eine wichtige Einschränkung. Read und Edit-Deny-Regeln decken die eigenen Dateitools von Claude sowie die Dateibefehle ab, die Claude in Bash erkennt, etwa cat, head, tail und sed. Sie decken kein Python- oder Node-Script ab, das die Datei selbst öffnet. Regeln werden zuerst mit deny, dann mit ask und anschließend mit allow ausgewertet. Eine deny-Regel kann daher keine Ausnahme in Form einer Allowlist enthalten.

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(./secrets/**)",
      "Bash(git push *)"
    ]
  }
}

Beobachten Sie, was das System verlässt, und lesen Sie den Diff

Ein Agent-Lauf erzeugt einen Diff und eine Reihe von Netzwerkaufrufen. Beides sollte geprüft werden, bevor etwas gemergt oder deployed wird. Eine selbst gehostete Prüfung des Diffs aus Sicherheitssicht erkennt eine andere Klasse von Änderungen als ein kurzes menschliches Überfliegen. Zu wissen, was ein Coding-Agent vom System sendet zeigt Ihnen, wie normaler Netzwerkverkehr aussieht. Dadurch fallen ungewöhnliche Anfragen auf.

Was noch ungelöst ist

Derzeit gibt es keine zuverlässige Trennung zwischen Inhalt und Anweisung. Jede verfügbare Abwehr ist entweder ein Filter mit einer Fehlerquote oder eine Begrenzung der möglichen Folgen. Nichts im Stack kennzeichnet einen Textabschnitt als Daten, die niemals befolgt werden dürfen.

Filter helfen, und sie versagen auch. Ein Klassifikator, der die meisten Injection-Versuche erkennt, muss jedes Mal richtig liegen, während ein Angreifer nur einmal richtig liegen muss. Diese Asymmetrie ist der Grund dafür, dass eine veröffentlichte Erfolgsquote einer Abwehr eher den Ausgangspunkt für den nächsten Versuch als eine Garantie darstellt.

Die vielversprechendsten Ansätze liegen auf der Design-Ebene und nicht auf der Modellebene. CaMeL aus Defeating Prompt Injections by Design (Debenedetti und Kollegen, 2025) extrahiert zuerst den Kontrollfluss und den Datenfluss aus der vertrauenswürdigen Anfrage. Dadurch können nicht vertrauenswürdige Daten das Verhalten des Programms nicht ändern. Anschließend setzt CaMeL bei Tool-Aufrufen Berechtigungsprüfungen durch. Die eigenen Zahlen des Papers zum AgentDojo-Benchmark zeigen, welche Kosten damit verbunden sind.

[
  {
    "label": "Undefended agent",
    "tasks_solved_pct": 84
  },
  {
    "label": "CaMeL",
    "tasks_solved_pct": 77
  }
]

Der nicht geschützte Agent löste 84 Prozent der Aufgaben. CaMeL löste 77 Prozent und bot dabei eine Sicherheitsgarantie. Das sind die veröffentlichten Zahlen des Papers für einen einzelnen Benchmark und keine Messung Ihrer Arbeitslast. Die Differenz zwischen beiden Werten entspricht ungefähr den Kosten, die eine echte Garantie heute verursacht.

Bis ein solches Design in den Tools verfügbar ist, die Sie täglich verwenden, sollten Sie davon ausgehen, dass der Agent irgendwann kompromittiert wird, und diesen Vorfall möglichst folgenlos machen. Genau dafür brauchen Sie eine Wegwerfmaschine, eingeschränkte Zugangsdaten, kontrollierten ausgehenden Netzwerkverkehr und die Gewohnheit, den Diff zu prüfen.

FAQ

Kann ich Prompt-Injection verhindern, indem ich den Agent anweise, Anweisungen in Dateien zu ignorieren?

Nein. Dieser Satz steht im selben Kontextfenster wie der Angriff und konkurriert dort gleichberechtigt mit dem Text des Angreifers. Die Dokumentation von Claude Code zieht die Grenze klar: Anweisungen in Ihrem Prompt oder CLAUDE.md bestimmen, was der Agent zu tun versucht, und ändern nicht, was das Tool zulässt. Betrachten Sie eine Anweisungsdatei als Absichtserklärung. Alles, worauf Sie sich verlassen, gehört in Berechtigungsregeln, einen PreToolUse-Hook oder eine Firewall-Regel.

Ist Prompt-Injection ein reales Risiko, wenn der Agent nur auf mein eigenes Repository zugreift?

Ja, denn Ihr Repository enthält viele Texte, die Sie nicht selbst geschrieben haben. README-Dateien von Abhängigkeiten, URLs in Lockfiles, Test-Fixtures, vendored Code und die Ausgabe von npm install werden während einer gewöhnlichen Aufgabe eingelesen. Alles, was aus einem Issue-Tracker oder einer Dokumentationswebsite übernommen wird, gelangt auf dieselbe Weise dorthin. Das Risiko steigt mit der Menge der Daten, die der Agent liest. Ein nützlicher Agent liest viele Daten.

Ist das Problem gelöst, wenn ich den Agent in einem Container ausführe?

Der mögliche Schaden wird begrenzt. Das gilt aber nur, wenn Sie dem Agent zusätzlich die Anmeldedaten entziehen. Ein Container mit weitergeleitetem SSH-Agent, Cloud-Anmeldedaten in der Umgebung und uneingeschränktem Netzwerkzugriff gibt einem Angreifer fast dieselben Möglichkeiten wie der Host. Der eigentliche Vorteil des Containers ist ein Dateisystem, das Sie löschen können, sowie eine saubere Umgebung zum Durchsetzen von Egress-Regeln. Kombinieren Sie das mit einem Token, der auf ein Repository beschränkt ist.

Welche einzelne Änderung reduziert das Risiko am stärksten?

Entfernen Sie langlebige Anmeldedaten aus der Umgebung, die von den Befehlen des Agents übernommen wird. Geben Sie dem Rechner anschließend eine standardmäßige Egress-Richtlinie mit Default-Deny. Zusammen unterbrechen diese Maßnahmen die dritte Bedingung der gefährlichen Kombination: Text kann den Agent weiterhin übernehmen, aber die Daten, auf die er zugreift, können keinen nützlichen Zielort erreichen. Bestätigungsabfragen und die Prüfung von Diffs helfen ebenfalls. Sie setzen jedoch voraus, dass ein Mensch während eines langen Durchlaufs aufmerksam bleibt. Deshalb stehen sie hinter diesen beiden Änderungen.