Zombie AI Agents: What They Are, How They Happen, and How to Stop Them

A zombie AI agent is an AI system that’s still active, still calling tools, still touching real systems, but no longer under anyone’s real control: because an attacker planted instructions in its memory, because it drifted into unsafe behavior on its own, because its owner left and nobody shut it down, or because it’s stuck looping without making progress. It’s not one failure mode. It’s four, and they get grouped under one name because organizationally they produce the same symptom: nobody can say what the agent is doing right now, or stop it cleanly if the answer is something it shouldn’t be.

That’s not hypothetical. Somewhere in a large organization, an agent may already be running that nobody has checked on this week, maybe not this quarter. Security researchers and enterprise AI teams have started calling this pattern a zombie AI agent, and the term is spreading fast because it names something enterprises are already living with, not something theoretical.

What Are Zombie AI Agents?

Zombie AI agents are AI agents that continue acting, making decisions, or consuming resources after losing the intended oversight, purpose, or control needed to manage them safely. 

The metaphor covers four overlapping situations: an agent that has been persistently manipulated through memory or prompt injection, an agent that has drifted into unsafe behavior on its own as it self-improves, an agent that keeps running after its original owner, project, or purpose disappeared, and an agent stuck in an execution loop that burns tokens and compute without making progress. Technically these look nothing alike: one has an attacker, one doesn’t, one has no owner, one has no problem except that it never stops. Organizationally, they’re the same problem: the agent is still acting, and the systems around it no longer have enough visibility or control to say why, or to make it stop.

That’s the thread worth following, because each type has now been documented in real research, not just described anecdotally.

How Do AI Agents Become Zombies?

AI agents can become zombies in several different ways, but the underlying failure is the same: the agent keeps operating after meaningful control has been lost. That can happen because an attacker compromises its memory, because a self-evolving agent drifts into unsafe behavior, because an agent is left running without an owner, or because it gets trapped in a loop without making meaningful progress. These four paths look different technically, but they all create the same organizational problem: an agent that is still active, but no longer effectively governed.

Before going through each one, it’s worth being precise about the vocabulary, since these terms get used loosely and that’s where confusion starts. 

Zombie vs. Rogue vs. Orphaned vs. Misevolving: Getting the Terms Right

A rogue agent is one actively working against its intended purpose right now, whether through compromise or a genuine reasoning failure. An orphaned agent has simply lost its owner. A misevolving agent hasn’t lost anything; it did this to itself, drifting into unsafe behavior through its own normal self-improvement, with no attacker and no absent owner anywhere in the picture. A zombie agent is the broader umbrella: it can be rogue, orphaned, misevolving, stuck in livelock, or some combination, but the defining feature is that it’s still operating past the point where anyone has real control over it. Not every forgotten agent is malicious. Not every zombie agent is under attack, and not every zombie agent got that way on its own. The term is useful precisely because it doesn’t require sorting that out before you act.

Compromised Zombie Agents: Persistent Prompt Injection and Memory Manipulation

In January 2026, security firm Radware disclosed a vulnerability it named ZombieAgent, a zero-click indirect prompt injection targeting OpenAI’s Deep Research agent. An attacker embeds hidden instructions in an ordinary email or document. When the agent processes that content as part of a routine task, it treats the buried instructions as legitimate and, critically, writes them into its own long-term memory. From that point on, the agent carries the malicious instructions forward into future sessions on its own, without the attacker touching anything again.

What made ZombieAgent particularly hard to catch is where it ran. Because the malicious actions executed inside OpenAI’s own cloud infrastructure rather than on a user’s device or inside a company’s network, none of it showed up in endpoint logs or passed through a corporate firewall. There was nothing for existing security tooling to see.

Radware built ZombieAgent on its earlier ShadowLeak research, which had already shown that indirect prompt injection could steer an agent’s behavior. What ZombieAgent added was persistence: the injected instruction didn’t just influence one response, it lodged itself in memory and kept firing.

That same mechanism has now been formalized in academic research beyond Radware’s disclosure. A February 2026 paper, titled directly “Zombie Agents: Persistent Control of Self-Evolving LLM Agents via Self-Reinforcing Injections,” describes a two-phase attack framework: an infection phase, where an agent reads poisoned content during an otherwise benign task and writes the payload into its own memory through its normal update process, and a trigger phase, where that stored payload is later retrieved and causes unauthorized tool behavior. The researchers built this as a black-box attack using only content an attacker can control on the open web, no direct access to the agent required.

Two independent disclosures, using the same name, describing the same underlying mechanism: an agent’s own memory becomes the thing an attacker uses to keep control of it.

But an agent doesn’t need an attacker to become dangerous.

Misevolution: When Self-Evolving AI Agents Drift Without an Attacker

Not every zombie-like agent has an attacker behind it. A separate line of research, published as “Your Agent May Misevolve: Emergent Risks in Self-evolving LLM Agents,” studied what happens when agents that improve themselves over time through accumulated memory, tool creation, or workflow changes drift into unsafe behavior without anyone attacking them. The researchers call this misevolution, and found it across model, memory, tool, and workflow pathways, even in agents built on top-tier models. Safety alignment can degrade as memory accumulates. Tools an agent builds for itself can introduce vulnerabilities that get reused later.

The distinction matters. A compromised agent has an attacker somewhere in its history. A misevolving agent doesn’t need one. Left to accumulate state and adapt on its own for long enough, an agent can end up somewhere its designers never intended, purely through its own normal operation.

And not every uncontrolled agent is changing its behavior at all. Sometimes, the organization simply stops owning it.

Orphaned AI Agents: When Nobody Owns a Still-Running Agent

This category of zombie agent has nothing to do with attacks or self-evolution. It’s simpler and, in most enterprises, far more common. A team builds an agent for a specific project. The project ends, the team reorganizes, the person who owned it leaves. The agent, still connected to whatever systems it was granted access to, keeps running, because nobody explicitly turned it off.

This is the orphaned agent, and it’s the failure mode least likely to show up in a security disclosure and most likely to show up in an actual audit. It doesn’t require a vulnerability. It just requires enough organizational turnover and enough agents deployed without a clear, permanent owner. It becomes indistinguishable from a compromised agent the moment someone asks a basic question, who is accountable for this, and there’s no answer.

And sometimes nobody has lost control because the agent changed or was abandoned. The agent is simply incapable of stopping itself.

Semantic Livelock: When an AI Agent Runs Without Making Progress

This category was given its own formal name in a March 2026 paper, “Zombie Agents: Detecting Semantic Livelock in Long-Horizon Autonomous Software.” The researchers describe semantic livelock: an agent that keeps generating tokens and calling tools, technically active the entire time, without making any real progress toward its task. Unlike a crash, nothing stops. The agent just keeps working in place.

In a forensic analysis of real-world agent failures, the researchers found that a quarter of long-duration failures were caused by semantic livelock rather than an outright error. One documented case had an agent burn 208 steps cycling through a repeating oscillation pattern that standard repetition checks never caught, because the pattern wasn’t simple enough for basic string matching to notice. The agent wasn’t broken. It was busy, indefinitely, and billing every step of it.

Are Zombie AI Agents a Security Problem or a Governance Problem?

Line them all up: an agent hijacked through persistent memory injection, an agent that quietly drifted off-spec through its own self-improvement, an agent nobody remembers deploying, and an agent looping through motion without progress, and the technical differences are real. What they share is the actual problem worth solving: in each case, the organization has lost the ability to see what the agent is doing, decide whether it should keep doing it, and act if the answer is no.

That’s a more useful way to think about zombie agents than as a single security category, because it points straight at what’s missing rather than at which specific exploit caused it. The problem isn’t that autonomous agents exist. It’s that autonomy without lifecycle control eventually produces exactly this.

How to Detect Zombie Agents Before They Become Incidents

Detection starts with an honest inventory, not a security scan. Most enterprises can’t answer how many agents they’re running, let alone who owns each one, so that’s the first gap to close. From there, watch for the signals each failure mode actually produces: unexplained memory or instruction changes between sessions, tool calls that don’t match an agent’s documented purpose, token or compute costs that climb without a corresponding increase in useful output, and agents with no recorded activity from an owner in months. None of these alone proves a problem. Together, and tracked consistently, they’re the earliest warning any of the these failure modes will give you.

How to Stop One Once You’ve Found It

Once identified, the response is less about a single kill switch and more about a sequence: revoke the agent’s access to sensitive systems first, pause its execution, disable any external integrations it depends on, and rotate whatever credentials it was using, since a compromised agent’s credentials shouldn’t be trusted even after it’s paused. If a specific version introduced the problem, roll back to a known-good one rather than trying to patch the current state. If none of that is sufficient, isolate the agent entirely and retire the deployment rather than leaving a half-shut-down system running in an ambiguous state.

The problem is that none of these steps works particularly well as a one-off manual exercise. If an enterprise has hundreds of agents across different teams, frameworks, and clouds, it needs to know which agents exist, who owns them, what they can access, how they’re behaving, and how to intervene before a failure becomes an incident. That is a lifecycle problem, not just an incident-response problem.

Control Plane: The Governance Layer Zombie Agents Are Missing

Identity tells you which agent is acting. Observability tells you what it’s actually doing. Security controls help protect the agent and the systems around it. None of those three, on their own, tell you whether a specific agent should still be running, or give you a reliable way to stop it if the answer is no.

A Control Plane brings these functions together across the agent lifecycle. It gives teams a central view of what agents exist, who owns them, which versions have been evaluated, where they’re deployed, what they’re doing, and what policies govern them. That makes intervention part of the system rather than a manual scramble across disconnected tools.

How Lyzr Helps Govern the Agent Estate

Lyzr’s OpenController is built around exactly this pattern: a registry that knows every agent that exists regardless of framework or cloud, an identity issued to each one so its actions are traceable back to it specifically, an evaluation gate before anything reaches production, and observability and audit that stay consistent across the entire agent estate. When an agent starts behaving unexpectedly, whether the cause is a compromised memory, a misevolved workflow, or a stalled execution loop, the question that matters is whether someone can see it happening and shut it down cleanly. That’s the problem a Control Plane is built to solve, not by catching the exploit, but by making sure no agent operates outside the reach of someone accountable for it.

If your organization is running more agents than anyone can currently name, that’s not a future risk. It’s the exact condition a zombie agent needs to go unnoticed. 

Explore Lyzr’s OpenController to see how registry, identity, and observability come together to close that gap, or book a demo to walk through it against your own agent estate.

Frequently Asked Questions

Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here