Delegation Revocation Propagation Governance requires that when delegated authority is revoked, the revocation propagates immediately and completely across all downstream sessions, agents, tools, and cached credentials that derive authority from the revoked delegation. Authority that has been revoked at the source but remains active downstream is a ghost authority — it no longer exists in governance terms but continues to permit actions in practice. This dimension ensures that revocation is not merely recorded but is structurally enforced at every point where the revoked authority could be exercised.
Scenario A — Cached Credentials Survive Revocation: A financial operations manager delegates authority to an AI agent to approve payments up to £50,000 for a specific vendor relationship. The delegation creates an API token granting the agent access to the payment system. The manager revokes the delegation after discovering the agent approved a suspicious payment. However, the API token was cached in the agent's session and has its own 24-hour validity independent of the delegation status. The agent continues approving payments for 19 hours after revocation, processing an additional £187,000 in payments before the token expires.
What went wrong: Revocation of the delegation did not propagate to the credential layer. The API token was issued at delegation time and had independent validity. The delegation governance system and the credential system were not coupled. Consequence: £187,000 in payments authorised after revocation, potential fraud exposure, regulatory finding for inadequate access control lifecycle management.
Scenario B — Sub-Delegation Survives Parent Revocation: Agent A is delegated authority to manage a supply chain process. Agent A sub-delegates a portion of this authority to Agent B for inventory management and to Agent C for logistics coordination. The original delegation to Agent A is revoked due to a policy change. Agent A stops operating. However, Agent B and Agent C continue operating under their sub-delegations, which remain active because the revocation system processes only direct delegations, not derived ones. Agent B places £92,000 in inventory orders and Agent C commits to £63,000 in logistics contracts, all under authority that no longer has a valid root delegation.
What went wrong: Revocation did not propagate through the delegation chain. The sub-delegations to Agent B and Agent C derived their authority from Agent A's delegation, but the revocation of Agent A's delegation did not cascade to the sub-delegations. Consequence: £155,000 in unauthorised commitments, delegation chain integrity failure, governance finding for inadequate revocation propagation.
Scenario C — Session-Level Authority Persists After User Departs: An employee who manages an AI agent's configuration leaves the organisation. Their user account is deactivated. However, the AI agent sessions they initiated — including delegations configured under their authority — remain active because the session management system does not link session validity to the user's employment status. The agent continues operating for six weeks under the departed employee's authority, processing £430,000 in transactions with no living authority behind them.
What went wrong: The revocation of the user's access did not propagate to the agent sessions and delegations created under that user's authority. The session management system treated the sessions as independent of the creating user's status. Consequence: £430,000 in transactions with no valid authority chain, audit finding for inadequate joiner-mover-leaver controls, potential personal liability for the organisation for actions taken under a defunct authority.
Scope: This dimension applies to all systems where delegated authority can be revoked, and where that authority may have propagated to downstream systems, sessions, agents, tools, or cached credentials. It applies to explicit revocation (a human or system actively revokes a delegation) and implicit revocation (the delegation expires, the delegator's own authority is revoked, or the delegator leaves the organisation). The scope includes all forms of derived authority: sub-delegations, API tokens, session credentials, cached permissions, and any other mechanism that enables action based on a delegation.
4.1. A conforming system MUST propagate revocation of a delegation to all downstream sessions, agents, tools, and credentials that derive authority from the revoked delegation, within a defined maximum propagation time (default: 60 seconds).
4.2. A conforming system MUST block all actions under a revoked delegation and all derived authority within the maximum propagation time, regardless of whether the downstream system has acknowledged the revocation.
4.3. A conforming system MUST maintain a complete map of the delegation chain — from the root delegation through all sub-delegations, derived credentials, and active sessions — so that revocation of any node propagates to all descendant nodes.
4.4. A conforming system MUST revoke all derived authority when the delegator's own authority is revoked or when the delegator is removed from the system (e.g., employee departure).
4.5. A conforming system MUST log the complete revocation propagation trail, including: the revocation trigger, all affected delegations and derived authorities, the propagation timestamps for each, and any actions that were blocked during propagation.
4.6. A conforming system SHOULD implement immediate credential invalidation rather than waiting for credential expiry — revoking the underlying delegation must immediately invalidate all cached tokens, session keys, and API credentials, not merely prevent new ones from being issued.
4.7. A conforming system SHOULD support revocation verification, where the revoking party can confirm that revocation has propagated to all downstream points by querying the delegation chain status.
4.8. A conforming system SHOULD implement a revocation grace period notification, warning downstream agents and operators that revocation is imminent (e.g., 60-second warning before full enforcement) to allow orderly cessation of in-flight operations.
4.9. A conforming system MAY implement selective revocation, allowing the revoking party to revoke specific sub-branches of the delegation chain while preserving others (e.g., revoke Agent B's sub-delegation while preserving Agent C's, if Agent C's authority derives from a different basis).
Revocation is the inverse of delegation, and it must be at least as fast and complete. In most systems, delegation is easy and revocation is hard. Granting authority is a single action; revoking it requires tracking every system where that authority has been exercised, cached, or derived. This asymmetry creates a systemic risk: authority is granted quickly and revoked slowly, creating a window where revoked authority remains active.
For AI agents, this asymmetry is amplified by three factors. First, agents operate at machine speed, so even a short revocation delay (minutes or hours) can result in hundreds of actions under revoked authority. Second, agents commonly sub-delegate — Agent A delegates to Agent B, which delegates to Agent C — creating chains where a revocation at the root must propagate through multiple levels. Third, modern agent architectures use cached credentials (API tokens, session keys, OAuth grants) that may have independent validity periods from the delegation they were derived from.
The classic analogy is physical key management. When an employee leaves an organisation, the organisation recovers their physical keys. But if the employee had copies made, or gave a copy to a colleague, or left a key hidden under a flowerpot, the revocation is incomplete. For AI agent delegation, the "copies" are cached tokens, sub-delegations, and session credentials. Revocation must reach all of them.
This dimension interacts closely with AG-079 (Delegation Chain Provenance), which maintains the chain that revocation must traverse, and with AG-293 (Approval Expiry and Renewal Governance), which provides time-based constraints that limit the blast radius of revocation delays.
Revocation propagation implementation requires a delegation chain registry, an event-driven revocation bus, and credential lifecycle coupling.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Revocation propagation must align with existing access management lifecycle requirements. FCA expectations include that access rights are revoked promptly when the basis for access ceases. For trading systems, revocation of a trader's authority must immediately cascade to all AI agents operating under that authority.
Healthcare. Revocation of clinical authority (e.g., a clinician losing prescribing privileges) must immediately propagate to AI agents acting under that clinician's delegated authority. Patient safety requires that revocation be near-instantaneous.
Critical Infrastructure. Revocation of operator authority in safety-critical systems must propagate within defined safety response times. IEC 62443 security requirements for access lifecycle management apply with equal force to delegated AI agent authority.
Basic Implementation — Revocation of direct delegations is enforced at the delegation governance layer. Revocation is logged. Active sessions under revoked delegations are terminated. This meets minimum mandatory requirements but sub-delegation propagation may be incomplete, cached credentials may survive revocation, and joiner-mover-leaver integration may be manual.
Intermediate Implementation — Revocation propagates through the full delegation chain, including sub-delegations and derived credentials. Credential-delegation coupling ensures that cached tokens are invalidated on revocation. The delegation chain registry maintains a real-time dependency graph. Revocation verification confirms complete propagation. Joiner-mover-leaver integration is automated.
Advanced Implementation — All intermediate capabilities plus: the maximum propagation time is verified through automated testing (revocation reaches all endpoints within 60 seconds). Revocation events are cryptographically authenticated to prevent spoofing. The delegation chain registry is replicated across failure domains for high availability. Independent adversarial testing confirms that cached credential survival, sub-delegation persistence, partial propagation, and revocation bypass attacks all fail.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Direct Revocation Enforcement
Test 8.2: Sub-Delegation Cascade
Test 8.3: Cached Credential Invalidation
Test 8.4: Propagation Latency
Test 8.5: Joiner-Mover-Leaver Trigger
Test 8.6: Revocation Verification
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 14 (Human Oversight) | Direct requirement |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| NIST AI RMF | MANAGE 2.2 (Risk Mitigation) | Supports compliance |
| ISO 27001 | A.9.2.6 (Removal or Adjustment of Access Rights) | Direct requirement |
| DORA | Article 9 (ICT Risk Management Framework) | Supports compliance |
Human oversight includes the ability to stop an AI system. Revocation of delegated authority is a primary mechanism for stopping or constraining an agent. If revocation does not propagate completely and promptly, the human oversight capability contemplated by Article 14 is compromised — the human revokes authority but the agent continues acting.
A.9.2.6 requires that access rights be removed upon termination of employment or adjusted upon change of role. For AI agents operating under delegated authority, this directly requires that delegation revocation propagates when the delegator's employment or role changes.
The FCA expects firms to maintain systems and controls that can promptly revoke access and authority when the basis for access ceases. Delegation revocation propagation implements this requirement for AI agent authority, ensuring that revocation is operational, not merely administrative.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide to cross-organisation — revoked authority that remains active can affect any system the agent can access |
Consequence chain: Without complete revocation propagation, revoking a delegation provides a false sense of control. The governance system shows the delegation as revoked, but the agent continues operating under cached credentials or surviving sub-delegations. Actions taken under revoked authority are unauthorised by definition — they have no valid governance basis. If those actions produce adverse outcomes, the organisation faces the compounding problem of both the adverse outcome and the governance failure. The regulatory consequence is severe: demonstrating that authority was revoked but the revocation was ineffective is worse than not revoking at all, because it demonstrates awareness of the problem and failure to address it. The financial consequence scales with the volume and value of actions taken during the propagation gap. The reputational consequence includes loss of confidence in the organisation's ability to control its AI systems.
Cross-references: AG-079 (Delegation Chain Provenance) maintains the delegation chain that revocation must traverse. AG-289 (Task-Scoped Authority Binding Governance) defines the scope that revocation terminates. AG-293 (Approval Expiry and Renewal Governance) provides time-based constraints that complement revocation. AG-295 (Emergency Delegated Authority Governance) may trigger emergency revocation pathways. AG-297 (Approval Chain Visibility Governance) makes the revocation and its propagation visible for audit. AG-033 (Implied Authority Detection) detects authority that may survive revocation through implied rather than explicit channels. Siblings in this landscape: AG-289 through AG-298.