TL;DR: Inventory, rotation, and ownership tracking do not close non-human identity risk when AI agents and machine accounts can still act far beyond their intended scope at runtime, according to EnforceAuth research. Authorization, not authentication hygiene, is the control boundary that decides whether NHIs can touch the right data and actions.
At a glance
What this is: This is an analysis of why non-human identity programmes fail when they stop at discovery and credential hygiene instead of governing what machine identities are allowed to do at runtime.
Why it matters: IAM, IGA, and PAM teams need to treat authorization as the missing control layer for NHIs, especially where AI agents and other machine identities can act faster than human review cycles.
By the numbers:
- 45:1 is the ratio of non-human identities to humans in the enterprise, according to EnforceAuth.
- 60% of NHI credentials are either stale or carry more privilege than the workload requires, according to EnforceAuth.
- around 31% of breaches involve stolen credentials, according to EnforceAuth.
Context
Non-human identity governance is the discipline of controlling service accounts, API keys, machine credentials, and AI agent tokens across their lifecycle. The core failure in this article is not discovery or rotation, but the absence of runtime authorization over what those identities can do once authenticated.
The article argues that many programmes can inventory NHIs and keep credentials current, yet still leave a live decision gap. That matters because machine identities now operate at enterprise scale and machine speed, so static role assignment does not reliably govern context-sensitive actions.
For IAM and IGA teams, the issue is no longer whether NHIs exist in the estate. It is whether the programme can answer, in real time, which actions, datasets, and workflows each identity is permitted to touch under the current request context.
Key questions
Q: What breaks when NHI governance relies on inventory alone?
A: Inventory alone tells you what credentials exist, but not whether they are active, over-scoped, shared, or being used by an agent at runtime. That leaves dormant keys, stale accounts, and hidden privilege drift outside the control process. Effective NHI governance needs evidence of use, ownership, and scope, not just a list of issued identities.
Q: Why do unmanaged non-human identities increase incident impact so quickly?
A: Because no real person is continuously watching the identity, compromise can continue until monitoring catches it or an outage exposes it. When the identity is also privileged, the same credential can touch many systems, making the blast radius much larger than a normal user account. That is why NHI ownership and access scope matter as much as detection.
Q: How do security teams know if NHI authorization is actually working?
A: Look for consistent allow and deny decisions at runtime, complete audit logs for each request, and fewer services that need code-level permission checks. If teams still rely on service-wide roles or cannot explain why a request was allowed, authorization is not being enforced tightly enough. The signal is decision precision, not credential rotation frequency.
Q: How should teams govern AI agent access to production data?
A: Treat agent actions as runtime events that need policy checks at execution time, not just pre-approved credentials. High-risk reads, writes, and deletes should be bounded by context, session limits, and approval gates that apply before the command completes.
Technical breakdown
Why NHI authentication does not solve authorization
Authentication proves a machine identity is genuine, using a token, certificate, API key, or other secret. Authorization is the separate decision about what that identity may do after it is trusted. The article’s central point is that many programmes have strong identity inventory and credential hygiene but no policy layer that evaluates the action itself. That gap becomes acute when the same identity can reach multiple systems, multiple data classes, or multiple workflows. In practice, authentication answers who is talking, while authorization decides whether the current request is permissible.
Practical implication: treat authenticated NHIs as untrusted until a runtime policy decision approves the specific action.
Why RBAC is too blunt for machine identities
Role-based access control works best when duties are stable and request patterns are predictable. The article shows why that assumption breaks for NHIs, especially AI agents whose context shifts during a session. A static role cannot express whether an identity may read one dataset but not another, or whether it may invoke a downstream tool only under specific task conditions. That is why decision-centric enforcement is needed. The policy must be evaluated at the moment of access, not inherited from a provisioning event months earlier.
Practical implication: replace coarse role grants with fine-grained, context-aware policy checks at request time.
How AI agents change the identity control problem
AI agents are not just high-volume NHIs. They can sequence actions, chain tools, and produce downstream effects that were never explicitly enumerated when access was first granted. That creates a control problem for policies built around fixed assumptions about intent and task scope. The article’s example of an agent querying a customer database without business need shows the issue clearly: the credentials worked, but the authorization model did not say no. Once an agent can choose among tools and act on intermediate outputs, governance has to focus on permitted outcomes, not just permitted logins.
Practical implication: define policy around task-scoped outcomes and data boundaries, not just identity possession.
Threat narrative
Attacker objective: The objective is to reach sensitive data or actions through a legitimately authenticated non-human identity that has no runtime authorization boundary.
- Entry occurred through a legitimate AI agent session using credentials that authenticated successfully to enterprise systems.
- The identity was able to query a production customer database because no authorization rule limited the action in that context.
- Impact followed when the agent accessed data it had no business accessing, exposing the gap between trusted identity and permitted behaviour.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authorization is the missing control plane for non-human identities: discovery and rotation solve inventory and credential freshness, but they do not govern what an authenticated machine identity may do at runtime. That gap becomes the operational failure point when service accounts, API keys, and AI agents are allowed to act without a policy decision on the actual request. The implication is that NHI governance must be measured by enforced authorisation, not by asset count alone.
Decision-centric governance is now the differentiator: role-based models are too coarse for machine identities whose context changes with every call. The article shows why action-level policy, not static role assignment, is the real control boundary for NHIs. Practitioners should interpret this as a shift from identity administration to continuous decision enforcement across data, applications, and workflows.
Machine speed exposes human-paced assumptions: controls built for periodic review assume an identity remains stable long enough to be observed and recertified. NHIs, especially AI agents, can authenticate, decide, and act before a reviewer sees the request. That means the governance model must move from after-the-fact review to pre-action authorisation, or the programme will certify the wrong thing.
Role assignment is not permission governance: many organisations still equate having an inventory with having control. This article shows that a spreadsheet of NHIs can coexist with a live exposure window if no one defined the allowed actions. The practitioner conclusion is simple: if runtime policy is absent, the NHI programme is administrative, not protective.
Identity blast radius is defined by what an NHI can reach, not by whether it is known: known credentials can still produce harmful outcomes when scope is unconstrained. The article’s strongest contribution is the reminder that visibility does not equal restraint. For practitioners, the field needs governance models that limit reachable data and actions at the decision point.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Read next: NHI Authentication Guide
What this signals
Decision-centric authorization is becoming the real NHI control boundary: discovery, classification, and rotation are necessary, but they do not answer whether a service account, API key, or AI agent may perform a specific action right now. That gap matters most where machine identities can chain requests faster than human reviewers can intervene.
Runtime policy is now the governance test: teams that can only describe identities in a spreadsheet have visibility, not control. The practical shift is to evaluate access at the point of each request, so the programme can prove what an NHI was allowed to do instead of assuming the credential itself was sufficient.
Identity blast radius is the concept to watch: the size of the risk surface is defined by reachable data and actions, not by how well the identity is catalogued. As more than 25x to 50x machine identities accumulate relative to humans, the programme that limits action scope will outperform the one that only inventories credentials.
For practitioners
- Define action-level authorization for NHIs Map each service account, API key, machine credential, and AI agent token to the specific actions, data classes, and workflows it may touch. Remove broad system access grants that cannot be defended at the request level.
- Move enforcement to the decision point Require a policy check at runtime before any non-human identity can read, write, invoke, or chain a sensitive action. Do not rely on provisioning-time role assignment as the final control.
- Separate discovery from governance metrics Track not only how many NHIs exist, but how many have explicit denied actions, scoped datasets, and auditable runtime decisions. Inventory without authorisation metrics leaves the programme blind to real exposure.
- Review AI agent access by task outcome For agents, express access as permitted outcomes and forbidden data paths rather than general-purpose roles. Reassess any agent that can reason through multi-step workflows without a policy boundary on the next action.
Key takeaways
- The article argues that non-human identity programmes fail when they stop at discovery and credential hygiene, because neither control answers what the identity may do at runtime.
- The evidence point is clear: NHIs now outnumber humans by 25x to 50x in many enterprises, and stale or over-privileged credentials remain common.
- Practitioners should shift from static role assignment to runtime authorization that constrains data, actions, and workflow chaining for each machine identity.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article distinguishes authentication from authorization for machine identities. |
| NHI-05 — Overprivileged NHI | The central risk is machine identities holding broader access than their task needs. | |
| NHI-10 — Human Use of NHI | The article shows the danger of treating machine identities as if human role models were sufficient. | |
| Recommendation — Separate identity proof from runtime permission checks for every non-human identity. Reduce non-human identity scope to the minimum actions and datasets each workload requires. Prevent human-centric role assumptions from governing machine identity permissions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the control principle violated when NHIs can access more than their task requires. |
| Recommendation — Apply least privilege to machine identities at the action and data layer, not just at account creation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about permissions and entitlements for NHIs at runtime. |
| Recommendation — Continuously verify that each non-human identity is authorized for the specific requested action. | ||
Key terms
- Non-Human Identity Access Management: The governance discipline for controlling machine identities such as service accounts, API keys, tokens, and certificates. It covers ownership, permissions, rotation, offboarding, and monitoring so autonomous systems do not accumulate unmanaged access over time.
- Decision-Centric Security: Decision-centric security shifts control from identity ownership to action-level approval. Rather than asking only who has the credential, it asks whether a specific action is authorized right now. For machine identities, this is the practical way to govern fast, context-changing access patterns.
- Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org