Blog · · 10 min read

AI agent decommissioning: retire an agent without zombie work

AI agent decommissioning: retire an agent without zombie work

AI agent decommissioning fails when a team deletes the agent record and assumes the job is finished. The chat entry disappears, but a scheduled run can still fire. An OAuth grant can remain valid. A delegated child, webhook, browser session, queue message, or memory record may still let the retired agent act on production data.

Retirement needs a terminal product transaction that goes beyond the UI. Inventory every execution path, freeze new admissions, decide what happens to active work, revoke triggers and authority, dispose of retained state, write a tombstone, then prove old sessions and credentials cannot execute. This produces a teardown you can retry, audit, and verify instead of a deletion you can only hope worked.

Treat deletion as a teardown transaction

An agent spans more systems than its configuration row. Its identity may live in an identity provider. Credentials may live in a broker or external tool. Runs may live in a workflow engine. Schedules, webhooks, callbacks, queues, sessions, files, memory, traces, and delegated agents each have separate owners and retention rules.

NIST's AI RMF Playbook makes safe decommissioning an explicit lifecycle control. GOVERN 1.7 calls for criteria and procedures for decommissioning, and GOVERN 2.2 includes retention, archiving, and retrieval of information released by a decommissioned system. That scope is wider than deleting an application object.

Current issue reports expose the boundary. A WSO2 Agent Manager issue reports that deleting an agent left its credential valid and reusable. A Julep issue asks for agent deletion to remove associated sessions. An OpenClaw report says sessions for a deleted agent remained accessible and executable, including one privileged session. Each report concerns one implementation. Together they show why teardown verification must cover execution residue separately from the parent record.

Model retirement as seven ordered phases:

  1. Inventory the complete residue set.
  2. Freeze every admission path.
  3. Drain, cancel, transfer, compensate, or quarantine active work.
  4. Disable triggers, callbacks, and delegated execution.
  5. Revoke credentials, grants, roles, and policy authority.
  6. Delete or retain data and infrastructure by policy, then write a tombstone.
  7. Run negative probes and issue a teardown receipt.

Each phase writes durable evidence. A retry resumes the first incomplete phase. The public product status remains decommissioning until every required check passes.

Build one residue manifest

Start with a manifest that joins resources across ownership boundaries. The active CoSAI/OASIS lifecycle proposal is useful as a discovery checklist. It names identities, delegated agents, tools, connectors, credentials, sessions, schedules, webhooks, callbacks, data stores, memory, embeddings, traces, cleanup retries, tombstones, and a signed decommission receipt. The issue is a proposal; no adopted standard exists yet.

A practical manifest needs an owner, a required disposition, and a negative test for each item:

Resource classExamplesRequired dispositionNegative proof
Admission pathsUI, API, scheduler, webhook, event bus, retry queueDisable and reject new startsEvery path returns terminal denial
Active workRuns, approvals, child tasks, browser sessionsDrain, cancel, transfer, compensate, or quarantineNo runnable item lacks a final disposition
AuthorityOAuth grants, API keys, roles, service accounts, capabilitiesRevoke or expireOld credentials fail at the enforcement point
Runtime residueWorkers, sandboxes, leases, queues, locks, callbacksTerminate, release, purge, or fenceStale workers and callbacks cannot mutate state
Product dataCheckpoints, memory, artifacts, embeddings, cachesDelete, anonymize, archive, or retain by policyInventory matches the approved retention plan
EvidenceTraces, receipts, approvals, audit eventsPreserve the minimum required recordAuthorized retrieval works; ordinary execution does not

Store one structured record per resource. Free-form notes are too loose for reconciliation. This schema is an implementation example:

{
  "decommission_id": "dc_2026_08_support_agent",
  "agent_id": "support-agent-v4",
  "requested_by": "platform-change-1842",
  "state": "draining",
  "admission_epoch": 19,
  "resources": [
    {
      "type": "schedule",
      "resource_id": "nightly-escalation-scan",
      "owner": "scheduler-service",
      "disposition": "disabled",
      "receipt": "scheduler-change-9821",
      "negative_probe": "fire-rejected"
    },
    {
      "type": "oauth-grant",
      "resource_id": "crm-grant-44",
      "owner": "credential-broker",
      "disposition": "pending-revocation",
      "receipt": null,
      "negative_probe": null
    }
  ],
  "required_checks": [
    "new-run-denied",
    "stale-session-denied",
    "old-token-denied",
    "callback-denied",
    "queue-empty-or-quarantined"
  ]
}

The manifest is complete only when discovery queries agree. Join the product database to the workflow engine, scheduler, queue, identity provider, credential broker, tool registry, memory store, artifact store, and trace index. Search both by agent ID and by related principals, releases, tenants, callbacks, and resource tags. Treat missing ownership as a blocker.

Decommission an AI agent in seven phases

1. Inventory before changing state

Snapshot active runs, pending approvals, delegated children, queued events, schedules, callback endpoints, open sessions, credentials, grants, memory namespaces, files, traces, and external tool resources. Record counts and stable IDs before revocation makes some systems harder to query.

The Cloud Security Alliance research note released in August 2026 reports that many surveyed organizations could not produce a complete agent registry and that dormant agents may retain valid credentials. A retirement process cannot remove resources it cannot enumerate.

Do not trust a single control-plane list. Reconcile the declared registry with observed workload identities, recent authentication, queue producers, scheduled invocations, callback traffic, and tool audit logs. Differences become manifest items with owners.

2. Freeze every admission path

Move the agent to decommissioning and increment an admission epoch. Require the current epoch at every start boundary: user API, event gateway, scheduler, retry worker, callback handler, delegated-agent launcher, and administrative resume endpoint. Reject new work before draining existing work.

Disabling the main API route is insufficient. A stale queue message or scheduler worker may already hold a valid payload. Admission checks belong at execution time, close to the mutation boundary, not only when work is first requested.

Keep read-only inspection available to operators. They need to investigate runs and receipts without reopening execution.

3. Give every active run a disposition

Do not apply one blanket action to all work. Classify each active run:

  • Drain: allow a safe, bounded run to finish before the deadline.
  • Cancel: stop work that has not crossed an external commit boundary.
  • Compensate: reverse a known completed effect through the product's normal compensation path.
  • Transfer: move approved work to a successor agent or human owner with a new authorization decision.
  • Quarantine: isolate a run when the outcome of an external call is unknown.

For a billing-support agent, a read-only nightly report may drain. An unresolved refund tool call should enter quarantine until the payment system confirms whether it committed. A pending approval should not silently transfer to a replacement agent because the approved actor, policy, or action version may have changed.

Set a deadline and escalation owner for every nonterminal run. If the deadline expires, the decommission coordinator stops progressing and reports the exact unresolved items.

4. Disable triggers before revoking credentials

Remove schedules, event subscriptions, webhook routes, callback destinations, polling leases, retry producers, and delegated-child launch rights. This order reduces noise and prevents a disabled trigger from repeatedly attempting work with a revoked credential.

Then fence queued and in-flight trigger payloads with the new admission epoch. Purge only when the payload has no required evidence. Otherwise move it to a non-executable quarantine store with its original causation and tenant metadata.

Verify external systems too. A vendor webhook subscription or SaaS-side schedule may not appear in your product database. The residue manifest should name the API call, console action, or support process used to disable it.

5. Revoke authority at the enforcement point

Revoke OAuth grants, refresh tokens, access tokens where supported, API keys, service-account roles, delegated capabilities, browser sessions, and cached authorization decisions. RFC 7009 defines OAuth token revocation and notes that revoking a token may also revoke related tokens and the underlying grant. It also warns that propagation delay can exist. Verification must test the credential after a successful revocation request.

Test the old authority where it is enforced. Call the tool gateway with the retired run identity. Attempt token refresh. Attempt a tool action from an old browser or workflow session. Confirm denial is caused by revoked authority or terminal agent state, not by a temporary network failure.

If an external system cannot revoke a long-lived credential, deny it at a broker, gateway, network policy, or destination allowlist while replacing or rotating the shared credential. Record the compensating control and its owner in the teardown receipt.

6. Dispose of state and write a tombstone

Apply explicit policy to checkpoints, sessions, memory, embeddings, artifacts, caches, uploaded files, generated files, traces, approvals, tool receipts, and audit events. "Delete all data" is usually too vague. Some records must be retained for security, contractual, or regulatory evidence, while derived memory and cached content may need prompt deletion.

Separate retained evidence from runnable state. An audit record should remain queryable by authorized responders without carrying a resumable checkpoint, live credential, writable callback, or tool capability.

Write a minimal tombstone containing the agent ID, terminal state, decommission ID, completion time, policy version, retained-evidence locations, and teardown-receipt hash. Reject recreation of the same identity unless an explicit new lifecycle creates a new principal and release.

7. Prove the agent cannot return

Run negative tests through every former execution path. A useful test suite attempts to:

  1. Start a new user-initiated run.
  2. Fire each old schedule and event subscription.
  3. Resume an old workflow or browser session.
  4. Refresh and use each revoked credential class.
  5. Deliver an old webhook or callback.
  6. Launch a delegated child with the retired parent identity.
  7. Consume a stale queue message.
  8. Read or mutate deleted memory and artifacts.
  9. Execute from a stale worker using the previous admission epoch.

Require terminal denials with stable reason codes such as agent_decommissioned, authority_revoked, or stale_admission_epoch. Count only those terminal denials as proof. A timeout, DNS error, or empty response may hide a temporary outage while the authority remains valid.

Repeat delayed probes after the longest credential-cache, queue-visibility, callback-retry, and session-expiry windows. Issue the teardown receipt only after immediate and delayed checks pass.

Handle partial teardown without lying

Decommissioning crosses systems that fail independently. Make each phase idempotent and record both attempts and confirmed outcomes. If token revocation succeeds but an external schedule cannot be disabled, the coordinator retries the schedule step without creating a new identity or losing the earlier receipt.

Use four terminal resource results:

  • verified_removed
  • verified_revoked
  • verified_retained_non_executable
  • blocked_with_owner

The overall agent cannot become decommissioned while any required item is blocked_with_owner. Keep it in decommissioning_failed, deny all admission, and alert the named operator with the resource ID and recovery action.

Protect against deletion races. A worker may create a child task after the inventory snapshot but before the freeze reaches it. The admission epoch closes that race by making all post-freeze starts fail. Run discovery again after draining, and compare the second manifest to the first. New resources indicate a missed path or a worker that ignored terminal state.

Do not reuse an old credential merely because the agent will be replaced. Create a distinct successor principal, authorize it from current policy, and transfer only the work and data approved for the new lifecycle. Retirement and replacement are separate transactions.

Verify the teardown receipt

A teardown receipt should let another engineer reproduce the conclusion. Include:

  • the final residue manifest and its discovery sources;
  • the requested and actual disposition for every resource;
  • revocation and deletion receipts from owning systems;
  • unresolved exceptions and their approved compensating controls;
  • immediate and delayed negative-probe results;
  • retention-policy and legal-hold decisions;
  • the tombstone ID, policy version, timestamps, and approving identities.

Have an independent verifier query the authoritative systems instead of accepting a success flag from the deletion code. The expected result is no executable resource without a terminal disposition and no former execution path that accepts the retired identity.

Present old credentials, sessions, callbacks, queue messages, and worker epochs to their real enforcement points. Every attempt must fail for a durable policy reason.

Run one retirement rehearsal now

Choose a noncritical agent in staging and build its residue manifest before deleting anything. Use this AI agent decommissioning rehearsal to freeze admissions, assign each active item a disposition, revoke one test grant through its real provider, dispose of test sessions and memory, then run the full negative suite twice. Do not mark the rehearsal complete until another engineer can verify the teardown receipt from authoritative systems.

References

Be first in line.

Join the waitlist and we'll email you the moment it's ready. No sales call.

Try the demo →
or talk to us