AI Agents Retire Too: A Decommissioning Playbook for Enterprise AI

The enterprise AI literature has a lifecycle blind spot: guides on deploying an agent are everywhere; guides on retiring one are vanishingly rare. The provisioning half of the lifecycle is lavishly documented — identity, scopes, budgets, evaluation, launch. The decommissioning half is treated the way organizations treat all endings: as something that will take care of itself. It does not, and 2026's identity research sketches what "taking care of itself" produces. Gravitee's 2026 survey work finds enterprise agent fleets roughly doubling in a quarter while only about a fifth of teams individuate agent identities at all — and the invisible layer that results, the population of credentials and actors nobody can attribute, may include agents and credentials that were never properly retired: the pilot that ended but whose service account didn't, the workflow replaced by a better one while the old agent's key kept working, the departed engineer's experiment still holding a token. Un-retired agents are dark matter in its most preventable form — mass added to the invisible layer not by hurried provisioning but by absent off-boarding. This post writes the missing half of the lifecycle: what decommissioning an agent actually involves (it is much more than stopping a process), the six-step playbook — inventory, redirect, revoke, retain, tombstone, verify — why audit obligations often make immediate blanket deletion the wrong instinct for the records, and the structural point underneath: retirement is cheap and reliable exactly in proportion to how well the agent was governed while alive, which makes decommissioning the final argument for the plane — and the first question to ask about any agent you're about to create.

1. Why Retirement Is the Lifecycle's Hard Half

Provisioning is easy to do well because everything about it is present-tense and motivated: a team wants the agent, budgets exist, checklists get followed because launch depends on them. Retirement inverts every one of those conditions, which is why it fails silently and often. The motivation is gone — the team has moved to the replacement, the pilot's sponsor has moved teams, nobody's OKR says "turn things off." The knowledge is gone — the engineer who knows where the agent's key lives has left, and the agent itself appears in no inventory because it was never individuated. And the incentive is inverted — turning something off risks breaking a dependency someone forgot, while leaving it running risks nothing visible today; so the rational move, locally, is always to leave it. The result is the mechanism running unopposed: when provisioning outpaces inventory and retirement, identities and credentials accumulate even after their original workloads disappear — and the specifically agentic escalation is that the leftover is not an inert key but running autonomy: an un-retired agent doesn't just sit there as attack surface, it keeps acting, spending, and touching data under a purpose nobody holds anymore. The year's incidents supply the caution generalized: compromised or misbehaving agents are contained by revoking what they hold, and an agent nobody remembers holding anything is the one that cannot be contained, because it cannot be found. Decommissioning, done as a discipline, is how an estate keeps its census true — and the census, as the dark-matter analysis shows, is the foundation everything else stands on.

2. The Six-Step Playbook

Here is the procedure the literature skips, in the order that prevents the classic failure modes. Inventory: enumerate everything the agent holds and touches — credentials (all of them: the official one and the copies), tool scopes, budget lines, scheduled triggers, queues it consumes, systems that call it, dashboards that reference it. The inventory is trivial if the agent was individuated on a plane and archaeological if it wasn't; either way, skipping it is how step three breaks production. Redirect (and drain): before anything is revoked, freeze the intake and move the dependents — scheduled triggers disabled so no new work starts, queues drained or transferred, active runs checkpointed or allowed to complete, child agents stopped, and callers pointed at a successor through an agent-level service alias, workflow registry, gateway route, or whatever indirection layer the application platform maintains, so downstream workflows never dial a dead number. Dependents that call through an indirection layer migrate with one entry changed; dependents that hard-coded the endpoint are a coordinated migration — the same staged-cutover discipline that governs model deprecations, applied one layer up. One caveat the mode of retirement decides: redirect suits planned replacement, while a compromised or unsafe agent should usually fail closed — callers get errors, not a silent successor inheriting bad assumptions. Revoke: every credential invalidated (revoking the credential revokes its copies — they are the same credential), scopes removed, identity disabled, and — where the agent has a dedicated virtual account or a reliably propagated identifier for budget rules to match — its spend rule enforced to zero so no further model calls clear the gateway: the containment levers from the incident runbook, pulled permanently. Retain: the step the deletion instinct gets wrong — a retired agent's traces, decisions, guardrail outcomes, and evaluation history often carry retention obligations (audit, legal hold, and the organization's own learning) that outlive the actor, while other records may fall under data-minimization, contractual, privacy, or customer-deletion duties that mandate the opposite; retirement silences the agent without amnesia, what is kept and for how long follows written policy rather than instinct, and central trace storage is what makes that separation possible rather than aspirational (the audit posture). Fold knowledge transfer in here: the prompts, scopes, eval cases, and incident-derived rules the agent accumulated are its successor's inheritance — migrating them is how the estate's verification layer compounds across generations instead of resetting. Tombstone: maintain a retirement record — in the agent registry, CMDB, governance ledger, or audit database — that keeps the retired identity resolvable to a real principal with an owner and an end date, and prevents the name from being silently reused to inherit stale grants; where the platform deletes the identity together with the agent's registration, the tombstone lives in the governance system of record rather than the runtime. Verify: run four checks against the attribution record — successful traffic attributed to the retired agent (must be zero; anything else means revocation is incomplete or an alternate credential exists), failed attempts presenting revoked credentials (the benign signature of a copy the inventory missed, now locked out), successful calls from undocumented identities mapping to the same workload, and traffic reaching the agent's dependencies outside the governed route entirely. The playbook's most valuable output is often this pass: the copy or the bypass caught by telemetry instead of by incident.

3. Retirement as a Plane Property — and as a Provisioning Test

Here is where TrueFoundry fits, and the argument is the playbook read structurally: every step is cheap where the agent's operational life ran through a governed layer, and expensive in proportion to how much of it ran around one. Inventory is a query when the agent is a registered principal whose scopes, budget, and traffic are plane records (access control; analytics) — and a forensic project when its access is a shared key pasted into environment variables, which is the dark-matter provisioning pattern meeting its predictable end. Redirect is one registry or route entry where dependents call through an indirection layer the platform maintains, and a coordinated multi-team migration where they hard-coded endpoints. Revocation is surgical where identity was individuated — one principal disabled, nothing else disturbed — and collateral where credentials were shared, which is how retirements get deferred indefinitely: nobody dares revoke the key eleven other things use. Retention is simpler and more reliable where traces were recorded centrally per request under a defined policy, and fragile where evidence is scattered across ephemeral deployment-local storage. Even verification — the zero-traffic check — is precisely the attribution-rate machinery the dark-matter analysis proposed, run for one principal. Which yields the post's backward-running conclusion: decommissioning is a provisioning test. The question "how would we turn this off?" — asked on launch day, before the first request — audits in one sentence whether the agent is being born governed: individuated identity, task-derived scopes, enforced budget, aliased dependents, central traces. An agent whose creation can answer it retires in an afternoon; an agent whose creation can't has pre-committed the organization to either an archaeology project or, more likely, to never retiring it at all — and "never retiring it at all," multiplied across estates that Gravitee's 2026 data shows roughly doubling in a quarter, is how invisible layers accrue. The lifecycle's two ends are the same discipline wearing different tenses.

4. Boundaries, Stated Plainly

Scope and candor. The six-step playbook is editorial synthesis — lifecycle management practice from the service-account and workload-identity world, adapted to agents and informed by the identity-survey record cited in our dark-matter and identity-census analyses — not a standard; retention steps in particular intersect legal and regulatory obligations that vary by jurisdiction and industry, and nothing here is legal advice or supersedes counsel on what must be kept and for how long. Our interest is the disclosed and by-now-familiar one: the playbook is cheap on a governed plane and expensive off one, and we sell the plane — which is why we've kept the procedure itself vendor-neutral (every step is executable on any stack providing individuated identity, revocable scopes, enforced budgets, aliased routing, and central traces) and framed the product mapping as a dependency statement rather than a differentiator. Two capability notes for precision: TrueFoundry's virtual models are model-layer routing — a stable name over provider targets — not an agent-service registry, which is why the redirect step names its indirection layer generically; and agent identity on the platform is one-to-one with the agent's registration and currently in beta, so the tombstone in this playbook is a record your governance system maintains, not a platform lifecycle state. Two limits against the piece. First, the playbook covers the agent's operational footprint; agents also leave outputs — documents written, records changed, decisions influenced — whose lifecycle belongs to the systems that hold them, and decommissioning the actor does not adjudicate the artifacts. Second, tombstoning and retention assume the organization wants history, and there are legitimate data-minimization regimes that mandate the opposite for certain records; where retention duties and deletion duties collide, that is a lawyer's tradeoff, not an engineer's. What we'll claim plainly is the gap this post exists to fill: the industry has written the birth half of the agent lifecycle a thousand times and the death half almost never, poor retirement is one preventable contributor to the invisible-agent layer everyone is now surveying, and the estates that stay visible will be the ones that treat "how would we turn this off?" as a launch-gate question — because agents, like everything else an enterprise runs, retire too.

References

• Context — Gravitee, State of AI Agent Security 2026 (agent-fleet growth; the roughly-one-in-five identity-individuation figure); classical service-account and workload-identity lifecycle practice, adapted.
• TrueFoundry documentation — AI Gateway introduction (official diagram); access control; virtual models (model-layer routing); agent identity (beta); budgets (official image); analytics and attribution.
• This blog — OAuth and token management at the MCP layer; TBAC: task-based access control; AI governance and audit; cost attribution and budgets.

No direct quotations are used; survey context is paraphrased from the cited Gravitee report, and the playbook is editorial synthesis rather than a compliance standard — retention and deletion obligations vary by jurisdiction, and nothing here is legal advice. Our commercial interest in the plane the playbook leans on is disclosed in the text; the procedure itself is executable on any stack providing the named capabilities. Product capabilities are paraphrased from public documentation current at the time of writing; the product images are TrueFoundry's own documentation assets, reproduced with attribution.

‍