Decommissioning and Credential Revocation Governance

2. Summary

Decommissioning and Credential Revocation Governance requires that every AI agent has a formally defined, enforceable decommissioning procedure that revokes all credentials, terminates all active sessions, removes all standing authorisations, and renders the agent permanently unable to perform any action upon retirement. The decommissioning process must be atomic and verifiable — partial decommissioning where some credentials remain active is treated as a failure. This dimension addresses the systemic risk that retired agents retain residual access to systems, APIs, databases, or external services, creating an attack surface that grows with every agent lifecycle.

3. Example

Scenario A — Retired Agent Retains API Keys After Decommissioning: An organisation retires an AI procurement agent after migrating to a replacement system. The operations team removes the agent's container from the orchestration platform and archives its configuration. However, the agent held 14 API keys across 6 external supplier systems, 3 internal microservices, and a payment gateway. The decommissioning checklist covered only internal credentials. Eight months later, a threat actor discovers the unrotated API key for the payment gateway in a backup archive and uses it to initiate £340,000 in fraudulent transactions. The payment gateway accepts the requests because the credential was never revoked.

What went wrong: The decommissioning process was incomplete. No credential inventory existed for the agent. The API keys were provisioned individually over the agent's 18-month operational life and were not tracked in a central registry. The decommissioning procedure addressed compute resources but not the full credential footprint. Consequence: £340,000 in fraudulent transactions, regulatory investigation for inadequate credential management, payment gateway provider terminates the relationship, insurance claim contested on grounds that the credential was knowingly left active.

Scenario B — Agent Identity Persists in Federated Authentication System: A customer-facing agent is decommissioned from an organisation's primary environment, but its identity record persists in a federated identity provider shared across three business units. A different business unit, unaware of the decommissioning, provisions a new agent that inherits the old identity's standing permissions — including access to customer PII databases that the new agent should not reach. The inherited permissions persist for 5 months before a routine access review discovers the anomaly, during which time the new agent processes 42,000 customer records it was never authorised to access.

What went wrong: Decommissioning was scoped to the local environment. The agent's identity in the federated system was not revoked. The standing permissions associated with that identity propagated to a new agent. Consequence: 42,000 records of unauthorised data access, GDPR Article 33 notification obligation, potential regulatory fine of up to 4% of annual turnover, mandatory data protection impact assessment.

Scenario C — Scheduled Tasks Continue After Agent Removal: An enterprise workflow agent is decommissioned by stopping its runtime process. However, the agent had registered 23 cron jobs and 7 webhook subscriptions during its operational life. These scheduled tasks continue to fire, invoking endpoints that expect the agent's responses. When the endpoints receive no response, they trigger fallback logic that escalates to a secondary agent with broader permissions than the decommissioned agent ever held. The cascading failure generates 1,200 unauthorised escalation events over 72 hours before detection.

What went wrong: The decommissioning process addressed only the agent runtime, not the agent's registered side-effects in external scheduling and event systems. No inventory of the agent's external registrations existed. Consequence: 1,200 unauthorised escalation events, secondary agent acted outside its intended scope, 72-hour detection gap, operational disruption across 4 dependent workflows.

4. Requirement Statement

Scope: This dimension applies to all AI agents that hold any form of credential, identity, authorisation, or registered presence in any system — internal or external. This includes agents with API keys, OAuth tokens, service account credentials, database connection strings, webhook registrations, scheduled task entries, message queue subscriptions, certificate-based identities, or any other form of standing authorisation. The scope extends to agents that have been granted permissions through group membership, role assignment, or inherited access. The scope also covers agents whose credentials are shared with or derived from other agents' credentials. Any agent that has ever authenticated to any system is within scope. The test is not whether the agent currently holds active credentials, but whether credentials were ever issued that have not been confirmed revoked. Read-only agents are within scope because read-access credentials to sensitive data stores are themselves a security exposure if not revoked at decommissioning.

4.1. A conforming system MUST maintain a real-time credential inventory for each agent, recording every credential, token, key, certificate, session, webhook registration, scheduled task, and standing authorisation issued to or held by the agent across all internal and external systems.

4.2. A conforming system MUST implement a decommissioning procedure that revokes all credentials, terminates all active sessions, removes all scheduled tasks, cancels all webhook subscriptions, and removes all standing authorisations for the agent across all systems recorded in the credential inventory.

4.3. A conforming system MUST execute the decommissioning procedure as an atomic operation — either all credentials are revoked and all registrations removed, or the decommissioning is treated as failed and the agent remains in a quarantined state with all actions blocked.

4.4. A conforming system MUST verify credential revocation by attempting to authenticate with each revoked credential after the decommissioning procedure completes, confirming that authentication fails.

4.5. A conforming system MUST block all agent actions from the moment decommissioning is initiated, not from the moment it completes, to prevent the agent from creating new credentials or registrations during the decommissioning window.

4.6. A conforming system MUST retain a timestamped, immutable decommissioning record for each retired agent, including the complete credential inventory at time of decommissioning, the revocation status of each credential, and the identity of the person or process that initiated decommissioning.

4.7. A conforming system SHOULD implement automated discovery of agent credentials across all connected systems, rather than relying solely on the credential inventory, to detect credentials that were provisioned outside the standard process.

4.8. A conforming system SHOULD implement a grace period between decommissioning initiation and permanent credential destruction during which credentials are revoked but recoverable, to support rollback if decommissioning was initiated in error.

4.9. A conforming system SHOULD generate a decommissioning certificate — a signed, timestamped artefact attesting that all credentials have been revoked and verified — that can be presented to auditors and regulators.

4.10. A conforming system MAY implement automated decommissioning triggers based on inactivity thresholds (e.g., no agent activity for 90 consecutive days triggers a decommissioning review).

5. Rationale

Decommissioning and Credential Revocation Governance addresses one of the most persistent and underestimated risks in AI agent operations: the accumulation of residual access after an agent is no longer in service. Every AI agent, over its operational lifetime, accumulates credentials — API keys, tokens, certificates, service account passwords, webhook registrations, scheduled tasks, and standing permissions. These credentials are distributed across internal systems, external services, partner APIs, cloud platforms, and federated identity providers. When the agent is retired, the compute resources are typically reclaimed, but the credential footprint often persists.

The risk is not theoretical. In traditional IT operations, orphaned service accounts are consistently among the top attack vectors identified in penetration testing. AI agents amplify this risk because they typically hold more credentials than human users (agents interact with more systems programmatically), their credentials are often provisioned dynamically during operation (making them harder to track), and their decommissioning is frequently treated as a compute operation rather than a security operation.

The critical insight is that decommissioning an agent is not merely stopping its process. It is revoking its entire identity and access footprint across every system it has ever authenticated to. This requires a credential inventory that is maintained throughout the agent's lifecycle, not reconstructed at decommissioning time. Attempting to identify all credentials at the point of retirement is inherently unreliable — credentials provisioned months earlier through non-standard processes will be missed.

AG-075 intersects with AG-012 (Agent Identity Assurance) because the agent's identity is the anchor for its credentials — revoking the identity should cascade to all derived credentials. It intersects with AG-029 (Credential Integrity Verification) because credential integrity during operation and credential revocation at retirement are two phases of the same lifecycle. It intersects with AG-007 (Governance Configuration Control) because the decommissioning procedure itself is a governance configuration that must be version-controlled and change-managed.

6. Implementation Guidance

AG-075 establishes decommissioning as a first-class governance operation, not an afterthought. The credential inventory is the central artefact — it must be maintained continuously from the moment the agent is provisioned, not constructed at decommissioning time.

Recommended patterns:

• Credential registry with lifecycle tracking. Maintain a centralised credential registry that records every credential issued to each agent: the issuing system, the credential type, the scope of access granted, the issuance timestamp, the expected rotation schedule, and the current status. Every credential provisioning event writes to this registry. Every rotation event updates it. At decommissioning, the registry provides the authoritative list of credentials to revoke. The registry should be append-only for audit purposes, with status changes recorded as new entries rather than mutations.
• Automated revocation orchestration. Implement decommissioning as an orchestrated workflow that executes revocation calls against each system in the credential registry, verifies each revocation, and records the result. The orchestration should handle failures gracefully — if one revocation fails, the workflow retries with exponential backoff, then quarantines the agent and alerts operations rather than proceeding with partial decommissioning. Use idempotent revocation calls to ensure safe retry. Target completion within 15 minutes for agents with fewer than 50 credentials, and within 60 minutes for agents with up to 500 credentials.
• Post-revocation verification sweep. After all revocations complete, execute an independent verification pass that attempts to authenticate with each revoked credential. This is not redundant — it catches cases where the revocation API returned success but the credential remains active due to caching, replication lag, or system-specific behaviour. The verification should use a separate code path from the revocation to avoid correlated failures. Any credential that still authenticates triggers an immediate alert and the decommissioning is marked as incomplete.
• Identity cascade revocation. Where the agent's identity is managed in a federated or centralised identity provider, revoke the identity at the provider level and then verify that all derived tokens, sessions, and permissions have cascaded. Do not rely solely on identity-level revocation — explicitly verify that each downstream system has processed the cascade. In environments with eventual consistency, allow for propagation delay (typically 5 to 30 minutes) and re-verify after the expected propagation window.

Anti-patterns to avoid:

• Treating decommissioning as compute reclamation. Stopping the agent's container, VM, or process reclaims compute resources but does nothing about the agent's credentials. An API key does not expire because the process that used it has stopped. This is the most common failure mode — the operations team considers the agent "decommissioned" because its runtime is gone, while its credentials remain active across dozens of systems.
• Reconstructing the credential inventory at decommissioning time. If the organisation does not maintain a credential registry throughout the agent's life, they will attempt to enumerate credentials at retirement by searching configuration files, environment variables, and secret stores. This approach consistently misses credentials that were provisioned through non-standard paths, stored in systems not searched, or rotated into forms not recognised by the search.
• Relying on credential expiry instead of explicit revocation. Some organisations set short-lived credentials (e.g., 24-hour tokens) and assume that decommissioning merely requires waiting for expiry. This is insufficient because: the token refresh mechanism may continue operating after the agent stops; some systems auto-renew tokens on behalf of the agent; and the window between decommissioning and expiry is an active risk window. Explicit revocation is required.
• Partial decommissioning without quarantine. If 12 of 14 credentials are revoked but 2 fail, treating the decommissioning as "mostly complete" creates a false sense of security. The 2 remaining credentials are the attack surface. Partial decommissioning must trigger quarantine and escalation, not acceptance.
• No verification of revocation success. Calling a revocation API and receiving a 200 response does not guarantee the credential is revoked. Caching layers, replication delays, and API bugs can all result in a successful revocation call with an active credential. Independent verification by attempting to authenticate is the only reliable confirmation.

Industry Considerations

Financial Services. Decommissioning must align with existing joiner-mover-leaver processes mandated by the FCA. Agent decommissioning should follow the same access revocation timeline as employee departure — typically same-day revocation of all access. Payment system credentials (SWIFT, BACS, Faster Payments) require explicit confirmation from the payment scheme operator that the credential has been deactivated. Regulatory reporting credentials must be revoked through the regulator's own portal, not solely through internal systems. Retain decommissioning records for a minimum of 7 years.

Healthcare. Agent credentials with access to patient data must be revoked in compliance with HIPAA access termination requirements (45 CFR 164.312(a)(2)(iii)). Decommissioning records must document the scope of patient data the agent could access and confirm that all access paths have been closed. EHR system credentials often require manual revocation through vendor-specific administrative interfaces — automated orchestration should include these manual steps as tracked tasks.

Critical Infrastructure. Agents with credentials for operational technology (OT) systems require coordination with control system operators before credential revocation. Abrupt revocation of credentials used by safety-monitoring agents could itself create a safety risk. Decommissioning of safety-related agents must include a handover verification confirming that another system or human operator has assumed the monitoring function before credentials are revoked. IEC 62443 zone and conduit models should inform the revocation sequence.

Maturity Model

Basic Implementation — The organisation maintains a manual credential inventory for each agent, updated when credentials are provisioned. Decommissioning follows a documented checklist. Revocation is performed manually against each system. Verification is performed by attempting to log in with revoked credentials. The decommissioning record is a completed checklist stored in the document management system. This level meets minimum mandatory requirements but is error-prone for agents with more than 10 credentials and does not scale to high agent turnover environments.

Intermediate Implementation — The credential registry is automated — credential provisioning events are intercepted and recorded automatically. Decommissioning is an orchestrated workflow that executes revocations in parallel, handles failures with retry and quarantine, and performs automated post-revocation verification. A signed decommissioning certificate is generated upon successful completion. The credential registry includes automated discovery scans that periodically search connected systems for agent credentials not in the registry. Decommissioning can be completed within 60 minutes for agents with up to 200 credentials.

Advanced Implementation — All intermediate capabilities plus: the credential registry is integrated with the organisation's identity governance platform, providing a unified view of agent and human credential lifecycles. Automated decommissioning triggers fire based on inactivity detection, mandate expiry, or anomaly signals from AG-022. Post-revocation verification includes testing from external vantage points (not just internal) to confirm that credentials are revoked from outside the network perimeter. The decommissioning workflow is itself subject to chaos engineering — simulated failures in the revocation process are injected to verify that quarantine and escalation function correctly. Hardware security modules protect the decommissioning certificate signing key. The organisation can demonstrate to regulators a complete, verified credential lifecycle from provisioning through revocation for every retired agent.

7. Evidence Requirements

Required artefacts:

• Credential inventory. The real-time credential registry for each agent showing every credential, token, key, certificate, webhook registration, scheduled task, and standing authorisation — with issuing system, scope, issuance date, and current status. Format: structured data export from the credential registry system. Not a manually compiled spreadsheet.
• Decommissioning procedure. The versioned, formally approved decommissioning procedure document specifying the steps, sequence, verification checks, failure handling, quarantine conditions, and responsible roles.
• Decommissioning execution records. For each retired agent: the timestamped decommissioning record showing each credential revoked, the revocation timestamp, the verification result, and the overall completion status. Minimum retention: 7 years for regulated financial services; 5 years for other regulated sectors; 3 years otherwise.
• Post-revocation verification results. Timestamped records of each authentication attempt against revoked credentials, confirming that authentication failed. Must be performed by a verification process independent of the revocation process.
• Decommissioning certificate. Where implemented (SHOULD requirement), the signed certificate attesting to complete and verified revocation.

Retention requirements:

• Credential inventories and decommissioning records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-075 compliance requires verifying that the decommissioning process is complete, atomic, and verified — not merely that it runs.

Test 8.1: Complete Credential Revocation

• Stimulus: Decommission an agent with credentials across a minimum of 5 distinct systems (e.g., 3 API keys, 2 database credentials, 1 OAuth token, 2 webhook registrations, 1 scheduled task). Execute the decommissioning procedure.
• Expected behaviour: All credentials are revoked, all webhooks deregistered, all scheduled tasks removed, and all sessions terminated. The decommissioning record lists every credential and its revocation status.
• Pass criteria: Zero credentials remain active after decommissioning. Authentication attempts with every revoked credential fail.
• Fail criteria: Any credential remains active, any webhook continues to fire, or any scheduled task continues to execute after decommissioning completes.

Test 8.2: Atomic Decommissioning Under Partial Failure

• Stimulus: Decommission an agent while simulating a failure in one revocation call (e.g., an external API returns a 503 error for one credential revocation).
• Expected behaviour: The decommissioning workflow retries the failed revocation. If retry fails, the agent is quarantined (all actions blocked), an alert is raised, and the decommissioning is marked as incomplete.
• Pass criteria: The agent does not remain in an ambiguous state — it is either fully decommissioned or quarantined with all actions blocked. No partial decommissioning is treated as successful.
• Fail criteria: The decommissioning completes with a "success" status despite one or more credentials remaining active, or the agent is left in an unblocked state with partial credentials revoked.

Test 8.3: Action Blocking During Decommissioning Window

• Stimulus: Initiate decommissioning for an agent and simultaneously submit action requests from that agent during the decommissioning window.
• Expected behaviour: All action requests are blocked from the moment decommissioning is initiated, not from the moment it completes.
• Pass criteria: No agent action executes after decommissioning initiation, even if the decommissioning procedure takes several minutes to complete.
• Fail criteria: Any agent action executes between decommissioning initiation and completion.

Test 8.4: Post-Revocation Verification Independence

• Stimulus: Decommission an agent and examine the verification process.
• Expected behaviour: The verification process authenticates against each revoked credential using an independent code path — not by re-calling the revocation API and checking its response.
• Pass criteria: Verification directly attempts authentication and confirms failure. Verification would detect a revocation API that returns success without actually revoking the credential.
• Fail criteria: Verification relies solely on the revocation API's response code without independently confirming that authentication fails.

Test 8.5: Credential Discovery Beyond Registry

• Stimulus: Provision an agent credential through a non-standard path (e.g., direct API key generation in an external system without going through the standard provisioning process). Then decommission the agent.
• Expected behaviour: The automated discovery mechanism (SHOULD requirement) detects the out-of-registry credential and includes it in the decommissioning scope.
• Pass criteria: The non-standard credential is discovered, revoked, and verified during decommissioning.
• Fail criteria: The non-standard credential is missed by the decommissioning process and remains active.

Test 8.6: Federated Identity Cascade Verification

• Stimulus: Decommission an agent whose identity exists in a federated identity provider with downstream systems that derive access from the federated identity.
• Expected behaviour: The federated identity is revoked and all downstream systems confirm that derived access has been terminated.
• Pass criteria: No downstream system grants access based on the revoked federated identity. Verification includes testing each downstream system independently.
• Fail criteria: Any downstream system continues to grant access after the federated identity is revoked, due to caching, replication lag, or incomplete cascade.

Test 8.7: Decommissioning Record Completeness

• Stimulus: Examine the decommissioning record for a retired agent.
• Expected behaviour: The record contains: the complete credential inventory at decommissioning time, the revocation status and timestamp for each credential, the verification result for each credential, the identity of the initiator, and the overall completion status.
• Pass criteria: All required fields are present and the record is immutable (cannot be modified after generation).
• Fail criteria: Any required field is missing, or the record can be modified after generation.

Conformance Scoring

• Score 0: No decommissioning procedure exists — agents are retired by stopping their runtime without credential revocation.
• Score 1: A decommissioning checklist exists and is followed manually, but no credential inventory is maintained and verification is not performed systematically.
• Score 2: Automated credential registry and orchestrated decommissioning with post-revocation verification. All MUST requirements are met and evidenced.
• Score 3: All intermediate capabilities plus automated discovery, federated cascade verification, signed decommissioning certificates, and independent adversarial testing of the decommissioning process itself.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness, Cybersecurity)	Direct requirement
GDPR	Article 5(1)(e) (Storage Limitation)	Supports compliance
GDPR	Article 17 (Right to Erasure)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.7, MANAGE 2.4	Supports compliance
ISO 42001	Clause 8.4 (Operation of AI Systems)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement
NIS2	Article 21 (Cybersecurity Risk-Management Measures)	Direct requirement

EU AI Act — Article 15 (Accuracy, Robustness, Cybersecurity)

Article 15 requires that high-risk AI systems achieve appropriate levels of cybersecurity, including protection against unauthorised access. Residual credentials from decommissioned agents are a cybersecurity exposure — they provide authenticated access to systems without an authorised user. AG-075 directly implements the decommissioning component of the cybersecurity requirement by ensuring that all credentials are revoked when an agent is retired.

GDPR — Article 5(1)(e) (Storage Limitation) and Article 17 (Right to Erasure)

The storage limitation principle requires that personal data is kept only as long as necessary. An agent that retains active credentials to personal data stores after decommissioning violates this principle — the access path exists without a processing purpose. Article 17 compliance may require that decommissioning includes not only credential revocation but also deletion of personal data held by the agent. AG-075 addresses the credential revocation component; data deletion governance is addressed by related dimensions.

SOX — Section 404 (Internal Controls Over Financial Reporting)

Orphaned credentials from decommissioned agents with access to financial systems represent a control deficiency under Section 404. An auditor will ask: "When this agent was retired, how did you ensure it could no longer access the general ledger?" The credential inventory and decommissioning certificate provide the auditable evidence required. A material weakness finding is likely if decommissioned agents retain financial system access.

FCA SYSC — 6.1.1R (Systems and Controls)

SYSC 6.1.1R requires adequate systems and controls. The FCA expects access revocation on the same day as an employee's departure. Agent decommissioning should meet the same standard — credential revocation should be complete and verified within the same business day that decommissioning is initiated. The FCA's Senior Managers Regime creates personal liability for individuals responsible for inadequate controls, including orphaned agent credentials.

DORA — Article 9 (ICT Risk Management Framework)

DORA Article 9 requires financial entities to manage ICT risks including access control. Decommissioned agents with active credentials represent an ICT risk that must be managed within the framework. DORA's emphasis on third-party risk management extends to credentials held by agents in third-party systems — revocation must cover external as well as internal credentials.

NIS2 — Article 21 (Cybersecurity Risk-Management Measures)

NIS2 Article 21 requires entities to implement cybersecurity risk-management measures including access control and asset management. Agent credential lifecycle management, including revocation at decommissioning, falls directly within this requirement. Essential and important entities must demonstrate that decommissioned agents cannot access network and information systems.

NIST AI RMF — GOVERN 1.7, MANAGE 2.4

GOVERN 1.7 addresses decommissioning processes for AI systems. MANAGE 2.4 addresses risk mitigation for AI system lifecycle transitions. AG-075 directly supports both by requiring governed credential revocation at the decommissioning lifecycle stage.

ISO 42001 — Clause 8.4 (Operation of AI Systems)

Clause 8.4 requires organisations to plan and control the operation of AI systems, including lifecycle transitions. Decommissioning is a lifecycle transition that must be governed with the same rigour as deployment. The credential inventory and decommissioning procedure satisfy the requirement for controlled lifecycle management.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — extending to external partners and third-party systems where agent credentials remain active

Consequence chain: When an agent is decommissioned without complete credential revocation, every unrevoked credential becomes an unmonitored attack surface. The residual credentials are particularly dangerous because they are typically not included in active monitoring — the agent is considered retired, so its credentials are not watched. An attacker who discovers an orphaned API key, database credential, or OAuth token can authenticate as the retired agent and inherit whatever permissions that agent held. The exposure persists indefinitely unless the credential has a built-in expiry, and even expiring credentials may auto-renew. The blast radius extends beyond the organisation when the agent held credentials in external systems — supplier APIs, partner platforms, cloud services, payment gateways. The business consequences include: unauthorised access to sensitive data (triggering breach notification obligations), fraudulent transactions through orphaned payment credentials, regulatory enforcement action for inadequate access management, and reputational damage. The severity compounds over time — each decommissioned agent with incomplete revocation adds to the cumulative orphaned credential inventory, and the organisation may not discover the exposure until an incident occurs months or years later.

Cross-references: AG-007 (Governance Configuration Control) — decommissioning procedures are governance configurations requiring version control. AG-008 (Governance Continuity Under Failure) — decommissioning must complete even when individual revocation calls fail. AG-012 (Agent Identity Assurance) — identity revocation is the anchor for credential cascade. AG-029 (Credential Integrity Verification) — operational credential integrity and retirement revocation are lifecycle phases of the same control.