Every organization has a human offboarding process. Access is revoked, accounts disabled, devices returned, and someone signs off. It is imperfect, but it exists and it is owned.
Almost no organization has the equivalent for agents. Agents are created for a project, tested, deployed, and then the project ends or the approach changes. The agent stops being used. Nothing else happens. Its credentials remain valid, its connections remain provisioned, its scheduled triggers keep firing, and its downstream service accounts keep working — with nobody monitoring any of it.
That accumulation is the largest non-human identity exposure in most estates, and it is invisible precisely because nobody owns it.
What Stays Alive After an Agent Stops Being Used
Credentials. API keys, client credentials, refresh tokens, signing keys. Long-lived by default in most setups, so they simply persist.
Downstream grants. The database role, the SaaS service account, the cloud IAM role, the OAuth grant on a third-party app. These live in the other system and are not touched by anything you do in yours. The agent's operator provisioned them by hand months ago and there is no record connecting them to the agent.
Connections and integrations. Registered webhooks that still deliver, MCP server registrations, message-queue consumers, event subscriptions.
Scheduled and event triggers. Cron schedules, webhook endpoints, event subscriptions that still invoke the agent. This is the category that produces surprises: an agent nobody has thought about for six months still runs every night, still spends money, and still writes to production. See triggering workflows: scheduled, webhook, event.
Budget allocations. Reserved spend that continues to be consumed, or a ceiling that keeps a stale agent funded.
Data. Cached content, vector store entries, conversation history, memory. Sometimes containing personal data with retention obligations attached.
Trust and reputation state. A reputation record that a compromised orphan can still trade on, especially in cross-organization contexts.
The Deprovisioning Sequence
Order matters, and the intuitive order is wrong. Deleting the agent first destroys the mapping you need to find everything else.
1. Freeze triggers first. Disable schedules, webhook endpoints, and event subscriptions before touching anything else. This stops new work from starting while you are mid-sequence, which otherwise produces confusing half-completed tasks.
2. Drain in-flight work. Let running tasks complete or cancel them deliberately. Abrupt termination mid-task leaves partial writes, orphaned records in downstream systems, and reconciliation work — worse for a payment or provisioning agent than a slightly slower offboarding.
3. Revoke credentials. All of them, including refresh tokens and any credential the agent could use to obtain another. Revocation must take effect on in-flight requests, which for stateless token validation means a denylist or a key-version bump. Verify by attempting a call, rather than assuming the revocation applied.
4. Enumerate and revoke downstream grants. The hard step, and the reason an inventory matters. Every connection record should name the downstream credential or grant it uses, so revocation is a list to walk rather than an investigation. Where grants were provisioned manually, this is where you discover it. See NHI credential lifecycle management.
5. Remove connections and registrations. Delete connection records, deregister from MCP servers and registries, unsubscribe from event streams, remove marketplace or federation listings so counterparties stop routing to it.
6. Release budget. Return reserved allocation so it is not counted as consumed capacity.
7. Handle data. Delete caches and vector entries derived from the agent's work; apply retention policy to conversation history and memory. Where personal data is involved, this intersects erasure obligations. See GDPR for AI systems and erasure rights.
8. Archive, do not delete, the audit trail. The record of what the agent did must outlive the agent. Deleting audit history along with the agent record is the mistake that makes a later investigation impossible, and it breaks hash-chain continuity if your audit log is chained. Mark the agent as retired and keep the history under its retention policy. See tamper-evident audit logs.
9. Record the offboarding itself. Who retired it, when, why, and confirmation of each step. This is what makes the deprovisioning auditable and what lets someone answer "when did this stop having access" a year later.
Finding Agents That Should Be Offboarded
Nobody files a ticket to retire an agent. You have to find them.
Inactivity. No invocations in 30, 60, 90 days. The cheapest signal and the most productive first sweep in almost every estate. Note that scheduled agents will look active while being functionally abandoned, so pair inactivity with ownership checks.
Orphaned ownership. The named owner has left the organization, changed teams, or does not recognize the agent. Human offboarding should trigger a review of agents owned by the departing person, and it almost never does — adding that one step to the HR offboarding checklist finds more stale agents than any automated sweep.
Unused credentials. Keys and tokens with no use in a defined window. Revoke on a schedule and let something break loudly rather than letting credentials accumulate silently.
Unused scopes. An agent still active but exercising a fraction of its grants. Not a full offboarding, but a scope reduction — the same signal that drives least-privilege tightening. See how to implement least privilege for agents.
Discovered but never registered. Agents visible in telemetry that were never formally onboarded. These have no owner and no lifecycle by definition. See building an AI agent inventory and OTLP telemetry ingest for agent discovery.
Duplicate or superseded. Version 2 shipped and version 1 was never retired. Extremely common, and the old version usually retains full credentials.
Prevent the Problem at Creation
Offboarding is easier if provisioning sets it up.
Require a named owner. A person or a team with an on-call rotation, not "the platform team." Ownership is what makes review requests actionable.
Set an expiry at creation. Every agent gets a review or expiry date. Renewal is a deliberate act — a lightweight confirmation that the agent is still needed. Expiry-by-default converts silent accumulation into an explicit decision, and it is the single highest-leverage change available here.
Record every downstream grant against the connection. If a grant is not recorded, it will not be revoked. Make provisioning go through the connection record rather than around it, so the inventory is a byproduct of normal operation rather than documentation someone has to maintain.
Prefer short-lived credentials. An agent whose credentials expire in minutes and are refreshed against a live identity is deprovisioned the moment the identity is disabled. This turns revocation from an enumeration exercise into a single action, and it is the strongest argument for token exchange over static keys. See token exchange for agent-to-tool authorization.
Tag by environment and purpose. Experimental agents get shorter default expiries than production ones. Most orphans start as experiments.
Common questions
How is this different from managing service accounts?
The lifecycle problems are the same and the scale and velocity are not. Service accounts are created deliberately by platform teams at a rate of a few per quarter. Agents are created by application teams, sometimes by other agents, at a rate of dozens per month, often with credentials provisioned ad hoc during development. Manual review processes that keep up with service accounts do not keep up with agents, which is why expiry-by-default and automated inactivity sweeps matter more here.
Should retired agents be deleted or disabled?
Disabled and retained, with credentials revoked. A deleted agent record breaks the foreign keys in your audit history, removes the mapping needed to interpret past events, and makes it impossible to demonstrate when access ended. Retain the record in a retired state, remove the access, and let retention policy govern eventual deletion of the associated data.
What about agents in a multi-tenant platform where the tenant owns the agent?
Tenant offboarding needs the same sequence applied across every agent in the tenant, plus tenant-level artifacts: shared connections, marketplace listings, federation trust entries, and data residency obligations. It is also where erasure requests and audit retention conflict most directly — the resolution is usually to erase personal data while retaining structural audit metadata, which requires that your audit records separate the two. See GDPR erasure and EU AI Act readiness.
How do I revoke a grant in a third-party system that has no API?
Manually, which is why recording it at provisioning time is what makes it possible at all. Where a third-party integration cannot be revoked programmatically, that is an argument for routing the access through a proxy that holds the credential — then revoking the connection at the proxy denies access even though the upstream grant technically remains. It is a compensating control, and it should be recorded as one.
How Praesidia approaches agent lifecycle closure
Praesidia treats the connection as the unit of access, so an agent's grants are enumerable rather than scattered — each connection names its credential, its scopes, and its destination, which makes revocation a walk of a recorded list. Credentials issued for governed connections are short-lived and audience-restricted, so disabling an agent's identity stops access at the next refresh rather than requiring a hunt for standing keys.
Agents carry owners, and discovery surfaces observed agents that were never registered so orphans become visible. Retiring an agent revokes credentials and halts in-flight work while preserving the tamper-evident audit history under its own retention policy, and the offboarding action is itself recorded. See managing API consumers and applications and the Praesidia documentation.