A gap opens the moment scheduling and execution separate
A deferred action is requested at one point in time but executed at a later one — a scheduled send, a delayed post, a future-dated change — which opens a gap between when the requester's authorization was originally checked and when the action actually takes effect. During that gap, the principal's actual authorization can genuinely change: access could be revoked, a role could shift, an account could be suspended, all after the action was scheduled but before it ever runs.
A system that authorizes only once, at scheduling time, and simply carries out the deferred action later without re-checking is effectively trusting a snapshot of authorization that may have already gone stale by the time it matters — the action executes under authority the principal may no longer actually hold.
Re-checking at execution, not just trusting the original snapshot
Closing this gap means re-verifying authorization at the moment a deferred action actually executes, not solely at the moment it was originally scheduled — the same underlying discipline that governs a long-lived session or a cached authorization decision, applied specifically to actions whose scheduling and execution are separated in time. A deferred action that skips this re-check inherits the exact risk a stale authorization cache does, for the exact same underlying reason: time has passed, and something relevant may have changed during it.