Prompt Injection

Angriffsfläche

Eingabe / Prompt
Memory / Zustand

Eine Eingabe, die das Modell liest — ein Prompt, abgerufene Inhalte, ein Tool-Ergebnis, ein Bild oder persistentes Memory —, verändert sein Verhalten auf eine Weise, die die Entwickler nicht vorgesehen haben.

Was es ist

Ein Modell trennt in seiner Architektur nicht zwischen Anweisungen und Daten — beides sind Tokens im selben Strom. Deshalb gibt es kein sauberes Gegenstück zu einer parametrisierten Abfrage, und heute existiert kein verlässlicher Schutzmechanismus. Prompt Injection ist jede unbeabsichtigte Verhaltensänderung des Modells, die von dem ausgeht, was es liest — egal, ob diese Eingabe für Menschen lesbar ist, vom Nutzer stammt oder auf dem Bildschirm sichtbar ist. Jailbreaking ist die Teilmenge, die auf die Sicherheitsprotokolle des Modells zielt.

Drei Eigenschaften eines Deployments vergrößern die Angriffsfläche. System Prompt, Nutzereingabe, abgerufene Dokumente, Tool-Ausgaben und Memory landen in einem gemeinsamen Kontext, ohne dass eine Vertrauensgrenze durchgesetzt wird. Eine Injektion, die in das Langzeit-Memory oder einen Retrieval-Korpus schreibt, verseucht jede spätere Sitzung, die davon liest. Und sobald die Ausgabe des Modells Tool-Aufrufe steuert, reicht der Schadensradius so weit wie diese Tools, während ihre Ausgaben zurück in den Kontext fließen. Ein Multi-Agenten-System fügt dieser Liste von Kanälen jede Nachricht eines anderen Agenten hinzu.

Die Abwehr ist daher eine Frage der Architektur, nicht des Abfangens. Die meisten folgenschweren Vorfälle wurden erst deshalb schwer, weil die Injektion in einem System landete, dessen Tools, Berechtigungen oder Darstellung das kompromittierte Modell mit den Rechten des Nutzers handeln ließen. Darum gehört dieser Eintrag mit Excessive Agency (LLM03) zusammen.

Arten

Direkte Injektion: Der Nutzer oder ein Angreifer mit demselben Zugangsweg liefert eine Eingabe, die die Anweisungen des Systems überschreibt — absichtlich als Jailbreak oder versehentlich, wenn eingefügter Text zufällig widersprüchliche Anweisungen enthält.
Indirekt: Das Modell nimmt Anweisungen auf, die in externen Inhalten stecken — einer Webseite, einer E-Mail, einer abgerufenen Textpassage, der Antwort eines Tools oder MCP-Servers, dem Titel eines Issues. Die Quelle kann nicht vertrauenswürdig sein, halb vertrauenswürdig (ein öffentlicher Bugtracker) oder sogar vertrauenswürdig (das eigene Repository der Entwickler, erreicht über einen vorgelagerten Kanal mit geringen Rechten).
Multimodal und kodiert: Anweisungen reisen über einen Nicht-Text-Kanal, etwa als kaum wahrnehmbare Störungen in Bild oder Audio, oder in einer Kodierung, die ein Filter nie gesehen hat: unsichtbare Unicode-Zeichen, Base64 oder eine Sprache mit wenig Trainingsdaten.

Angriffsszenarien

In einem Multi-Agenten-System

Das Ergebnis eines Websuche-Tools enthält eine versteckte Anweisung, der ein Recherche-Agent folgt, als käme sie vom Nutzer — und ändert so still die nächste Aktion des Agenten.

Umgehung des Support-Bots

Ein Angreifer schickt einem Kundensupport-Chatbot eine gezielt gestaltete Eingabe. Sie überschreibt dessen Richtlinien, verleitet ihn zur Abfrage privater Daten und bringt ihn dazu, im Auftrag des Angreifers E-Mails zu versenden.

Vergiftete Webseiten-Zusammenfassung

Ein LLM soll eine Webseite zusammenfassen und verarbeitet dabei eine darin versteckte Anweisung. Sie bringt es dazu, ein Markdown-Bild einzufügen, dessen URL die Konversation unbemerkt exfiltriert.

Aufgeteilte Payload in einem Lebenslauf

Ein Angreifer verteilt eine bösartige Anweisung auf mehrere Felder eines Lebenslaufs, sodass kein einzelnes Feld verdächtig wirkt. Liest das Modell das ganze Dokument, setzt es die Fragmente wieder zusammen und verzerrt seine Bewertung.

Vergiftetes Issue, privilegierter Agent

Ein Angreifer platziert Text in einem öffentlichen GitHub-Issue. Der per MCP angebundene Agent eines Entwicklers liest ihn mit dessen eigenen Zugangsdaten und exfiltriert private Repositories. Der Angreifer berührt nie das Backend; die privilegierte Aktion führt der Agent selbst aus.

Abwehrmaßnahmen

Fähigkeiten außerhalb des Modells halten: Zugangsdaten und zustandsverändernde Fähigkeiten im Anwendungscode halten, pro Vorgang nur minimale Rechte vergeben und privilegierte Aufrufe durch eine deterministische Richtlinienprüfung leiten, gemäß Least Privilege Agent und Permission-scoped Tools.
Fähigkeiten eines Agenten begrenzen: Die Rule of Two als Untergrenze anwenden: Ein Agent, der gleichzeitig nicht vertrauenswürdige Eingaben verarbeitet, sensible Daten erreicht und Zustand ändert oder nach außen kommuniziert, braucht für jede Aktion eine Freigabe über ein HITL Approval Gate.
Jeden Kanal trennen und filtern: Externe Inhalte über einen eigenen, nach Herkunft gekennzeichneten Kanal getrennt von den Anweisungen des Nutzers übergeben, unsichtbare Unicode-Zeichen an jeder Grenze entfernen, an der Inhalte aufgenommen oder dargestellt werden, und jede Modalität filtern, nicht nur Text, gemäß Multimodal Guardrails.
Memory-Schreibzugriffe als privilegiert behandeln: Den Prompt protokollieren, der einen Memory-Schreibzugriff ausgelöst hat, und eine Freigabe verlangen, bevor Memory-Einträge mit Anweisungen sitzungsübergreifend gespeichert bleiben.
Gegen adaptive Angreifer testen: Red-Teaming so betreiben, dass die Tester die eingesetzte Abwehr kennen: Erfolgsraten nahe null gegen statische Angriffe steigen regelmäßig auf über 90 %, sobald sich der Angreifer anpasst.

Quellen

Sicherheit

Wohin als Nächstes

SicherheitAlle BedrohungenÖffnen