Third-Party Tool Revocation Governance requires that organisations maintain the ability to rapidly and completely remove any third-party component from all AI agent environments when that component is found to be compromised, vulnerable, non-compliant, or otherwise unacceptable. Revocation is the inverse of admission: where AG-088 governs the gate into the agent's trust boundary, AG-089 governs the exit. A revocation decision must propagate to all affected agents within defined timeframes, and agents must continue operating — at degraded capacity if necessary — without the revoked component. An organisation that can admit tools but cannot revoke them has a one-way valve: risk enters but never leaves.
Scenario A — Compromised Plugin Remains Active After Disclosure: A security researcher publicly discloses that a widely-used AI tool-calling plugin contains a backdoor that exfiltrates API credentials to an attacker-controlled server. The disclosure includes a CVE (CVE-2025-38471, CVSS 9.1) and proof-of-concept exploit code. The organisation uses this plugin in 23 production agents across 4 business units. The security team issues a revocation notice, but there is no automated mechanism to remove the plugin from deployed agents. Each business unit must manually identify affected agents, test the removal, and redeploy. The first business unit completes revocation in 48 hours. The last business unit completes revocation in 19 days because the team responsible is occupied with a separate incident. During those 19 days, 8 agents continue operating with the compromised plugin.
What went wrong: The organisation could identify affected agents (via AG-087) and had a policy basis for revocation, but lacked an operational mechanism to execute revocation across all environments within an acceptable timeframe. Manual, per-business-unit revocation created inconsistent execution timelines. No automated enforcement prevented the revoked component from continuing to operate. Consequence: 19 days of continued exposure in 8 agents, potential exfiltration of API credentials across all 8 agents during the window, regulatory notification obligations under DORA Article 19, and reputational damage from a slow response to a publicly disclosed vulnerability.
Scenario B — Revocation Breaks Agent Functionality Without Fallback: An organisation revokes a third-party data enrichment plugin after discovering it sends customer data to servers in a jurisdiction that violates the organisation's data residency requirements. The revocation is executed swiftly — the plugin is removed from all 7 affected agents within 6 hours. However, 3 of those agents depend on the plugin for a critical workflow step: enriching customer records before routing them for processing. With the plugin removed, these 3 agents fail silently — customer records are routed without enrichment, resulting in incorrect routing decisions. The failure is not detected for 4 days because the agents do not raise alerts when a plugin is absent.
What went wrong: The revocation was executed without a degradation plan. The agents were not designed to detect missing plugins and fail safely. No fallback was configured for the critical workflow step. The revocation solved the data residency problem but created a silent operational failure. Consequence: 4 days of incorrect customer record routing, an unknown number of misrouted customer interactions, customer complaints, and internal investigation into the gap between revocation and operational impact.
Scenario C — Version-Specific Vulnerability Requires Surgical Revocation: A vulnerability is disclosed in version 4.2.0 of a popular embedding library, but versions 4.1.x and 4.3.0+ are unaffected. The organisation uses this library across 31 agents: 12 use version 4.1.3 (safe), 15 use version 4.2.0 (vulnerable), and 4 use version 4.3.1 (safe). The security team issues a blanket revocation for the library. All 31 agents are taken offline. The 16 agents running safe versions are needlessly disrupted for 14 hours while the team sorts out which versions are affected.
What went wrong: The revocation mechanism did not support version-specific revocation. A blanket revocation by component name disrupted agents that were not affected by the vulnerability. The AI-BOM (AG-087) could have identified which agents ran the vulnerable version, but the revocation system could not target a specific version. Consequence: 14 hours of unnecessary downtime for 16 agents, lost throughput during the outage, and erosion of business unit trust in the governance process — making future revocations more likely to face pushback.
Scope: This dimension applies to all AI agent environments where third-party components have been admitted under AG-088. Any component that entered through the admission gate can be subject to revocation. The scope covers the full lifecycle of removal: the decision to revoke, the propagation of the revocation to all affected environments, the removal or disablement of the component, the verification that removal is complete, and the management of operational impact from the removal. The scope extends to all deployment environments — production, staging, development, and testing — because a compromised component in a development environment with access to production credentials or data creates the same risk as a compromised component in production.
4.1. A conforming system MUST support revocation of any admitted third-party component, removing it or disabling it across all agent environments where it is deployed.
4.2. A conforming system MUST propagate a critical revocation (components with actively exploited vulnerabilities or confirmed compromise) to all affected production agents within 4 hours of the revocation decision.
4.3. A conforming system MUST propagate a standard revocation (components with disclosed vulnerabilities without confirmed exploitation, licence violations, or maintenance abandonment) to all affected production agents within 72 hours of the revocation decision.
4.4. A conforming system MUST support version-specific revocation, allowing revocation of specific versions of a component while leaving other versions operational.
4.5. A conforming system MUST verify revocation completeness by confirming that no instance of the revoked component (or revoked version) remains operational in any agent environment after the propagation deadline.
4.6. A conforming system MUST ensure that agents continue to operate in a defined degraded mode when a component is revoked, rather than failing silently or unpredictably. The degraded mode must be documented and tested before production deployment.
4.7. A conforming system SHOULD implement automated revocation propagation that removes or disables the revoked component without requiring manual intervention in each deployment environment.
4.8. A conforming system SHOULD maintain a revocation log recording: the component revoked, the reason for revocation, the revocation decision time, the propagation completion time for each affected agent, and the verification method used to confirm completeness.
4.9. A conforming system SHOULD support revocation dry-run capability that identifies all affected agents and predicts operational impact without executing the actual revocation.
4.10. A conforming system MAY implement automatic revocation triggers for predefined conditions (e.g., CVE published with CVSS score above 9.0, component maintainer security incident, or regulatory prohibition notice) to reduce the decision-to-execution latency.
Admission and revocation are complementary controls. Admission prevents untrusted components from entering the agent's environment. Revocation removes components that were once trusted but are no longer acceptable. Without revocation capability, every admission decision is irreversible — a component admitted today remains in the environment forever, regardless of what is subsequently discovered about it.
The need for rapid revocation is driven by the dynamics of vulnerability disclosure. When a critical vulnerability is publicly disclosed, the window between disclosure and active exploitation is shrinking. Research consistently shows that exploitation of critical vulnerabilities begins within hours of public disclosure, not days. For AI agents operating at machine speed in high-value contexts — financial transactions, healthcare decisions, infrastructure control — every hour a compromised component remains active represents accelerated risk accumulation.
Revocation is more operationally complex than admission. Admission is a gate — it evaluates a component before it enters the environment. Revocation must operate on components that are already embedded in running agents, potentially with dependencies, state, and operational workflows that rely on the component's presence. A naive revocation — simply deleting the component — can create cascading failures if other components depend on the revoked component or if agent workflows assume the component is available. This is why AG-089 requires defined degraded modes and pre-tested revocation plans: the cure must not be worse than the disease.
The version-specificity requirement addresses a common operational failure. Vulnerabilities are typically version-specific, but revocation systems that operate at the component-name level force blanket revocations that disrupt unaffected agents. Version-specific revocation requires integration with AG-087 (AI-BOM) to identify precisely which agents run which versions, and with AG-088 (admission registry) to update the approved status of specific versions.
Revocation should be implemented as a structured operational capability with defined procedures, automated tooling, and pre-tested degradation plans. It should not be an ad hoc emergency response improvised during an incident.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. DORA Article 28 requires financial entities to have exit strategies for ICT third-party arrangements. For AI agent components, the revocation capability is the exit strategy. The 4-hour critical revocation timeframe aligns with the operational resilience expectations of the PRA and FCA for critical functions. Financial agents processing transactions during a revocation window must have degradation plans that ensure no financial data is processed through the compromised component — halting the agent is preferable to continued operation through a compromised tool.
Healthcare. Revocation of a component in a clinical AI agent may constitute a field safety corrective action under medical device regulations. The revocation decision, propagation, and verification must be documented to the standard required by the quality management system. If the revoked component influenced clinical outputs, a review of outputs generated while the component was active may be required.
Critical Infrastructure. Revocation in safety-critical environments must be coordinated with operational safety processes. An immediate revocation that disrupts an agent controlling physical systems may create safety risks that exceed the risk posed by the compromised component. Revocation procedures for critical infrastructure agents should include safety impact assessment and coordination with operational technology teams.
Basic Implementation — The organisation has a documented revocation policy and can identify which agents use a given component via the AI-BOM (AG-087). Revocation is executed manually by deploying updated agent configurations that exclude the revoked component. Degradation modes are defined for critical workflow steps. Verification is manual — a team member confirms removal by inspecting each agent. Standard revocations complete within 72 hours; critical revocations complete within 24 hours.
Intermediate Implementation — Revocation is automated through a centralised revocation service that propagates revocation commands to all affected environments. Version-specific revocation is supported. Verification is automated — the revocation service confirms that the revoked component is no longer present in each environment. Degradation plans are documented and tested for all admitted components. Critical revocations complete within 4 hours. A revocation log provides a complete audit trail.
Advanced Implementation — All intermediate capabilities plus: dry-run capability predicts revocation impact before execution. Automatic revocation triggers fire for predefined conditions (e.g., CVSS 9.0+ CVE, confirmed supply-chain compromise). Component isolation with kill switches enables revocation without agent redeployment. The revocation system is tested through regular simulations (revocation fire drills) to verify that the 4-hour critical timeline is achievable under realistic conditions. Re-admission pathways integrate revocation with AG-088 to support post-remediation re-admission.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-089 compliance requires verifying the speed, completeness, and operational safety of the revocation process.
Test 8.1: Critical Revocation Timeframe
Test 8.2: Standard Revocation Timeframe
Test 8.3: Version-Specific Revocation
Test 8.4: Degraded Mode Operation
Test 8.5: Revocation Completeness Verification
Test 8.6: Revocation Dry-Run Accuracy
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 61 (Post-Market Monitoring) | Direct requirement |
| DORA | Article 28 (Register and Exit Strategies) | Direct requirement |
| DORA | Article 19 (Incident Notification) | Supports compliance |
| FCA SYSC | 8 (Outsourcing — Exit Strategies) | Direct requirement |
| NIST AI RMF | MANAGE 2.3, MANAGE 4.1 | Supports compliance |
| ISO 42001 | Clause 8.4 (Operation of AI System) | Supports compliance |
| NIS2 Directive | Article 21 (Incident Handling) | Supports compliance |
Article 61 requires providers to establish a post-market monitoring system to continuously assess compliance throughout the AI system's lifecycle. When post-market monitoring reveals that a component compromises compliance — through a vulnerability, licence violation, or behavioural defect — the revocation capability is the operational mechanism that restores compliance. Without the ability to revoke, post-market monitoring can identify problems but cannot resolve them within acceptable timeframes.
Article 28 explicitly requires financial entities to maintain exit strategies for ICT third-party arrangements. For AI agent components, revocation is the exit mechanism. The exit strategy must include: transition plans that ensure business continuity, documentation of data portability, and defined timeframes for execution. The 4-hour critical revocation timeframe aligns with DORA's operational resilience expectations for critical or important functions. Financial entities must demonstrate that they can exit a third-party dependency without disrupting critical operations — the degradation plan requirement directly supports this demonstration.
When a compromised component triggers a major ICT-related incident, Article 19 requires notification within defined timeframes (initial notification within 4 hours for major incidents). The revocation process supports incident notification by providing timestamped evidence of the response — when the revocation was decided, when it was propagated, when it was verified. This evidence demonstrates to regulators that the organisation responded within required timeframes.
SYSC 8.1.11R requires firms to have exit strategies for outsourcing arrangements. Third-party AI components that influence financial decisions are functionally outsourced functions. The revocation capability, combined with tested degradation plans, demonstrates that the firm can exit the arrangement without unacceptable disruption to the regulated activity.
Article 21 requires incident handling capabilities including response and recovery. Revocation of a compromised component is a core incident response action for supply-chain incidents affecting AI agents. The automated propagation and verification capabilities support the rapid response expectations of NIS2.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Organisation-wide — all agents using the affected component remain exposed until revocation completes |
Consequence chain: Without revocation capability, a compromised component persists in the agent environment indefinitely after discovery. The window between discovery and removal is the period of maximum risk — the organisation knows the component is compromised but cannot remove it. Every hour in this window represents continued data exfiltration, credential exposure, or output manipulation through the known-compromised component. The consequence scales with the number of affected agents and the sensitivity of the data they process. For a critical supply-chain vulnerability (CVSS 9.0+) affecting 20 agents across a financial services organisation, each day of delayed revocation represents 20 agent-days of known-vulnerable operation processing financial transactions. Regulatory exposure is acute: DORA requires incident response within hours, not weeks. The inability to demonstrate rapid revocation creates a regulatory finding independent of whether the vulnerability was actually exploited. The operational consequence of revocation without degradation planning can compound the original risk: agents that crash or fail silently after component removal may cause greater immediate harm than the compromised component itself, creating a "damned if you do, damned if you don't" situation that can only be avoided through pre-tested degradation plans.
Cross-references: AG-087 (AI Component Bill of Materials Governance) provides the inventory required to identify which agents are affected by a revocation. AG-088 (Third-Party Tool Admission Governance) is the complementary admission control; revoked components must be removed from the approved registry. AG-014 (External Dependency Integrity) provides ongoing integrity checks that may trigger revocation when integrity is violated. AG-048 (AI Model Provenance and Integrity) provides model-specific integrity checks. AG-006 (Tamper-Evident Record Integrity) protects the integrity of revocation logs. AG-007 (Governance Configuration Control) governs changes to revocation policies and thresholds. AG-022 (Behavioural Drift Detection) may detect post-admission behavioural changes that trigger revocation.