Plan-Drift-Erkennung

Sicherheitsziel

Plan-Drift-Erkennung vergleicht den Plan, den ein Agent vorschlägt, und die dahinterliegende Handlungsabsicht mit einer maßgeblichen Aufgaben-Baseline, die die Anwendung erfasst hat. Fügt der Plan Ziele, Nebenwirkungen, Empfänger, Ressourcenklassen oder folgenreiche Aktionen hinzu, die die aktuelle Baseline nicht enthält, meldet der Detektor ein Drift-Signal. Dieses Signal speist eine Reaktionsrichtlinie, eine Alarmwarteschlange und spätere Untersuchungen.

Die Kontrolle ist nötig, weil viele Prompt Injections eine Aufgabe umlenken, statt offensichtlich feindseligen Text zu erzeugen. Ein Agent, der zwei Anbieter vergleichen soll und plötzlich plant, eine interne Tabelle zu lesen und weiterzusenden, ist abgedriftet, egal wie sein Plan formuliert ist.

Zuständigkeitsgrenzen

Der übergeordnete Artikel Erkennung von Prompt Injection erklärt, wie Inhalts-, Verhaltens-, Plan-, Tool- und Durchsetzungssignale korreliert werden. Diese Seite vertieft einen dieser Eingänge: den Vergleich von Plänen mit einer Baseline.

Bedrohungsmodell

Die Bedrohung ist Text im Kontext, der verändert, was der Agent zu tun versucht. Er kann über eine indirekte Prompt Injection in abgerufenen Seiten, Nachrichten, Dateien oder Tool-Ergebnissen eintreffen oder direkt in einem Nutzerbeitrag stehen. In agentischen Systemen wird die Beeinflussung als veränderter Plan sichtbar: neue Empfänger, neue Schreibvorgänge, breitere Lesezugriffe oder ein anderer Zweck.

Es ist davon auszugehen, dass Angreifende Formulierungen so wählen, dass der Plan weiter nach der Aufgabe klingt, Einfluss über Schritte oder Agenten verteilen und wissen können, dass ein Planvergleich existiert. Ebenso ändern legitime Nutzer ihre Meinung, und Agenten passen Pläne aus gewöhnlichen Gründen an. Der Detektor muss unter beiden Bedingungen arbeiten und wird dennoch manche Fälle übersehen oder zu oft melden.

Was ist eine Aufgaben-Baseline?

Eine Aufgaben-Baseline ist ein anwendungseigener Datensatz darüber, worum es in der aktuellen Aufgabe gehen darf. Sie wird aus der aktuellen Nutzeranfrage, der Ablaufdefinition, Richtlinien, dem Aufgabenumfang, erlaubten Ressourcenklassen, erlaubten Zielklassen und der aktuellen Ablaufphase abgeleitet. Sie ist versioniert und außerhalb der Modellausgabe gespeichert.

Was gilt als Drift?

Legitime Änderungen durch Nutzer

Nutzer überarbeiten Aufgaben. Bittet derselbe authentifizierte Nutzer in einem späteren Beitrag ausdrücklich um etwas Neues, erfasst die Anwendung diesen Beitrag und aktualisiert die Baseline auf eine neue Version, bevor der nächste Plan bewertet wird. Ein Plan, der zur aktualisierten Baseline passt, ist keine Drift.

Harmlose Anpassung und wesentliche Drift

Entscheidend ist nicht, ob der Plan anders aussieht, sondern ob Ziel, Wirkungen, Ressourcen oder Empfänger den Rahmen der Baseline verlassen.

Vertrauensmodell

Der Detektor ist eine Systemkomponente, seine Ausgabe bleibt aber variable Evidenz. Systementscheidungen sind nur die Reaktionsrichtlinie, die das Signal verarbeitet, und die Durchsetzungskontrollen, die unabhängig davon handeln.

Aufbau der Baseline

Strukturierte Felder stammen aus der Anwendung: Ablaufdefinitionen, Formulareingaben, ausgewählte Datensätze und Richtlinien. Ist das Ziel Freitext, bleibt der Nutzertext als Verweis erhalten, zusammen mit einer normalisierten Absicht, die die Anwendung oder ein eingeschränkter Parser abgeleitet hat, und der Angabe, wie sie abgeleitet wurde.

Versionierung und Aktualität der Baseline

Jede akzeptierte Änderung erzeugt eine neue Baseline-Version mit auslösendem Ereignis, Principal und Zeitstempel. Pläne werden gegen die Version bewertet, die beim Vorschlag galt. Ein Vergleich mit einer veralteten Version erzeugt nach legitimen Nutzeränderungen falsche Drift oder übersieht Drift, wenn eine alte, weitere Baseline noch gilt.

Baselines werden geschlossen oder eingeengt, wenn eine Ablaufphase endet. Eine Baseline, die stillschweigend jeden früheren Umfang ansammelt, wird zu großzügig, um noch etwas zu erkennen.

Darstellung des vorgeschlagenen Plans

Der Vergleich ist deutlich verlässlicher, wenn der Plan strukturiert ist. Wo möglich, gibt das Agenten-Framework vorgeschlagene Schritte als Datensätze mit Tool, Operation, Wirkungsklasse, Ressourcenverweisen, Empfängern und Zweck aus, statt Fließtext zu parsen.

Planversion und vollständiges Parsen werden erfasst. Ein Plan, den der Detektor nicht darstellen konnte, ist für die betroffenen Felder unobserved, nicht within baseline.

Vergleichsdimensionen

Sprachliche Ähnlichkeit zwischen Plan und Anfrage allein reicht nicht. Ein Plan kann nah an der Aufgabe klingen und trotzdem einen neuen Empfänger hinzufügen, und ein legitimer Plan kann ganz anders formuliert sein als die Anfrage.

Drift bei Empfängern und Nebenwirkungen

Neue Empfänger und neue Nebenwirkungen sind die sicherheitsrelevantesten Drift-Dimensionen, weil dort aus Beeinflussung eine Folge wird. Sie lassen sich zudem am leichtesten deterministisch vergleichen: Zielklasse und Wirkungsklasse jedes vorgeschlagenen Schritts stehen in der Baseline oder nicht.

Eine Baseline nur für Entwürfe, die ein Senden erhält, oder eine rein interne Baseline, die eine Adresse unter outside.example.test erhält, sollte unabhängig von der Begründung im Plan ein Drift-Signal auslösen.

Drift bei Ressourcen und Fähigkeiten

Ressourcendrift betrifft Lesezugriffe auf Datenklassen außerhalb der Aufgabe, Fähigkeitsdrift die Nutzung von Tools oder Operationen, die die Aufgabe nicht brauchte. Beide gehen oft einem ausgehenden Schritt voraus. Least Privilege begrenzt, was überhaupt verfügbar ist; Plan-Drift-Erkennung bemerkt, wenn der Plan mehr vom Verfügbaren beansprucht, als die Aufgabe erfordert.

Delegation zwischen Agenten und Übergabegrenzen

Delegiert ein übergeordneter Agent, sollte die Delegation einen begrenzten Umfang tragen, der eine Teilmenge seiner Baseline ist, dazu eine Korrelations-ID für übergeordneten und untergeordneten Lauf. Der Plan des untergeordneten Agenten wird mit diesem Delegationsumfang verglichen. Ein nachgelagerter Agent kann die Aufgabe nicht stillschweigend neu definieren.

In Multi-Agenten-Systemen ist eine reine Lese-Teilaufgabe, deren Plan eine Kontaktaufnahme nach außen hinzufügt, abgedriftet, auch wenn der übergeordnete Agent diesen Schritt nie sieht. Erst der Vergleich pro Übergabe macht das sichtbar.

Abgrenzung zur Tool-Chain-Analyse

Beide ergänzen sich. Die Tool-Chain-Analyse hat einen eigenen Artikel; das Lab Tool-Chain-Analyse übt die Sequenzsicht.

Detektorfamilien

Modellgestützte Drift-Erkennung

Ein Modell kann ein Freitextziel mit einem vorgeschlagenen Plan vergleichen. Es ist als probabilistischer Detektor zu behandeln: möglichst vom Kontext des Agenten isoliert, nur mit Baseline und strukturiertem Plan versorgt, ohne Tools und auf ein festes Ausgabeschema mit Begründungscodes beschränkt.

Reaktionsrichtlinie

Reaktionen werden in einer deterministischen Richtlinie außerhalb des Modells den Risikostufen der Abläufe zugeordnet. Eine Reaktionsrichtlinie darf Befugnisse nur einengen. Sie gewährt nie Erlaubnisse, stuft keine Daten herab und erlässt weder Autorisierung noch eine erforderliche menschliche Freigabe.

Telemetrie-Design

Unbeobachtet heißt nicht innerhalb der Baseline

Fehlt der Baseline ein Feld, lässt sich der Plan nicht parsen oder hat eine Übergabe ihren Plan nicht gemeldet, kann der Detektor nicht vergleichen. Diese Dimension wird als unobserved erfasst und der Lauf als unvollständig gemeldet. Wer fehlende Telemetrie als within baseline behandelt, verbirgt genau die Pfade, die Angreifende bevorzugen würden.

Alarmqualität und Triage

Ein nützlicher Alarm zeigt Baseline-Version, Planversion, abweichende Dimensionen, Begründungscodes, die Quellen im Kontext und was danach geschah. Die Triage klärt dann, ob die Drift eine legitime Änderung widerspiegelt, die die Baseline verpasst hat, eine harmlose Anpassung, die der Detektor falsch gelesen hat, oder eine wahrscheinliche Beeinflussung durch Inhalte.

Provenienz, Autorisierung, Klassifikation und Drift bleiben getrennte Felder. Ein einziger vermischter Vertrauenswert verbirgt, warum ein Fall gemeldet wurde, und verleitet dazu, ihn als Erlaubnissignal zu nutzen.

Durchgespieltes Szenario A: legitime Nutzeränderung

Der Nutzer bittet um einen Vergleich der fiktiven Anbieter Alpha und Beta bei den Supportbedingungen. Die Baseline erfasst ein Vergleichsziel, reine Lesewirkungen und keine Empfänger. In einem späteren Beitrag bittet derselbe Nutzer, zusätzlich eine Nachricht an procurement@corp.example.test zu entwerfen.

Durchgespieltes Szenario B: externe Inhalte fügen ein Senden hinzu

Der Nutzer bittet um einen Vergleich aus öffentlichen Quellen. Nachdem abgerufene externe Inhalte in den Kontext gelangt sind, fügt der Plan das Lesen einer internen Preistabelle und das Senden einer Zusammenfassung an reviewer@outside.example.test hinzu.

Eine Variante über Übergaben hinweg: Ein übergeordneter Agent delegiert eine reine Leseabfrage des Bestands von SKU-17, und der Plan des Unteragenten fügt eine E-Mail an supplier@vendor.example.test hinzu. Der Plan überschreitet den Delegationsumfang und wird als Drift gemeldet.

Was die Szenarien belegen und was nicht

Szenario A zeigt, dass eine legitime Änderung keinen Alarm auslösen sollte. Szenario B zeigt, dass das Signal nützliche Evidenz für die Triage ist. Keines zeigt, dass das System sicher ist, dass anderswo keine Drift auftrat oder dass der gemeldete Plan böswillig war.

Tests und Validierung

Ein gelabelter Regressionssatz enthält harmlose Nutzeränderungen, harmlose Anpassungen, eindeutige Drift und Drift über Übergaben hinweg, mit fiktiven Daten und Empfängern unter .example.test. Er läuft bei jeder Änderung an Detektor, Baseline-Schema oder Agenten-Framework. Fälle mit fehlenden Baseline-Feldern bestätigen, dass sie als unobserved gemeldet werden.

Das Lab Plan-Drift-Erkennung ist eine deterministische Simulation zum Erlernen der Einordnung, kein Detektor-Benchmark. Forschungsbenchmarks wie AgentDojo können Agentenaufgaben für breitere Evaluierungen liefern, und Entwürfe wie CaMeL zeigen, wie die Trennung von Kontrollfluss und nicht vertrauenswürdigen Daten die Abhängigkeit von Erkennung verringert; keines definiert diese Kontrolle.

Metriken

Das sind operative Kennzahlen. Sie werden nicht zu einem einzigen Sicherheitswert verrechnet, und gute Werte sind kein Sicherheitsnachweis.

Häufige Fehler

Umsetzungscheckliste

Standards und Quellen

Zur Quellennutzung: Microsofts Leitlinie führt Plan-Drift-Erkennung als Laufzeitüberwachung, die mehrstufiges Schlussfolgern auf Abweichungen vom beabsichtigten Aufgabenablauf beobachtet, kombiniert sie mit deterministischen Kontrollen wie Informationsflusskontrolle und weist darauf hin, dass probabilistische Abwehrmaßnahmen wie Plan-Drift-Erkennung Fehlalarme erzeugen können. Einen Algorithmus legt sie nicht fest. OWASP LLM01:2026 liefert den Risikokontext für Prompt Injection, keine Spezifikation für Plan Drift. NIST AI 100-2e2025 wird nur für Terminologie herangezogen. Baseline-Schemata, Begründungscodes, Reaktionsstufen und Kennzahlen auf dieser Seite sind Engineering-Empfehlungen, keine Anforderungen dieser Quellen.

Häufige Fragen