Dormant agents are dangerous because they keep their identity and permissions even when the original project is forgotten. Without recent activity, there is no behavioural baseline, no obvious owner attention, and no natural trigger for offboarding. If an attacker later compromises that identity, the response window is narrower because the activity looks unusual by default.
Why dormant agents are a high-value target
Dormant agents create risk because they often remain fully entitled even after the project, team, or owner has moved on. The security problem is not the label “inactive”, it is the gap between retained authority and reduced oversight. Once an agent is forgotten, it is less likely to be reviewed, rotated, or retired on schedule.
That combination matters because dormant access can sit quietly inside normal enterprise systems, cloud tenants, and automation chains. If the account or token is still valid, an attacker does not need to create a new foothold, only to find a neglected one and use it before anyone notices.
Long-lived access paths are a good fit for OWASP Non-Human Identity Top 10 because they capture the core failure mode: stale identity material, overprivilege, and weak retirement discipline. The same pattern is also why Agentic AI Identity Guide treats registration, ownership, and offboarding as lifecycle controls rather than optional hygiene.
What changes when there is no recent activity
Recent activity creates signals. Dormancy removes them. A live agent usually has logs, a known owner, routine approvals, and a clear operational pattern. A dormant one has fewer comparisons, weaker anomaly context, and less chance that someone will notice if its permissions are reused in a way that is technically valid but operationally suspicious.
That also changes incident response. When a dormant agent is compromised, defenders may not have a strong baseline for expected behaviour, so malicious use can blend in as an old but legitimate workflow. The response window is therefore shorter, not because the compromise is inherently faster, but because the environment has less context to prove that the action is abnormal.
This is why AI Agent Observability, Audit and Incident Response Guide is relevant here: the control value is in attribution, behavioural baselines, and revocation readiness. It is also why Shadow AI and AI Agent Discovery Guide matters, because discovery is what exposes forgotten agents before they become blind spots.
Why dormant access is harder to govern than active access
Dormant agents are a governance problem as much as a technical one. Ownership decays, business purpose becomes unclear, and approval chains stop matching reality. The security consequence is that an identity can outlive the control relationship that justified it, which makes review cadence, recertification, and retirement the actual control points that matter.
Enterprises also tend to underestimate how often dormant systems survive because nothing breaks. If no one depends on the agent day to day, it can evade attention indefinitely, yet still retain access to sensitive APIs, internal tools, or production data. That is why access review must be tied to utility and accountability, not just to age or last login.
That governance lesson aligns with AI Agent Authorisation Guide, which treats least privilege and per-action decisions as the default for agent access. It also aligns with Zero Trust for AI Agents, because stale trust assumptions are exactly what dormant identities exploit.
Risk and Threat Considerations
Dormant agents are attractive to attackers because they often combine valid credentials, weak monitoring, and low owner visibility. A compromised dormant identity may look like an old integration rather than an intrusion, which raises the chance of delayed detection and increases the value of the account for persistence or quiet data access.
Failure mechanism: The identity remains active after the original operational need has faded, so the control plane still trusts it even though the business no longer watches it closely. That creates a condition where token theft, password reuse, or delegated access abuse can succeed without immediately triggering a human review.
Impact: An attacker can turn forgotten access into a durable foothold, move laterally through connected systems, or use the agent as a trusted path to sensitive data and services. The longer the dormancy, the more likely the organisation has lost the context needed to distinguish legitimate automation from malicious use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Dormant agents become risky when valid access is never retired. |
| NHI-05 — Overprivileged NHI | Dormant identities often retain more access than their current purpose needs. | |
| Recommendation — Revoke dormant agent access promptly and remove stale credentials. Trim dormant agent permissions to the minimum current task scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dormant agents remain exposed when secrets and tokens are not rotated or expired. |
| AC-2 — Account Management | Dormant agents are an account lifecycle problem requiring ownership and disablement. | |
| AC-6 — Least Privilege | Unused agents still carrying broad rights increase blast radius if compromised. | |
| Recommendation — Rotate, expire, and inventory dormant agent authenticators. Review dormant accounts and disable identities with no active business need. Reduce dormant agent permissions to the minimum required access. | ||
Practitioner Guidance
What to prioritise: Start with dormant identities that still carry production access, especially those with broad API scopes, shared secrets, or delegated authority. If the agent can still reach sensitive systems, treat it as an active exposure until proven otherwise.
What to verify: Confirm who owns the agent, whether the business purpose still exists, when permissions were last reviewed, and whether the secret or token is still valid. If any of those answers are unclear, the safest assumption is that the agent should be revalidated or retired.
Common mistake: Teams often assume inactivity equals safety. In practice, inactivity can mean the opposite, because a dormant agent may be easier to overlook while still being fully usable by an attacker or by an overbroad integration path.
Practitioner takeaway: The security objective is not to keep every agent alive, it is to keep only the agents that still have a current owner, current purpose, and current access boundary.
Related resources from NHI Mgmt Group
- Why do AI agents increase security risk when they can act asynchronously across enterprise systems?
- Why do AI agents increase browser security risk for IAM teams?
- Why do Claude AI security risks increase when agents inherit enterprise credentials?
- Why do embedded AI agents increase enterprise risk so quickly?