Dual-LLM-Muster
Das Dual-LLM-Muster teilt einen Assistenten in ein privilegiertes Modell mit Werkzeugzugriff und ein isoliertes, werkzeugloses Modell für nicht vertrauenswürdige Inhalte. Der Sicherheitsgewinn entsteht nur, wenn unverarbeiteter oder frei formulierter Rücklauf des isolierten Modells nie wieder in den Kontext des privilegierten Modells gelangt.1 Ein konventioneller Controller verwaltet Datenreferenzen und führt freigegebene Aktionen aus.
Einordnung
Das Muster behandelt /was-ist-prompt-injection/ als Vertrauensgrenzenproblem, nicht als bloßes Befolgen einer stärkeren Systemanweisung. E-Mail, Webseiten oder Suchtreffer bleiben potentiell steuernder Fremdinhalt, auch wenn ein Modell sie als „Daten“ beschreiben soll. Das privilegierte Modell plant nur mit vertrauenswürdiger Nutzerabsicht und symbolischen Verweisen; die Inhaltsverarbeitung findet auf der quarantänisierten Seite statt. Zulässig sind höchstens Ausgaben mit eng begrenzter, programmatisch prüfbarer Bedeutung, etwa ein Wert aus einer festgelegten Kategorie. Freitext-Zusammenfassungen, die selbst wieder Anweisungen enthalten könnten, sind gerade kein sicherer Übergabekanal.1 Gegenüber /glossar/camel/ bleibt dies ein Architekturvorschlag mit anspruchsvollen Übergaberegeln, keine formal durchgesetzte Datenfluss-Policy.
Dokumentiertes Beispiel
Simon Willison beschreibt eine Anfrage zum Zusammenfassen der neuesten E-Mail. Der Controller lässt das privilegierte Modell die Nachricht nur in einer Variablen referenzieren, übergibt ihren Inhalt an das quarantänisierte Modell und speichert dessen Ergebnis wiederum als Variable. Das privilegierte Modell sieht weder die fremde E-Mail noch die Zusammenfassung im Klartext, sondern veranlasst nur, dass der Controller das Ergebnis anzeigt.1 Das Beispiel ist keine Produktzusage, macht aber die entscheidende Nebenbedingung sichtbar: Die Trennung scheitert, sobald der Controller den unbereinigten Inhalt oder eine offene Zusammenfassung zurück in einen privilegierten Prompt kopiert. Die spätere CaMeL-Arbeit verfolgt dieselbe Grundintuition der Daten- und Kontrollfluss-Trennung, erzwingt sie aber mit einer Policy-Schicht und Capabilities.2
Bedeutung für die Abwehr
Das Dual-LLM-Muster ist nützlich, wenn eine Aufgabe untrusted Content verstehen muss, der eigentliche Assistent jedoch wirksame Rechte besitzt. Die Abwehrarbeit liegt nicht im Einsatz eines zweiten Modells allein, sondern im Controller: Er muss Daten als nicht interpretierbare Referenzen führen, Übergabeformate strikt validieren und Aktionen außerhalb des Modells autorisieren. OWASP empfiehlt korrespondierend, Werkzeugrechte und -umfang zu minimieren sowie folgenreiche Operationen bestätigen zu lassen.3 Der Preis ist Funktionsverlust: Aufgaben, die aus dem gelesenen Inhalt eigenständig neue Werkzeugschritte ableiten sollen, passen schlecht zu einer strengen Quarantäne. Das Muster ist deshalb eine bewusste Entscheidung zugunsten einer kleineren, klarer überprüfbaren Handlungsmacht.
Quellen
- Simon Willison, „The Dual LLM pattern for building AI assistants that can resist prompt injection“, 25. April 2023, https://simonwillison.net/2023/Apr/25/dual-llm-pattern/ ↩
- Edoardo Debenedetti et al., „Defeating Prompt Injections by Design“, 24. Juni 2025, https://arxiv.org/abs/2503.18813 ↩
- OWASP Gen AI Security Project, „LLM03:2026 Excessive Agency“, 3. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ ↩