Decommissioning and Retirement
Retiring an agent so that nothing it held, wrote, or was trusted by outlives it.
Objective
Retire an agent so that nothing it held, wrote, or was trusted by outlives it.
Minimum bar (L2). Every agent has stated decommission criteria recorded at registration, and retirement is an executed procedure with a named owner and a completion record—not a disabled flag on a principal that still exists.
16.1 Controls #
| ID | Control | Minimum bar (L2) | Enforced state (L3) |
|---|---|---|---|
| RET-1 | Retirement trigger and owner | Decommission criteria recorded at registration—project closure, owner departure, replacement by a successor, or a defined inactivity threshold—with a named owner accountable for executing them, reviewed on the registry cadence. | Triggers evaluated automatically against registry and activity data, opening a retirement workflow without waiting for someone to notice the agent has gone idle. |
| RET-2 | Credential and identity teardown | Every credential issued to the agent is revoked and its principal deleted rather than disabled, with revocation confirmed against the issuing systems rather than assumed. Federated and delegated grants are enumerated and withdrawn. | Teardown executed automatically from the retirement workflow, with post-teardown verification that no token issued to the principal remains valid anywhere in the estate. |
| RET-3 | Data, memory, and context disposal | Memory stores, vector indexes, cached context, and transcripts belonging to the agent are inventoried and dispositioned against retention policy—deleted, archived, or transferred to a named successor owner. Regulated data classes are handled explicitly rather than by default. | Disposal executed and evidenced as part of the retirement workflow, with verified deletion or cryptographic erasure where data classification requires it. |
| RET-4 | Integration and dependency withdrawal | MCP servers, tool registrations, webhooks, service connections, and inbound trust relationships created for the agent are deregistered. Agents and systems that depended on it are identified before shutdown rather than discovered by their failure. | A continuously maintained dependency graph, so the blast radius of a retirement is known in advance and orphaned integrations are detected automatically. |
| RET-5 | Evidentiary retention past shutdown | Action logs, authorization decision records, and registry history are retained beyond the agent’s life for a period exceeding the expected detection window, and remain queryable after the agent and its runtime are gone. | Retention enforced by policy on an immutable store independent of the agent’s platform, so a retired agent’s history survives the decommissioning of that platform too. |
16.2 Evidence to Request #
- A completed retirement record for a recently decommissioned agent, showing credential revocation confirmations, data disposition, and deregistered integrations.
- The count of registered agents inactive beyond their stated threshold but not yet retired—the gap between those two numbers is the real measure of this domain.
16.3 Failure Modes #
- Agents disabled rather than deleted, leaving principals and credentials that survive every subsequent access review as “inactive but present.”
- Memory and vector stores outliving the agent that populated them, becoming ungoverned data with no owner and no retention clock.
- Retirement treated as a platform action, so an agent removed from the orchestrator keeps its cloud role, its MCP registrations, and its inbound webhooks.
- Logs retained on the agent’s own platform, so decommissioning that platform destroys the evidence of what the agent did.