Switching an AI agent off is not the same as retiring it: the delegated grants it collected, the tool connections it holds, the schedules that wake it and the memory it built all survive the moment someone presses stop. This template is a run sheet for permanently retiring an AI agent, whether it is an in-house agent, an agent built on a managed platform or low-code builder, a coding agent, or a vendor agent connected to your tenant. It covers the parts that are specific to agents: delegated OAuth consents, MCP and tool connections, scheduled triggers and webhooks, memory and vector stores, and the registry record. Generic key and account removal is handled by the NHI Offboarding and Decommissioning Guide, and this checklist points to it rather than repeating it. It is written for agent owners, platform and IAM teams, and the auditors who check their evidence. Platforms are listed alphabetically where more than one is named; order is not a ranking.
How to use this template
- Replace text in square brackets, such as [Organisation], [agent registry], [AI security team] and [30 days], with your own teams, tools and values.
- Copy each table into your change or ticketing tool and add Result (Done, Not applicable, Blocked) and Evidence columns. A step counts as done only when evidence is attached: an export, an API response, a screenshot with a date, or a log query result.
- Work the sections in order. The order matters: freeze and preserve first, cut delegated and tool access next, then remove the identity, then delete data, then close the record. Deleting the identity first can strand grants and schedules that are then harder to find.
- For an emergency stop of a misbehaving agent use the AI Agent Kill Switch and Containment Guide first; return to this checklist once the agent is contained and the decision to retire is made.
1. Purpose and scope
This checklist ensures that when [Organisation] retires an AI agent, every identity, grant, credential, tool connection, trigger and data store associated with it is revoked, deleted or deliberately retained, with an accountable person signing off and evidence kept for [retention period]. It applies to any software that uses a model to decide which tools to call or actions to take, on any platform, including agents provided by third parties that hold access to [Organisation] systems.
The NIST AI RMF Playbook, under GOVERN 1.7, says organisations should establish policies for decommissioning AI systems that address upstream and downstream dependencies, regulatory requirements such as data retention, potential future investigations and migration to a replacement system. It also calls for policies on where, and for how long, decommissioned systems, models and related artefacts are stored. Sections 3 and 8 of this checklist implement those two points for agents.
| Decommission type | When it applies | Target completion |
|---|---|---|
| Planned retirement | Purpose ended, project closed, agent replaced by a new version, platform migration | [30 days] from approval |
| Governance retirement | Failed recertification, owner left with no successor, no activity for [90 days], unregistered agent found | [10 working days] from finding |
| Security retirement | Agent compromised, misbehaved, or a vendor it depends on reported a breach | Contain within [4 hours] using the kill switch; complete this checklist within [5 working days] |
2. Trigger, decision and owner
| ID | Step | Evidence |
|---|---|---|
| DC-1 | The trigger is recorded (planned, governance or security) with the date and the person or process that raised it | Change ticket reference |
| DC-2 | The agent's registry record is located and the decommission owner is named: the agent's business sponsor or, if they have left, [AI governance lead] | Registry entry ID and owner name |
| DC-3 | Dependants are identified: users, workflows, other agents (including any agent that calls this one over A2A or as a sub-agent) and downstream systems that consume its output | Dependency list signed by the owner |
| DC-4 | Where a replacement exists, the cut-over date is agreed and the replacement has passed its own go-live checks | Link to the replacement's deployment checklist |
| DC-5 | Users who granted the agent delegated access are told the date their consent will be revoked and what replaces the service | Notification record |
If no registry record exists, the agent is a shadow agent. Build a temporary record from discovery data before you start, so that every later step has somewhere to land; see the Shadow AI Discovery Guide.
3. Freeze and preserve
Preserve before you delete: a retired agent may later feature in an investigation, a data subject request or a dispute about an action it took.
| ID | Step | Evidence |
|---|---|---|
| FP-1 | The agent is stopped from starting new work: runtime disabled or scaled to zero, published endpoints and chat channels unpublished | Runtime status export |
| FP-2 | A configuration snapshot is taken: system prompt and instructions, model and version, tool and MCP server list with scopes, guardrail and approval settings, environment variables (names only, never values) | Snapshot stored in [evidence store] |
| FP-3 | Audit logs, tool call traces and identity sign-in logs for the agent are exported or confirmed to be held for [retention period], whichever system holds them | Export location or retention setting |
| FP-5 | Legal or investigation holds are checked; if a hold applies, memory and data deletion in section 8 is deferred and the reason recorded | Hold check record |
Scan retained traces for secrets before archiving and add any found to section 5; see How to Find Secrets in AI Agent Transcripts and Traces.
4. Delegated OAuth grants and consents
Delegated grants are the part of an agent most often left behind. Consent that users or administrators gave to the agent's application lives at the identity provider or SaaS platform, not in the agent, so stopping the agent does not remove it. The 2026 Vercel Context.ai OAuth breach began with a long-lived grant to an AI application that one employee had connected with broad access and that no one had reviewed or revoked.
| ID | Step | Evidence |
|---|---|---|
| OG-1 | List every OAuth client the agent used, in every identity provider and SaaS tenant (productivity suite, CRM, code hosting, ticketing) | Client ID list |
| OG-2 | Remove both user-level and tenant-wide delegated grants. In Microsoft Entra ID an application can hold a per-user grant (consentType Principal) and an admin grant for all users (consentType AllPrincipals); removing one can leave the other in force | Grant list before and after |
| OG-3 | Remove application permissions (app role assignments) and any directory roles held by the agent's service principal | Assignment list before and after |
| OG-4 | Revoke refresh tokens at each authorisation server that supports it (OAuth token revocation, RFC 7009). Under RFC 7009, revoking a refresh token should also invalidate access tokens from the same grant only where the server supports access token revocation, so record the residual access token lifetime for each platform | Revocation response; residual window noted |
| OG-5 | Block re-consent: remove the requested permissions from the application, or restrict user consent so that the application cannot be granted access again by an individual user | Consent policy or app registration change |
| OG-6 | For agents that acted on behalf of users through token exchange or on-behalf-of flows, confirm no stored user tokens remain in the agent platform's token vault | Vault entry count for the agent is zero |
Microsoft documents that deleting an oAuth2PermissionGrant stops new access tokens being issued for those delegated permissions, while existing access tokens stay valid for their lifetime. Plan for that residual window on every platform and keep monitoring (section 10) until it has passed. For the wider grant model see AI Agent Service Accounts vs On-Behalf-Of Access.
5. Agent identity and credentials
Disable, then delete, the agent's own identities and credentials using the generic NHI process. The agent-specific points are below; the full mechanics for keys, service accounts, certificates and cloud roles are in the NHI Offboarding and Decommissioning Guide and the AI Agent Credential Lifecycle and Rotation Guide.
| ID | Step | Evidence |
|---|---|---|
| ID-1 | Each agent identity is disabled first, then deleted after the observation period. In Microsoft Entra Agent ID, sponsors can disable and soft-delete an agent identity, but only owners or administrators can re-enable, restore or hard-delete it, so the decommission owner needs the right role for the final step | Disable and delete timestamps |
| ID-2 | Where several agents share a blueprint, template or parent application, confirm whether other live agents still depend on it before removing its credentials; retire the parent only when its last agent is retired | Dependency check result |
| ID-3 | Model provider API keys used only by this agent are revoked at the provider; shared keys are rotated | Key revocation or rotation record |
| ID-4 | Secrets in [secrets manager] issued to the agent are revoked and their paths and policies removed; dynamic secret leases are revoked | Vault audit entries |
| ID-5 | Workload identity federation trusts and cloud role trust policies that name the agent's workload are removed | Trust policy diff |
| ID-6 | Any credential that a person could have seen (developer tokens used during build, keys pasted into test prompts) is rotated, as the OWASP Non-Human Identities Top 10 recommends for credentials a departing person could access | Rotation record |
A retired agent's model API key is worth money to an attacker; see the LLMjacking Guide.
6. MCP servers and tool connections
| ID | Step | Evidence |
|---|---|---|
| TC-1 | List every tool, plugin, skill and MCP server the agent could call, from the registry record and the configuration snapshot in FP-2 | Tool inventory |
| TC-2 | For remote MCP servers using OAuth, revoke the tokens issued to the agent's MCP client and remove the client registration (pre-registered client, or the client ID metadata document URL the server trusted) | Authorisation server record |
| TC-3 | For local MCP servers over STDIO, which take credentials from the environment rather than OAuth, remove the server configuration and revoke the environment credentials it used | Configuration diff; credential revocation |
| TC-4 | MCP servers that existed only for this agent are shut down and removed from the [MCP registry or gateway] allow list | Registry or gateway change |
| TC-5 | Tool-side accounts, API keys and webhook secrets that third-party tools issued to the agent are revoked in each tool | Per-tool revocation record |
| TC-6 | Policy engine and gateway rules that referenced the agent are removed so that a new agent cannot inherit them by reusing the name | Policy diff |
The MCP authorisation specification (revision 2026-07-28) requires servers to accept only tokens issued for them as the audience. That limits what a leftover token can reach, but it does not remove the token: revocation still has to happen at the authorisation server. See the AI Agent Tool and Plugin Security Guide.
7. Triggers, schedules and orchestration
Triggers are what bring a "retired" agent back. A cron schedule, an event subscription or a parent agent that still lists it as a sub-agent can restart work under a new deployment or a restored identity.
| ID | Step | Evidence |
|---|---|---|
| TR-1 | Scheduled runs (cron jobs, platform schedules, recurring flows) are deleted, not paused | Schedule list before and after |
| TR-2 | Event triggers are removed: mailbox and file change subscriptions, message queue consumers, SaaS webhooks, repository events and CI pipeline steps that invoke the agent | Subscription list before and after |
| TR-3 | Orchestrators and parent agents no longer route to the agent; A2A agent cards or catalogue entries for it are withdrawn | Routing configuration; catalogue change |
| TR-4 | Infrastructure as code, templates and low-code solution packages that would redeploy the agent are updated or archived, so the next pipeline run does not recreate it | Commit or package change reference |
8. Memory, vector stores and data
Agent memory is personal and business data that outlives the agent. Decide, store by store, whether to delete, retain for a defined period, or migrate to a replacement, and record the decision against the retention schedule. For memory design see the AI Agent Memory Security Guide.
| Store | What it holds | Retirement action |
|---|---|---|
| Short-term or session memory | Conversation turns, tool calls and results per session | Delete unless covered by FP-3 retention or a hold |
| Long-term memory | Facts, preferences and summaries extracted across sessions, often per user | Delete per user namespace, or migrate only with the data owner's approval |
| Vector index used for retrieval | Embeddings of documents the agent indexed, plus source copies | Delete the index and any copied source documents; keep the original sources |
| Caches and scratch storage | Prompt caches, file uploads, generated artefacts, sandbox volumes | Delete and confirm storage buckets or volumes are removed |
| Fine-tuning data and adapters | Training examples and model adapters built for this agent | Retain or delete per the model retention policy; record location |
| Traces and evaluations | Observability traces, evaluation datasets, feedback | Retain per FP-3; scan for secrets and personal data first |
As a platform example, AWS Bedrock AgentCore Memory separates short-term memory (immutable events per actor and session) from long-term memory records organised by namespace, and its DeleteMemoryRecord operation permanently removes a record that cannot then be recovered. Other platforms differ, so confirm each platform's deletion behaviour, including backups and soft-delete windows, in its own documentation and record it. Where deletion is required, NIST SP 800-88 Rev. 2 (Guidelines for Media Sanitization) is the reference for how far deletion must go for the data's sensitivity. If the agent held personal data, check the obligations in AI Agents and Data Subject Rights.
9. Registry and records
| ID | Step | Evidence |
|---|---|---|
| RR-1 | The [agent registry] record status is set to Retired with the retirement date, decommission owner and change ticket; the record is kept, not deleted, so the history stays auditable | Registry record |
| RR-2 | The agent's name and identifiers are reserved for [12 months] so a new agent cannot reuse them and inherit trust, logs or policy matches | Reservation entry |
| RR-3 | CMDB, IGA and AI register entries are updated to match, so reconciliation does not flag the agent as missing or recreate it | Reconciliation result |
| RR-4 | Contracts and vendor records are updated where a third-party agent is retired, including data return or deletion confirmation from the vendor | Vendor confirmation |
For the registry data model see the AI agent registry guide.
10. Verification and sign-off
| ID | Check | Pass criterion |
|---|---|---|
| VS-1 | Sign-in and token logs for every retired identity and client ID | No successful authentication after the revocation time plus the residual token window |
| VS-2 | Tool and API logs at each connected system | No calls from the agent's identities, clients or source addresses for [30 days] |
| VS-3 | Grant and assignment queries re-run at each identity provider | Zero delegated grants, app role assignments or roles for the agent |
| VS-4 | Schedule and subscription queries re-run | Zero triggers referencing the agent |
| VS-5 | Storage inventory | Memory stores and indexes deleted, or listed as retained with an expiry date |
| VS-6 | Sign-off | Decommission owner and [AI security team] sign the ticket; final deletion of disabled identities is scheduled |
Set an alert, for at least the observation period, on any authentication attempt by a retired agent identity or client ID. Useful measures across the agent estate are: median days from decommission approval to sign-off; percentage of retirements with sections 2 to 10 fully evidenced; count of retired agents with any remaining grant at the 30-day re-check; and count of authentication attempts by retired identities.
11. Framework mapping
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Other |
|---|---|---|---|
| 2. Trigger, decision and owner | AC-2 Account Management | GV.RR-02, ID.AM-08 | NIST AI RMF GOVERN 1.7, MANAGE 2.4 |
| 3. Freeze and preserve | AU-11 Audit Record Retention | ID.AM-08 | NIST AI RMF GOVERN 1.7 |
| 4. Delegated grants | AC-2(3) Disable Accounts, AC-6(7) Review of User Privileges | PR.AA-05 | ATT&CK T1550.001 Application Access Token |
| 5. Identity and credentials | IA-4 Identifier Management, IA-5 Authenticator Management | PR.AA-01 | OWASP NHI1:2025 Improper Offboarding; ATT&CK T1078.004 Cloud Accounts |
| 6 and 7. Tools and triggers | CM-3 Configuration Change Control | PR.PS-01 | OWASP ASI10 Rogue Agents |
| 8. Memory and data | MP-6 Media Sanitization, SI-12 Information Management and Retention | ID.AM-08 | NIST SP 800-88 Rev. 2 |
| 9. Registry | CM-8 System Component Inventory | ID.AM-02 | NIST AI RMF GOVERN 1.6 |
| 10. Verification | AC-2 | DE.CM-03 | ATT&CK T1528 Steal Application Access Token |
Implementation guidance
- Start with the registry. The checklist is only as complete as the agent's record. Make tools, MCP servers, grants, triggers and memory stores mandatory registry fields at onboarding, using the AI Agent Onboarding Request Template, so retirement has a list to work from.
- Pilot on a low-risk agent. Run the checklist on a read-only internal agent first, measure how long each section takes, and note which platforms could not produce evidence.
- Automate the queries, not the deletions. Script the inventory and verification queries (grants, assignments, schedules, stores) per platform so VS-1 to VS-5 are repeatable; keep destructive steps behind a human approval in the change ticket.
- Use disable, observe, delete. Disable identities and grants, watch logs for the observation period, then delete. If a dependant breaks, re-enable from the owner role and fix the dependency list rather than leaving the agent live indefinitely.
- Connect retirement to recertification. A failed review should open a decommission ticket automatically; see Agent Identity Recertification.
- Re-check at 30 days. Re-run VS-3 and VS-4 once more after sign-off. Re-consent by users and pipeline redeployment are the two most common ways a retired agent comes back.
Common failure patterns to watch for: revoking the per-user grant but leaving the tenant-wide admin consent; deleting the identity while a schedule still points at it, which hides the trigger rather than removing it; deleting the memory store but not the copied source documents in the vector pipeline; reusing a retired agent's name for its replacement so old policy rules apply to the new agent; and treating a vendor agent's retirement as complete without the vendor's data deletion confirmation. Agents with standing, account-wide tokens cause the most damage when they outlive their purpose, as the PocketOS database deletion shows for an over-scoped token an agent found and used.
Standards and references
- NIST: AI RMF Playbook, Govern (GOVERN 1.6 and 1.7)
- NIST: AI RMF Playbook, Manage (MANAGE 2.4 and 4.1)
- OWASP: Non-Human Identities Top 10, NHI1:2025 Improper Offboarding
- IETF: RFC 7009 OAuth 2.0 Token Revocation
- Model Context Protocol: Authorization specification
- NIST: SP 800-88 Rev. 2 Guidelines for Media Sanitization
- AWS: Bedrock AgentCore Memory terminology
- Microsoft: Review and revoke permissions granted to an enterprise application
Related NHI Mgmt Group resources: AI Agent Lifecycle Management Guide, NHI1 Improper Offboarding, AI Agent Deployment Checklist, Identity Governance for AI Agents Guide.