A dark data center at night, most racks powered down but a few forgotten terminals still glowing with active sessions — abandoned AI agents that were never turned off

Most of the conversation about why AI governance is failing focuses on the beginning of the lifecycle: approvals, principles, review boards. A sharp CIO analysis by Stephanie Overby names something the front-of-lifecycle framing keeps missing. Governance also fails at the end — and that failure is quieter, more dangerous, and almost entirely unmeasured.

The finding that should keep security leaders up at night is this: in Cloud Security Alliance research, only 21% of organizations have a formal process for decommissioning AI agents. The other four-fifths stand up autonomous software with real credentials and standing access to real systems, and then never systematically turn any of it off. The agents do not disappear when the project ends, the champion leaves, or the pilot is quietly abandoned. They keep their keys.

The one-line version

Every AI agent you deploy is a credential with a heartbeat. If you have no process to stop the heartbeat, you are not governing a fleet of agents — you are accumulating a graveyard of them, and every grave is still logged in.

The shape of the blind spot

Put the survey numbers next to each other and the pattern is hard to unsee. In the same body of research, 82% of organizations discovered shadow AI agents they did not know were running, and 65% had already experienced an AI agent-related incident. EY's data rhymes: 78% of technology leaders say adoption is outpacing their ability to audit and monitor, and 52% report department-level AI initiatives operating without formal approval. Confidence, meanwhile, stays high — which is exactly the problem. As CSA's Hillary Baron put it, organizations have strong visibility into known agents, and that "quietly becomes belief nothing else exists."

A zombie agent is what you get when creation has a process and retirement does not. It was provisioned properly. It was given a service account, an API token, a set of tool permissions, maybe access to a database or an internal system. Then its reason for existing went away and nothing reclaimed any of that. It is still authenticated. It may still be running on a schedule. Its credentials are still valid. And because nobody is looking at it, it is the perfect place for an attacker to hide — a legitimate identity with standing access that raises no alarms because it was supposed to be there.

Why decommissioning is uniquely hard for agents

Traditional IT has offboarding. When an employee leaves, HR triggers a workflow that revokes their accounts. When a server is retired, it is wiped and pulled. Agents fit neither pattern cleanly, and that is why the process quietly never gets built.

The compounding math

Standing access is a liability that accrues interest. Every agent you cannot cleanly retire widens the attack surface a little more, permanently. A governance program that only measures deployment is measuring the rate at which its own liability grows.

The fix is not another policy. It's a revocable, evidenced lifecycle.

You cannot decommission your way out of this with a document that says "agents must be decommissioned." The CIO piece is right that the gap is enforcement, not paperwork. Three things have to be true at the mechanism level, not the policy level.

Authority has to be bound to the agent's actions, not to a long-lived credential it carries around. If an agent's ability to act comes from a standing API key, revoking it means hunting down that key everywhere it was copied. If instead every consequential action is authorized in the moment against a policy — and denied by default when the agent is no longer sanctioned — retirement becomes a policy change, not a credential hunt. The off-switch lives in one place.

Every action has to leave evidence. You cannot retire what you cannot see, and you cannot investigate a zombie's activity from logs it wrote itself. A tamper-evident record of what each agent was permitted to do, and when, is what turns "we think that agent is idle" into "here is exactly what it did last, and under what authority."

There has to be a real kill path. The ability to stop an agent — and to prove it was stopped — has to be a first-class operation, not a scramble. This is why the market is suddenly funding agent registries and kill switches; the demand is real. But a kill switch on discovery alone stops the agents you found. The 82% problem is the agents you did not.

This is the half of the lifecycle EVE was built to govern. EVE CoreGuard evaluates each proposed AI action against a versioned policy before it executes, so an agent's authority is a live decision rather than a credential it holds — withdraw the sanction and the next action is denied, by default, everywhere. And every decision emits a signed record you can verify independently, so the account of what an agent did does not depend on trusting logs the agent could have touched. Retirement stops being a credential archaeology project and becomes a governed, provable event.

The takeaway

AI governance is failing at both ends of the lifecycle, but the front end gets all the attention because it is where the meetings are. The back end — the agents nobody turned off, still holding live credentials, still logged into systems whose owners have moved on — is where the incidents actually come from. Only 21% of organizations can cleanly retire an agent today. The other 79% are not running a fleet. They are running a fleet plus a graveyard, and the graveyard still has the keys.

Count your agents. Then ask the harder question: how many of them could you turn off this afternoon, completely, and prove it? That number is your real governance posture.

Frequently Asked Questions

What is a "zombie" AI agent?
A zombie AI agent is an autonomous agent that was provisioned with real credentials and access but never decommissioned after its purpose ended. It remains authenticated and may still run, holding standing access to systems whose owners have moved on. Because it was legitimately created, it raises no alarms — which makes it both a compliance gap and an attractive place for an attacker to operate under a trusted identity. Cloud Security Alliance research found only about 21% of organizations have a formal agent decommissioning process.
Why is decommissioning AI agents so hard?
Agents fit neither the employee-offboarding nor the server-retirement model. Nothing automatically fires when an agent's purpose ends, its access is spread across multiple service accounts, API keys, and tool scopes, and it appears as infrastructure rather than a user, so identity access reviews miss it. Teams also hesitate to turn off an un-owned agent with unclear dependencies. The result is standing access that accumulates permanently.
How do you actually turn an AI agent off?
Cleanly retiring an agent requires three mechanism-level properties: authority bound to each action rather than to long-lived credentials the agent carries; a tamper-evident record of what the agent was permitted to do; and a real kill path that can stop the agent and prove it was stopped. When authorization is a live per-action decision, retirement becomes a single policy change that denies the agent's next action everywhere, rather than a hunt for every copied credential.
Isn't an agent registry or kill switch enough?
Discovery, registries, and kill switches are necessary and the reason the category is being funded, but they act on the agents you have found. Research shows 82% of organizations discovered shadow agents they did not know about — so a kill switch over a partial inventory leaves the most dangerous agents untouched. Pairing discovery with per-action authorization and signed evidence closes the gap for both known and unknown agents, because unsanctioned actions are denied by default regardless of whether the agent is in a registry.

Statistics are attributed to their published sources (Cloud Security Alliance research and EY, as cited in the referenced CIO analysis) and reflect those sources as of July 2026; verify current specifics with each publisher. This is independent analysis, not affiliated with or endorsed by CIO, CSA, EY, or any vendor named. EVE CoreGuard capabilities described here are verified from the EVE AI Core production system.