Introduction
Retiring an agent is the step nobody plans for, and the one that quietly breaks a governance programme — because the evidence you need after an agent is gone is the evidence you stopped collecting when you deleted it.
Three ways to stop governing something
Action | Record | History | Reversible |
Leave it registered | Stays | Kept | N/A |
Exclude it (discovered assets) | Stays, marked | Kept | Yes — toggle it back |
Delete it | Kept, marked disabled | Kept | A discovered agent reappears as |
Note: The default answer is "leave it registered". A decommissioned agent stops sending traces, drops to zero activity and costs nothing. It sits in the registry as a record of something you used to run — which is exactly what an auditor asking about last year wants, and exactly what deleting removes.
Delete and the Register toggle do the same thing underneath.
What survives a deletion, and what does not
This is the question to answer before deleting anything, and the answer is not uniform:
Incidents persist. They are their own records, referencing the control and the policy that raised them. They are the durable evidence.
Traces were already expiring. Telemetry ages out of retention after thirty days regardless, so deletion is rarely what loses you a trace.
The record stays, marked disabled. Name, owner, department, description, platform and registration date are kept, so incidents stay interpretable.
The real cost is for manual agents. A discovered agent can be registered again from its connection; a manually registered agent cannot be restored from the UI.
Offboarding properly
Stop the agent sending first — Remove the instrumentation or decommission the service. Do this before anything in the registry, or new traces keep arriving against a record you are trying to retire.
Record why it was retired, in the description — The description field outlives everyone's memory. "Replaced by X, Aug 2026" is worth more than the name of the agent.
Reassign or close its open incidents — An open incident on a retired agent will never be triaged by its owner — they have moved on. Close them with a note explaining the agent is gone.
Remove it from policies, or leave it — A retired agent covered by a policy costs nothing. Removing it makes coverage reports honest; leaving it is harmless. Removing is tidier.
Note who the owner is — Whoever is named remains the person an auditor asks. Owner cannot be changed on the agent, so record any handover in your own procedures.
Leave the record in place — Unless you have a positive reason to delete, stop here.
When deleting is actually right
Situation | Delete? |
A duplicate record for the same agent | Yes — deleting one disables it and keeps its history. A discovered agent found on two connections is one record, not a duplicate |
Registered by mistake, never sent a trace | Yes — nothing to lose |
A test record from an evaluation | Yes, if it never carried real traffic |
A real agent that has been decommissioned | No — this is the case for leaving it |
Tidying the registry | No. A long registry is not a problem; an unexplainable incident is |
"You are not keeping the record for the agent. You are keeping it for the incidents that point at it."
Who can delete
The Delete row action appears only for users holding delete permission on that specific record, so the option being absent is a permissions answer rather than a missing feature. See Access & Permissions.
The offboarding nobody schedules: people
Agents outlive the people who own them, and nothing in the product reassigns ownership when someone leaves. An agent owned by a departed colleague is still fully governed and has nobody to escalate to — which only becomes visible when an incident needs triaging.
The fix is procedural rather than technical: put "review owned agents" into your standard people-offboarding checklist, alongside accounts and access — owner cannot be changed on an agent, so record handovers outside the product. Filtering the registry by owner is the fastest way to produce the list.