Agent Decommissioning Procedures and Credential Cleanup
Stopping an agent's process leaves its credentials live and fully authorized to act.
Decommissioning an AI agent means tracking down and eliminating every credential, token, service account, and delegated permission it ever held. Shutting it down means stopping a process. These are not the same action, and treating them as interchangeable is how organizations end up with fully authorized identities that no longer have a pulse.
Why shutting down an agent is not decommissioning it
Offboard a human employee and the playbook is well understood: disable the badge, pull the laptop, revoke the SSO login, and the person's access to company systems ends on schedule. Agents break that playbook in a specific way. An agent typically authenticates with its own API keys, its own service account, and its own tokens, and none of these depend on whether the agent's operator still exists or whether its process is still running. An employee gets offboarded right on schedule, and the agent that employee built keeps placing orders anyway, because it was never authenticating as that employee in the first place, a practitioner pattern documented in the field. The agent's identity, from an access perspective, outlives the thing that created it.
Token Security's lifecycle analysis names the result bluntly: spinning down the container leaves the API keys sitting in the vault and the service account sitting in the IAM policy. The organization now has ghost identities that are technically dead but still fully authorized to act. The operational footprint makes this worse before it makes it better. Agents push updates to CRMs, trigger escalations, feed output to other agents, and hold webhook subscriptions, and none of those touchpoints vanish the moment the process exits. Incomplete retirement doesn't just leave a loose end; it leaves dormant privilege sitting exactly where an attacker, an auditor, or a very confused IT team will eventually find it.
How agents accumulate credentials across their lifetime
By the time an agent reaches the end of its working life, it isn't carrying just the credentials tied to its final job; it's carrying a kind of sediment, layered in from every phase it passed through.
The first layer gets deposited at birth. Agents are typically assigned a service account, a set of API keys, and a role the moment they're deployed, and developers routinely over-provision at this stage, handing out Admin or Editor privileges simply to avoid permission-denial errors during setup. Token Security's lifecycle breakdown identifies this as the point where post-deployment security fails before the agent has done a single day of work: it starts its life already holding more power than its job requires.
Operation adds the next layer. As the agent runs, it generates logs, creates temporary files, and opens new connections to other agents through the Model Context Protocol, a standard that lets agents share context and call each other's tools. If the agent is compromised later or decommissioned incompletely, the blast radius grows with each connection. Token Security's lifecycle analysis also flags privilege drift as a hazard specific to this phase: retrain the agent and its behavior changes, but its permissions almost never get revisited, so it keeps holding access tied to a function it no longer performs. MCP configuration files deserve particular suspicion here. Setup guides commonly encourage placing API keys directly into those config files, and many organizations have no visibility into what those files actually contain, so MCP is one of the newest and least governed leak surfaces in the whole stack.
Training and fine-tuning contribute a stranger layer. Training data can contain accidental API keys or passwords, and if it does, the model learns them the same way it learns everything else, so the agent's memory becomes a repository of leaked credentials it can surface in production without anyone intending it to. Token Security's analysis treats this as a real risk category, not a hypothetical: a vault of leaked credentials can be sitting inside a model before that model ever sees a production environment.
The most overlooked layer comes from what the agent builds on its own. Agents frequently spin up helper service accounts, webhook subscriptions, deployment hooks, and queue consumers in the course of doing their job, and those artifacts can easily outlive the task that created them without ever showing up in the primary agent's credential record. Compounding all of this is an ownership problem: whoever built the agent is usually its default owner, and when that person changes roles or leaves the company, ownership doesn't transfer automatically. It keeps running, keeps accumulating access, and answers to no one.
The scale of the orphaned-credential problem agents are entering
Agents are being decommissioned, badly, into an environment that was already in trouble before agents showed up. Most non-human identity credentials across organizations are never revoked at all, and incomplete agent retirement doesn't create a new problem so much as pour more fuel on an existing one. The same reporting that tracks this finds that credential leaks tied to AI services are the fastest-growing category of secret exposure year over year, so this is not a niche concern.
Governance has not caught up. Industry reporting finds that only about one in five organizations had a formal process for decommissioning AI agents as of 2026, and only a similarly small share have anything resembling a mature governance model for managing agentic AI risk. The zombie-agent pattern appears operationally: an IT operations agent gets set up to run a nightly log-cleanup routine, the people who used to interact with it stop paying attention months later, but the cron trigger that fires it never got the memo. Every night it wakes up, authenticates, and acts on production systems anyway. Documentation of this failure mode makes the point directly: "no one uses it anymore" is not true, operationally speaking, until the schedule itself gets disabled. The agent doesn't know it's been forgotten, so it just keeps showing up for a shift nobody scheduled it for.
Inventorying what an agent touched
No revocation sequence means anything until the inventory is finished first. If you clean up credentials without first mapping what exists, you get an incomplete decommissioning, no matter how thorough the cleanup feels in the moment.
The inventory needs to cover four distinct classes of artifact, and each one needs a different method to find it. The first is direct credentials: the API keys, OAuth tokens, service account credentials, certificates, and other secrets the agent was explicitly issued, which should turn up in secrets management systems and IAM consoles, or, if governance was thin to begin with, hardcoded in config files and environment variables where nobody thought to look. The second is delegated permissions and role assignments: the RBAC roles, IAM policy bindings, and group memberships that gave the agent its reach, which have to be tracked separately from the credentials themselves because a permission can keep working even after its paired credential is dead, if the role assignment was never pulled. The third is downstream machine identities: the helper service accounts, webhook subscriptions, queue consumers, and deployment hooks the agent created on its own during operation, items that frequently don't appear anywhere in the primary agent's record and have to be traced by examining what the agent provisioned. The fourth is automation triggers and scheduled effects: cron jobs, event subscriptions, and pipeline hooks the agent registered, all of which keep executing on their own schedule regardless of whether the agent's process is even running anymore. A September 2026 arXiv paper by Genliang Zhu and Chu Wang gives this fourth category a formal name, "pre-authorized carriers," and identifies it as one of three mechanisms that make simple token revocation insufficient on its own.
Building this inventory means pulling records out of several systems at once: the IAM console, the secrets manager, the agent platform's own logs, and whatever downstream services the agent was configured to reach. MCP configuration files earn a specific line item in this process: setup conventions encourage embedding API keys directly in those files, so secrets managers may miss credentials sitting there in plain text. The inventory also answers a question that determines everything about the procedure that follows: did this agent hold credentials independently, or was it acting inside a user's delegated session the whole time? That distinction, found during discovery, reshapes the revocation sequence below.
Deleting the local record versus revoking the credential at the source
The mistake usually looks harmless. Someone opens the platform dashboard, finds the agent's integration, and deletes it. The dashboard confirms the deletion, the entry disappears from the list, and the job looks done. The job isn't done. Deleting that record only removes the organization's own stored copy of the credential. It does nothing to the credential at the system that actually issued it.
An OAuth token, an API key, a service-account secret: each one lives at the provider first and in an organization's own records second. Only the provider can make the credential stop working. Deleting the local copy just makes a still-valid credential harder for anyone inside the organization to notice. That can be worse than leaving the dashboard entry visible as a reminder. Field guidance on this point is unambiguous: deleting the local record without revoking the credential at its source does not count as decommissioning it.
Removing permissions and revoking credentials are two separate operations too, and both need to happen. Permissions define what the agent is allowed to do inside the access control model. Credentials are the physical keys the agent is holding, and if some downstream system's access controls were configured loosely to begin with, a key that still works can sometimes open doors the access control model never accounted for. Pulling the IAM role binding without revoking the API key leaves the key still authenticating successfully, limited only in what it can do once it's in. If you revoke the key without pulling the role binding, the role sits there waiting for any replacement credential issued under that same identity to walk right through it.
The inventory step flags the one real exception: an agent acting inside a user's delegated session, holding no independent credential of its own. Revoke the person's access and the agent's access goes with it, no separate credential revocation required. Cloud Security Alliance agentic identity guidance states this directly: decommissioning a session-bound copilot is operationally equivalent to decommissioning the user's access to the copilot capability itself. The full revocation sequence that follows applies specifically to agents holding independent credentials, which the inventory step shows is most of them.
The revocation sequence
Order matters here because the four artifact classes depend on each other, so sequencing mistakes get punished. Revoke a credential before pulling its paired role binding, and the binding sits open for the next credential minted under that identity. Pulling a role binding before revoking the credential leaves the credential authenticating against any system that was never wired into that IAM policy. Kill automation triggers last, after credentials and permissions are gone: a cron job can still fire into a system using a secret that's already supposed to be dead, because the job never checked, it just ran.
The practical order follows the dependency chain outward from the most central artifact to the most peripheral. Automation triggers and scheduled effects get disabled first, since these are the artifacts most likely to act autonomously the moment nobody's watching, and disabling them removes the risk of a credential getting exercised mid-cleanup. Downstream machine identities come next: the helper service accounts and webhook subscriptions the agent spun up on its own, cut off before the credentials that authorize the primary agent disappear, so that nothing downstream is left holding a connection to a now-dead parent. Delegated permissions and role assignments get pulled third, so the access paths close before the keys themselves are destroyed. Direct credentials get revoked last, at the source, with the provider itself confirming the revocation rather than a local dashboard entry disappearing quietly.
OWASP's non-human identity risk list ranks improper offboarding as the single largest category of NHI risk, ahead of secret leakage and ahead of over-permissioning. That ranking lines up with everything in the sequence above: the damage doesn't come from any one missed credential so much as from retirement procedures that assume deletion equals revocation, and permission removal equals credential death, when neither assumption holds. Anything short of that sequence is just turning off the lights and hoping nobody's still in the building, not decommissioning.
