AISVS's closest analog to a check-then-act mitigation re-checks authorization policy, not world state — narrower than TOCTOU or lost-update

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.