Zombie Agents: How Unmanaged AI Identities Become Security Risks

Zombie agents are AI agents that still exist in the estate while ownership, tool access or business purpose has gone stale. They differ from experiments that never entered a registry and from ordinary offboarding of people. A zombie agent may remain registered, retain tool grants and sit outside active review. Citadel Identity360 helps teams bring agents discovered from Microsoft Entra, Amazon Web Services and Google Cloud central registries under ownership, grant review, containment and retirement workflows. Signals such as unused runtime still need to be gathered by the operating team and attached to that governance process.

Zombie agents are a retirement problem

Shadow programmes ask how unseen AI use enters an owned inventory at all. Zombie-agent work assumes an agent is already visible in a supported registry or governed inventory and asks a different question: should this agent still exist, under whose authority, with which tools.

That distinction matters. An unknown browser assistant is not yet a zombie agent in the registry sense. An agent that still appears in a Microsoft Entra, Amazon Web Services or Google Cloud registry after its project ended is a candidate for zombie handling: confirm owner, inspect grants, contain if needed and retire what no longer has a purpose.

Contractor offboarding without residual human access, covered in Astranova’s contractor lifecycle guidance, is also a different problem. People leave. Agents can remain as non-human principals with their own tool authorisations. Treating zombie agents as a special case of human JML understates the tool and configuration surface that must be closed.

What “zombie” should mean in an identity programme

Use a practical definition that teams can investigate:

• No active owner: the recorded owner has left, the owning team dissolved, or no owner was ever assigned after registry discovery.
• Stale tool grants: the agent still has tool or MCP permissions that no longer match a current business purpose.
• Unused or idle runtime signals: operations, platform or application telemetry suggests the agent is no longer used. Treat these as inputs the team gathers, not as a claim that Citadel independently measures agent runtime.

An agent can meet one criterion without meeting all three. An owned agent with oversized tools is a least-privilege problem. An unowned agent that still runs is an accountability problem. Both deserve action; the remediation sequence differs.

Keep discovery honest. Citadel discovers AI agents from Microsoft Entra, Amazon Web Services and Google Cloud central registries and places them in a governed inventory. It does not, on that basis, claim to detect unused runtime or inactivity by itself. Combine registry inventory with owner attestation, review outcomes and whatever activity signals your cloud or application teams can provide.

Why abandoned agents create hidden access risk

An agent with tool access can still reach documents, tickets or APIs long after the sponsoring project ends. If nobody owns it, reviews may skip it. If configuration files for MCP clients remain distributed, people may keep using a capability the business thinks it retired.

Typical failure patterns include:

• A pilot agent remains in a cloud registry after the pilot funding stops.
• Tool grants expand during experimentation and never shrink.
• The human sponsor leaves and the agent’s owner field is empty or points to a disabled account.
• Related service accounts or API keys outlive the agent’s purpose.
• Containment is unclear because nobody tested who can intervene.

These patterns are illustrative. They show why counting agents is weaker than explaining each agent’s owner, tools and retirement status.

Separate zombie handling from shadow AI mapping

Earlier coverage of shadow AI governance focuses on making unseen AI use visible and moving newly found registry agents into ownership. Zombie-agent work starts after that handoff, when the agent is already known.

A useful split:

• Shadow track: find AI uses and registry agents that are not yet in the governed inventory.
• Zombie track: for agents already known, decide keep, reassign, contain or retire.

Obvious abandoned agents in supported cloud registries can be retired without finishing every shadow-mapping workstream. At the same time, most registry agents are not zombies. Triage beats bulk deletion.

While an agent remains active, deeper product guidance covers MCP access control for AI agents and governing agents and MCP tools beyond a login. This piece stays on abandonment, owner reassignment and retirement.

Standards context without inventing a zombie metric

The NIST AI RMF describes continuous oversight across an AI system’s life, not a single enrolment event. That programme language supports why registered agents still need owners, purpose checks and retirement when conditions change.

NIST never labels a control “zombie agent.” Treat the framework as context for accountability and changing risk. Day-to-day identity work still has to supply registry inventory, named owners, reviews and containment for the agents you choose to govern.

If the inventory only grows and never retires rows, teams cannot show which AI systems still match approved purpose. Pair intake with a retirement path so the list stays honest.

NIST SP 800-53 Rev. 5 account-management and least-privilege themes still apply to the identities and authorisations agents depend on. Retiring an agent without addressing related non-human credentials can leave residual paths.

A triage sequence teams can run

1. Build the candidate list from registries you can govern

Start with agents Citadel already pulled from Microsoft Entra, Amazon Web Services and Google Cloud registry sources. Include agents already sitting in the governed inventory. Leave aside browser-only assistants that those registries never list.

2. Attach ownership before judging activity

If no active owner exists, assign one or escalate to the platform owner for the registry source. Reassignment is often the first remediation. Containment and retirement without an accountable decision-maker recreates the same vacuum.

3. Inspect tool grants and access paths

Review which MCP servers and tools the agent may use and how access reaches sensitive resources. Path visibility matters more than the agent display name. Stale grants are a primary zombie indicator even when someone still claims ownership.

4. Gather unused-runtime or idle signals from the right operators

Ask cloud, application or agent-platform owners what usage evidence they can provide. Document the source and date of any idle signal. Do not imply Citadel produced a runtime unused score unless your deployment explicitly includes that operational feed. The governance decision can still proceed on owner absence and stale grants alone.

5. Decide keep, reassign, contain or retire

• Keep: confirm owner, purpose and tool set; schedule the next review.
• Reassign: move ownership to the team that still needs the capability; update who-can-use rules.
• Contain: apply the kill switch as a temporary stop while investigation continues.
• Retire: remove tool authorisations, withdraw distributed client configuration as appropriate, complete related credential changes and record the outcome.

Follow approved removals through to completion. An owner decision that never reaches fulfilment leaves the zombie in place.

Document decisions in the same evidence style you would use for other non-human access changes: who decided, what changed, when fulfilment completed and which related credentials were included. Auditors and internal assurance teams can then sample zombie retirement the same way they sample other privileged-path removals.

When ownership cannot be resolved quickly, time-box containment. Record the reason, the person authorised to lift containment and the next review date. Open-ended containment without an owner becomes another form of abandonment.

An illustrative retirement path

A product team creates an agent in a cloud tenant to summarise backlog tickets. Tools are authorised for ticket read and comment. Six months later the product line is sold. The agent remains in the cloud registry. The original owner account is disabled. Ticket tools still allow comments.

Registry discovery brings the agent into Citadel’s governed inventory with no active owner. The platform team assigns a temporary owner from IT operations. Review shows ticket-write tools are no longer justified. The team contains the agent, removes the write tools, confirms no business owner wants the read-only capability and retires the agent. Related API credentials used only by that agent are included in the same change set.

The story is illustrative. It shows ownership reassignment, containment and retirement without claiming a product-native unused-runtime detector found the idle state. The idle clue may have come from the ticket platform owner noticing no recent automated comments.

Where Citadel fits zombie-agent ownership and retirement

For agents already inside the supported cloud inventories, Citadel Identity360 helps teams close the zombie loop rather than only listing rows:

• Registry intake: pull agents from Microsoft Entra, Amazon Web Services and Google Cloud registry sources into one governed list.
• Named accountability: every zombie candidate needs a living owner before keep or retire decisions stick.
• Grant and path context: relationship views show which tools and downstream resources the agent can still touch.
• Periodic certifications: access reviews surface risk context with generated recommendations so owners confirm or revoke stale agent grants.
• Intervention control: teams can apply a kill switch as containment while they finish investigation.
• Distributed client setup: operators export a Citadel-produced configuration for MCP-capable clients so shared setup files do not carry tokens, keys or secrets.

Service accounts, API keys and other machine identities that exist only to support the agent should stay under non-human ownership through the same retirement window. Closing the agent row while leaving those credentials alive recreates residual paths.

Risk scoring and toxic-combination alerts can rank which abandoned agents to inspect first. Ranking is not a substitute for an owner choosing keep, reassign, contain or retire.

Operating cadence that prevents zombies from accumulating

Run a monthly or quarterly zombie pass on registry-ingested agents:

1. List agents with missing, disabled or left owners.
2. List agents with tool grants unchanged across multiple review cycles.
3. Collect any idle or unused signals offered by platform owners.
4. Require a keep, reassign, contain or retire decision.
5. Verify fulfilment and record evidence for the period.

Connect this cadence to joiner-mover-leaver events for human sponsors. When a sponsor leaves, open an agent-ownership check for every agent they owned. That is parallel to, not identical to, removing the person’s own application roles.

For inherited membership issues that can also hide residual access, see the group sprawl article. Agent tool grants deserve the same path discipline.

Coordinate with application owners who consume the agent’s outputs. Retiring an agent that still feeds a dashboard can look like an outage to business users even when identity risk is clear. Give them a short notice window when the risk rating allows it. When risk does not allow delay, contain first and communicate in parallel.

Temporary ownership after a reorganisation needs an end date. Without one, the interim assignment recreates the zombie condition.

Avoid deletion theatre

Mass-deleting registry agents without path review can interrupt a quiet but critical automation. Prefer investigation, temporary containment when risk is high, owner reassignment when the capability is still needed and tracked retirement when it is not.

Also avoid parking every uncertain agent in “contain forever.” Containment is an intervention state. It should lead to a keep-with-controls decision or a completed retirement.

Questions raised by idle or unowned agents

Is every inactive-looking agent a zombie?

No. Seasonal processes and standby automations may be idle between cycles. Require ownership and purpose confirmation before retirement. Unused-runtime signals are clues, not automatic delete authority.

How is this different from shadow AI?

Shadow AI focuses on AI uses and agents outside owned visibility. Zombie agents are known registry or inventory agents whose ownership, grants or purpose have gone stale. One programme needs both tracks.

Can Citadel tell us the agent has not run for 90 days?

Do not treat unused runtime as a native discovery claim for agents unless your operational integration supplies that signal. Use owner attestation, review history and platform telemetry your teams already trust.

What is the first safe action when no owner exists?

Assign or escalate ownership, then inspect tools and paths. Use containment if ongoing risk is unacceptable while ownership is resolved. Retirement follows an accountable decision.

Should related credentials be retired with the agent?

Often yes, when they exist only to support that agent. Investigate dependencies first. Citadel’s non-human identity ownership model helps keep those credentials from becoming the next orphaned path.

How do zombie agents relate to group sprawl?

Group membership can still grant humans access to the same systems an agent uses. Closing the agent without reviewing nested groups that authorised its tools can leave a human path open. Use path views for both.

What belongs in the retirement evidence pack?

Owner or escalated decision-maker, tool and path summary before change, containment timestamp if used, fulfilment confirmation for tool removal and related credentials, and the final inventory status.

What should we show in a demonstration?

Take one registry-discovered agent with a missing owner or clearly outdated tool set. Reassign or contain, adjust tools, and complete retirement or a documented keep decision. Show the fulfilment trail, not only the inventory row.

Retire one zombie agent with an owner and a trail

Choose one agent already listed under Microsoft Entra, Amazon Web Services or Google Cloud registry inventory with no living owner or still holds tools for a finished project. Walk it through Citadel Identity360 ownership, grant review, containment if required and a finished keep or retire outcome. Request Demo. Preview capabilities on the videos page before you pick the candidate.