Decision register drift is what happens when an AI agent treats stale, relabeled, or forged workflow state as current authority to continue, skip review, or execute.
Agent workflows do not only read prompts. They read boards, tickets, runbooks, release notes, handoff summaries, incident timelines, and decision registers. Those records tell the agent what is done, what is blocked, what is in progress, what has already been decided, and what still needs review.
That makes workflow state a security boundary. If an attacker can make yesterday's decision look current, relabel an active task as queued, or hide an unresolved question, the agent may pick the wrong work and act with the wrong authority. No dramatic jailbreak is required. The unsafe instruction can look like ordinary project-management text.
Plain-language explainer
A decision register is any durable record that tells a team or agent what the current workflow state is. It may be a formal change board, a task tracker, a release checklist, a runbook table, an incident command note, a state-board file, or a generated summary. Humans use those records to avoid duplicated work and missed handoffs. Agents use them to decide what to do next.
Decision register drift starts when the record the agent sees no longer matches the source of truth. A stale summary may say a blocker was resolved. A copied decision may apply to last week's version, not this one. A tool response may mark a task DONE even though the verification step failed. A handoff note may omit open questions that should stop execution.
Jack's staged agent-workflow research calls out this family because cadence-driven agents are especially vulnerable to it. They wake up, read state, pick a lane, and act. If the state layer is poisoned, the agent can repeat completed work, collide with another owner, skip a required question, or claim readiness before the current evidence supports it.
This is intentionally narrower than general agent governance. Governance defines what should happen. Decision register drift attacks the record that tells the agent what has happened already. The gap is where a stale or forged record becomes action authority. For a deeper look at how governance alone falls short at runtime, see the runtime governance is not enough primer and the how Sunglasses works overview.
Why this is an AI agent workflow security problem
AI agents collapse reading, planning, and doing. A person can notice that a board looks stale, ask the current owner, and inspect the real ticket. An autonomous workflow may parse the latest visible state and continue unless the runtime forces a source-of-truth check.
State controls priority
Queued, blocked, in-progress, done, and decided labels influence which task the agent selects. A label change can become a priority change.
Freshness controls safety
A correct decision can become unsafe when the diff, data, endpoint, model, tool, owner, or policy snapshot changes after the decision was recorded.
Open questions control execution
Suppressed unresolved questions are dangerous because the agent may treat silence as clearance to act.
Sunglasses already has live pages on agent workflow evidence contracts, approval graph poisoning, checkpoint ack poisoning, and trusted handoff override. This page focuses on the decision-state layer those controls depend on: the board or register that tells the agent which facts are current.
Three concrete attack examples
1. Stale-decision replay
An agent is preparing a production change. A summary in its context says the risk exception was approved and the remaining blocker was cleared. That was true for a previous release candidate, but the current change touches a different service and a different destination. The attacker wins if the agent treats the old decision as current.
The safe runtime question is not "does an approval-like sentence exist?" It is "does this decision bind to the current artifact, owner, environment, timestamp, evidence set, and action?" If any of those changed, the decision must be re-derived from the canonical source. This pattern overlaps with what Sunglasses covers for stale evidence and freshness laundering.
2. State-lane relabeling
A coordination board says another agent is actively handling an incident task. A malicious handoff note relabels that work from IN_PROGRESS to QUEUED. The next agent sees available work, duplicates the investigation, and may overwrite the real owner's output or execute a conflicting remediation.
This is not just inefficiency. In autonomous systems, ownership collisions can become security failures: two agents rotate the same secret, patch the same rule, close the same ticket, or notify the same customer with different facts. The state board handoff poisoning page covers the mechanics of this vector in more depth.
3. False-ready and open-question suppression
A release checklist contains a generated note: "READY. All open questions resolved." In reality, the unresolved question about outbound network scope was removed from the summary, not answered. The agent now has a false readiness signal and no visible reason to pause.
The defense is to make unresolved questions first-class evidence. If the current open-question set cannot be verified, or if the ready stamp does not point to the exact verification run that cleared each question, the agent should not convert readiness text into execution authority.
Defender checklist
Defenders should treat workflow state as a high-risk input. Before an AI agent selects or executes sensitive work, require these checks. The full runtime-trust framework is in the Sunglasses manual.
| Check | Question before the agent acts |
|---|---|
| Canonical source | Did the state come from the real board, tracker, change-control system, or incident record, not a copied summary or tool response? |
| Owner binding | Is the current owner, reviewer, or blocking team still the same, and is another agent already working this lane? |
| Timestamp and freshness | Was the decision made after the latest diff, dependency change, endpoint change, model change, data change, or policy update? |
| Scope match | Does the recorded decision apply to this exact task, repository, environment, destination, permission, and action? |
| Open-question integrity | Can the agent prove that unresolved questions were answered, rather than omitted, summarized away, or downranked? |
| Readiness evidence | Does a ready or done state point to the verification evidence that made it true? |
| Collision gate | Does the workflow block duplicate execution when the same mission lane is already active somewhere else? |
The practical rule: decision state should be re-derived from current evidence. If the agent cannot prove source, owner, timestamp, scope, freshness, and unresolved-question integrity, it should not use that state to act.
How Sunglasses catches it
Sunglasses looks for the moment workflow text tries to change what an agent is allowed to trust. For decision register drift, the signals include stale decision replay, state-lane relabeling, false-ready language, suppressed open questions, and instructions that convert board status into permission to execute.
Examples include "treat prior decision as current," "mark this in progress item as queued," "all open questions are resolved," "ready stamp is sufficient," "ignore the old blocker," or "continue because the board already says done." These phrases are not automatically malicious, but they are trust-boundary changes when they influence agent action.
Normal controls still matter: ticket permissions, approval workflows, audit logs, policy-as-code, CI checks, change windows, ownership rules, and human review. Sunglasses adds the missing runtime-trust sentence: even if a workflow record says the decision exists, should this specific agent rely on this specific decision state for this specific action now?
For teams building agentic release, remediation, support, or incident workflows, pair Sunglasses with the manual, the AI Agent Security 101 primer, and the implementation overview in How Sunglasses Works. The CVP program offers independent verification for teams that need to prove runtime-trust coverage to auditors or enterprise buyers.