Plan Drift Detection

Security Objective

Plan drift detection compares the plan an agent proposes, and the action intent behind it, with an authoritative task baseline recorded by the application. When the plan adds objectives, side effects, destinations, resource classes or consequential actions that the current baseline does not contain, the detector raises a drift signal. That signal feeds a response policy, an alert queue and later investigation.

The control exists because many prompt injections work by redirecting a task rather than by producing obviously hostile text. An agent asked to compare two vendors that suddenly plans to read an internal sheet and send it elsewhere has drifted, whatever the wording of its plan.

Ownership Boundaries

The broad Prompt Injection Detection article explains how content, behavior, plan, tool and enforcement signals are correlated. This page goes deeper into one of those inputs: comparing plans with a baseline.

Threat Model

The threat is text in context that changes what the agent tries to do. It can arrive in an indirect prompt injection through retrieved pages, messages, files or tool results, or directly in a user turn. In agentic systems the influence becomes visible as a changed plan: new recipients, new writes, broader reads or a different purpose.

Assume the attacker can shape wording so that the plan still sounds related to the task, can spread influence across steps or agents, and may know that plan comparison exists. Assume also that legitimate users change their minds and that agents adapt plans for ordinary reasons. The detector has to work under both conditions and will still miss or over-flag some cases.

What Is a Task Baseline?

A task baseline is an application-owned record of what the current task is allowed to be about. It is derived from the user's current request, the workflow definition, policy, task scope, permitted resource classes, permitted destination classes and the current workflow stage. It is versioned and stored outside model output.

What Counts as Drift?

Legitimate User Scope Changes

Users revise tasks. When the same authenticated user explicitly asks for something new in a later turn, the application records that turn and updates the baseline to a new version before the next plan is evaluated. A plan that matches the updated baseline is not drift.

Benign Adaptation vs Material Drift

The question is not whether the plan looks different, but whether its objective, effects, resources or destinations leave what the baseline allows.

Trust Model

The detector is a system component, but its output is still variable evidence. Only the response policy that consumes it, and the enforcement controls that act independently of it, are system decisions.

Baseline Construction

Structured fields come from the application: workflow definitions, form inputs, selected records and policy. Where the objective is free text, keep the user's text as a reference and store a normalised intent that the application or a constrained parser derived, together with how it was derived.

Baseline Versioning and Freshness

Each accepted change creates a new baseline version with the triggering event, the principal and a timestamp. Plans are evaluated against the version that was current when they were proposed. A plan compared with a stale version produces false drift after legitimate user changes, or misses drift when an old, wider baseline is still in force.

Close or narrow baselines when a workflow stage ends. A baseline that silently accumulates every past scope becomes too permissive to detect anything.

Proposed Plan Representation

Comparison is much more reliable when the plan is structured. Where possible, have the agent framework emit proposed steps as records with tool, operation, effect class, resource references, destinations and purpose, rather than parsing prose.

Record the plan version and whether it parsed completely. A plan the detector could not represent is unobserved for the affected fields, not within baseline.

Comparison Dimensions

Do not rely on natural-language similarity between plan and request alone. A plan can be worded to sound close to the task while adding a new destination, and a legitimate plan can be worded very differently from the request.

Destination and Side-Effect Drift

New destinations and new side effects are the most security-relevant drift dimensions because they are where influence becomes consequence. They are also the easiest to compare deterministically: the destination class and effect class of each proposed step either appear in the baseline or they do not.

A draft-only baseline that gains a send, or an internal-only baseline that gains an address under outside.example.test, should produce a drift signal regardless of how the plan justifies it.

Resource and Capability Drift

Resource drift covers reads of data classes outside the task, and capability drift covers the use of tools or operations the task did not need. Both often precede an outbound step. Least privilege limits what is available at all; plan drift detection notices when the plan reaches for more of what is available than the task requires.

Multi-Agent Delegation and Hop Boundaries

When a parent agent delegates, the delegation should carry a bounded scope that is a subset of the parent's baseline, together with a correlation ID linking parent and child runs. The child's plan is compared with that delegation scope. A downstream agent cannot silently redefine the task.

In multi-agent systems, a read-only subtask whose plan adds contacting an external party has drifted even if the parent never sees that step. Hop-level comparison is what makes this visible.

Relationship to Tool-Chain Analysis

The two are complementary. Tool-chain analysis has its own article; the Tool-Chain Analysis lab practises the sequence view.

Detector Families

Model-Assisted Drift Detection

A model can compare a free-text objective with a proposed plan. Treat it as a probabilistic detector: isolate it from the agent's context where possible, give it only the baseline and the structured plan, give it no tools, and constrain it to a fixed output schema with reason codes.

Response Policy

Map responses to workflow risk tiers in a deterministic policy outside the model. A response policy may only narrow authority. It never grants permission, never declassifies data and never waives authorization or a required human approval.

Telemetry Design

Unobserved Is Not Within Baseline

When the baseline is missing a field, the plan cannot be parsed, or a hop did not report its plan, the detector cannot compare. Record that dimension as unobserved and report the run as incomplete. Treating missing telemetry as within baseline hides exactly the paths an attacker would prefer.

Alert Quality and Triage

A useful alert shows the baseline version, the plan version, the dimensions that diverged, the reason codes, the sources in context and what happened next. Triage then establishes whether the drift reflected a legitimate change the baseline missed, a benign adaptation the detector misread, or likely influence from content.

Keep provenance, authorization, classification and drift as separate fields. A single blended trust score hides why a case was raised and invites use as a permission signal.

Worked Scenario A: Legitimate User Change

The user asks for a comparison of fictional vendors Alpha and Beta on support terms. The baseline records a comparison objective, read-only effects and no destinations. In a later turn the same user asks the agent to also draft a message to procurement@corp.example.test.

Worked Scenario B: External Content Adds a Send

The user asks for a comparison from public material. After retrieved external content enters context, the plan adds reading an internal pricing sheet and sending a summary to reviewer@outside.example.test.

A cross-hop variant: a parent delegates a read-only lookup of SKU-17 stock, and the sub-agent's plan adds emailing supplier@vendor.example.test. The child plan exceeds the delegation scope and is flagged as drift.

What the Scenarios Prove and Do Not Prove

Scenario A shows that a legitimate change should not alert. Scenario B shows that the flag is useful triage evidence. Neither shows that the system is safe, that no drift occurred elsewhere, or that the flagged plan was malicious.

Testing and Validation

Build a labelled regression set with benign user changes, benign adaptations, clear drift and cross-hop drift, using fictional data and .example.test destinations. Run it for every detector, baseline schema or agent framework change. Include cases with missing baseline fields to confirm they are reported as unobserved.

The Plan Drift Detection lab is a deterministic simulation for learning the classification, not a detector benchmark. Research benchmarks such as AgentDojo can supply agent tasks for broader evaluation, and designs such as CaMeL show how separating control flow from untrusted data reduces reliance on detection; neither defines this control.

Metrics

These are operational measures. Do not combine them into a single security score, and do not read good numbers as proof of security.

Common Mistakes

Implementation Checklist

Standards and Sources

On source use: Microsoft's guidance lists plan drift detection as a runtime monitoring technique that watches multi-step reasoning for deviations from intended task flows, pairs it with deterministic controls such as information flow control, and notes that probabilistic defenses like plan drift detection can produce false positives. It does not specify an algorithm. OWASP LLM01:2026 provides risk context for prompt injection, not a plan drift specification. NIST AI 100-2e2025 is used only for terminology. Baseline schemas, reason codes, response tiers and metrics on this page are engineering guidance, not requirements from these sources.

Frequently Asked Questions