Enterprise AI agents are not NHIs: why governance breaks

At a glance

What this is: Aizome argues that enterprise AI agents should not be governed as NHIs because their runtime behaviour invalidates core NHI security assumptions.

Why it matters: This matters because IAM, PAM, and lifecycle programmes need to distinguish between stable machine identities and agents whose permissions, actions, and execution paths change at runtime.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Aizome's analysis of why enterprise AI agents are not NHIs

Context

Enterprise AI agent governance starts with a basic question: is the identity stable enough for NHI controls to model accurately, or does it reason at runtime in ways that change its access path? The article argues that enterprise AI agents behave differently from service accounts and API keys, so the first-order problem is not secret handling but whether the programme is trying to govern the wrong actor type.

That distinction matters for NHI, IAM, and lifecycle programmes because control design depends on what the identity is allowed to do, how predictable it is, and whether its behaviour remains consistent across sessions. For a broader NHI baseline on governance, visibility, rotation, and offboarding, see the Ultimate Guide to NHIs.

Key questions

Q: What breaks when enterprise AI agents are governed like service accounts?

A: The main failure is that service-account governance assumes fixed scope and stable behaviour, while enterprise AI agents can select tools, alter execution paths, and expand workflows at runtime. That means access may be technically authorized even when the resulting action no longer matches the original intent. The result is compliance-looking control with weak operational assurance.

Q: Why do enterprise AI agents complicate NHI governance?

A: They complicate NHI governance because the security model was built around predictable non-human identities such as API keys and workload credentials. Agents reason over context, can chain actions, and may use multiple protocols in one workflow. That makes permission modelling necessary but insufficient, because the real control issue is whether the execution still reflects approved intent.

Q: How do teams know if agent access is still operating inside its intended boundary?

A: Teams should look for evidence that the full action chain still matches the original business request, not just that each call was individually permitted. Useful signals include unexplained tool expansion, unexpected delegation depth, and outputs that satisfy the letter of access policy but not the operational purpose. If the chain cannot be reconstructed, the boundary is not being enforced.

Q: Who is accountable when an enterprise AI agent acts within policy but outside intent?

A: Accountability should sit with the organisation that approved the workflow and the team that owns the agent, but policy compliance alone does not settle responsibility. When actions are technically allowed yet materially misaligned with intent, the governance failure is architectural. That is why agent review and approval design must be explicit, not implicit in NHI controls.

Technical breakdown

Why fixed-scope NHI controls fail for enterprise AI agents

NHI security assumes the identity has a discoverable permission set that can be defined at provisioning time. That works for service accounts, API keys, and workload identities because their runtime behaviour is supposed to stay inside a stable scope. Enterprise AI agents are different: they infer next steps from context, may invoke new tools mid-task, and can traverse workflows that were never fully enumerated up front. In practice, the control boundary becomes an approximation rather than a complete description of authority.

Practical implication: review whether your current authorisation model depends on knowing the full action set before execution begins.

Intent drift is not the same as anomalous access

Traditional NHI monitoring looks for deviation from a known behavioural baseline. That approach is effective when the identity behaves deterministically, because unusual activity often signals misuse. Enterprise AI agents can execute different tool chains for the same task on different days without being compromised. The harder problem is not whether a call is technically permitted, but whether the overall sequence still matches the human intent that initiated it. That is an intent-level governance issue, not a simple anomaly problem.

Practical implication: separate permission monitoring from intent validation in your detection and review design.

Multi-agent delegation breaks identity continuity

In an agent-to-agent chain, identity context gets filtered at each hop. A supervisor agent may delegate to a worker, which delegates again, and each step can remain technically authorized while the original authorization intent becomes progressively less visible. NHI governance can assign ownership to the first agent, but it does not preserve the semantics of the human request across the chain. That is why chain length matters: accountability can still exist while intent integrity disappears.

Practical implication: map which workflows allow delegated execution to outrun the original approval context.

Threat narrative

Attacker objective: The objective is to turn legitimate agent access into uncontrolled business action by exploiting the gap between technical permission and intended authorization.

1. Entry occurs when an enterprise AI agent is granted legitimate access to enterprise APIs, tools, or MCP-connected services as part of its intended workflow.
2. Escalation happens when the agent expands into additional tools, sub-agents, or data sources at runtime, beyond the practical scope assumed at provisioning.
3. Impact emerges when the agent completes an action sequence that is technically authorized but inconsistent with the original human intent, creating governance failure and potential data exposure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Enterprise AI agents are a different identity problem, not a bigger NHI problem. NHI security was built for stable principals, fixed scopes, and deterministic behaviour. Enterprise AI agents violate those premises because runtime reasoning changes what they do, which tools they touch, and how far a workflow can expand before anyone reviews it. The implication is that extending existing NHI policy alone does not create a valid governance model for agents.

Fixed scope is a governance assumption, not a technical property. The assumption that an identity can be fully described at provisioning time was designed for service accounts and API keys. That assumption fails when the actor is autonomous because tool selection and execution timing are decided during runtime, not fully at setup. The implication is that least privilege becomes a moving target when intent is non-deterministic.

Intent integrity is the named concept this category has been missing. Identity controls can certify credentials, ownership, and permission sets, but they cannot on their own prove that a multi-hop agent chain still matches the original human authorization. This is the failure mode that makes agent governance unlike standard NHI lifecycle management. Practitioners need to recognise intent integrity as a separate control plane, not a variant of secret governance.

Cross-protocol visibility gaps make the vendor-extension story too narrow. Enterprise AI agents may interact through APIs, OAuth, managed identity, and MCP relationships in a single workflow, which means no single NHI view captures the full trust picture. That fragmentation is exactly where accountability weakens. The practitioner conclusion is that governance must follow the chain, not the credential type.

Market messaging that collapses agents into NHIs will overstate compliance and understate risk. The category may still reuse some NHI controls, but the governance target is not a service account with a new label. If a programme cannot preserve intent across delegation, it cannot claim to have governed the agent. Security teams should evaluate agent-native control requirements before accepting NHI-only coverage as sufficient.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• For a broader governance baseline, see 52 NHI Breaches Analysis for recurring failure patterns across machine identities and delegated access.

What this signals

Intent integrity will become a useful governance shorthand for programmes that need to distinguish authorised credentials from authorised outcomes. As enterprise AI agents spread, the programme question is no longer whether an identity can authenticate, but whether its delegated chain still represents the business purpose that was approved. That makes runtime observability and review design more important than static entitlement catalogues, especially when workflows span APIs, MCP links, and sub-agents.

The practical signal is that IAM teams should expect more review friction around delegated AI workflows than around conventional machine accounts. A useful external baseline is the NIST Cybersecurity Framework 2.0, but the operational challenge is specific: policy must follow execution, not merely provisioned access. Organisations that cannot trace the path from request to action will struggle to explain agent behaviour after the fact.

As the number of connected machine and agent identities grows, visibility gaps become programme risk rather than an inventory issue. Our own research shows only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for any team extending controls into agentic workflows. The next phase is not broader naming, but tighter chain-level governance and clearer ownership across identity types.

For practitioners

• Classify the actor before selecting controls Separate service accounts, API keys, workload identities, and enterprise AI agents in your identity inventory so the governance model matches the actor type rather than the tool stack.
• Map runtime decision points in agent workflows Document where an agent can choose tools, call sub-agents, or expand a workflow without a human approval gate, then treat those points as governance boundaries.
• Test for intent drift across delegation chains Review whether the original human request can still be reconstructed after two or three agent hops, especially when MCP connections and API calls are involved.
• Separate permission review from authorization intent review Keep routine access certification for the credentials, but add a distinct review for whether the completed action still matches the intended business outcome.

Key takeaways

• Enterprise AI agents break the stable-scope and deterministic-behaviour assumptions that conventional NHI controls rely on.
• Governance failures appear when technically authorized agent actions drift away from the original human intent across multi-hop delegation chains.
• IAM teams should treat agent governance as a distinct control problem, with runtime intent review added alongside existing credential and entitlement management.

Key terms

• Intent integrity: Intent integrity is the ability to prove that an automated or agentic action still matches the business purpose that authorised it. In enterprise AI systems, this means preserving the connection between the original request, the delegated execution chain, and the final output, even when multiple tools or agents are involved.
• Delegation chain: A delegation chain is the sequence of human, system, or agent handoffs through which authority is passed before an action is executed. In agentic environments, each hop can preserve technical permission while weakening the visibility of original intent, which makes chain length a governance concern.
• Runtime governance: Runtime governance is the control layer that evaluates behaviour while a system is operating, not only when it is provisioned. For enterprise AI agents, this is essential because tool selection, execution timing, and workflow expansion can emerge only during the session, after static policy has already been approved.
• MCP trust relationship: An MCP trust relationship is the ongoing connection between an AI agent and a tool server established through the Model Context Protocol. It differs from a one-time credential check because the relationship can persist across interactions, making visibility and re-evaluation harder for traditional identity tooling.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aizome: Stop Calling Enterprise AI Agents NHIs. They're Not. Read the original.