The agent nobody decommissioned.

Why the dormant agent became a liability

The adoption curve of 2026 had a quiet asymmetry built into it. Standing up an agent went from a project to a menu click: pick a task, wire a few tools, grant it the credentials it needs, and it is in production by the afternoon. Aging one out never got the same treatment. There is no menu click for retirement, no default gate that revokes what the agent held, no owner reminded that the thing they created three quarters ago is still running. So the fleet grows in one direction only — easy to add, hard to remove — and the organisation that celebrates "we have two hundred agents in production" discovers, in the first real audit, that a large share of them are orphaned and still hold access to systems that matter.

The reason this is a liability rather than an untidiness is what a dormant agent keeps. When a team stops using an agent, the interface may go quiet, but the agent's attachments do not. It retains the API key that was minted for it, the OAuth token sitting in a cache, the memory and embeddings it accumulated, and every integration it was wired into. None of that is revoked by the act of ignoring it. The dormant agent is therefore a live identity with standing privilege that no human is watching — the exact profile a compromise wants, and the exact thing a least-privilege review is supposed to catch, except that a review can only act on agents it knows exist.

That last clause is the whole problem. The governance most organisations wrote in 2026 assumes you can enumerate what you are governing. Agent sprawl breaks the assumption: agents proliferate without a unified strategy, spun up by different teams for different tasks, and no central record ties them together. You cannot revoke, review, or right-size the access of a fleet you cannot list — and the agent nobody registered is, by construction, the agent nobody will decommission.

This is lifecycle, not identity and not observability

Three disciplines get folded together whenever "agent risk" comes up, and collapsing them is the fastest way to buy one control and believe the whole problem is handled. Each answers a genuinely different question, and only one of them is about whether every agent has an owner, a review date, and a way to be turned off for good.

Treating machine identity as a breach vector — the ratio of non-human to human identities, the sprawl of service accounts, keys and tokens that has become the fastest-growing attack surface — is a security problem. Watching an agent execute — tracing its steps, inputs and context while it runs so you can reconstruct a decision — is an observability problem. Both are necessary, and both are adjacent to the question this piece is about. Agent lifecycle governance sits across the whole life of the agent, not just its credential or its runtime: does every agent in the fleet have a named owner, a review date, a mapped set of privileges, and a decommissioning gate that revokes all of it at once when the agent is retired? Identity security tells you the credential is a risk. Observability tells you what the agent did. Neither one retires the agent or proves it was retired cleanly.

Read the rows together and the design consequence is clear: an organisation can have strong secrets hygiene and rich runtime tracing and still accumulate a fleet of orphaned agents. Those two capabilities secure the credential and observe the action; neither one owns the agent across its life or forces the question of when it should stop existing. That question lives in a registry and a lifecycle process, and a team that built the first two rows and left the third blank has secured and instrumented agents it can no longer count.

The framework that is forming

What is emerging is not a single tool but a small set of moves that together turn "we have a lot of agents" from an unbounded governance debt into a fleet you can actually manage. None of them is exotic; each is the agentic-era version of a discipline that IT asset management, joiner-mover-leaver and least-privilege review already established for people and machines.

A central registry, because you cannot govern what you have not inventoried

The foundational move is an authoritative record of every agent that exists — what it does, which systems it touches, which credentials it holds, when it was created, and whether it is still meant to be running. Without it, every downstream control is theatre: you cannot review access you cannot list, revoke privilege you cannot see, or detect an orphan you never registered. The registry is the agentic counterpart to the asset inventory that every mature security programme already treats as prerequisite — the difference is that agents are created faster and by more people than any prior class of asset, so the inventory has to be a by-product of creation, not a spreadsheet someone updates quarterly.

A named owner and a review date on every agent

Every agent needs a human sponsor and a date by which someone must confirm it is still needed. An agent without an owner is an agent no one will ever retire, because retirement requires a decision and a decision requires a decider. The review date turns the default from "runs forever" into "runs until reaffirmed" — the same joiner-mover-leaver discipline that governs employee access, applied to the agent. This is where lifecycle governance meets proportional agent governance: the owner and review cadence should scale with the authority the agent actually holds, so a read-only summariser is reviewed lightly and an agent that can write to a system of record is reviewed hard.

A decommissioning gate that revokes credential, memory, embedding and integration at once

Retirement has to be a single, complete operation, not a UI toggle. When an agent is aged out, the gate revokes the API key, invalidates the cached tokens, purges or archives the memory and embeddings, and disconnects every integration — in one action, so nothing is left live. The failure mode this prevents is the most common one in the wild: an agent "removed" from a dashboard while its credentials and its wiring keep working in the background. A clean decommissioning gate is also what lets you prove retirement — a signed record that this agent's access was fully revoked on this date, which is exactly the kind of versioned trail that makes an autonomous system defensible to an auditor asking what happened to the two hundred agents you no longer run.

Orphan detection and an agent-to-privilege-to-data map

The last move is continuous: detect the dormant agent with live privilege before an audit does, and maintain a mapping from each agent to the privileges it holds to the data those privileges reach, so a periodic least-privilege review has something concrete to act on. The map is what turns "we should review access" from an aspiration into a task with a target — this agent, these scopes, this data, last used ninety days ago, owner unresponsive — and it is what makes the whole programme legible to the governance evidence an auditor asks for rather than a claim that access is under control.

The old question was "how many agents can we ship?" The new one is "can we name the owner, the review date, and the retirement of every agent we already shipped?" — a registry so the fleet is visible, a sponsor and a review cadence so nothing runs unaccountable, a decommissioning gate that revokes everything at once, and an orphan map that finds the dormant privilege before an attacker or an auditor does.

Four ways it goes wrong

The failures here are predictable, and they cluster into four shapes. Each one lets an organisation grow its agent fleet while believing it is governed, and each surfaces at the worst possible time — the security review, the incident, or the audit that asks for a list nobody kept.

1. Creating an agent with no owner and no review date

The most common failure is at birth: an agent is spun up for a task, wired into systems, granted credentials, and shipped — with no human named as responsible and no date on which anyone will ask whether it is still needed. It runs indefinitely by default, because nothing in its creation obliged it to justify its continued existence. The fix is to make owner and review date mandatory fields of creation, so an agent cannot enter production unaccountable, and "runs forever" stops being the path of least resistance.

2. "Retiring" the agent from the interface while its credentials stay live

The second failure is the false decommission: someone removes the agent from a dashboard or disables its trigger and calls it retired, while the API key it was issued, the token in the cache, and the integrations it was wired into all keep working. The agent is gone from view and present in the system — the definition of a dormant identity with live privilege. The fix is the decommissioning gate that revokes everything in one operation, so that "retired" means the access is actually dead, not merely hidden.

3. No registry, so the fleet is invisible

The third failure is structural: agents are created across teams and tools with no central record, so no one can say how many exist, what they touch, or which are still in use. Every governance control that assumes an inventory — access review, least-privilege, revocation — has nothing to operate on, and the first honest count happens during an audit. The fix is the registry as a by-product of creation, so the inventory is always current and the fleet is never a surprise.

4. Treating the agent as a one-off project with no retirement plan

The fourth failure is conceptual: the agent is scoped, built and launched as a project, and the project ends — but the agent keeps running, now detached from the team, the context and the intent that created it. Nobody planned for its end because nobody thought of it as having one. The fix is to treat every agent as having a lifecycle with a defined retirement, so that decommissioning is a planned phase rather than an event that never comes.

The trade-off, stated honestly

The honest version names the tension, because it is real: the ease of creating agents and the discipline of governing them pull against each other. Every gate you add to creation — a required owner, a review date, a registration step, a decommissioning process — slows the moment that made agents attractive in the first place. A team that could ship an agent in an afternoon now has to name who owns it and when it will be reviewed, and that friction is not free; it is the cost of not accumulating an ungovernable fleet. An organisation that promises frictionless agent creation with full governance and no overhead is describing a state that does not exist.

What you buy for that cost is a fleet you can actually stand behind: a list you can produce on demand, an owner for every agent, a clean retirement you can prove, and no dormant privilege waiting to be found. The friction is worth it precisely where agents hold real authority — access to systems of record, the ability to act with a side effect, reach into sensitive data — because that is where an orphaned agent is a genuine exposure rather than a tidiness problem. It is over-engineering only for a throwaway agent that touches nothing consequential and is torn down the same week. The tell that an organisation understands the trade is that it can answer three questions about any agent instantly: who owns it, when it is next reviewed, and what happens to its access the day it is retired — rather than celebrating a headcount of agents it has never counted.

What this looks like for document AI specifically

Document AI is where the abstract exposure gets concrete fast, because an extraction agent holds exactly the attachments that make a dormant identity dangerous: credentials to the systems it files into, memory of the documents it has seen, embeddings of sensitive content, and integrations with the pipelines that pay, report, or decide on what it read. Four things change when a document platform is built for the whole agent lifecycle rather than just the launch.

Every extraction agent is registered at creation, not rediscovered at audit. The moment an agent is created to process a document type, it enters the registry with its owner, its scope, the systems it touches and its review date — so the fleet processing invoices, contracts and claims is always a list you can produce, never a count you have to reconstruct after the fact.

Retirement revokes the agent's reach into documents and systems in one gate. When a document workflow is retired, the agent behind it is decommissioned completely: its access to the source repository, its cached tokens, its embeddings of the documents it processed, and its write path into the system of record are all revoked together, leaving no dormant route into sensitive content.

Access maps to data, so least-privilege review has a target. Each agent's privileges are mapped to the documents and systems they actually reach, so a periodic review can see that a still-running extraction agent has access to a repository it has not touched in months — the same signed, replayable record that makes the pipeline defensible also makes its access reviewable.

The dormant agent is surfaced before it becomes an incident. Orphan detection flags the extraction agent whose owner has moved on and whose workflow went quiet but whose credentials are still live, and routes it for review or retirement — mapping cleanly to the governance evidence an auditor asks for rather than a claim that the fleet is under control.

Closing thought

The agent that is easy to create and hard to retire is not a temporary artefact of early adoption — it is the default outcome of tooling that optimised for shipping and never built for stopping. That is how an organisation ends up proud of two hundred agents in production and unable to say, in an audit, which of them are still owned, still needed, or still holding access to a system that matters. The dormant agent with live privilege is not a rare edge case; it is what the missing half of the lifecycle produces, reliably, at scale.

At Cogneris we build the agent to be retired as deliberately as it is deployed: registered at creation with a named owner and a review date, mapped from privilege to data so its access stays reviewable, and torn down through a decommissioning gate that revokes credential, memory, embedding and integration in a single, provable operation — because an agent that acts on a document is a governance object for its whole life, not just the day it ships. The registry makes the fleet visible, the owner and review date keep it accountable, and the decommissioning gate makes retirement something you can prove rather than something you assume. If you are working out how to move from "we have a lot of agents" to a fleet you can name, review and retire, and want to map which of your agents still hold access they no longer use, see our product page, read the security page, or talk to our team. We would rather inventory the fleet — who owns each agent, when it is reviewed, what its retirement revokes — in the first conversation than watch a dormant agent surface as the finding in someone else's audit.