Was ist Prompt Injection?

Prompt Injection bezeichnet Eingaben, die ein KI-System dazu bringen sollen, seine vorgesehenen Anweisungen zu ignorieren, umzudeuten oder mit fremden Anweisungen zu vermischen. Das Problem entsteht, weil Sprachmodelle Daten und natürlich formulierte Befehle nicht verlässlich voneinander trennen. Es ist daher nicht mit einer einfachen Liste verbotener Wörter lösbar.

Wie funktioniert Prompt Injection?

Eine LLM-Anwendung kombiniert häufig Systemanweisungen, Benutzereingaben, Gesprächsverlauf, abgerufene Dokumente und Ergebnisse externer Tools in einem Kontext. Manipulierter Text kann behaupten, frühere Regeln aufzuheben oder eine andere Rolle zu besitzen. Selbst wenn das Modell die Hierarchie meistens beachtet, können Varianten, Übersetzungen, Kodierungen oder mehrstufige Dialoge das Verhalten verändern. Ein System-Prompt ist deshalb keine belastbare Sicherheitsgrenze.

Direkte und indirekte Prompt Injection

Indirekte Angriffe sind besonders relevant, wenn ein Agent selbstständig fremde Inhalte liest. Der Angreifer muss dann keinen direkten Zugang zur Anwendung besitzen.

Welche Auswirkungen sind möglich?

• Vertrauliche Systemanweisungen, Dokumente oder Daten anderer Mandanten werden offengelegt.
• Ein Agent ruft nicht vorgesehene Tools auf, verschickt Daten oder verändert Datensätze.
• Sicherheits- und Inhaltsregeln werden umgangen und unzulässige Ausgaben erzeugt.
• Manipulierte Antworten täuschen Nutzer oder werden von Folgesystemen als vertrauenswürdige Daten verarbeitet.

Das Risiko hängt vor allem von Datenzugriff und Fähigkeiten der Anwendung ab. Ein reiner Textgenerator hat meist weniger Schadenspotenzial als ein Agent mit E-Mail-, Datei- und Administrationsrechten.

Ist ein Jailbreak dasselbe?

Ein Jailbreak ist eine Form der Manipulation, die meist Inhalts- oder Verhaltensbeschränkungen eines Modells umgehen soll. Prompt Injection ist weiter gefasst und betrifft die Integrität von Anweisungen in einer konkreten Anwendung. Anders als bei SQL Injection wird kein fester Parser mit sauber trennbarer Daten- und Befehlssyntax angegriffen. Herkömmliches Escaping allein löst das Problem daher nicht.

Wie lässt sich das Risiko reduzieren?

• Berechtigungen, Mandantentrennung und Geschäftsregeln außerhalb des Modells erzwingen.
• Tools nach dem Prinzip der minimalen Rechte beschränken und Parameter serverseitig erlaubnislisten.
• Riskante Aktionen mit einer verständlichen Vorschau vom Nutzer bestätigen lassen.
• Externe Inhalte kennzeichnen, ihre Herkunft protokollieren und nur notwendige Ausschnitte abrufen.
• Modellausgaben vor HTML, Datenbank, Shell oder anderen Folgesystemen kontextgerecht validieren.
• Anomalien überwachen und Schutzmaßnahmen mit adversarialen Regressionstests prüfen.

Ein- und Ausgabefilter sind zusätzliche Hürden, aber kein vollständiger Schutz. Besonders sensible Daten sollten gar nicht erst in den für das Modell erreichbaren Kontext gelangen.

Codebeispiel: Das Modell darf keine Berechtigungen vergeben

Verwundbares Prinzip: Der vom Modell erzeugte Tool-Name und seine Parameter werden direkt ausgeführt.

tool = modelResponse.tool
tools[tool.name](**tool.arguments)

Sicherer Grundaufbau:

ALLOWED_TOOLS = {'read_ticket': readTicket}

tool = validateToolSchema(modelResponse.tool)
if tool.name not in ALLOWED_TOOLS:
    raise PermissionError('Tool not allowed')

authorize(currentUser, tool.name, tool.arguments)
result = ALLOWED_TOOLS[tool.name](**tool.arguments)

Auch erlaubte Tools benötigen serverseitige Objektberechtigungen, enge Schemas, minimale Zugangsdaten und Limits. Eine Prompt-Anweisung wie „verwende nur sichere Tools“ ist dafür keine Zugriffskontrolle.

Wie wird die Schwachstelle getestet?

Ein LLM-Penetrationstest prüft direkte und indirekte Quellen, mehrere Rollen, Sprachen und Dialogfolgen. Er bewertet nicht nur ungewöhnliche Antworten, sondern bestätigt kontrolliert, ob geschützte Daten oder Aktionen erreichbar sind. Modellversion, Kontext und Wiederholungsrate müssen dokumentiert werden, weil Ergebnisse nicht vollständig deterministisch sind.