Erkennung von Prompt Injection

Sicherheitsziel

Die Erkennung von Prompt Injection identifiziert wahrscheinliche Injection-Versuche und ihre Folgen, während ein System läuft. Sie verbindet Signale aus mehreren Ebenen einer Anfrage: den Inhalt, der in den Kontext gelangt ist, das Verhalten des Modells, den vorgeschlagenen Plan eines Agenten, seine Tool Calls sowie versuchte, erlaubte oder abgelehnte Aktionen. Das Ergebnis speist eine Reaktions-Policy, eine Alarmwarteschlange und spätere Untersuchungen.

Erkennung ist nötig, weil Prävention unvollständig bleibt. Manche eingeschleusten Inhalte erreichen das Modell, und manche Ausgaben spiegeln sie wider. Erkennung verkürzt die Zeit, bis jemand es bemerkt, hilft betroffene Abläufe einzudämmen und liefert die Evidenz, um den Hergang zu verstehen. Allein verhindert sie keine Auswirkungen.

Zuständigkeitsgrenzen

Erkennung reicht weiter als die Eingabe- und Inhaltsprüfung, die Inhalte vor oder während der Kontextzusammenstellung bewertet. Erkennung beobachtet auch, was geschieht, nachdem das Modell diese Inhalte gelesen hat. Plan-Drift-Erkennung und Tool-Chain-Analyse sind spezialisierte Erkennungstechniken, die in der Abwehrtaxonomie getrennt geführt werden; diese Seite ordnet sie in die Gesamtarchitektur ein, ohne sie zu ersetzen.

Bedrohungsmodell

Die Bedrohung ist Text, der verändert, was das Modell als Anweisung behandelt: von einem Nutzer eingegeben bei direkter Prompt Injection oder eingebettet in abgerufene Daten, Nachrichten, Dateien oder Tool-Ergebnisse bei indirekter Prompt Injection. In agentischen Systemen betrifft das Risiko auch vorgeschlagene Pläne und Aktionen, die Ausbreitung zwischen Agenten und die Persistenz in Speicher oder Datenbeständen.

Es ist davon auszugehen, dass ein Angreifer einige Ausgaben beobachten, iterieren und vorhandene Detektoren kennen kann. Ebenso können Versuche über Turns, Quellen und Schritte verteilt werden, sodass kein einzelnes Ereignis auffällt. Erkennung ist für diese Bedingungen ausgelegt und kann dennoch nicht vollständig sein.

Erkennungsergebnisse sind Evidenz

Vertrauensmodell

Detektoren sind Systemkomponenten, doch die Telemetrie, die sie lesen, und die Werte, die sie erzeugen, bleiben variabel. Nur die Reaktions-Policy, die Erkennungen verarbeitet, und die unabhängig davon wirkenden Durchsetzungskontrollen sind Systementscheidungen.

Daraus folgen drei Regeln. Telemetriefelder, die Systementscheidungen festhalten, stammen von der durchsetzenden Komponente, nicht aus Modelltext. Die Ausgabe eines Detektors fließt nie als Berechtigung in die Autorisierung. Und fehlende Telemetrie wird als nicht beobachtet dargestellt, nie als unauffällig.

Signalebenen

Einzelne Ebenen sind allein schwach. Werden sie innerhalb einer Anfrage und über Anfragen desselben Principals, derselben Quelle oder desselben Ablaufs korreliert, entsteht deutlich stärkere Evidenz als durch ein einzelnes Signal.

Durchsetzungsergebnisse als wertvolle Signale

Deterministische Kontrollen liefern einige der verlässlichsten Erkennungssignale. Wenn die Agentenautorisierung eine vorgeschlagene Aktion ablehnt, die Informationsflusskontrolle Daten auf dem Weg zu einer externen Senke blockiert oder eine prüfende Person eine Freigabe verweigert, hat das System eine konkrete Abweichung zwischen Modellvorschlag und Policy beobachtet.

Aufgabentreue und Planabweichung

Viele Injections wirken, indem sie die Aufgabe umlenken. Die Erkennung kann den vorgeschlagenen Plan und die Tool Calls mit dem erklärten Nutzerziel, den erwarteten Schritten des Ablaufs und den für diese Aufgabe üblichen Tools vergleichen. Eine Abweichung ist ein Signal, kein Beweis: Nutzer ändern ihre Meinung, und legitime Aufgaben variieren. Eine eigene Plan-Drift-Erkennung formalisiert diesen Vergleich; hier ist er ein Eingang der Korrelation.

Die Darstellung des Nutzerziels muss maßgeblich bleiben. Die Anwendung erfasst sie aus dem eigenen Turn des Nutzers oder aus der Ablaufdefinition, nicht aus Modellausgaben, die selbst beeinflusst sein können.

Eine kontrollierte Übung, das Lab Plan-Drift-Erkennung, trainiert die Unterscheidung zwischen legitimer Anpassung und wesentlicher Drift bei Aufgabe oder Nebenwirkungen anhand maßgeblicher, von der Anwendung erfasster Ziele. Es ist eine deterministische Simulation, kein Detektortest.

Sequenz- und Tool-Chain-Signale

Einzeln plausible Schritte können sich zu schädlichen Wirkungen verbinden: einen sensiblen Datensatz lesen, zusammenfassen und die Zusammenfassung an ein neues Ziel senden. Sequenzsignale betrachten die Kette statt des einzelnen Schritts, etwa sensible Lesezugriffe gefolgt von ausgehenden Aktionen oder neue Ziele, nachdem externe Inhalte in den Kontext gelangt sind. Eine spezialisierte Tool-Chain-Analyse vertieft dies; die Erkennung nutzt sie als eine Ebene.

Korrelation über Turns, Agenten und Sitzungen

Versuche können sich über mehrere Turns, Agentenübergaben oder Sitzungen erstrecken, etwa wenn in den Speicher geschriebene Inhalte eine spätere Anfrage beeinflussen. Korrelation braucht stabile Kennungen: Anfrage- und Konversations-IDs, Provenienzverweise für Inhaltselemente, Agenten- und Ablaufkennungen sowie den Principal, in dessen Auftrag Aktionen liefen.

In agentischen und Multi-Agent-Systemen wird jeder Hop mit Ein- und Ausgaben erfasst, damit sich eine Erkennung bis zu dem Inhalt zurückverfolgen lässt, der zuerst in den Kontext gelangt ist.

Arten von Detektoren

Für jede Erkennung werden Familie und Version des Detektors erfasst. Kombinierte Familien verbessern die Abdeckung, das Gesamtergebnis bleibt aber probabilistisch.

Integrität und Isolation der Detektoren

Ein modellbasierter Detektor liest dieselben nicht vertrauenswürdigen Inhalte wie das geschützte System und kann davon beeinflusst werden. Seine Ausgabe wird auf ein festes Schema beschränkt, er erhält keine Tools und keine Befugnisse und läuft in einem vom Hauptauftrag getrennten Kontext. Wo möglich, sind Detektoren vorzuziehen, die strukturierte Telemetrie statt rohe natürliche Sprache lesen.

Ist ein Detektor nicht verfügbar oder überschreitet er sein Zeitlimit, wird die Lücke als nicht beobachtet erfasst. Ob der Ablauf fortgesetzt, in einen eingeschränkten Modus versetzt oder gestoppt wird, entscheidet die Reaktions-Policy nach Risikostufe.

Inline-, zeitnahe und retrospektive Erkennung

Inline-Erkennung muss schnell und in ihrem Umfang zurückhaltend sein; sie ergänzt deterministische Prüfungen an derselben Grenze, ersetzt sie aber nicht. Retrospektive Erkennung ist für persistente Injection unverzichtbar, weil neue Detektoren Inhalte finden können, die vor ihrer Einführung gespeichert wurden.

Reaktions-Policy

Eine Reaktions-Policy außerhalb des Modells ordnet Erkennungen, Konfidenz, Risikostufe des Ablaufs und betroffene Werte einer Aktion zu. Abläufe mit höheren Befugnissen rechtfertigen niedrigere Schwellen und stärkere Reaktionen.

Alarmqualität und Triage

Alarme, mit denen Analysten nichts anfangen können, werden ignoriert. Jeder Alarm trägt die korrelierte Evidenz: welche Signale ausgelöst haben, beteiligte Inhaltselemente und Provenienz, Modellausgabe und vorgeschlagene Aktionen sowie die Entscheidung der Durchsetzung. Zusammengehörige Signale werden zu einem Fall gebündelt statt pro Ereignis einen Alarm auszugeben.

Der Schweregrad ergibt sich aus Schadenspotenzial und beobachteter Auswirkung, nicht allein aus der Konfidenz des Detektors. Ein Signal mit geringer Konfidenz an einer abgelehnten externen Datenübertragung kann mehr Aufmerksamkeit verdienen als ein Treffer mit hoher Konfidenz in einem reinen Lese-Ablauf.

Falsch-Positive, Falsch-Negative und Drift

Falsch-Negative werden vorausgesetzt; dafür gibt es die nachgelagerte Durchsetzung. Falsch-Positive kosten Analystenzeit und Nutzervertrauen und drängen Teams zu Unterdrückungsregeln. Beide werden getrennt gemessen, und jede Unterdrückungsregel erhält eine verantwortliche Person und ein Ablaufdatum.

Abläufe, Tools, Inhaltsmix, Modellversionen und Angriffstechniken ändern sich. Detektoren und Schwellen werden versioniert, ein gelabeltes Regressionsset läuft bei jeder Änderung, und Erkennungsraten pro Ablauf werden auf Verschiebungen überwacht, die auf Drift oder stilles Versagen hindeuten.

Telemetrie-Design

Telemetrie kann sensible Inhalte und verborgenen Kontext enthalten. Zugriffskontrolle, Datenminimierung und Aufbewahrung müssen mindestens so streng sein wie für die zugrunde liegenden Daten, und Felder für Systementscheidungen bleiben von modellgeneriertem Text getrennt.

Datenschutz und Aufbewahrung

Erkennung braucht genug Daten, um Ereignisse zu rekonstruieren, doch vollständiges Protokollieren von Prompts und Ausgaben kann personenbezogene Daten, Geheimnisse und verborgene Anweisungen offenlegen. Wo es genügt, sind Verweise, Hashes und Auszüge vorzuziehen; der Zugriff auf vollständige Datensätze wird beschränkt und die Aufbewahrung nach Zweck festgelegt. Zugriffe auf Erkennungsevidenz werden protokolliert.

Durchgespieltes Szenario

Synthetisches Beispiel. Ein interner Assistent hilft einer Mitarbeiterin bei einem Anbietervergleich. Er kann geteilte Dokumente lesen, im Web suchen und in ihrem Auftrag E-Mails senden. Eine abgerufene Webseite enthält einen synthetischen Testmarker, der als Anweisung formuliert ist, eine interne Preisliste an eine externe Adresse zu senden.

In einer harmlosen Variante bittet die Nutzerin ausdrücklich darum, eine öffentliche Zusammenfassung an einen Kollegen zu senden. Der Plan passt zum Ziel, die Daten sind öffentlich, der Fluss ist erlaubt, und der Versand läuft über ihre eigene Bestätigung. Es entsteht kein Alarm.

Was das Szenario zeigt und was nicht

Es zeigt, wie Korrelation mehrere schwache Signale und eine deterministische Ablehnung zu einem handlungsfähigen Alarm verbindet, und dass die schädliche Wirkung durch die Flusskontrolle verhindert wurde, nicht durch die Erkennung. Es zeigt nicht, dass eine umformulierte oder sitzungsübergreifende Variante erkannt würde, dass die Autorin der Webseite böswillig war oder dass die harmlose Variante risikofrei war. Die Verhinderung wird der IFC zugeordnet, Sichtbarkeit und Eindämmung der Erkennung und der Reaktions-Policy.

Bedeutung für Incident Response

Eine Erkennung eröffnet eine Untersuchung. Schlüsse auf eine Kompromittierung folgen aus Evidenz für Auswirkungen, nicht aus dem Alarm selbst.

Kontrolliertes Testen

Erkennung wird Ende zu Ende mit synthetischen Markern und gelabelten Szenarien getestet, die jede Signalebene ansprechen: Inhalt, Planabweichung, Tool-Abfolgen und Durchsetzungsergebnisse. Tests laufen in isolierten Umgebungen mit Testidentitäten, Nicht-Produktionsdaten und harmlosen Senken. Jedes Szenario wird mit erwarteten Signalen und erwarteter Reaktion gelabelt. Wiederverwendbare Payload-Bibliotheken werden weder aufgebaut noch veröffentlicht; Ziel ist die Messung von Erkennungs- und Reaktionsverhalten.

Metriken

Jede Kennzahl behält ihren eigenen Nenner. Es gibt keinen Gesamtscore, und der Nutzen für harmlose Aufgaben wird getrennt berichtet.

Häufige Fehler

Umsetzungscheckliste

Standards und Quellen

Zur Quellennutzung: OWASP LLM01:2026 ist die aktuelle Klassifikation für Prompt Injection. NIST AI 100-2e2025 wird nur für Terminologie herangezogen; es ist kein Erkennungsstandard. Microsofts Leitlinie zu indirekter Prompt Injection ist eine Herstellerleitlinie, die probabilistische und deterministische Maßnahmen zu schichten empfiehlt und erkennungsbezogene Techniken wie Prompt Shields, Plan-Drift-Erkennung und Tool-Chain-Analyse neben Informationsflusskontrolle, Least Privilege und Human-in-the-Loop nennt. Microsofts Dokumentation zu Prompt Shields beschreibt die Erkennung von Nutzerprompt- und Dokumentangriffen durch ein Produkt in dessen dokumentiertem Umfang; sie dient als Beispiel, nicht als allgemeines Modell. Diese Seite nennt keine Wirksamkeitszahlen für Erkennung.

Häufige Fragen