Why do unmanaged NHIs and AI agents create more risk than tracked service accounts?

Tracked service accounts at least sit inside a governance model. Unmanaged NHIs and AI agents do not. That means their credentials, privileges, and behaviours can persist without review, which increases the chance of credential theft, lateral movement, and automation abuse. The risk rises again when these identities can spawn additional access or operate across multiple platforms.

Why This Matters for Security Teams

Tracked service accounts at least exist inside an inventory, an owner model, and a review cadence. Unmanaged NHIs and AI agents do not. That difference matters because risk is not just about having credentials, but about whether those credentials can be observed, constrained, rotated, and revoked before they are abused. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which turns invisible identities into a broad attack path rather than a narrow operational tool.

The problem becomes sharper with AI agents because their activity is goal-driven and dynamic. A service account may execute a predictable integration, but an agent can chain tools, request new access, and operate across systems in ways that were never pre-approved at design time. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime controls rather than static trust assumptions. In practice, many security teams encounter this only after an unmanaged identity has already been used for lateral movement or automation abuse, rather than through intentional lifecycle control.

How It Works in Practice

The practical distinction is governance depth, not label. A tracked service account usually has a named owner, known scope, rotation policy, and an offboarding path. An unmanaged NHI or agent often has none of those, which means no one can answer basic questions such as who issued the secret, what workload is using it, or whether it should still exist. NHI Management Group’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both reflect the same pattern: unmanaged identities become durable attack surface.

For autonomous workloads, current best practice is evolving toward runtime authorisation and short-lived credentials. That usually means:

• Using workload identity, not shared static secrets, so the system can prove what the agent is at runtime.
• Issuing just-in-time credentials per task, with short TTLs and automatic revocation after completion.
• Evaluating policy at request time with context such as task intent, data sensitivity, and destination system.
• Separating tool access by action, so an agent cannot reuse one privilege to unlock unrelated systems.

This aligns with the direction of CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which emphasize lifecycle controls, measurable risk, and operational accountability. These controls tend to break down when agents are allowed to self-provision credentials in loosely governed CI/CD, SaaS automation, or multi-tenant orchestration layers because the issuing source and revocation path are no longer centrally enforced.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance automation speed against revocation certainty. That tradeoff is real, especially where teams rely on legacy integrations, long-running batch jobs, or vendor-managed automations that cannot easily adopt short-lived identity. In those environments, security leaders sometimes keep static credentials temporarily, but current guidance suggests they should be tightly scoped, heavily monitored, and treated as exceptions rather than a normal operating model.

There is no universal standard for this yet, but the direction is clear: unmanaged NHIs and AI agents are riskier because they escape the control plane. If an identity cannot be inventoried, attributed, rotated, or revoked, then it is effectively permanent access. That becomes especially dangerous when agents can discover new tools or expand into adjacent systems. The issue is not only secret theft, but also unauthorized delegation, invisible privilege accumulation, and repeated reuse of the same access path across workflows. The NIST Cybersecurity Framework 2.0 remains useful here because it forces teams back to identification, protection, detection, response, and recovery rather than assuming an identity is safe just because it was once created.

Related resources from NHI Mgmt Group

• Why do AI agents create more audit risk than traditional service accounts?
• Why do service accounts and AI agents create different identity risk than employees?
• Why do AI agents create more authorization risk than static service accounts?
• Why do shared service accounts create risk for AI agents?