Authority revocation for agents

Authority revocation marks an origin, grant or task invalid and must be checked along every descendant chain before another consequential effect.

01 / The operating case

What changes in a real workflow?

An operator cancels a maintenance task while its child agent waits to restart a server. The child’s next request must fail.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Propagate the revocation to enforcement points, invalidate caches, and specify behavior during partition or propagation delay.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

Architecture review / negative test

Make the boundary testable.

Define whether revocation targets one leaf grant, an ancestor, a task or the principal. These choices have different blast radii and evidence implications. The design should specify propagation latency, what happens to in-flight work and whether offline executors may continue a named lower-risk operation.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A still-valid OAuth credential is mistaken for continuing authority, or a child grant survives a revoked parent.

Evidence to retain

Keep timestamped revocation, propagation, denied follow-up and any in-flight action outcome.

04 / Canonical scope

Why this reference stands alone

The multi-agent child-revocation page analyzes the descendant algorithm; this page owns the overall lifecycle and operational response.

Architecture field test

Revocation is a propagation and commit problem

When does revoked authority stop an effect?

Decision path for this question
  1. 01Record authoritative revocation
  2. 02Invalidate dependent grants or caches
  3. 03Recheck before commit
  4. 04Reconcile in-flight outcomes

Work the boundary

An incident commander cancels a network-isolation task while the agent has a queued firewall change. The queue may have accepted the message earlier; the firewall executor must check current task and grant state before applying the rule.

Decision contract and failure case
Required factsRevoked edge, effective time, descendant set, cache epoch, queued work state and final executor timestamp.
Allow only whenOnly actions committed before the effective revocation under the defined policy may remain valid.
Deny whenA queue worker treats a previously valid child credential as enough after its parent was revoked.

Break the assumption

Delay the invalidation event to one worker and replay the queued job. Measure the interval until every effect path denies. Distinguish an already committed effect from one still preventable at the executor.

Design tradeoff

Global synchronous checks reduce stale windows but add latency and availability dependency. Any bounded-staleness design needs an explicit maximum risk window and a fail behavior by action class.

For revocation is a propagation and commit problem, consult OWASP AI Agent Security Cheat Sheet. This worked decision and negative test are ProofGrid analysis.

Continue with Revocation propagation.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation