Organisations should bind every agent to an explicit task, owner, and expiry condition, then force decommission when the task ends or the model changes. Monitoring must confirm that privileges are removed, not merely dormant. If revocation is manual or delayed, agents can keep acting long after the original justification has disappeared.
Why This Matters for Security Teams
AI agents become zombie identities when their authority outlives the task, owner, or context that created it. That is not a niche hygiene issue. It is an operational failure that turns an agent into a standing, reusable identity with tool access, data reach, and the ability to keep acting after the business justification has expired. NIST’s NIST AI Risk Management Framework treats this as a governance and lifecycle problem, not just an access review problem.
The risk is amplified in agentic environments because behaviour is dynamic. An agent may chain tools, call APIs in unexpected sequences, or continue operating after a model update changes its output pattern. That means the usual assumptions behind static IAM, periodic recertification, and dormant account checks are too slow. NHIMG’s OWASP NHI Top 10 research and the AI agents attack surface report both show the same pattern: once agents have access, they are often granted more visibility and persistence than their purpose justifies. In practice, many security teams discover zombie behaviour only after an agent has already retained access beyond its intended scope.
How It Works in Practice
The practical answer is to treat every agent like a scoped workload with an expiration date. Bind the identity to four things at creation time: an explicit task, a named owner, an approved policy envelope, and a decommission trigger. That trigger should fire when the task finishes, the prompt or workflow changes materially, the model is swapped, or the agent is inactive beyond its expected window. Current guidance suggests that static RBAC alone is insufficient because agent behaviour is goal-driven, not role-driven.
Security teams are increasingly pairing workload identity with just-in-time access. Instead of long-lived secrets, issue ephemeral credentials per task, then revoke them automatically on completion. That pattern aligns with the direction of travel in agentic controls described by the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize runtime controls over static trust.
- Use workload identity as the primary identity primitive, not shared API keys.
- Issue short-lived tokens with task-scoped claims and automatic revocation.
- Evaluate policy at request time, with context about task, data sensitivity, and destination.
- Log both permission grants and permission removals so decommissioning is provable.
- Reconcile the agent inventory continuously so orphaned identities are flagged quickly.
NHIMG’s LLMjacking research is a useful reminder of why speed matters: exposed credentials are often probed within minutes, not days. These controls tend to break down in environments that still rely on shared service accounts, manual revocation, or loosely governed tool chains because the agent can outlive the operational process that was supposed to retire it.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, so organisations must balance safety against automation maturity. That tradeoff becomes more visible when agents are embedded in customer workflows, software delivery pipelines, or multi-agent systems where one agent depends on another’s output. Best practice is evolving, but there is no universal standard for how much autonomy can remain after a task boundary is crossed.
Some edge cases need special handling. Long-running agents may need rolling leases rather than one-time expiry. Shared orchestration layers may require separate identities for the orchestrator and each tool-using subagent. And if the model or prompt changes, a previously approved agent should usually be treated as a new identity until it is re-reviewed. The Ultimate Guide to NHIs and the DeepSeek breach analysis both reinforce the same operational lesson: persistence without lifecycle control is what turns useful automation into a zombie identity.
For high-risk workloads, policy-as-code and zero standing privilege are the safer default. For lower-risk internal agents, shorter TTLs and stronger monitoring may be enough for now, but that should be treated as a temporary posture, not a stable end state. Organisations that wait for a manual cleanup process usually find the agent is still active long after the owner has moved on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems need runtime controls to stop over-privileged, persistent identities. |
| CSA MAESTRO | PAM-04 | MAESTRO addresses lifecycle governance for autonomous agents and their tool access. |
| NIST AI RMF | AI RMF governance applies to lifecycle oversight and accountability for agent identities. |
Bind each agent to task-scoped, time-bound permissions and revoke access when context changes.
Related resources from NHI Mgmt Group
- How can organisations prevent AI agents from becoming overprivileged?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- How can organisations govern AI agents that use service accounts and tokens?
- How should security teams stop AI agents from using approved tools to exfiltrate data?
