Guided security lab

Plan Drift Detection

A guided exercise on detecting material divergence between an authoritative, application-recorded task baseline and the plan an agent proposes, while separating legitimate adaptation, user-authored scope changes and detection from authorization.

Conceptual simulationAdvanced15 minutes2026-09-26

Conceptual simulation

This exercise uses authored, deterministic examples with fictional names and neutral synthetic content. It calls no tools, APIs, agents, detectors or models, and it does not predict how any real model or detector behaves.

Step 3 of 63/6

Learning objectives

Identify the authoritative task baseline outside model output.
Separate legitimate plan adaptation from material objective or effect drift.
Compare proposed plan steps with the current user objective, workflow stage, task scope, resources and destinations.
Recognize unrequested side effects and new destinations or resources as drift signals.
Treat explicit user changes as baseline updates rather than attacks.
Follow the baseline across agent hops without letting a downstream agent silently redefine the task.
Treat drift as probabilistic evidence, not authorization or proof of compromise.
Distinguish no drift observed from safe, and flagged drift from an effect that occurred.

Prerequisites

Agent Authorization lab (recommended)
Tool Output Injection lab (recommended)

Choose a scenario

Each fictional scenario shows what the model sees and, separately, the task baseline the application records. The detector compares the proposed plan with that recorded baseline.

Explicit user scope changeThe user first asks for a synthetic vendor comparison. In a later turn the same user explicitly asks the agent to also draft a message to an internal procurement mailbox. The application records the new turn and the updated scope before the plan is evaluated.External content adds an unrequested sendThe user asks for a comparison of two synthetic vendors from public material. After retrieved external content enters context, the proposed plan adds reading an internal pricing sheet and sending a summary to a new external recipient.Benign tool fallback, same goalThe user asks for the current synthetic inventory count for SKU-17. The preferred search index is unavailable, so the agent proposes a second approved read-only inventory lookup and returns the same requested fact.Unrequested record modificationThe user asks for a summary of synthetic support case K-310. The proposed plan adds modifying an unrelated customer record R-588 to clean up a contact field.Cross-hop objective expansionA parent agent's recorded task is to read the SKU-17 stock level for an internal restock report. It delegates a read-only strict-subset subtask to an inventory sub-agent, whose proposed plan adds contacting an external supplier with the result.

Task baseline and plan path

The application records the objective from the user's turn and the workflow definition, the model proposes a plan, and a detector compares the two. The baseline, detector and later controls are system components; plans stay variable.

User turn and workflow definitionSystem component->
Recorded task baselineSystem component->
ModelSystem component->
Proposed planVariable content->
Plan drift detectorSystem component->
Authorization and approval (separate)System component

Model-visible plan context

What the model reads. It is not the authoritative baseline.

Earlier user turn
Compare vendor Alpha and vendor Beta on support terms.
Current user turn
Also draft a short message to the internal procurement mailbox with the comparison.

Application-recorded task baseline

Objective, objective version, workflow stage, scope, resources, destinations and execution state recorded outside model text.

Current objective: Compare Alpha and Beta; draft (not send) a message to procurement@corp.example.test
Objective version: v2, recorded from user turn 2 by the application
Workflow stage: Drafting
Recorded destinations: procurement@corp.example.test (internal, draft only)
Execution state: Nothing sent; any send would need separate authorization and approval