19. Oktober 2026
Das Grundproblem: ein gemeinsamer Kontext
Ein Sprachmodell verarbeitet keinen technisch sicheren Kanal für „Befehl“ und einen anderen für „Daten“. Systemvorgaben, Nutzereingaben, Dokumente, E-Mails, Suchtreffer oder Webseiten landen letztlich als Text im Kontext. Rollen und Markierungen geben dem Modell zwar Orientierung. Sie sind aber keine harte Sicherheitsgrenze.
Genau dort beginnt Prompt Injection. In einem abgerufenen Dokument kann Text stehen, der wie eine Arbeitsanweisung formuliert ist: frühere Regeln ignorieren, Daten weitergeben oder ein Tool benutzen. Das Modell kann diesen Text als relevant für seine nächste Antwort interpretieren, obwohl die Anwendung ihn nur als Inhalt behandeln wollte.
Das ist keine bloße Frage der Prompt-Qualität. Ein LLM kann Bedeutung und Priorität von Text nicht verlässlich so trennen, wie eine Anwendung Datenfelder und Berechtigungen trennt. Deshalb ist LLM Sicherheit vor allem eine Architekturaufgabe.
Direkte und indirekte Prompt Injection
Bei einer direkten Prompt Injection liefert die Person am Chat selbst die problematische Anweisung. Das ist sichtbar und lässt sich oft zumindest durch Produktlogik, Eingabegrenzen oder eine klare Interaktion entschärfen.
Die indirekte Prompt Injection ist schwieriger. Hier stammt die Anweisung aus Inhalten, die das System selbst abruft. Das kann ein Dokument in einer Wissensbasis, eine E-Mail, ein Ticket oder eine Webseite sein. Die Person stellt etwa eine harmlose Frage zu einem Dokument. Der Agent liest den Inhalt, findet darin anweisungsähnlichen Text und folgt ihm möglicherweise.
Ein typisches Szenario: Ein LLM-Agent darf Dokumente durchsuchen und anschließend eine Nachricht vorbereiten. Ein abgerufenes Dokument enthält die Aufforderung, vertrauliche Informationen in die Antwort aufzunehmen oder einen weiteren Empfänger einzubeziehen. Selbst wenn der Prompt sagt, Dokumente seien nur Daten, bleibt das eine Anweisung innerhalb desselben Modellkontexts.
Warum Rollen und Datenmarkierungen nicht reichen
Eine sinnvolle Baseline ist, Systemanweisungen, Nutzereingaben und externe Inhalte getrennt zu übergeben und externe Inhalte eindeutig als untrusted data zu kennzeichnen. Das reduziert Missverständnisse und verbessert die Steuerbarkeit.
Die Grenze ist klar: Das Modell muss diese Kennzeichnung selbst beachten. Es gibt keine Garantie, dass es eine geschickt formulierte fremde Anweisung immer als bloßen Inhalt behandelt. Wer seine Schutzstrategie darauf aufbaut, dass das Modell niemals abweicht, verlagert eine Sicherheitsentscheidung in ein probabilistisches System.
Auch Filter sind nur ergänzende Maßnahmen. Sie können offensichtliche Muster erkennen, aber nicht jede Formulierung, jede Sprache und jeden Kontext zuverlässig abdecken. Ein Filter oder ein besonders strenger Prompt löst das Problem nicht grundsätzlich.
Gegenmaßnahmen nach Wirksamkeit
Die wichtigste Frage lautet nicht: Kann das Modell manipuliert werden? Sondern: Was darf passieren, wenn es manipuliert wird?
1. Rechte von LLM-Agenten minimieren
Tools sollten nur die Berechtigungen erhalten, die für ihren konkreten Zweck nötig sind. Ein Agent, der Inhalte zusammenfasst, braucht keinen Zugriff auf sensible Datensätze und keine Berechtigung, Nachrichten zu versenden.
Trennt insbesondere lesende von schreibenden Funktionen. Lesezugriffe können ebenfalls sensibel sein, aber Aktionen mit Seiteneffekten erhöhen den möglichen Schaden erheblich. Dazu zählen etwa das Versenden, Löschen, Ändern oder Veröffentlichen.
2. Aktionen mit Seiteneffekten bestätigen lassen
Eine Tool-Anfrage des Modells darf nicht automatisch zur Aktion werden. Vor dem Ausführen sollte die Anwendung Zweck, Ziel und relevante Parameter anzeigen und eine explizite Bestätigung einholen.
Das gilt besonders für externe Kommunikation und Änderungen an Daten. Eine Zusammenfassung darf automatisch erzeugt werden. Eine Nachricht an einen Empfänger sollte eine Freigabe erfordern.
3. Tool-Ausgaben strikt validieren
Das Modell sollte keine frei formulierten Befehle erzeugen, die ein nachgelagertes System blind ausführt. Besser ist ein festes Schema für Tool-Aufrufe und eine Allowlist erlaubter Aktionen.
Die Anwendung prüft dabei unabhängig vom Modell: Ist die Aktion erlaubt? Sind alle Parameter vorhanden und im erwarteten Format? Darf dieser Nutzer dieses Ziel bearbeiten? Liegt der Wert im zulässigen Bereich? Erst danach darf der Tool-Aufruf stattfinden.
4. Sensible Datenzugriffe begrenzen
Nicht jedes Dokument muss in jeden Kontext. Zugriffskontrollen, Mandantentrennung und eine möglichst kleine Auswahl abgerufener Inhalte reduzieren, was ein manipuliertes Modell überhaupt sehen oder weitergeben kann.
Keine perfekte Trennung, aber kontrollierbarer Schaden
Prompt Injection lässt sich nicht vollständig wegfiltern, weil die Ursache im gemeinsamen Textkontext liegt. Rollen, Markierungen und Filter bleiben sinnvoll, aber sie sind keine Sicherheitsgarantie. Robuste LLM Sicherheit entsteht durch mehrere Grenzen: wenig Rechte, bestätigte Seiteneffekte, begrenzte Datenzugriffe und validierte Ausgaben.
Prüft, welche Rechte euer LLM hat: Was wäre der Schaden, wenn es eine fremde Anweisung ausführt?