A parent agent can fan work out to children, and those children may be paused, remote or waiting for tools. Cancelling the parent task only helps if the descendants’ future actions are actually stopped.
01 / Read the source
What the primary material says
NIST’s work places delegation among the central identity and authorization questions for agents. OWASP’s runtime controls point toward enforcement at action time. Neither document supplies a universal propagation latency for every enterprise system, so a design must state its own consistency and failure assumptions.
No distributed architecture can retroactively prevent an action that committed before cancellation. “Kill switch” language can obscure this limit. The goal is to stop future effects, bound the propagation interval and reconcile actions already accepted. NIST’s discussion identifies delegation as a challenge; the concrete state machine and timing guarantees here are an engineering proposal.
02 / Architectural consequence
Where the trust boundary changes
Imagine a child queued to restart a server after a parent maintenance task is cancelled. Its credential may not expire for several minutes. If an executor checks only the child’s token, the cancellation has no effect. If it validates the ancestor grant and current revocation state, the restart can be denied before the effect.
The hard case is the paused, remote child
A cancellation event should invalidate grants derived from the cancelled parent, but descendants may not be running when it occurs. One child may hold a token in a queue, another a cached allow in a different region and a third may be in the middle of a downstream call. A graph reference to the ancestor makes dependency explicit; an action-time executor check or reliable propagation makes the cancellation effective. The system must define its consistency window and record an in-flight result that cannot be reversed by revocation.
03 / ProofGrid analysis
Authority beyond the credential
The authority graph offers a way to name dependency: the child grant is valid only while each relevant ancestor remains valid. ProofGrid applies this revocation principle; no performance or propagation-latency claim is made without benchmark evidence.
04 / A testable next step
What a security architect can do
Create a revocation test with a paused child, a different region and a warm decision cache. Record cancellation time, propagation time, next decision and any in-flight action. Define what happens if the revocation source is unreachable.
How fast must a high-impact executor learn of revocation? Is an offline child allowed read-only work, or must it stop? Does a valid credential outlive its ancestor grant? What does the operator see when an action was in flight at cancellation? Test all cases before stating that child revocation is complete.
Primary sources
Read the documents
Durable references