OWASP sagt, Prompt Injection ist ungelöst. Konfiguration wird Sie nicht retten.
Die Sicherheitsbranche hat zwei Jahre lang Prompt Injection wie einen Bug behandelt: etwas, das ein guter Filter, ein strengerer System-Prompt oder die nächste Modellversion schon aufräumen würde. Diese Rahmung ist bequem, weil sie unterstellt, das Problem habe einen Eigentümer und ein Patch-Datum. Sie ist auch falsch, und die Menschen, die dem Problem am nächsten sind, sagen das inzwischen laut.
Nur ist die Geschichte von der Infosecurity Europe, wie Infosecurity Magazine berichtet, nicht "wir haben einen besseren Filter gefunden". Sie ist das Gegenteil. OWASP führt Prompt Injection als Risiko Nummer eins für LLM-Anwendungen, und ein OWASP-Forscher nutzte eine öffentliche Bühne, um zu warnen, dass sie ungelöst bleibt. Nicht schwer. Nicht teilweise entschärft. Ungelöst. Das ist eine andere Art von Aussage, als die Branche über eine Spitzenreiter-Schwachstelle zu hören gewohnt ist, und sie sollte ändern, wie Sie entwerfen, nicht nur, wie Sie sich sorgen.
Denn wenn die eigene Autorität des Feldes für LLM-Risiken Ihnen sagt, dass das Problem auf Modellebene keine Behebung hat, dann steht jede Abwehr, die eine kommende Behebung voraussetzt, auf Sand.
"Ungelöst" ist eine Entwurfseingabe, kein Haftungsausschluss
Die meisten hören "ungelöst" und legen es unter schlechte Nachrichten zum Verwalten ab. Das ist der falsche Ort. Ungelöst ist eine architektonische Tatsache, und sie diktiert, was ein verantwortlicher Entwurf annehmen darf.
Prompt Injection ist aus einem strukturellen Grund ungelöst, nicht aus einem Reifegrund. Ein Sprachmodell liest einen Strom von Tokens und kann die Anweisungen, die Sie ihm gaben, nicht zuverlässig von den Inhalten trennen, die es verarbeiten soll. Liest es ein Dokument, kommen der Text des Dokuments und Ihre Befehle über denselben Kanal, und das Modell hat keinen privilegierten Weg zu wissen, was was ist. Deshalb widersteht das Problem dem Patchen: Es ist eine Eigenschaft davon, wie das Modell liest, kein Mangel eines bestimmten Modells.
Die Berichterstattung von Help Net Security zum selben OWASP-Material benennt die umliegenden Fehler deutlich, und der rote Faden ist konsistent. Die Angriffsfläche schrumpft nicht, während Modelle besser werden. Sie wächst, während sie an mehr Werkzeuge verdrahtet werden. Neben der OWASP-Warnung zitierte Berichte verweisen auf einen starken Anstieg dieser Angriffe im Jahresvergleich, genau das, was man erwartet, wenn die zugrunde liegende Schwäche strukturell ist und die Zahl ausgerollter Agenten steigt.
Die ehrliche Planungsannahme lautet also nicht "Injection wird auf eine akzeptable Rate gesenkt". Sie lautet "Injection wird manchmal gelingen, und meine Architektur muss dann sicher bleiben". Alles Weitere folgt daraus, diesen Satz anzunehmen, statt mit ihm zu streiten.
Konfiguration ist keine Grenze
Hier scheitern die meisten Unternehmensabwehren still. Vor einem ungelösten Problem greifen Teams zur Konfiguration: ein besserer System-Prompt, ein Trennzeichen um unzuverlässigen Text, ein Klassifikator, der verdächtige Eingaben markiert. Das hilft, und Sie sollten es nutzen. Aber nichts davon ist eine Grenze. Es sind Wahrscheinlichkeitsminderer, und ein Wahrscheinlichkeitsminderer auf einem strukturell ungelösten Problem senkt die Fehlerrate, ohne je null zu erreichen.
Warum Konfiguration nicht reicht, wurde 2026 konkret. CVE-2025-6514 mit einem CVSS-Score von 9,6 wurde in zentraler MCP-Infrastruktur offengelegt, Remote Code Execution in der Installation, die Agenten mit Werkzeugen verbindet. Und Microsoft dokumentierte in seiner Untersuchung "when prompts become shells", wie Prompt Injection aufhört, ein Textproblem zu sein, und zu einem Code-Ausführungs-Primitiv wird, sobald ein Agent an echte Werkzeuge verdrahtet ist. Das ist die Eskalation, die zählt. Auf einem Chatbot erzeugt eine gelungene Injection einen schlechten Satz. Auf einem Agenten mit Werkzeugen erzeugt dieselbe Injection eine Aktion, und hat die Installation eine RCE, erzeugt sie beliebigen Code in Ihrer Umgebung.
Keine System-Prompt-Feinjustierung adressiert das. Die Lücke zwischen "das Modell hat etwas Falsches gesagt" und "der Agent hat etwas Falsches getan" schließt Konfiguration nicht, denn die Gefahr ist nicht, was das Modell glaubt. Sie ist, was das Modell tun darf, wenn es das glaubt. Ein Klassifikator, der eine gebastelte Eingabe verfehlt, ist nicht sanft degradiert. Er hat einem Angreifer die Werkzeuge dahinter übergeben.
Ein strukturelles Problem braucht eine strukturelle Antwort
Lässt sich das Problem auf Modellebene nicht lösen, ist der einzig verantwortliche Zug, aufzuhören, das Modell vertrauenswürdig machen zu wollen, und anzufangen, die Fehler des Modells harmlos zu machen. Das ist eine Verschiebung von Wahrscheinlichkeit zu Struktur, und sie hat eine bestimmte Gestalt.
Eine Taint-Grenze. Unzuverlässige Daten, alles, was der Agent gelesen und nicht verfasst hat, werden markiert und können nie zu ausführbarem Privileg werden. Das ist kein Filter, an dem unzuverlässiger Inhalt vorbeirutschen könnte. Es ist eine Regel darüber, was unzuverlässiger Inhalt strukturell werden darf, vom System durchgesetzt statt vom Modell erhofft.
Das CaMeL-Dual-LLM-Muster. Teilen Sie die Arbeit auf zwei Modelle. Ein privilegierter Planer plant und ruft Werkzeuge auf, liest aber nie unzuverlässige Inhalte. Ein isolierter Reader liest das vergiftete Dokument und extrahiert das Nötige, hält aber keine Werkzeuge und kann nicht handeln. Bei jedem Zweifel schlägt das Muster geschlossen fehl. Die Komponente, die den Angriff sieht, hat keine Hände, und die Komponente mit Händen sieht den Angriff nie. Wo ein Klassifikator die Chance auf Verwirrung senkt, entfernt dies die Fähigkeit, darauf zu handeln.
Least-Privilege-Identität ohne Menschen. Jeder Agent läuft unter seiner eigenen kurzlebigen, zugeschnittenen Identität mit expliziter Egress-Allow-List, sodass eine gelungene Injection einen Akteur befehligt, der nur eine Handvoll benannter Aktionen zu einer Handvoll erlaubter Ziele ausführen kann. Ein gestohlener oder gekaperter Agent ist fast nichts wert, weil es keine stehende Macht zu missbrauchen gibt.
Defense-in-Depth. Keine dieser Schichten soll allein halten. Sie werden geschichtet, damit ein Umgehen der einen auf der nächsten landet, gerade weil "ungelöst" heißt, dass jedes einzelne Control irgendwann von etwas Neuem geschlagen wird.
Beachten Sie, was alle vier eint. Keine versucht, das Modell gegen Injection zu härten. Jede nimmt an, dass die Injection gelingt, und sorgt dafür, dass der Erfolg nichts Folgenschweres bewirkt. So sieht eine strukturelle Antwort auf ein strukturelles Problem aus.
Die Umdeutung
Die Frage, die die Branche immer wieder stellt und die direkt zum nächsten Klassifikator führt, lautet "wie stoppen wir Prompt Injection?". OWASP hat sie gerade beantwortet: Sie stoppen sie nicht, nicht auf Modellebene, noch nicht, vielleicht nie. Ihre Abwehr um die Lösung herum zu organisieren heißt, sich um eine Lösung zu organisieren, die es nicht gibt.
Die bessere Frage lautet: wenn eine Injection gelingt, und OWASP sagt uns, dass sie das wird, was verhindert unsere Architektur strukturell, dass sie tut? Lautet die Antwort "hängt davon ab, ob der Klassifikator sie fängt", haben Sie keine Grenze, sondern eine Wette. Lautet sie "die Komponente, die den Angriff las, kann nicht handeln, und der handlungsfähige Akteur läuft unter einer Identität, die auf fast nichts zugeschnitten ist", haben Sie ein ungelöstes Problem eingedämmt, statt so zu tun, als sei es gelöst.
Die Modellschicht wird Sie nicht retten. Konfiguration wird Sie nicht retten. Struktur ist das Einzige, was hält, wenn das, wogegen Sie sich verteidigen, keine Behebung hat.
Wenn Sie Ihre laufenden Agenten gegen die vier strukturellen Controls prüfen und finden wollen, wohin eine gelungene Injection tatsächlich reichen würde, buchen Sie einen Termin und bringen Sie uns den mit, der an die meisten Werkzeuge verdrahtet ist.