Ghost Agents in the Server Room: The Access You Forgot to Revoke

When a senior engineer resigns, most American enterprises follow a familiar ritual. HR schedules the exit interview. IT disables single sign-on. Security collects the laptop, kills the VPN certificate, and forwards the email alias. Within hours, the departed employee is a ghost in the directory — present only in payroll history.

But somewhere in a cloud account, a script the engineer wrote eighteen months ago is still awake. It queries a customer database every morning. It drafts procurement recommendations. It holds a service token that grants it the same privileges its creator once had. Nobody has looked at it in weeks, because nobody was assigned to look.

Security researchers have started calling these systems orphaned agents, and they represent one of the most undermanaged risk categories in the enterprise AI stack. Unlike a forgotten SaaS license, an agent does not sit idle. It acts — with credentials, context, and often autonomy that outlived its owner's employment by design or by accident.

The Inheritance Nobody Documented

The core of the problem is architectural. Agents built on modern AI platforms frequently authenticate through service accounts rather than individual logins, precisely so they can run unattended. That is the point of automation. But it also means that when the builder departs, standard offboarding does nothing. There is no checkbox in Workday that maps to "revoke the agentic workflow in account 4471."

The result is a growing population of software that operates with inherited authority. A departed data scientist's forecasting agent may still trigger inventory reorders. A former IT administrator's remediation bot may still restart production services. In the worst cases, these agents hold write access to systems their successors do not even know exist — undocumented, unowned, and unmonitored.

The compliance exposure is not theoretical. Under frameworks like SOX, HIPAA, and the growing patchwork of state privacy statutes, an organization is generally accountable for what its systems do with data, regardless of who built them. An agent that retains access to protected health information after its creator's departure is a finding waiting for an auditor.

Why Traditional Offboarding Misses It

The gap exists because enterprises treat identity as the unit of access, when agents increasingly operate as delegated identity. A human leaves; their human credentials die. But the agent's credentials were never the human's — they were issued separately, often with broader scope and longer lifetimes than any personal account would tolerate.

There is also an ownership problem. In many organizations, the person who builds an agent is its de facto operator. No formal handoff occurs because no formal handoff process exists. When that person resigns, the agent becomes software without a sponsor — technically alive, organizationally abandoned.

Finally, discovery is harder than it sounds. Agents proliferate across platforms: internal automation tools, vendor-provided copilots, custom LLM pipelines stitched together with API keys. Unlike endpoints, they do not all report to a single console. Many security teams, asked to produce an inventory of active agents, would struggle to get past fifty percent coverage.

A Decommissioning Discipline Worth Building

The fix is procedural, not technological, though tooling helps. Progressive organizations are beginning to treat agent lifecycle management as an extension of offboarding. A practical audit sequence looks like this:

• Inventory before departure. Require every agent built on company infrastructure to be registered in a central catalog, with a named owner and a business purpose. Unregistered agents should be treated like unpatched servers.
• Trigger the review at notice, not at exit. The moment an employee gives notice, their registered agents should surface for review: reassign, retire, or formally retain with a new owner.
• Rotate what the agent knows. Service tokens, API keys, and embedded credentials should be rotated as a matter of course — not only when someone remembers.
• Log the decision. A decommissioned agent should have a paper trail: what it did, what access it held, when and why it was retired. This is the artifact auditors will ask for.
• Assign successor accountability. For agents that survive, the new owner inherits not just the code but the obligation to understand it. An agent nobody can explain should not be running.

From Cleanup to Culture

Some enterprises will read this as an IT hygiene issue and delegate it to a quarterly access review. That underestimates the shift underway. As agentic systems take on operational responsibility — approving invoices, triaging tickets, drafting customer communications — the question of who owns them becomes an organizational design question, not a scripting one.

The companies that get ahead of this will treat every agent like a departing employee treats their badge: something that must be accounted for, returned, and retired on the record. The ones that do not will discover their ghost agents the way organizations usually discover unmanaged risk — after it has already acted.

The departed CTO's agent does not know it works for a company that no longer employs its creator. It will keep running until someone decides it should not. That decision is overdue.