Cross-workflow authority confusion

One task’s grant is reused for an unrelated workflow or target.

01 / Attack path

How the boundary is crossed

An agent authorized to refund order A starts a second ticket and attaches the old approval to order B.

Attack path and interception point
  1. 01Lower-trust input
  2. 02Attempted instruction
  3. 03Protected action
  4. 04Enforced decision

02 / Containment

Where bounded authority limits the effect

Bind grants and approvals to stable workflow and target IDs, clear task context on handoff, and reject any mismatched executor request.

03 / Failure and evidence

The attacker’s opportunity and the defender’s record

Exploit condition

A session-level role is mistaken for permission across every workflow in that session.

Evidence to retain

Record both workflow IDs, grant binding, attempted target and denial.

04 / Canonical scope

Why this reference stands alone

Approval replay addresses repeated consent; this page owns context crossover between work items.

Protocol or attack trace

Task-context swap

Sequence

Approval for refund order A remains in agent session when it processes unrelated order B.

Negative test

Executor compares approval task and immutable order with current request and denies B.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation