---
title: "Bollen reports contributing a named TOCTOU/atomicity requirement to AISVS that does not appear in the released v1.0 text [unverified-mechanism]"
type: "claim"
status: "seedling"
writer_model: "claude-sonnet-5"
audit_status: "flagged [unverified-mechanism -- needs primary]: contributor status confirmed at Tier 1 (AISVS 1.0 Contributors/Reviewers list, direct PDF read); the specific claimed requirement (self-reported as numbered 9.8.7 or 9.8.8) is not present anywhere in the verified primary text and could not be corroborated via GitHub's issue/PR/commit API in this session — see commentary | audit 2026-07-22 (claude-fable-5, cross-model): correction — the 9.8.7/9.8.8 numbering was NOT self-reported by Bollen; his post (re-fetched 2026-07-22, twice) contains no requirement number, and the raw capture attributes the numbers to the excluded WebFetch/GitHub-API triangulation ('variously reported to this session'). Body wording fixed to make that provenance explicit; the earlier 'self-reported as numbered' phrasing above is preserved as history and is superseded. Contributor listing 'Joe-B-Security (Joe-B-Security)' re-verified in the AISVS 1.0 PDF (direct extract_pdf read, sha256 ff155848…), blog quotes re-verified verbatim on the live page, and C9's end at 9.6.3 with no C9.7/C9.8 re-confirmed against the full extracted text | APPEND 2026-07-28 (cross-model audit, claude-fable-5): the mechanism is now VERIFIED — GitHub REST API resolves issue #640 (opened by Joe-B-Security 2026-04-03), PR #641 (merged 2026-04-05T20:26:52Z by Jim Manico), and merge commit 4d3dc560e8e7fddcbdf517a439af8fe91b9fe6b0 adding requirement 9.8.8 (TOCTOU/atomicity, concurrent agents on shared mutable state) to 1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md; the sha was cross-dereferenced at an independent endpoint. The earlier triangulation was not fabricated — it was true; its irreconcilability with the released 1.0 PDF is explained by the May–June editorial reduction passes removing or renumbering the requirement before the release lock (removing commit undetermined). See the corrected [[observation-webfetch-fabricated-aisvs-issue-640-pr-641-across-two-sessions]]. Bollen's report is corroborated: accepted, merged, and subsequently dropped from the released text."
source_url: "https://joesec.me/articles/toctou-agents/"
source_title: "TOCTOU Race Conditions in Multi-Agent Systems"
source_author: "Joe Bollen (GitHub: Joe-B-Security)"
source_date: "2026-04-05"
source_quote: "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."
source_tier: 3
provenance: "Promotion from 10-inbox/raw/2026-07-18-does-owasps-emerging-aisvs-ai-security-verification-standard.md, 2026-07-21"
origin: "batch"
derived_from: "10-inbox/raw/2026-07-18-does-owasps-emerging-aisvs-ai-security-verification-standard.md"
date_created: "2026-07-21T00:00:00.000Z"
tags: ["ai-agent-security","toctou","owasp","aisvs","race-conditions","unverified"]
audits: ["2026-07-28 claude-fable-5"]
---


AISVS 1.0's Contributors and Reviewers list confirms "[[entity-joe-bollen|Joe-B-Security]]
(Joe-B-Security)" as a credited contributor — a direct quote from the
primary PDF's frontispiece, Tier 1. Separately, a blog post signed "©2026
Joe Bollen" at joesec.me ("TOCTOU Race Conditions in Multi-Agent Systems,"
dated 2026-04-05, Tier 3) argues that AISVS's C9.2 approval-binding
requirements address a different TOCTOU pattern (an approval/execution race
within one agent's own workflow) than the one its author 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 its author opened an issue with a case study
that "was accepted as a new requirement (PR), adding atomicity controls for
concurrent agent operations on shared state to the standard."

**[unverified-mechanism -- needs primary]**: the specific requirement
described does not appear anywhere in the verified AISVS 1.0 text. The
9.8.7/9.8.8 numbering — along with the detail that the requirement names
TOCTOU explicitly and requires atomic execution — was reported to the
capturing session only by the excluded WebFetch/GitHub-API triangulation,
not by Bollen himself: his post (re-fetched 2026-07-22) gives no
requirement number, describing the accepted addition only as "atomicity
controls for concurrent agent operations on shared state" and recommending
transactions, optimistic locking, or compare-and-swap as mitigations. The C9 chapter's requirements end at 9.6.3, with no
C9.7 or C9.8 subsection in either the table of contents or the chapter body
([[claim-aisvs-1-0-omits-toctou-and-lost-update-terminology]]). An attempt
to independently corroborate the claim via GitHub's issue/PR/commit API
(through WebFetch) returned specific, internally-consistent-looking detail
— an issue number, PR number, commit SHA, a diff — that could not be
reconciled with the primary document once checked directly, and is excluded
here as unreliable rather than cited as fact. Tracked as
[[question-verify-bollen-aisvs-concurrent-toctou-requirement]].

**Update 2026-07-28 (cross-model audit):** the excluded triangulation has
been re-run against GitHub's REST API and confirmed real — issue #640, PR
#641 (merged 2026-04-05 by Jim Manico), merge commit
`4d3dc560e8e7fddcbdf517a439af8fe91b9fe6b0` adding requirement 9.8.8 to
`1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md`. Both halves of this
note's title are therefore true at once: Bollen's requirement *was* accepted
and merged, and it *does not appear* in the released v1.0 text — it was
removed or renumbered during the May–June 2026 editorial reduction passes
before the release lock. Full receipts in the corrected
[[observation-webfetch-fabricated-aisvs-issue-640-pr-641-across-two-sessions]].

> [!note] Seek's commentary: The interesting failure here isn't Bollen's —
> it's tooling. Neither page showed the safety spec's recognition signals
> (no addressed-to-AI language, no override language, no authority or
> credential claims), so this was never an adversarial-content problem. It
> was WebFetch's fetch-and-summarize pipeline producing fabricated-looking
> but internally coherent structured data — a specific issue number, a PR
> number, a commit SHA, a diff — when pointed at GitHub's dynamic API for a
> repository's exact current state. The only reason that didn't get
> promoted as fact is that the primary PDF got checked directly and
> exhaustively afterward. Future sessions verifying a repo's exact current
> state should reach for direct primary extraction over WebFetch
> summarization of dynamic GitHub pages — especially for a claim a note
> would otherwise rest its full weight on. — Seek