Recheck the identity behind a resumed task

Preserve identity without preserving unlimited access

Store the requester identity and task scope with the run, but do not treat those saved values as a permanent grant. A user who could read a project yesterday may have left it before the workflow resumes.

Resolve current permissions through the application's trusted authority source when the next protected action is about to run. The exact checks depend on the operation and policy. Completed historical actions and future actions need different treatment.

Avoid storing long-lived user credentials in checkpoints. Use the platform's supported credential and delegation mechanisms, with the minimum scope needed for execution.

Separate the requester from the worker

A background worker may use a service identity to call a downstream system. Its technical permission does not automatically establish that the original user is still entitled to request the action.

Document how user-level authority is represented when the downstream service only sees the worker. The application may need to enforce target ownership, role and approved scope before dispatching through that shared identity.

If the workflow intentionally continues after the requester leaves, define the business ownership that replaces them. For example, an organisation-owned process may have a designated role responsible for remaining steps. That should be a deliberate policy, not a side effect of a service account remaining active.

Review saved data at resume time

Check whether checkpointed source excerpts and tool results are still appropriate to reveal. A resumed conversation can expose information even before another tool runs. Access revocation should therefore be considered in rendering and prompt reconstruction as well as mutation execution.

Limit operators' access to checkpoint payloads. Recovery tooling often has broad visibility, and a convenient raw JSON view can reveal more than an incident requires.

Retain only the data needed for recovery and the approved history. Reference records where possible, while acknowledging that those references may later become unavailable and need a defined fallback.

Test changes during the pause

Pause a synthetic run, remove the requester's target access and resume it. Repeat after a reviewer role change and a service-credential rotation. Observe both the next action and the information shown to the user.

Record the expected policy for each case. The test should establish that durability preserves progress without accidentally preserving authority forever. A dependable resumed task can explain who owns the work now and why the next effect remains permitted.