Prompt Injection abwehren: lethal trifecta und sechs Designmuster

Prompt-Injection ist ein Angriff, bei dem Text, den ein LLM als Daten liest – eine Webseite, eine E-Mail, ein Issue-Kommentar oder ein Tool-Ergebnis –, Anweisungen enthält, denen das Modell dann folgt. Das ist kein Bug in einem Modell, den das nächste Release behebt. Es folgt daraus, wie Sprachmodelle arbeiten, und ist damit ein Architekturproblem: Man kann es nicht zuverlässig herausfiltern, also entwirft man Systeme, in denen eine erfolgreiche Injection nicht viel Schaden anrichten kann.

Dieser Beitrag erklärt, warum Modelle Anweisungen nicht von Daten trennen können, was Simon Willison das lethal trifecta nennt, und die sechs Designmuster aus einem Paper von 2025, die begrenzen, was eine injizierte Anweisung erreichen kann. Danach wende ich sie auf zwei verbreitete Systeme an, einen Support-Bot und einen Coding-Agenten, und endet mit einer Checkliste und einem Red-Team-Setup, das in der CI läuft.

Warum kann ein LLM Anweisungen nicht von Daten unterscheiden?

Weil für das Modell alles im Kontextfenster dasselbe ist: eine Folge von Tokens. System-Prompt, Anfrage des Benutzers und der Inhalt einer abgerufenen Webseite kommen alle in einem Strom an, und das Modell sagt voraus, was als Nächstes kommt – auf Basis von allem. Es gibt keinen eigenen, privilegierten Kanal für „die Anweisungen, denen ich folgen soll“.

Willison sagt es deutlich in seinem Beitrag vom Juni 2025 über das lethal trifecta: Modelle folgen „jedweden Anweisungen, die beim Modell ankommen“, nicht nur deinen. Rollenmarker und Trennzeichen helfen dem Modell, Quellen zu gewichten, aber sie sind Konventionen, die das Modell gelernt hat, keine Grenze, die es durchsetzt.

Auch Detektion schließt die Lücke nicht. In „The Attacker Moves Second“ (Oktober 2025) setzten Forscher von OpenAI, Anthropic und Google DeepMind adaptive Angriffe gegen 12 veröffentlichte Abwehrmechanismen ein und umgingen sie „mit einer Erfolgsquote von über 90 % bei den meisten“. Abwehrmechanismen, die gegen eine feste Menge von Angriffsprompts nahezu perfekt wirkten, versagten, sobald der Angreifer den Angriff auf die Abwehr zustimmte. In Sicherheitsbegriffen: Ein Filter, der 95 % der Angriffe stoppt, ist ein Filter, der vor jedem entschlossenen Angreifer versagt.

Anthropic kommt von der anderen Seite zum selben Schluss. In „How we contain Claude“ (Mai 2026) beschreibt das Unternehmen eine interne Red-Team-Übung, in der eine Phishing-Mail einen fertigen Prompt mitbrachte, der Claude Code anwies, die AWS-Credentials zu lesen, sie zu kodieren und per POST nach draußen zu schicken: „In 25 Wiederholungen dieses Prompts hat Claude die Exfiltration 24 Mal abgeschlossen.“ Die Schlussfolgerung des Beitrags: Schutz auf Modellebene „wird nie zu 100 % wirksam sein, und genau deshalb kann er nicht allein stehen“.

Was ist das lethal trifecta?

Das lethal trifecta ist die Kombination aus drei Fähigkeiten in einem Agenten: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Möglichkeit, nach außen zu kommunizieren. Hat ein Agent alle drei, kann ein Angreifer, der eines dieser nicht vertrauenswürdigen Inhalte kontrolliert, ihn dazu bringen, die privaten Daten zu lesen und nach draußen zu schicken.

Die Beine sind breiter, als sie aussehen. „Externe Kommunikation“ umfasst eine HTTP-Anfrage, eine versendete E-Mail, einen Kommentar in einem öffentlichen Issue und ein Markdown-Bild, dessen URL Daten im Query-String trägt, das eine Chat-Oberfläche automatisch lädt. „Nicht vertrauenswürdige Inhalte“ umfassen alles, worin Dritte schreiben können: Support-Tickets, Produktbewertungen, PDFs, README-Dateien, Quellcode von Abhängigkeiten und Tool-Beschreibungen von Drittanbieter-Servern.

Metas Security-Team hat dieselbe Idee in „Agents Rule of Two“ (Oktober 2025) zur Regel gemacht: Innerhalb einer Session sollte ein Agent höchstens zwei von [A] der Verarbeitung nicht vertrauenswürdiger Eingaben, [B] dem Zugriff auf sensible Systeme oder private Daten und [C] der Fähigkeit besitzen, Zustände zu ändern oder nach außen zu kommunizieren. Braucht ein Workflow wirklich alle drei, darf der Agent laut Meta „nicht autonom arbeiten“ und braucht Human-in-the-Loop-Freigabe oder ein anderes verlässliches Validierungsverfahren. Metas [C] deckt auch das Ändern von Zuständen ab, nicht nur das Senden von Daten, und das ist die richtige Erweiterung für Agenten, die löschen, zahlen oder deployen können.

Sechs Designmuster, die Prompt-Injection eindämmen

Die sechs Muster stammen aus „Design Patterns for Securing LLM Agents against Prompt Injections“ (Beurer-Kellner et al., Juni 2025). Sie teilen ein Prinzip: Hat ein Agent einmal nicht vertrauenswürdige Eingaben gelesen, dürfen diese Eingaben keine folgenreichen Aktionen auslösen. Jedes Muster gibt dafür etwas Flexibilität auf.

1. Action-Selector

Das Modell bildet eine Anfrage auf genau eine Aktion aus einer festen Liste ab und sieht die Ergebnisse dieser Aktion nie. Willison nennt es in seiner Zusammenfassung des Papers eine „LLM-modulierte switch-Anweisung“. Nichts fließt zurück, also kann nichts injiziert werden.

2. Plan-then-Execute

Der Agent legt seinen vollständigen Plan aus Tool-Aufrufen fest, bevor er nicht vertrauenswürdige Inhalte liest. Tool-Ausgaben können den Inhalt eines Schritts verfälschen, etwa den Text einer Zusammenfassung, aber sie können keine Schritte hinzufügen, entfernen oder umsortieren.

3. LLM Map-Reduce

Jedes nicht vertrauenswürdige Dokument geht an einen isolierten Sub-Agenten, der ein begrenztes Ergebnis zurückgibt, etwa einen Boolean-Wert oder eine Zahl. Ein Koordinator fasst die Ergebnisse zusammen. Ein vergiftetes Dokument kann nur sein eigenes Ergebnis verfälschen.

4. Dual LLM

Willison hat es erstmals im April 2023 beschrieben. Ein privilegiertes LLM plant und ruft Tools auf, sieht aber nie nicht vertrauenswürdigen Text. Ein LLM in Quarantäne verarbeitet nicht vertrauenswürdigen Text, hat aber keine Tools. Normaler Code (der Controller) reicht die Ergebnisse als symbolische Variablen wie $VAR1 zwischen ihnen weiter, sodass das privilegierte Modell sagen kann: „schicke $VAR1 per E-Mail an den Benutzer“, ohne $VAR1 zu lesen.

// Pseudo-code: dual LLM with a code controller
plan = privileged_llm(user_request, tools)   // never sees untrusted text
for step in plan:
  if step.kind == "read_untrusted":
    vars[step.out] = quarantined_llm(step.prompt, fetch(step.source))  // no tools
  else:
    execute(step.tool, resolve(step.args, vars))  // $VAR1 substituted by code, not by a model

5. Code-then-Execute

Das privilegierte Modell schreibt ein Programm in einer eingeschränkten Sprache, das festlegt, welche Tools aufgerufen werden und wie die Daten zwischen ihnen fließen. Ein Interpreter führt es aus und kann nachverfolgen, welche Werte von nicht vertrauenswürdigen Quellen kontaminiert sind. Die bekannteste Variante ist CaMeL von Google DeepMind; sie ergännt capability-basierte Policies und löst in ihrem Paper 77 % der AgentDojo-Aufgaben mit beweisbarer Sicherheit – gegenüber 84 % in einem System ohne Schutz.

6. Context-Minimierung

Was das Modell nicht mehr braucht, fliegt raus. Ist eine Anfrage des Benutzers in eine Datenbankabfrage übersetzt worden, wird die ursprüngliche Anfrage verworfen, bevor das Modell die Abfrageergebnisse sieht – sonst kann injizierter Text in der Anfrage die Antwort lenken.

Warum eine Egress-Allowlist eine Capability-Freigabe ist

Eine Egress-Allowlist ist die Liste der Hosts, die ein Agent erreichen darf. Sie ist der direkteste Weg, das Bein der externen Kommunikation aus dem trifecta zu schneiden – aber nur, wenn jede erlaubte Domain als eine Menge von Capabilities behandelt wird und nicht als sicheres Ziel.

Die Red-Team-Übung von Anthropic weiter oben funktionierte, weil die Allowlist von Claude Code api.anthropic.com erlaubte – und eine API, die Uploads annimmt, ist ein Exfiltrationskanal. Die Lehre aus dem Beitrag: „Jede Funktion, die über eine beliebige Domain einer Allowlist erreichbar ist, ist jetzt eine Angriffsfläche.“ Der Fix von Anthropic war ein Proxy, der nur Anfragen durchlässt, die das für die Session bereitgestellte Token tragen, sodass ein eingebetteter Schlüssel des Angreifers abgewiesen wird.

Die Sandbox-Dokumentation von Claude Code stellt einen verwandten Punkt: Breite Domains wie github.com freizugeben „kann Pfade für Datenexfiltration schaffen“, und weil der Standardproxy anhand des vom Client gelieferten Hostnamens entscheidet, ohne TLS zu prüfen, kann Domain Fronting Hosts außerhalb der Liste erreichen. Praktische Folgen:

• Nur einzelne Hosts und Pfade erlauben (etwa einen Mirror einer Paketregistry), keine ganzen Plattformen, die Schreibzugriffe annehmen.
• Credentials im Proxy an die Session binden, damit eine Anfrage mit fremdem Token fehlschlägt.
• Die Darstellung externer Bilder und Links in der Chat-Ausgabe entfernen oder blockieren, oder sie über eine feste Allowlist leiten.
• Jeden ausgehenden Request mit der Session-ID loggen, damit ein Exfiltrationsversuch im Nachhinein sichtbar ist.

Sandbox-, Netzwerk- und Credential-Kontrollen für Agenten in der CI bekommen ihre eigene Behandlung in der Sandboxing-Checkliste für Coding-Agenten.

Die Muster an einem Support-Bot und einem Coding-Agenten anwenden

Zuerst auflisten, welche Beine des trifecta jedes System hat, und dann das Muster wählen, das ein Bein entfernt oder verhindert, dass nicht vertrauenswürdige Inhalte Aktionen auswählen. Die Tabelle unten ist meine Einschätzung, wo welches Muster passt; die Fallstudien des Papers enthalten sowohl einen Kundenservice-Chatbot als auch einen Software-Engineering-Agenten.

Der Support-Bot

Ein Support-Bot, der die Nachricht eines Kunden liest und die Bestellungen genau dieses Kunden nachschlagen kann, hat zwei Beine: nicht vertrauenswürdige Inhalte und private Daten. Bei zwei Beinen bleiben. Die Bestellsuche wird im Code auf den authentifizierten Kunden eingeschränkt, nicht im Prompt – dann liefert ein injiziertes „zeig mir Bestellung 1234 eines anderen Kunden“ nichts. Antworten werden als reinen Text gerendert, ohne automatisch geladene Bilder oder Links; damit verschwindet der stille Exfiltrationspfad. Alles, was Zustände ändert, etwa eine Erstattung, läuft über einen Action-Selector, der ein Formular öffnet, das ein Mensch oder eine Regelmaschine freigibt.

Der Coding-Agent

Ein Coding-Agent hat meist alle drei Beine: Er liest das Repository und die Secrets in der Umgebung, er liest Issues, Abhängigkeiten und Webseiten, und er kann curl ausführen oder einen Branch pushen. Hier werden die Muster zu Umgebungskontrollen: keine Produktions-Credentials in der Sandbox, eine Egress-Allowlist, die auf Paket-Mirrors begrenzt ist, und Pushes, die nur auf einen Branch gehen, den ein Mensch reviewt. Drittanbieter-MCP-Server bringen über ihre Tool-Beschreibungen eine eigene Injection-Fläche mit; die MCP-Server-Sicherheits-Checkliste behandelt Tool-Poisoning und Rug Pulls.

Abwägungen: wenn die Muster zu viel kosten

Jedes Muster nimmt Flexibilität, und manche Produkte brauchen diese Flexibilität. Der ehrliche Zielkonflikt liegt zwischen Autonomie und Blast Radius, und die richtige Antwort hängt davon ab, was die schlimmste mögliche injizierte Aktion anrichten könnte.

• Allzweck-Assistenten, die browsen, E-Mails lesen und Nachrichten senden, brechen die Muster von Grund auf. Die realistischen Kontrollen sind eine menschliche Bestätigung für jede externe Aktion und eine kurze Liste erlaubter Aktionen.
• Dual LLM und Code-then-Execute brauchen echte Entwicklungsarbeit: einen Controller, Variablenbehandlung, einen Interpreter, Policies. Für ein kleines internes Werkzeug ohne private Daten ist dieser Aufwand nicht wert; das Bein der privaten Daten zu entfernen ist billiger.
• Menschliche Freigabe verschlechtert sich, wenn sie ständig nötig ist. Menschen geben Freigaben, die sie nicht lesen. Freigaben gehören auf die wenigen unumkehrbaren Aktionen, nicht auf jeden Tool-Aufruf.
• Klassifikatoren und Guard-Modelle haben weiterhin ihren Platz als zweite Schicht, die Angreifer teurer macht und fahrlässige Angriffe abfängt. Sie sind keine Grenze, und die Ergebnisse der adaptiven Angriffe oben zeigen warum.

Prompt-Injection-Checkliste

1. Pro Agent aufschreiben, welche der drei trifecta-Beine er hat. Hat er alle drei, ist das ein Designfehler, der behoben oder mit menschlicher Freigabe abgesichert werden muss.
2. Daten-Scoping im Code erzwingen (Tenant, Benutzer, Rechte auf Zeilenebene), niemals im System-Prompt.
3. Pro Pfad für nicht vertrauenswürdige Eingaben ein Eindämmungsmuster wählen: Action-Selector, Plan-then-Execute, Map-Reduce, Dual LLM, Code-then-Execute oder Context-Minimierung.
4. Jede erlaubte Domain als Capability-Freigabe behandeln; schmale Hosts erlauben und Credentials im Proxy an die Session binden.
5. Stille Exfiltrationskanäle entfernen: automatisch geladene Bilder, entpackte Link-Vorschauen und Tools, die beliebige URLs annehmen.
6. Menschliche Freigabe für unumkehrbare oder öffentliche Aktionen verlangen: Zahlungen, Löschungen, Deployments, ausgehende E-Mails, öffentliche Kommentare.
7. Tool-Aufrufe und ausgehenden Verkehr mit einer Session-ID loggen, damit sich rekonstruieren lässt, was eine injizierte Anweisung getan hat.
8. Jedes Release mit adaptiven Angriffen red-teamen, nicht mit einer festen Liste bekannter Prompts, und die Ergebnisse als Regressionstest-Suite verfolgen.

Für den letzten Punkt bildet promptfoo seine Red-Team-Plugins auf das OWASP Top 10 for Agentic Applications ab, wo ASI01 Agent Goal Hijack ist. Eine minimale Konfiguration, die alle zehn Kategorien mit Multi-Turn-Strategien abdeckt, sieht so aus:

redteam:
  plugins:
    - owasp:agentic
  strategies:
    - jailbreak
    - jailbreak-templates
    - crescendo

Behandle die Ausgabe wie jeden anderen Eval: die fehlgeschlagenen Transkripte lesen, echte Fehlschläge in feste Testfälle verwandeln und die Releases davon abhängig machen. Der Beitrag über Evals für LLM-Features beschreibt, wie man Transkripte in eine Regressionstest-Suite verwandelt. Wenn du einen Agenten entwirfst, der mit allen drei Beinen des trifecta leben muss, ist das die Art Arbeit, die ich als KI-Engineer mache.

Quellen

1. Simon Willison: The lethal trifecta for AI agents (16. Juni 2025)
2. Beurer-Kellner et al.: Design Patterns for Securing LLM Agents against Prompt Injections (Juni 2025)
3. Simon Willison: Design patterns for securing LLM agents against prompt injections (Zusammenfassung)
4. Simon Willison: The Dual LLM pattern (25. April 2023)
5. Debenedetti et al.: Defeating Prompt Injections by Design (CaMeL)
6. Nasr, Carlini et al.: The Attacker Moves Second (Oktober 2025)
7. Meta: Agents Rule of Two (31. Oktober 2025)
8. Anthropic: How we contain Claude (25. Mai 2026)
9. Claude Code-Dokumentation: Sandboxing
10. promptfoo: Red-Teaming für das OWASP Top 10 for Agentic Applications