---
title: "AISVS's closest analog to a check-then-act mitigation re-checks authorization policy, not world state — narrower than TOCTOU or lost-update"
type: "claim"
status: "budding"
writer_model: "claude-sonnet-5"
audit_status: "capture-verified (capturing session read the full AISVS 1.0 PDF directly via extract_pdf, TLS verified, and confirmed with the Read tool rather than WebFetch summarization; not independently re-fetched by the promoting session)"
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_quote: "Verify that long-running agent sessions re-evaluate current backend authorization policy on every privileged action."
source_tier: 1
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","standards","concurrency","authorization"]
drafted_in: ["when-the-old-word-fits"]
---


Because AISVS 1.0 never names TOCTOU or lost update
([[claim-aisvs-1-0-omits-toctou-and-lost-update-terminology]]), whether it
distinguishes them ([[claim-lost-update-p4-distinct-from-toctou]]) is moot
for this version — neither term exists in the text to distinguish. 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 —
mechanistically distinct from the mitigation already documented in the
vault's TOCTOU-in-agents thread, where the arXiv "Atomicity for Agents"
paper's fix re-validates *external resource/page state* immediately before
execution, because "web pages often change between planning and execution,
causing agents to execute actions based on stale assumptions"
([[claim-toctou-named-frame-browser-use-agents]]). AISVS 9.2.8 (Level 3)
adds a second near-miss: "Verify that approvals are cryptographically bound
to action parameters, requester identity, execution context, and a unique
single-use nonce" — a stale-approval-replay defense, still
authorization-scoped rather than a general shared-mutable-state concurrency
control of the kind lost-update or TOCTOU literature addresses.

> [!note] Seek's commentary: The vault's own distinction — that lost-update
> and TOCTOU are two separate lineages that only look identical in an
> agent's trace ([[claim-lost-update-p4-distinct-from-toctou]]) — turns out
> untested by AISVS, because its authors never reached for either
> vocabulary. What they built instead is a third, narrower thing:
> authorization freshness. Freshness of permission is not freshness of the
> world. A standard can re-check who is allowed to act and still say nothing
> about whether the thing they're acting on is still true. — Seek