EVIDENCE TRAIL
Workflow state consistency
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The threat model (T21 Inconsistent Workflow State, T31 Insufficient Isolation Between Agent Actions) is defined verbatim in OWASP MAS Guide v1.0. The control mechanisms — WAL, OCC, 2PC — derive from distributed-systems literature; Temporal.io's engineering blog provides the workflow-engine application of those primitives.
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP MAS Guide v1.0 — Multi-Agentic System Threat Modeling Guide
§3 RPA Expense Reimbursement Agent Threat Modeling — Layer 3: Agent Framework (T21 entry)
"T21 - Inconsistent Workflow State: Discrepancies in the system's state and shared objects (e.g., shared memory) among agents can lead to conflicting actions or denial of service. For instance, an RPA agent may route only a subset of approved claims for payment due to a state synchronization delay between the validation and routing steps."
Supports: Verbatim source definition of the primary threat this control addresses. Establishes state-synchronization delay as the concrete exploit vector — exactly the gap that hash-chained snapshots and merge-point conflict detection close.
Does not prove: Does not prescribe a specific mitigation mechanism. The guide identifies the threat; Helmwart derives the WAL/OCC/merge-check control from the threat model.
OWASP MAS Guide v1.0 — Multi-Agentic System Threat Modeling Guide
§3 Threat Summary Table (page 35) — T21 row
"T21 — Inconsistency Workflow's State — Inconsistent\ unsynchronized views of the workflow's state \ shareable objects (e.g., shared memory or graph objects) among agents can lead to conflicting actions or result in a denial of service."
Supports: Canonical tabular definition of T21. Adds "graph objects" to the shared-memory scope, confirming the threat applies to any shared data structure, not only message queues.
Does not prove: Table form only — no mitigation text in this row. Extended threat scenario column references are on subsequent pages.
OWASP MAS Guide v1.0 — Multi-Agentic System Threat Modeling Guide
§4 Eliza OS Threat Modelling — Layer 3: Agent Framework (T31 entry)
"T31 - Insufficient Isolation Between Agent Actions: The framework doesn't provide strong enough isolation between the actions of different agents or between different actions performed by the same agent. This could allow a vulnerability in one part of the system to affect other parts."
Supports: Verbatim source definition of T31 — the secondary threat this control addresses. Confirms that per-stage state scoping (the consistency-layer analogue of namespace ACL) is the required isolation mechanism.
Does not prove: T31 is described in the ElizaOS blockchain context; the underlying isolation principle is general but the surrounding examples are blockchain-specific.
Martin Fowler — Write-Ahead Log (Patterns of Distributed Systems)
Pattern description — Problem and Solution sections
"Provide durability guarantee without the storage data structures to be flushed to disk, by persisting every state change as a command to the append only log. Once a server agrees to perform an action, it should do so even if it fails and restarts losing all of its in-memory state."
Supports: Establishes the WAL pattern as the canonical mechanism for durable state capture before execution — the same append-only-log primitive that event-sourced workflow engines (Temporal, Step Functions) build on.
Does not prove: Describes the storage-layer primitive, not the application-level workflow orchestration use case. Does not name multi-agent systems or agentic AI.
Temporal.io — Workflow Engine Principles
Slides: "State preservation" and "Transactional guarantees" sections
"If your program restarts or the backend service goes down, your program will be in exactly the same state with all local variables and stack traces in exactly the same state. … If all these updates are transactional, then all these race conditions disappear. The system becomes simpler and application level code doesn't see all these edge cases and it simplifies the programming model."
Supports: Provides verbatim evidence that transactional state preservation eliminates the race-condition edge cases that produce T21. The "race conditions disappear" quote is the direct operational justification for deploying an event-sourced workflow engine as the implementation substrate for this control.
Does not prove: Describes Temporal's own engine; does not generalise to other orchestrators. Does not use the phrases "exactly-once" or "hash-chained" explicitly.
Martin Fowler — Two-Phase Commit (Patterns of Distributed Systems)
Pattern description — Intent and Problem sections, plus Solution note linking 2PC to WAL
"Update resources on multiple nodes in one atomic operation. When data needs to be atomically stored on multiple cluster nodes, nodes cannot make the data accessible to clients until the decision of other cluster nodes is known. It is crucial for each participant to ensure the durability of their decisions using pattern like Write-Ahead Log."
Supports: Documents 2PC as the distributed-consistency primitive for multi-node atomic writes — the fallback mechanism referenced in the mitigation's Limitations section for workflows with hard safety requirements where OCC is insufficient.
Does not prove: Describes the infrastructure primitive, not the agentic-workflow application. 2PC is listed as a fallback, not the primary mechanism.
Gray and Reuter — Transaction Processing: Concepts and Techniques (1992)
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Canonical academic reference for write-ahead logging, optimistic concurrency control, and two-phase commit — the three primitives that Helmwart maps onto the multi-agent workflow context. WAL (Chapter 10), OCC (Chapter 8), and 2PC (Chapter 12) are all defined here. Every subsequent implementation (Temporal, Step Functions, PostgreSQL) is an engineering application of these foundational treatments.
Does not prove: Published 1992; predates multi-agent AI systems and agentic workflows. No verbatim excerpt pulled — the book is not freely available online; cited as authoritative background reference, not a web-verifiable quote source.