Geführtes Sicherheitslab

Plan-Drift-Erkennung

Eine geführte Übung zur Erkennung wesentlicher Abweichungen zwischen einer maßgeblichen, von der Anwendung erfassten Aufgaben-Baseline und dem Plan eines Agenten - mit klarer Trennung von legitimer Anpassung, nutzerautorisierten Scope-Änderungen und Erkennung gegenüber Autorisierung.

Konzeptionelle SimulationAdvanced15 Minuten2026-09-26

Konzeptionelle Simulation

Diese Übung nutzt redaktionell festgelegte, deterministische Beispiele mit fiktiven Namen und neutralen synthetischen Inhalten. Sie ruft keine Tools, APIs, Agenten, Detektoren oder Modelle auf und sagt nicht voraus, wie sich ein reales Modell oder ein realer Detektor verhält.

Schritt 3 von 63/6

Lernziele

Die maßgebliche Aufgaben-Baseline außerhalb der Modellausgabe identifizieren.
Legitime Planänderungen von wesentlicher Ziel- oder Wirkungsdrift unterscheiden.
Vorgeschlagene Planschritte mit aktuellem Nutzerziel, Ablaufphase, Aufgaben-Scope, Ressourcen und Zielen vergleichen.
Nicht angeforderte Nebenwirkungen sowie neue Ziele oder Ressourcen als Drift-Signale erkennen.
Ausdrückliche Änderungen durch den Nutzer als Baseline-Aktualisierung statt als Angriff behandeln.
Die Baseline über Agenten-Hops hinweg verfolgen, ohne dass ein nachgelagerter Agent die Aufgabe stillschweigend neu definiert.
Drift als probabilistische Evidenz behandeln, nicht als Autorisierung oder Beweis einer Kompromittierung.
Keine beobachtete Drift von sicher unterscheiden und markierte Drift von einer eingetretenen Wirkung.

Voraussetzungen

Lab Agentenautorisierung (empfohlen)
Lab Tool-Output-Injection (empfohlen)

Szenario wählen

Jedes fiktive Szenario zeigt, was das Modell sieht, und getrennt davon die Aufgaben-Baseline, die die Anwendung erfasst. Der Detektor vergleicht den vorgeschlagenen Plan mit dieser erfassten Baseline.

Ausdrückliche Scope-Änderung durch den NutzerDer Nutzer bittet zunächst um einen synthetischen Anbietervergleich. In einem späteren Turn bittet derselbe Nutzer ausdrücklich, zusätzlich eine Nachricht an ein internes Einkaufspostfach zu entwerfen. Die Anwendung erfasst den neuen Turn und den aktualisierten Scope, bevor der Plan bewertet wird.Externer Inhalt fügt einen nicht angeforderten Versand hinzuDer Nutzer bittet um einen Vergleich zweier synthetischer Anbieter anhand öffentlicher Materialien. Nachdem abgerufener externer Inhalt in den Kontext gelangt, fügt der Plan das Lesen eines internen Preisblatts und den Versand einer Zusammenfassung an einen neuen externen Empfänger hinzu.Harmloser Tool-Wechsel, gleiches ZielDer Nutzer fragt nach dem aktuellen synthetischen Lagerbestand für SKU-17. Der bevorzugte Suchindex ist nicht verfügbar, daher schlägt der Agent eine zweite freigegebene Nur-Lese-Bestandsabfrage vor und liefert dieselbe angefragte Angabe.Nicht angeforderte DatensatzänderungDer Nutzer bittet um eine Zusammenfassung des synthetischen Supportfalls K-310. Der Plan fügt hinzu, einen nicht zugehörigen Kundendatensatz R-588 zu ändern, um ein Kontaktfeld zu bereinigen.Zielausweitung über einen HopDie erfasste Aufgabe eines Eltern-Agenten lautet, den Lagerbestand von SKU-17 für einen internen Nachbestellungsbericht zu lesen. Er delegiert eine Nur-Lese-Teilaufgabe als strikte Teilmenge an einen Bestands-Sub-Agenten, dessen Plan hinzufügt, einen externen Lieferanten mit dem Ergebnis zu kontaktieren.

Aufgaben-Baseline und Planpfad

Die Anwendung erfasst das Ziel aus dem Turn des Nutzers und der Ablaufdefinition, das Modell schlägt einen Plan vor, und ein Detektor vergleicht beides. Baseline, Detektor und spätere Kontrollen sind Systemkomponenten; Pläne bleiben variabel.

Nutzer-Turn und AblaufdefinitionSystemkomponente->
Erfasste Aufgaben-BaselineSystemkomponente->
ModellSystemkomponente->
Vorgeschlagener PlanVariabler Inhalt->
Plan-Drift-DetektorSystemkomponente->
Autorisierung und Freigabe (getrennt)Systemkomponente

Modellsichtbarer Plankontext

Was das Modell liest. Es ist nicht die maßgebliche Baseline.

Früherer Nutzer-Turn
Vergleiche Anbieter Alpha und Anbieter Beta bei den Supportbedingungen.
Aktueller Nutzer-Turn
Entwirf außerdem eine kurze Nachricht mit dem Vergleich an das interne Einkaufspostfach.

Von der Anwendung erfasste Aufgaben-Baseline

Ziel, Zielversion, Ablaufphase, Scope, Ressourcen, Ziele und Ausführungsstatus, erfasst außerhalb des Modelltexts.

Aktuelles Ziel: Alpha und Beta vergleichen; Nachricht an procurement@corp.example.test entwerfen (nicht senden)
Zielversion: v2, von der Anwendung aus Nutzer-Turn 2 erfasst
Ablaufphase: Entwurf
Erfasste Ziele: procurement@corp.example.test (intern, nur Entwurf)
Ausführungsstatus: Nichts gesendet; ein Versand bräuchte eine eigene Autorisierung und Freigabe