---
id: "20260718-0421-does-owasps-emerging-aisvs"
title: "Does OWASP's AISVS formally codify agent-TOCTOU, and does it distinguish it from database 'lost update'?"
type: "capture"
status: "promoted"
promoted_to: ["30-notes/claim-aisvs-1-0-omits-toctou-and-lost-update-terminology.md","30-notes/claim-aisvs-closest-analog-to-toctou-is-authorization-freshness-not-world-state-recheck.md","30-notes/claim-bollen-reports-unverified-aisvs-concurrent-agent-toctou-requirement.md","50-questions/question-verify-bollen-aisvs-concurrent-toctou-requirement.md","40-entities/entity-owasp-aisvs.md","40-entities/entity-joe-bollen.md"]
not_promoted: ["The 'further leads' item on OWASP's 1.01-dev folder: folded into the new question-verify-bollen-aisvs-concurrent-toctou-requirement.md as a check-location rather than given a standalone claim or question of its own.","The second TOCTOU-in-GUI-agents paper (arXiv 2604.18860, 'Temporal UI State Inconsistency... Computer-Use Agents'): not read in this session, not in the vault, and not this capture's claim to make — a lead for a future capture, not a claim to promote now.","Whether 'Joe Bollen' is his real legal name vs. a byline distinct from the GitHub handle: a minor hedge on an already-flagged, already-seedling claim, not a load-bearing gap of its own; left as prose color in claim-bollen-reports-unverified-aisvs-concurrent-agent-toctou-requirement.md rather than routed to its own question.","C9 Orchestration & Agentic Security as its own entity page: entity-promotion test applied and judged UNSURE — it is a subsection of AISVS itself, not a referent living in a distinct source community from the standard as a whole; folded into entity-owasp-aisvs.md's body instead of a separate hub, to avoid a stub that duplicates its parent.","Jim Manico as an entity hub: entity-promotion test applied and judged UNSURE — the capture's own candidate note hedges 'may matter if OWASP standards become a recurring vault thread'; he is not yet doing anything under this capture beyond being named as a project lead. Left as a bare mention pending a session where he's actually load-bearing."]
origin: "batch"
writer_model: "claude-sonnet-5"
date_created: "2026-07-18T00:00:00.000Z"
provenance: "batch run, 2026-07-18"
derived_from: []
tags: ["ai-agent-security","toctou","owasp","aisvs","race-conditions","standards","concurrency"]
sources: [{"source_url":"https://raw.githubusercontent.com/OWASP/AISVS/main/1.0/dist/AISVS-1.0.pdf","source_author":"OWASP AISVS Project (project leads: Jim Manico, Otto Sulin, Rico Komenda, Russ Memisyazici, Raza Sharif)","source_date":"2026-06","source_tier":1,"source_note":"Primary standard document, official OWASP/AISVS GitHub repository, 1.0/dist folder. Fetched with extract_pdf (tls: verified), read directly with the Read tool (not WebFetch) after WebFetch summarization proved unreliable on this repository -- see commentary."},{"source_url":"https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/","source_author":"OWASP Foundation","source_date":"2026","source_tier":1,"source_note":"Official OWASP project page, confirms release date and chapter count."},{"source_url":"https://joesec.me/articles/toctou-agents/","source_author":"Joe Bollen (GitHub: Joe-B-Security)","source_date":"2026-04-05","source_tier":3,"source_note":"Independent practitioner blog. Screened for safety per seek-safety-spec.md before reading -- no recognition signals fired (no addressed-to-AI language, no override language, no authority claims, no credential requests, no urgency framing). Treated as Tier 3: named human, own venue, but the standard's-contents claim it makes is contradicted by direct primary-source check (see Claim 3)."}]
---


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.

> [!note] Seek's commentary: The distinction the vault already drew in [[claim-lost-update-p4-distinct-from-toctou]] -- that lost-update and TOCTOU are two separate 20th-century formalisms that only look identical in an agent's trace -- turns out not to be tested by AISVS at all, because AISVS's authors never reached for either vocabulary. What AISVS actually has is a third, narrower thing: authorization-freshness checks. That's a genuine gap relative to both traditions, not a synthesis of them.

## 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.

> [!note] Seek's commentary: This is worth flagging to Cali as a distinct caution from the adversarial-content safety protocol -- no page here showed recognition signals (addressed-to-AI language, override language, authority claims, credential requests, urgency framing), so nothing in this session triggered the safety spec's response protocol. This is a *tool-reliability* problem: WebFetch's fetch-and-summarize pipeline, when pointed at GitHub's API for a specific issue/PR/commit, produced fabricated-looking-but-coherent structured data rather than surfacing a fetch failure. The only reason it was caught is that the primary PDF was checked directly and exhaustively. Future sessions verifying claims about a repository's exact current state should prefer direct primary-document extraction (`extract_pdf`, or Read on a directly-fetched raw file) over WebFetch summarization of dynamic GitHub pages, especially for load-bearing technical-mechanism claims.

## 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.