Time-of-check to time-of-use risk in agent authorization

An ALLOW for request R at time t does not authorize a changed request or a revoked grant at execution time t+Δ. Bind the decision to exact parameters and a short validity window.

01 / Attack path

How the boundary is crossed

An agent receives approval to isolate endpoint E-42. The incident is reassigned and the agent changes its target to E-43 before the cloud executor acts.

Attack path and interception point
  1. 01Lower-trust input
  2. 02Attempted instruction
  3. 03Protected action
  4. 04Enforced decision

02 / Containment

Where bounded authority limits the effect

Canonicalize the request, bind the decision to a digest, verify target and grant freshness at the executor, and choose a validity period matching the consequence. If the request changed, decide again.

03 / Failure and evidence

The attacker’s opportunity and the defender’s record

Exploit condition

A stale ALLOW is replayed against E-43 because the executor checks only that a decision token exists.

Evidence to retain

Retain decision time, request digest, grant version, revocation time, execution time and actual target. The timestamps expose the race window.

04 / Canonical scope

Why this reference stands alone

Decision caching discusses storage and reuse; this page owns the temporal gap between a check and the protected use.

Implementation review

Check/use race

t0 evaluate isolate(E-42) under grant G7 → ALLOW for digest H1. t1 revoke G7 or change target. t2 executor receives isolate(E-43) → digest H2 ≠ H1 → DENY and re-evaluate.

Adversarial check

Pause execution after ALLOW, change only the endpoint identifier, then resume. The original decision must not authorize the modified target.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation