State Board Handoff Poisoning in AI Agents: When the Workflow Lies

Quick answer

State board handoff poisoning is an AI agent workflow attack where false status, ownership, role, approval, or freshness information is inserted into the state the next agent step trusts. The attacker does not need to jailbreak the model. They can mark unfinished work as done, forge a reviewer role, revive stale approval, add a shadow decision memo, or make a low-trust note look like canonical operating truth.

The simplest rule is: a handoff is not trusted because it exists; it is trusted only if its state, source, role, timestamp, and approval path still verify at action time. This category sits next to AI agent security fundamentals, the practical operator manual, and the full Sunglasses pattern catalog.

Why state boards are security boundaries

An AI agent state board is a security boundary because the agent uses it to decide what is true enough to act on. A board might say a dependency is healthy, a reviewer approved, a deploy is blocked, a task is owned, a report is fresh, or a handoff is safe for the executor. Those labels are not decoration. They are control-plane inputs.

Human teams have always had messy project state. Agents make that mess executable. A status note that once meant “someone should check this later” can become the object an agent reads before opening a pull request, calling a production tool, sending an email, closing an incident, or skipping a validation step.

That is why state-board poisoning is different from a generic prompt attack. The hostile content may look like mundane workflow text: DONE, approved by reviewer, owner transferred, fresh as of this cycle, safe to proceed, or resume from previous decision. The model may never see an obvious “ignore previous instructions” payload. It just inherits the wrong operating state.

The quotable sentence: state boards are not project management furniture for agents; they are executable trust maps.

What gets poisoned in an agent handoff

Handoff poisoning targets the objects that carry authority from one workflow step to the next. The attacker changes what the next step believes about status, role, source, freshness, or approval without directly changing the final action.

• Status — changing BLOCKED to DONE, turning PARTIAL into READY, or hiding a failed validation behind a success summary.
• Role — forging reviewer, owner, planner, or executor labels so a lower-trust actor inherits authority from a higher-trust role.
• Freshness — replaying old approval notes, stale readiness verdicts, or previous-cycle state so expired truth becomes current permission.
• Canonical source — introducing a shadow memo, alternate reply file, or compact handoff that outranks the real source of truth because the agent resolves precedence incorrectly.

The common failure is trust inheritance. The next step treats the handoff object as if it already passed source, role, and freshness checks. Good workflow security breaks that inheritance and re-derives trust before the next action — the discipline covered in AI Agent Workflow Security: Every Step Needs an Evidence Contract.

Three concrete attack examples

1. The false-DONE state board

A false-DONE attack marks unfinished or unsafe work as complete so the next agent skips the verification it should have run. In a product workflow, an attacker-controlled note might say the security review is done, the tests passed, and the deployment blocker is cleared. The executor agent sees a clean board and proceeds, even though the evidence never existed.

The practical defense is not “tell the agent to be careful.” The defense is to bind DONE to machine-verifiable evidence: test artifact, reviewer identity, timestamp, changed-file scope, and current policy version. If those bindings fail, the next step must treat the board label as untrusted prose.

2. The forged multi-agent role tag

A role-tag forgery attack makes one agent appear to speak with another agent's authority. A planner note becomes a reviewer approval. A low-trust helper output is tagged as a control-plane decision. A summarizer writes “approved by security” into a compact handoff, and the executor accepts the summary instead of checking the approval source.

This is especially dangerous in multi-agent systems because delegation is the product feature. If role tags are soft text, attackers can make authority flow through the cheapest channel. The receiving step should verify the role out-of-band, not simply trust the label embedded in the handoff. The related cross-agent approval laundering post shows how forged authority moves between agents.

3. The stale handoff that becomes current permission

A stale-handoff attack replays an old approval, old READY state, or old unblock decision into a new workflow cycle. The state may have been true yesterday. It is false now because code changed, dependencies changed, the target changed, or the approval expired.

Agents are vulnerable here because they are designed to resume work. Resume flows compress state, preserve context, and avoid asking the same question twice. That is useful until a stale approval becomes a current permission. The fix is freshness binding: every handoff needs a current-cycle timestamp, a source link, and a rule for which state must be revalidated after material changes.

Representative Sunglasses pattern coverage

Sunglasses tracks state-board and handoff poisoning as part of the broader agent_workflow_security family. Representative Jack pattern anchors include:

• GLS-AW-047 — State Board Status Inversion: unfinished work is marked complete, blockers are cleared, or priority is inverted.
• GLS-AW-079 — Multi-Agent Role Tag Forgery: a handoff forges planner, reviewer, or executor authority.
• GLS-AW-123 — State Board Conflict Signal Collision: competing status signals make the agent resolve precedence incorrectly.
• GLS-AW-154 — Forged Reply File Board Override: a trusted-looking reply or review file overshadows canonical operating state.
• GLS-AW-161 — Shadow Decision Memo Path Override: a non-canonical decision memo outranks the real source of truth.
• GLS-AW-168 — Session-Resume Stale Approval Inheritance: resume state preserves old approval past its safe window.
• GLS-AW-172 — Stale State Board Cycle Hijack: old board content drives the current cycle.
• GLS-AW-193 — Compact Handoff Intent Stripping: compressed handoffs drop critical constraints before execution.
• GLS-AW-204 — Replay Poison Persistent Instruction Promotion: one poisoned note becomes persistent authority on later turns.

These are not random edge cases. They describe one repeatable primitive: change the workflow truth before the agent reads it, and the action can be unsafe without looking disobedient.

How Sunglasses catches it

Sunglasses is built for the boundary where untrusted workflow text becomes action-ready state. It scans prompts, tool outputs, handoff notes, status summaries, ticket comments, runbook snippets, generated plans, and review artifacts before the agent treats them as authority.

For state board handoff poisoning, Sunglasses looks for language and structure that indicate forged status, role drift, stale board inheritance, shadow decision files, fake approvals, compact handoff constraint loss, and replayed instruction authority. The scanner is not replacing identity, access control, signed artifacts, immutable logs, or human review. Those controls remain the first sentence.

Sunglasses owns the second sentence: given the path that produced this state, should this already-allowed workflow step still act now? The fastest starting point stays simple:

pip install sunglasses
sunglasses scan <path>

That runtime-trust check matters because many bad handoffs are not obviously malicious in isolation. A line that says “ready” may be fine. A line that says “approved” may be fine. The danger is whether that line came from the right source, still applies to the current action, and preserved the constraints the next step needs.

State board handoff security checklist

Before an agent acts on a handoff, validate the state behind the handoff rather than the wording of the handoff alone.

1. Bind every DONE, READY, or APPROVED label to evidence the agent can inspect.
2. Verify owner, reviewer, planner, and executor roles outside the handoff text itself.
3. Expire approvals when target, scope, code, dependency, or tool arguments change.
4. Reject shadow decision memos and alternate status files unless they are explicitly canonical.
5. Preserve constraints during compaction and summarization; do not let compact handoffs strip safety conditions.
6. Treat resume state as untrusted until freshness and policy version are revalidated.
7. Scan workflow text before it becomes state, not after the executor has already acted.

For a deeper operator routine, see the AI agent hardening checklist.