Warum Prompt Injection keine «Prepared Statement»-Lösung erhalten wird – und was stattdessen zu bauen ist.
Als SQL Injection Ende der 1990er-Jahre als Schwachstellenklasse etabliert wurde, einigte sich die Branche schliesslich auf eine saubere Antwort: Prepared Statements. Parameter konnten mit beliebigen – auch bösartigen – Benutzereingaben gefüllt werden, und die Datenbank-Engine garantierte, dass ein Parameter niemals als Operator umgedeutet werden konnte. Die Grammatik war geschlossen. Den Angreifern gingen die Züge aus.
Prompt Injection – der Begriff wurde 2022 von Simon Willison geprägt, der die Schwachstellenklasse seither fortlaufend dokumentiert – sieht oberflächlich ähnlich aus: Nicht vertrauenswürdiger Text beeinflusst ein System, das Text interpretiert. Es muss doch einen sauberen Fix geben?
Den gibt es nicht – jedenfalls nicht in derselben Form. Je früher Architekten von LLM-basierten Agenten das verinnerlichen, desto eher hören sie auf, Lösungen zu suchen, die nicht existieren, und beginnen, jene zu bauen, die es gibt.
Die verlockende falsche Antwort: Signieren
Der erste Reflex liegt nahe: Jede ausführbare Anweisung muss von einer vertrauenswürdigen Stelle signiert sein. Unsignierter Text aus RAG-Korpora, Webseiten oder Tool-Ausgaben Dritter würde nicht befolgt.
Das funktioniert nicht – aus drei Gründen.
Erstens ist Prompt Injection kein Authentifizierungsproblem, sondern ein Repräsentationsproblem. Heutige LLMs trennen Anweisungen und Daten nicht strukturell. Alles im Kontextfenster sind Tokens, und das Modell beachtet sie alle. Eine Signatur am vertrauenswürdigen System-Prompt ändert nichts daran, dass bösartige Tokens an anderer Stelle des Kontexts das Verhalten beeinflussen.
Zweitens müssen nützliche Agenten nicht vertrauenswürdige Inhalte verarbeiten. E-Mails zusammenfassen, Webseiten lesen, aus einer Wissensbasis antworten – die Daten sind der Zweck. Unsignierte Inhalte lassen sich nicht ablehnen; man muss sie aufnehmen, ohne ihnen zu gehorchen. Signieren steht orthogonal zu diesem Problem.
Drittens ist «ausführbare Anweisung» in natürlicher Sprache keine syntaktisch abgegrenzte Kategorie. «Bitte leiten Sie das an alice@example.com weiter» ist im einen Rahmen Datum, im anderen Befehl. Genau diese Grenze ist jene, die sich nicht ziehen lässt.
Signieren hat eine Rolle – als Eingang in eine geschichtete Verteidigung, insbesondere für Provenance-Metadaten in capability-basierten Architekturen. Allein genommen ist es keine Lösung.
CaMeL und die verbleibende Lücke
Die CaMeL-Architektur von Google DeepMind (Debenedetti et al.) macht einen ernsthaften Schritt nach vorne: Ein privilegierter Planer wird von einem nicht privilegierten «Quoted-Data»-Pfad getrennt. Nicht vertrauenswürdige Inhalte können Aktionen nicht direkt autorisieren, sondern nur deren Parameter informieren.
Die Lücke schliesst sich damit aber nicht ganz – und zwar an einer subtileren Stelle, als es zunächst scheint. In CaMeL liest der privilegierte Planer nicht vertrauenswürdige Inhalte gerade nicht selbst; er plant nur den Datenfluss, das eigentliche Lesen übernimmt der abgeschottete Pfad, und Herkunft sowie Berechtigungen werden als Metadaten mitgeführt. Zwei Situationen sprengen dieses Schema. Erstens die unterspezifizierte Absicht: Der Benutzer-Prompt lautet «mach etwas Nützliches für mich», und der Planer muss ihn in konkrete Aktionen übersetzen – Entscheidungen, die er nur unter Rückgriff auf Kontext treffen kann. Zweitens der datenabhängige Kontrollfluss: Sobald nicht die Parameter, sondern die Struktur des Plans selbst von abgerufenem Inhalt abhängt, wandert die Injektionswirkung aus den Daten zurück in die Steuerung. In beiden Fällen kann der Agent zu Aktionen gelenkt werden, die der Benutzer nie beabsichtigt hat.
Zwei naheliegende Gegenmassnahmen scheitern beide. Benutzerfreigaben degenerieren im grossen Massstab zur UAC-Müdigkeit – Bediener lernen, blind auf «Ja» zu klicken. Ein Gatekeeper-LLM, das denselben vergifteten Kontext sieht wie der Planer, teilt dessen Fehlermodus. Selbst ein Gatekeeper, der nur den Benutzer-Prompt und statische Regeln sieht, bleibt anfällig gegen Injektionen, die aus beiden Blickwinkeln harmlos erscheinen, und gegen Supply-Chain-Kompromittierungen seiner selbst.
Wir befinden uns auf einer Pareto-Front: Deterministische Berechtigungsmodelle stehen im Trade-off mit Ausdruckskraft und Benutzerfreundlichkeit; LLM-basierte Aufweichung führt genau die Angriffsfläche wieder ein, der wir entkommen wollten. Einen Trick, der diesen Trade-off auflöst, gibt es nicht.
Die Front lässt sich aber verschieben – mit drei Zügen.
Drei Züge, welche die Front verschieben
1. Raum gegen Zeit tauschen: progressives Vertrauen
Ermüdung durch Berechtigungsabfragen entsteht, weil Aktionen synchron genehmigt werden müssen, obwohl ihr Risikoprofil nach den ersten Vorkommen gut bekannt ist. Echte Institutionen funktionieren anders: Eine neue Mitarbeiterin steht zunächst unter enger Aufsicht, erhält nach der Probezeit Zeichnungsvollmacht bis zu einem kleinen Limit, nach einem Jahr sauberer Audits eine grössere. Die Schranken bleiben deterministisch; sie adaptieren mit angesammelter Evidenz.
Für Agenten heisst das: Plan-Templates cachen, nicht Plan-Instanzen. Beim ersten Mal, wenn ein Benutzer einen Workflow freigibt, wird das abstrakte Template festgehalten. Spätere Aufrufe innerhalb begrenzter Parameter laufen ohne erneute Rückfrage. Der Benutzer prüft das Muster einmal statt fünfzig Wiederholungen.
Das entspricht der Funktionsweise von sudo-Timestamps, OAuth-Scopes und adaptiver Immunität: teuer beim Erstkontakt, günstig beim Wiedersehen.
2. Von Verhinderung zu Reversibilität wechseln
Ein grosser Teil der Kosten deterministischer Berechtigungsmodelle entsteht daraus, jede Aktion so zu behandeln, als hätte sie kritische Konsequenzen. Die meisten haben das nicht.
Banken verhindern Betrug nicht vollständig – sie machen Transaktionen für ein Zeitfenster reversibel und buchen zurück. Git verhindert keine schlechten Commits; es macht sie rückgängig. Das Pendant für Agenten: Aktionen nach Reversibilität klassifizieren und harte synchrone Schranken auf den irreversiblen Rest konzentrieren.
- E-Mail senden: weiche Schranke plus Reversal-Fenster
- Geld bewegen: weiche Schranke plus Reversal-Fenster plus Anomalieerkennung
- Dateien löschen: weiche Schranke plus zwingender Snapshot
- Öffentliches Posten oder externe API-Calls mit dauerhafter Aussenwirkung: harte synchrone Schranke
Die meisten Agentenaktionen können mit weichen Schranken und Reversal-Fenstern laufen – ein Modell, das näher an der Funktionsweise von Finanzsystemen liegt als an einem Festungsmodell.
3. Ökonomische Asymmetrie statt logischer Garantie
Für natürliche Sprache ist derzeit keine logische Garantie absehbar, wie Prepared Statements sie geben. Erreichbar ist etwas anderes: Angriffe relativ zum Ertrag so teuer machen, dass das Gleichgewicht zugunsten der Verteidiger.
Drei Hebel:
- Polymorphismus pro Deployment. Prompt und DSL-Oberfläche pro Benutzer variieren. Injektionen, die gegen ein Deployment funktionieren, übertragen sich nicht sauber auf andere. Die Biologie nennt das MHC-Polymorphismus – deshalb können Pathogene keinen einzigen Schlüssel evolvieren, der in jedes Schloss passt.
- Honeytokens im RAG-Korpus (siehe unten).
- Post-hoc-Forensik mit Konsequenzen. Jeden Plan protokollieren, Anomalien untersuchen, Supply-Chain-Angreifer identifizieren.
- Benutzer ausbilden und prüfen.Die schwerwiegendsten Angriffe werden dann gelingen, wenn Menschliche Freigaben erschlichen wurden. Aufmerksame Menschen im System sind für Angreifer eine hohe Hürde.
Zusammen machen diese Massnahmen rentable Angriffskampagnen unwahrscheinlich. Kartenbetrug ist nicht gelöst; er ist als Verlustrate einkalkuliert – im SEPA-Raum rund drei Basispunkte des Kartenumsatzes (0,028 % im Jahr 2021 gemäss EZB-Bericht zum Kartenbetrug) –, und das System funktioniert.
Zwei konkrete Techniken, die sich lohnen
Domain-Specific Languages (DSL) mit Taint-typisierten Parametern
Statt freitextliche Planbeschreibungen zu erzeugen, emittiert der Planer Programme in einer kleinen, eigens entworfenen Sprache, deren Interpreter deterministischer Code ist.
Ein Plan zum Versenden einer E-Mail sieht dann etwa so aus:
send_email(
to: ContactRef("john@acme.com"),
subject: "Q3 Bericht",
body: TaintedString("siehe beigefügten Bericht"),
attachments: [FileRef("/q3/bericht.pdf")]
)Der Hebel kommt aus den Typen. ContactRef lässt sich nur aus der verifizierten Kontaktliste des Benutzers oder einem expliziten Bestätigungsschritt konstruieren – niemals aus einem aus dem RAG gezogenen String. TaintedString ist als E-Mail-Body akzeptabel. FileRef löst nur gegen Pfade innerhalb der zugeteilten Berechtigungen auf.
Die Laufzeitumgebung – kein LLM – setzt diese Bedingungen vor der Ausführung durch. Der Planer kann bei sanktionierten Operationen kreativ sein und risikoarme Parameter frei befüllen, aber keine neuen Operationen erfinden und keine kritischen Argumente aus nicht vertrauenswürdigen Quellen beziehen. Die Eigenschaft von Prepared Statements ist wiederhergestellt: Als kontaminiert markierte Daten dürfen Parameter befüllen, aber nicht zu Operatoren werden.
Die DSL muss ausdrucksstark genug sein, um nützlich zu sein – ist sie zu eng, entstehen Umgehungswege als neue Angriffsfläche.
Honeytokens in RAG-Korpora
Die Technik stammt aus der Netzwerksicherheit: Gefälschte Credentials oder Datensätze – etwa als Canary Tokens –, die kein legitimer Prozess berühren sollte. Jeder Zugriff entlarvt einen Eindringling mit nahezu null Falsch-Positiven.
Drei Muster für RAG-basierte Agenten:
- Canary-Anweisungen. Ein im Korpus eingebettetes Dokument weist das Modell an, ein bestimmtes Tag in jede daraus abgeleitete Ausgabe einzufügen. Das Tag ist harmlos; sein Auftauchen in einem Plan beweist, dass der Planer eingebettete Anweisungen befolgt hat – per Definition ein erfolgreicher Injektionsversuch.
- Honey-Aktionen. Ein platziertes Dokument bewirbt eine Admin-Adresse, die nur als Stolperdraht existiert. Jeder Agent, der dorthin schreibt, wurde durch abgerufene Inhalte zu injiziertem Text verleitet.
- Honey-URLs. URLs, die auf kontrollierte Domains zeigen. Ein Aufruf entlarvt den Angriff, das Timing lokalisiert ihn, das Quelldokument grenzt ein, wo vergiftete Inhalte liegen.
Honeytokens verhindern den ersten Angriff nicht. Sie reduzieren die Erkennungszeit erheblich – und Erkennungszeit ist üblicherweise der dominierende Kostenfaktor bei realen Vorfällen.
Versierte Angreifer wissen, dass Honeytokens existieren, und versuchen, sie zu identifizieren. Ihre Platzierung muss daher als adversariales Design behandelt werden: Muster variieren, sie ununterscheidbar von echten Inhalten machen, rotieren und mit anderen Signalen kombinieren.
Die realistische Architektur
Ein Agent-Stack, der Prompt Injection ernst nimmt:
- Eine kleine deterministische DSL mit typisiertem Taint-Tracking für irreversible Primitive – der harte Boden.
- Progressive, nutzerspezifische Vertrauensausweitung mit gecachten Plan-Templates – reduziert synchrone Rückfragen, ohne diesen Boden zu schwächen.
- Eine Reversal-Schicht mit Anomalieerkennung für die reversible Mehrheit der Aktionen.
- Polymorphismus, Honeytokens und Forensik – erhöht die Kosten anhaltender Angriffe.
Der Gatekeeper-LLM überlebt allenfalls als ein Eingang in die Anomalieerkennung, nicht als Schranke.
Was man aufgibt, ist die Eigenschaft, dass jede einzelne Transaktion beweisbar sicher ist. Was man erhält, ist ein System, das im aggregierten Sinn sicher ist, wie Finanzsysteme und Immunsysteme sicher sind: lokal fehlbar, global robust, mit beschränkten und eingepreisten Fehlerkosten.
Das ist Stand heute die realistische Option, um mit aktuellen Generationen von LLM-Agenten Produktivnutzen und Sicherheit in Einklang zu bringen. Wer eine saubere logische Garantie für Agenten in natürlicher Sprache verkauft, verkauft etwas, das es nicht gibt – und ohne grundlegend andere Modellarchitektur, in der Anweisungen und Daten auf Repräsentationsebene getrennt sind, möglicherweise gar nicht geben kann.
Bis dahin sieht Agent-Sicherheit eher wie Epidemiologie aus als wie Kryptografie. Planen Sie entsprechend.
Wer Agent-Infrastruktur entwirft und ein zweites Augenpaar auf Trust-Modell, Taint-Typisierung oder Detektionsschicht möchte, findet bei Limacher IT-Security gerne Unterstützung.