Approval-to-Execution Races
Is the approved action still the action about to execute?
Reference notes by Min · Reviewed October 15, 2026
Definition
An approval-to-execution race occurs when a material fact changes after a decision is checked but before the operation uses it. Agent workflows are exposed when proposals, permissions or target records can change during a long approval or execution interval.
A person can make a reasonable decision based on the information shown and still authorize a different eventual action if the system does not preserve that relationship. The gap may be seconds or hours; its significance depends on what can change during it.
What it covers
- Checked facts
- The values and permissions considered during review.
- Mutable state
- What may change before execution.
- Commitment
- The boundary where effects become real.
- Revalidation
- The conditions that must still hold.
List the material facts for each action class. Recipients, amounts, data scope and permission status are common examples. Some facts can be captured in an immutable proposal; others must be revalidated because they depend on current authorization or resource state.
In practice
Practical design patterns by Min.
- Bind approval to a stable proposal or version.
- Recheck material conditions at commitment.
- Invalidate approval after relevant values change.
Use a service contract that checks the relevant preconditions as part of committing the operation. Where the external service cannot provide that guarantee, document the residual race and choose restrictions or a manual process suitable for the consequence.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
The check and the use can diverge
MITRE CWE-367 describes a resource changing between checking its state and using it. Agent approval delays create an analogous design concern; the article’s transaction controls are an application, not a separate CWE.
Source: MITRE CWE-367: Time-of-check Time-of-use Race Condition ↗
Working example
An approved payment changes destination
A payment waits in a queue after approval while the supplier record is edited.
- Retain the approved recipient and amount.
- Compare them with the final proposed transaction.
- Stop and request new review when the destination differs.
Why the controls matter
The payment case shows why reviewing a supplier name is insufficient if its underlying bank destination can change. The execution record should identify the approved version and actual committed values so investigators can detect divergence.
Common pitfalls
- Approving a mutable object by name alone.
- Checking immediately before a call without an atomic service guarantee.
- Assuming a valid approval has unlimited duration.
Revalidation should not silently alter the proposal to make it executable. A changed value may require a fresh decision. Test delayed execution, permission revocation and concurrent edits rather than only immediate approvals on an unchanged record.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which facts can change after review?
- Does commitment enforce the approved version?
- What requires a fresh decision instead of automatic repair?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- MITRE CWE-367: Time-of-check Time-of-use Race Condition ↗Accessed October 15, 2026
- IETF RFC 9110: HTTP Semantics, conditional requests ↗Accessed October 15, 2026