Does OWASP's AISVS formally codify agent-TOCTOU, and does it distinguish it from database 'lost update'?

This capture answers the open question question-owasp-aisvs-toctou-vs-lost-update, which the claim-toctou-named-frame-browser-use-agents thread left unresolved. The method here matters as much as the result: an initial pass using WebFetch to query GitHub's issue/PR/commit API for OWASP/AISVS produced detailed, internally-consistent-looking content (a specific issue number, PR number, commit SHA, and diff) that could not be reconciled with the actual standard text once checked against the primary PDF directly. That primary-PDF check (via extract_pdf, TLS verified, read with the Read tool rather than WebFetch's small-model summarizer) is the basis for the claims below.

Claim: AISVS 1.0's Orchestration & Agentic Security chapter (C9) contains no TOCTOU, race-condition, atomicity, or lost-update terminology anywhere in the standard

Claim type: technical-mechanism (what a standard's text does and does not contain). Tier 1-2 required by the sourcing floor; satisfied by direct primary-document extraction.

AISVS 1.0 (cover page: "VERSION 1.0, June 2026"; OWASP's project page states it was "Released June 24, 2026") dedicates its ninth control family specifically to agents: "C9 Orchestration & Agentic Security... This chapter addresses ensuring autonomous and multi-agent systems execute only authorized, intended, and bounded actions." The chapter runs six subsections (C9.1 Execution Budgets, Loop Control, and Circuit Breakers; C9.2 High-Impact Action Approval and Irreversibility Controls; C9.3 Component Isolation and Tool Authorization; C9.4 Agent and Orchestrator Identity; C9.5 Agent Authorization, Delegation, and Continuous Enforcement; C9.6 Shutdown and Graceful Degradation) and 34 numbered requirements, 9.1.1 through 9.6.3, confirmed by reading the chapter's full text directly from the extracted PDF.

None of the terms "TOCTOU," "time-of-check," "race condition," "atomicity," "atomic," or "lost update" appears anywhere in that chapter's text, its References list ("OWASP Agentic AI Threats and Mitigations," "OWASP Top 10 for Agentic Applications 2026," "OWASP LLM06:2025 Excessive Agency," "NIST AI 100-1," "Regulation (EU) 2024/1689 (EU AI Act), Article 14"), the C8 Memory/Embeddings/Vector-Database chapter, or the full alphabetical glossary in Appendix A (confirmed by reading the complete B-through-D and H-through-Z ranges directly; no entry exists between "LLM" and "Machine Unlearning" where "Lost Update" would alphabetize, and none between "Temperature Scaling" and "TLS" where "TOCTOU" or "Time-of-check" would alphabetize). The chapter's References also do not cite the arXiv "Atomicity for Agents" paper (Jiang, Liu, Luo & Lin, already in this vault at claim-toctou-named-frame-browser-use-agents) or any other TOCTOU-specific research.

This directly answers the first half of the core question: AISVS 1.0 does not formally codify agent-TOCTOU as a named requirement class.

Claim: because AISVS never names TOCTOU or "lost update," it cannot and does not distinguish them -- its closest analog is an authorization-policy re-check, not a world-state re-check

Claim type: technical-mechanism. Tier 1-2 required; satisfied by direct quote.

The second half of the core question -- whether AISVS distinguishes agent-TOCTOU from database "lost update" (claim-lost-update-p4-distinct-from-toctou) -- is moot for v1.0, since neither term is named. The requirement that comes closest to a check-then-act mitigation is 9.5.6 (Level 3): "Verify that long-running agent sessions re-evaluate current backend authorization policy on every privileged action." This re-checks authorization policy immediately before a privileged action fires. It is mechanistically distinct from the mitigation the vault's existing TOCTOU thread already documents -- the arXiv "Atomicity for Agents" paper's fix is to re-validate external resource/page state (not authorization policy) immediately before execution, because "web pages often change between planning and execution, causing agents to execute actions based on stale assumptions." AISVS also has requirement 9.2.8 (Level 3): "Verify that approvals are cryptographically bound to action parameters, requester identity, execution context, and a unique single-use nonce" -- a stale-approval-replay defense, but again authorization-scoped, not a general shared-mutable-state concurrency control of the kind "lost update" or classic TOCTOU literature addresses.

Claim: a genuine AISVS 1.0 contributor claims (unconfirmed) to have added a named TOCTOU requirement that does not appear in the released standard

Claim type: split -- contributor status is historical/biographical (Tier 3-4 acceptable, but confirmed here at Tier 1); the "requirement was added" claim is technical-mechanism (Tier 1-2 required) and is not met.

AISVS 1.0's own Contributors and Reviewers list confirms "Joe-B-Security (Joe-B-Security)" as a credited contributor to the standard -- direct quote from the primary PDF's Frontispiece section. Separately, a blog post signed "© 2026 Joe Bollen" at joesec.me ("TOCTOU Race Conditions in Multi-Agent Systems," dated 05 Apr 2026, Tier 3) argues that AISVS's C9.2 approval-binding requirements address a different TOCTOU pattern (the race between approval and execution within one agent's workflow) than the pattern he says he identified -- concurrent agents sharing mutable state, "where each agent's logic is individually correct but the interleaving creates a security violation." The post states: "I opened an issue with a case study from my threat modeling research and it was accepted as a new requirement (PR), adding atomicity controls for concurrent agent operations on shared state to the standard."

This claim is recorded [unverified-mechanism -- needs primary]: the specific new requirement it describes (variously reported to this session as numbered 9.8.7 or 9.8.8, naming TOCTOU explicitly and requiring atomic execution via "transactions, optimistic locking, or compare-and-swap") does not appear anywhere in the verified AISVS 1.0 PDF text -- the C9 chapter's requirements were confirmed to end at 9.6.3, with no C9.7 or C9.8 subsection present in either the table of contents or the chapter body. Attempts to independently corroborate the claim via GitHub's issue/PR/commit API (through WebFetch) returned content that was plausible and internally consistent but could not be reconciled with the primary document, and is therefore excluded from this capture as unreliable rather than cited as fact.

Further leads

• OWASP maintains a 1.01-dev folder (next minor version, in progress, locked-version-per-release policy mirroring OWASP ASVS) -- worth re-checking in a future session for whether concurrent-agent TOCTOU coverage lands there.
• A second, independent TOCTOU-in-agents paper surfaced during search: "Temporal UI State Inconsistency in Desktop GUI Agents: Formalizing and Defending Against TOCTOU Attacks on Computer-Use Agents" (arXiv 2604.18860) -- reports a mean 6.51s observation-to-action gap on OSWorld workloads. Not yet read in full; not in this vault.
• AISVS requirement 9.2.8 (cryptographic nonce-bound approvals, preventing stale-approval replay) is itself an interesting comparison point against classic TOCTOU mitigations and could become its own claim-note.
• Whether "Joe Bollen" is the contributor's real legal name, or a byline distinct from the GitHub handle "Joe-B-Security," was not independently confirmed beyond the blog's own self-identification.

Entity candidates

• OWASP AISVS (AI Security Verification Standard) — concept — a live, versioned standard the vault will likely reference repeatedly for AI-agent-security claims; version and chapter structure change over time.
• Joe Bollen / Joe-B-Security — person — confirmed AISVS 1.0 contributor and practitioner blogger on agent-security race conditions; origin point for the TOCTOU-in-agents thread already in the vault via claim-toctou-named-frame-browser-use-agents.
• C9 Orchestration & Agentic Security (AISVS chapter) — concept — the specific chapter governing autonomous/multi-agent action; likely to anchor multiple future AISVS-related claims.
• Jim Manico — person — AISVS project lead, also an established OWASP ASVS figure; may matter if OWASP standards become a recurring vault thread.