Subscribe to the Non-Human & AI Identity Journal

Agent decommissioning

The process of retiring an AI agent and revoking every credential, connection, and permission it used. Proper decommissioning is a lifecycle control, not a shutdown notice, because lingering access can become a standing entry point for later abuse.

Expanded Definition

Agent decommissioning is the controlled retirement of an AI agent after its business role ends, with explicit removal of every credential, token, certificate, endpoint binding, callback route, and delegated permission it ever used. In NHI security, the term is broader than shutdown because the agent may have touched secrets, workflow automations, data stores, and downstream service accounts that remain active unless they are intentionally revoked.

Definitions vary across vendors on whether decommissioning also includes deletion of logs, embeddings, prompts, and memory stores, but the security baseline is consistent: eliminate standing access and preserve only what is required for audit and legal retention. That makes decommissioning a lifecycle control aligned with zero trust, not a simple application-offboarding task. The operational model should be informed by the NIST AI Risk Management Framework and by agent-specific guidance such as OWASP Top 10 for Agentic Applications 2026, which both emphasize lifecycle-aware risk treatment.

The most common misapplication is treating decommissioning as a ticket to disable the user interface while leaving API keys, service tokens, and third-party grants intact, which occurs when teams confuse product retirement with identity retirement.

Examples and Use Cases

Implementing agent decommissioning rigorously often introduces short-term operational friction, because teams must coordinate application owners, IAM administrators, security operations, and data governance to avoid breaking legitimate dependencies while removing access.

  • A customer-support agent is retired after a workflow redesign, and its mailbox access, CRM OAuth grants, and retrieval connectors are revoked before the agent configuration is archived.
  • An internal coding agent used in CI/CD is sunset, and its repository permissions, signing secrets, and deployment tokens are rotated out of service to prevent later misuse.
  • A sales-ops agent that posted to Slack and queried a warehouse is removed, and those channel tokens and database roles are explicitly reviewed against the offboarding checklist in the Ultimate Guide to NHIs — 2025 Outlook and Predictions.
  • An externally hosted agent is terminated after a vendor contract ends, and the organisation confirms token revocation, webhook teardown, and any federation trust removal in line with CSA MAESTRO agentic AI threat modeling framework.
  • A prompt-automation agent is replaced after a security review, and its memory store and tool permissions are assessed to ensure only evidence needed for compliance remains.

These examples map closely to the kinds of control failures discussed in CoPhish OAuth Token Theft via Copilot Studio and the broader patterns captured in the OWASP NHI Top 10.

Why It Matters in NHI Security

Agent decommissioning matters because retired agents are still identities in the security sense until every secret and permission is removed. If that cleanup does not happen, the organisation inherits hidden access paths that can be abused long after the business believes the system is gone. NHI Mgmt Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which makes incomplete decommissioning a common control gap rather than an edge case; that gap is especially dangerous when paired with findings that 91.6% of secrets remain valid five days after notification, as shown in the Ultimate Guide to NHIs.

Mismanaged decommissioning also undermines zero trust, because dormant tokens can bypass intent-based access reviews and remain usable by attackers, contractors, or compromised automation. This is why the control model should be read alongside the NIST SP 800-53 Rev 5 Security and Privacy Controls for access revocation discipline and the NIST AI Risk Management Framework for lifecycle governance.

Organisations typically encounter the full significance of agent decommissioning only after a retired agent is found still acting on production systems, at which point the term becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-07 Covers lifecycle offboarding and revocation for non-human identities.
OWASP Agentic AI Top 10 A-08 Addresses agent lifecycle, tool access, and residual authority risks.
NIST CSF 2.0 PR.AC-4 Access permissions should be managed and revoked when no longer needed.
NIST SP 800-63 IAL/AAL null Identity assurance principles inform how strong credentials are retired.
NIST Zero Trust (SP 800-207) SP 800-207 core principle Zero Trust requires continuous revalidation and no standing access after retirement.

Review and remove dormant agent entitlements before closing the decommissioning record.