TOCTOU in AI agents: atomicity violations between observation and action

What is this?

Time-Of-Check to Time-Of-Use (TOCTOU, CWE-367) is a decades-old class of operating-system bug: a program checks a condition, then acts on it, but the state changes in the window between the two — so the check was valid when it ran and no longer holds when the action fires. Three independent publications in 2026 show that AI agents reintroduce this flaw, and that the timing window is wider than in conventional software because the agent waits on model inference between perceiving and acting.

A UC San Diego paper, “Temporal UI State Inconsistency in Desktop GUI Agents” (arXiv:2604.18860, 20 April 2026), formalizes it for computer-use agents as a Visual Atomicity Violation. A parallel paper, “Atomicity for Agents” (arXiv:2603.00476, February 2026), documents the same flaw in browser-use agents. And security researcher Joe Bollen described it (5 April 2026) in multi-agent orchestration, contributing a new requirement to the OWASP AISVS standard.

How it works

A screenshot-and-click agent runs a loop: capture the screen (the check), send pixels to a model, wait for a decision, then dispatch a click at fixed coordinates (the use). The UC San Diego team measured the gap between observation and action — the observation-to-action gap — at a mean of 6.51 seconds on real OSWorld workloads. That is an enormous window for an unprivileged local process or a piece of dynamic web content to rearrange the interface after the agent has “decided” but before it acts.

The paper characterizes three attack primitives, all defensive demonstrations rather than deployable exploits:

# Conceptual only — illustrative, not an actionable payload.
A) Notification Overlay Hijack  — pop an overlay over the agent's target after the screenshot
B) Window Focus Manipulation    — shift focus so a fixed-coordinate click lands on a different control
C) Web DOM Injection            — mutate the DOM under the cursor with zero visual footprint

Primitive B — the closest desktop analog to Android “action rebinding” — achieved a reported 100% action-redirection success rate with zero visual evidence at observation time: the screenshot the agent reasoned over looked completely benign. The flaw is model-agnostic, reproduced across the three frontier models the authors tested (the paper names Claude Opus 4.6, GPT-4o, and Qwen3.6-plus).

The multi-agent variant needs no UI at all. When a Refund Agent and a Fraud Agent read and write the same account state concurrently, a refund can be issued in the milliseconds before a fraud freeze lands — both agents behave correctly in isolation, but the interleaving lets value leave the system. This is the same hazard as the lethal trifecta seen from the orchestration layer instead of the prompt layer.

Why it matters

This is a logic and timing vulnerability, not a prompt-content one, so the defenses we usually reach for miss it. Input filters, instruction hierarchies, and jailbreak classifiers all inspect text; none of them notice that the screen moved or that another agent wrote first. Sequential testing also misses it, because the bug only exists under concurrent execution or adversarially timed UI changes — the system looks like it is working when you check the end state and the audit log.

The blast radius scales with autonomy. A computer-use agent that clicks “Confirm” on the wrong dialog, or a billing agent that pays out a flagged account, produces a real-world side effect that no amount of post-hoc log review reverses.

Defenses

The unifying fix is atomicity: make the check and the use inseparable.

For GUI and browser agents, re-verify the world immediately before each action. The UC San Diego Pre-execution UI State Verification (PUSV) does this in three layers — masked-pixel SSIM at the click target, a global screenshot diff, and a window-snapshot diff — and reports a 100% action-interception rate across 180 adversarial trials with zero false positives and under 0.1 s overhead. Crucially, no single layer caught everything (the zero-footprint DOM-injection primitive slipped past pixel checks entirely), which argues for defense-in-depth across the OS and DOM rather than one detector. The browser-agent paper proposes the same shape of mitigation: validate DOM and layout state right before execution. This generalizes the “look again before you commit” idea behind verify-before-commit tool handling and screenshot guards like SnapGuard.

For multi-agent systems, push atomicity into the state layer: database transactions, optimistic locking, or compare-and-swap so that an authorization check and the mutation it gates cannot be split by another agent’s write. These are familiar concurrency primitives that get overlooked when teams focus on model behavior instead of orchestration. Keeping agents within the Agents Rule of Two limits how much damage a lost race can do.

Status

Setting	Publication	Date	Defense proposed
Desktop / computer-use agents	arXiv:2604.18860 (UC San Diego)	20 Apr 2026	PUSV (pre-execution UI re-verification)
Browser-use agents	arXiv:2603.00476	Feb 2026	Pre-execution DOM/layout validation
Multi-agent orchestration	OWASP AISVS contribution (J. Bollen)	5 Apr 2026	State-layer atomicity (locking / CAS)

All three are published research with working mitigations; none describes an unpatched product 0-day. TOCTOU in agents is a design hazard to engineer against, not a single CVE to wait on.