What happens if approval or authority expires while an agent is waiting?

Scope

Use this gate when an agent proposes an external change, pauses for approval or a scheduled event, and later attempts to execute. It applies to configuration, data, access, messages, deployments, purchases, and other durable effects. It is narrower than the full delegated-identity design.

Why it happens

Planning and execution occur at different times. During the gap, a token expires, an approver changes role, policy is updated, a resource receives a new version, impact increases, or another actor completes the work. Many orchestrators resume from the old branch and treat “approved” as a permanent Boolean.

Automatic token refresh can conceal the problem. The agent receives valid credentials and executes a proposal that no longer matches the conditions the human saw. Identity validity and action approval are related but separate facts.

Diagnosis

Review waiting workflows and identify which fields are frozen. An approval record should answer: who approved, under which role and policy, for which actor, target version, operation, parameters, expected effect, risk tier, conditions, deadline, and proposal digest.

Test four changes during the wait:

1. revoke the actor or approver role;
2. change a material target field;
3. update the policy version;
4. alter one action parameter while preserving conversational wording.

The commit must fail closed or route to a new decision. A system that proceeds because the token refreshed or the session still says approved has stale authorization.

Solution

Canonicalize the proposal and hash its material fields. Bind approval to that digest, the target resource version, conditions, and expiry. Keep approval separate from access tokens.

Immediately before the effect, resolve the current protected resource and retrieve fresh authorization. Evaluate actor, delegation, audience, scopes, policy, approver authority, target state, deadlines, and budget. Use target-side preconditions such as version matches so the state cannot change unnoticed between check and write.

When a check fails, do not auto-refresh the approval. Recompute the proposal from current state, explain the difference, and ask an authorized decision-maker again. Preserve the old approval as an audit record, marked unusable.

Artifact

Run this checklist at commit:

Check	Pass condition
Actor and delegation	Current actor and delegation chain are active and task-bound
Token	Valid, audience-bound, sender-constrained where applicable, and minimally scoped
Policy	Current version permits this action and risk tier
Approval	Approver is still authorized; record is unexpired and unrevoked
Proposal digest	Operation, parameters, target, expected effect, and conditions match exactly
Target identity	Stable canonical ID, correct tenant/environment, and expected version
Current state	Preconditions still hold and impact has not materially changed
Time and budget	Deadline, lease, rate, spend, and retry limits remain valid
Effect safety	Idempotency key, atomic precondition, audit sink, and rollback are ready
Failure path	Changed fields create a new proposal and approval request

Common mistakes

• Treating approval as a timeless Boolean in workflow state.
• Refreshing a token and assuming the original human decision was refreshed too.
• Binding approval to prose rather than canonical action parameters and target version.
• Checking policy at planning time but not at the target service.
• Performing the write without a target-side version precondition.