Amir Ofek· CEO - Co-founder of aizome10 min readI want to make an argument that may make some uncomfortable.
The identity industry has spent the last two years building NHI security programs, extending governance frameworks, and applying non-human identity controls to enterprise AI agents. The vendors are on board. The analysts are aligned. The conference sessions are packed.
But with the emergence of enterprise AI Agents we are managing and governing the wrong thing.
Not because NHI security is wrong - it isn't. It's a necessary foundation. And not because AI Agents are not “Non-Human” - I am not saying they are Human… But enterprise AI agents' identities are what the industry tokenizes as non-human identities. They share some surface characteristics, and that surface resemblance is exactly what is leading security and IAM teams to build programs that will fail them at precisely the moments that matter most.
Let’s cover it from an architectural level.
To understand why NHI fails for enterprise AI agents, you need to understand what it was actually designed to solve.
NHI security emerged from a real and urgent problem: enterprises (especially cloud-native ones) had thousands, sometimes hundreds of thousands, of service accounts, API keys, tokens, bots, and workload identities operating in their environments with no systematic governance. They weren't being rotated. They weren't being scoped. They weren't being tied to accountable human owners. And they were being exploited.
The NHI security discipline that emerged to address this was built around a set of core assumptions that are true for service accounts and API keys:
Assumption 1: The identity has a fixed, discoverable scope. A service account is provisioned with a defined set of permissions. Those permissions describe what the identity can do. If you scope them correctly and enforce least privilege, you have meaningful control.
Assumption 2: The behavior is deterministic. An API key does what it is configured to do. A workload credential operates within a defined execution context. If the behavior deviates from what was expected, something has gone wrong, and that deviation is detectable.
Assumption 3: The identity is stable. A service account's identity doesn't change between invocations. It has a consistent principal, a consistent scope, and a consistent behavioral profile. Governance models built on lifecycle management, credential rotation, and ownership mapping work because the identity you governed yesterday is the same identity you're governing today.
Assumption 4: The trust relationship is explicit. Machine-to-machine communication involves explicit credential exchange. The trust relationship is defined, scoped, and auditable. You know which service is calling which, with what credentials, under what authorization.
These assumptions are reasonable for the identity types NHI security was designed to govern. They are structurally false for enterprise AI agents.
Fixed scope breaks immediately.
Enterprise AI agents don't have fixed scopes in any meaningful sense. At provisioning time, you define what resources an agent can access. But the AI agent's actual behavior, which tools it invokes, which data it accesses, which sub-agents it calls, is determined at runtime based on ad-hoc context and reasoning (very much like a human employee would), not by a configuration file.
An agent tasked with "preparing the monthly close report" might access accounts payable data, query the ERP, pull from the vendor database, call a currency conversion API, and invoke a sub-agent to reconcile discrepancies, none of which was fully enumerated at provisioning time. The scope you define is an approximation of what the agent might need. It is far from a precise description of what it will do.
This is not a configuration programming problem. It is a fundamental property of systems that reason. You cannot fully enumerate or code the scope of an agent that decides what to do based on the problem it's solving and the obstacles it is tackling in real time. The best you can do at provisioning time is define boundaries, and boundaries are not the same as scope (very much like you do for a Human identity).
Deterministic behavior breaks at the reasoning layer.
NHI security's detection models are built around anomaly detection from a baseline. If a service account starts doing something outside its expected behavior pattern, that's an alert signal.
Enterprise AI agents have no stable behavioral baseline in the same sense. Their behavior is contextually determined; the same agent executing the same task on two different days and maybe on behalf of two different employees may follow entirely different execution paths, invoke different tools, and access different data, all within its defined permissions, all for entirely legitimate reasons.
This means the anomaly detection model that works well for service accounts produces unacceptable false positive rates when applied to AI agents without significant modifications. More importantly, it means that behavior which looks normal at the individual action level may represent significant drift at the intent level, and that distinction requires a governance model that understands intent, not just actions.
Stable identity breaks in multi-agent A2A (Agent-to-Agent) chains.
This is the failure mode that concerns me the most, because it's the least visible.
In a multi-agent architecture, identity isn't a property of a single actor; it's a property of an A2A chain. A supervisor agent delegates to a worker agent. The worker calls a sub-agent. The sub-agent accesses a sensitive system. At each hop, the identity context is filtered, summarized, and reinterpreted.
By hop three, the agent executing the action has a technically valid identity and technically valid permissions. What it has lost is the original authorization context, the human intent that started the chain, the scope of what was actually meant to be authorized, and the boundary between what was permitted and what was intended.
NHI governance assigns accountability at provisioning time: this agent is owned by this team, governed by this policy. That is correct and necessary. It does not tell you whether the action at hop three is consistent with what the human at hop one actually authorized.
Identity control in an A2A chain degrades. NHI governance has no model for that degradation.
Explicit trust relationships break in the MCP layer.
Traditional NHI security is built around explicit credential exchange, OAuth tokens, service account credentials, and API keys. The trust relationship is declared in the protocol.
Enterprise AI agents operating through the Model Context Protocol introduce a trust model that is fundamentally different. MCP connections establish ongoing relationships between agents and tool servers that are not re-evaluated at each invocation. An agent that has connected to an MCP server has a persistent trust relationship, one that the standard identity governance stack has no visibility into.
An enterprise AI agent in a typical deployment might authenticate to an LLM provider via API key, to enterprise APIs via OAuth, to cloud databases via managed identity, and to tool servers via MCP tokens, each with a different trust model, each in a different visibility domain. Your NHI program sees the OAuth layer. It has no visibility into what's happening in the MCP layer, where some of the most consequential actions are occurring.
Let me make this concrete with a scenario that is not hypothetical; it is a pattern I have seen in enterprise AI deployments.
An enterprise deploys a finance automation agent. The security team does everything right by NHI standards: the agent has a distinct identity, scoped permissions, a documented human owner, credential rotation, and a full audit log.
One day. Just one day goes by, and the agent is already three hops into a workflow it was never designed for, or simply updated to handle one, because that's how easy it is now. A supervisor agent, also correctly governed by NHI standards, delegated a task that fell within the letter of both agents' permissions. The action being executed is technically authorized. It is also accessing a dataset that nobody intended to make available to this workflow, producing an output that nobody explicitly authorized, via a tool chain that nobody mapped at provisioning time.
Every NHI control fired correctly. The audit log shows compliant behavior at every step.
Something has gone seriously wrong. The NHI governance model cannot see this failure because it is not a credentialing failure, a permission failure, or a lifecycle management failure. It is an intent failure, a divergence between what the original human-authorization covered and what the agent chain produced. Intent is not addressed by the existing NHI governance model. It requires a different layer entirely.
The incumbent identity vendors pushing the "extend NHI to cover AI agents" narrative are not doing so because it's the right architectural answer. They're doing it because it's the answer that fits inside their existing product portfolios, existing architecture and existing models.
If enterprise AI agents’ Identities are “NHIs”, then the enterprise already has the governance infrastructure it needs; it just needs to extend existing licenses, expand existing platforms, and deepen existing vendor relationships. The problem fits neatly inside a category the market already understands, and the vendors that own that category get to own the solution.
This is not a conspiracy. It's a rational business response to a new threat category. Every major technology transition produces the same pattern: incumbents reframe the new problem as a variation of the old problem they already solve. Sometimes they're right. Browser security was an extension of SASE in many ways. Mobile endpoint management really did build on desktop management fundamentals.
Enterprise AI agents are not that kind of transition. When an identity vendor tells you that agent governance is an NHI problem with additional policy controls, ask them this: Can their product tell you whether a specific action taken by an enterprise AI agent at runtime is consistent with the intent of the human authorization that initiated the chain three hops back?
Can their product detect behavioral drift at the intent layer, not just the permission layer?
Can their product maintain identity integrity across a multi-agent workflow where the original human actor has been fully abstracted from the transaction?
The answer, today, is no. Because those capabilities require a fundamentally different architecture, one that was designed for how enterprise AI agents actually operate, not one that was adapted and tweaked from an infrastructure built before they existed.
The vendors extending NHI to cover AI agents may eventually build toward the right answer, but they are not AI Native themselves; they cannot move at AI speed... In the meantime, enterprises deploying AI agents at scale are making architectural decisions based on a governance model that was not designed for the problem they actually have - creating an inherent big exposure risk.
I am not arguing that NHI security is irrelevant for enterprise AI agents. I am arguing that it is a risky side road floor, not the highway - and treating it as sufficient is the architectural mistake that will define a generation of security incidents and failed rollout of agents.
What enterprise AI agents require, beyond NHI, is a governance layer built around three capabilities that NHI was never designed to provide:
Runtime behavioral governance. Not anomaly detection against a static baseline. Continuous observation at the point of operation, understanding what an agent is doing right now, in this workflow, against this data, and whether that behavior is consistent with the authorization context that initiated it.
Intent-aware dynamic controls. The ability to evaluate whether a permitted action is appropriate in context, not just whether it is technically authorized. This requires maintaining a model of agent intent across the execution chain and enforcing controls that respond to intent drift, not just permission violations.
Cross-chain identity integrity. A governance model that maintains accountability across multi-agent chains, tracing the original human authorization through every hop and ensuring that actions at the end of the chain remain within the scope of what was actually authorized at the beginning.
These capabilities require agent-native identity architecture. Not a service account with additional monitoring. Not an OAuth token with a tighter scope. A hybrid identity model that evolves with the execution context, maintains integrity across delegation chains, and enforces controls at the behavioral layer, not just the credential layer.
And here is where the opportunity becomes as important as the risk. Enterprise AI agents carry something no prior identity type ever has: a prompt and a reasoning chain. If you instrument that correctly, the agent's own intent becomes the recipe for what access should actually be granted, not a static policy defined by a human at provisioning time, but a dynamic authorization model derived from what the agent is genuinely trying to accomplish. The agent tells you what it needs. The governance layer validates whether that need is consistent with what was authorized. That is agent-native identity done right, not just securing the agent, but using the agent's own intelligence to make the security smarter.
The identity industry is making architectural decisions about how to govern enterprise AI agents that will be very difficult to reverse once they are embedded in enterprise security programs.
If we commit to the "NHI extended" model, treating enterprise AI agents as a category of non-human identity governed by the same frameworks, we will build programs that pass compliance audits and fail in production. The audit trail will look clean. The agents will be scoped, owned, and rotated. And the failure modes that actually matter - intent drift, chain accountability gaps, cross-protocol visibility blind spots- will accumulate until they produce an incident that makes the architectural gap undeniable.
The enterprises that build the right governance architecture now - one that treats enterprise AI agents as a categorically distinct identity problem requiring a new layer - will be the ones that deploy AI confidently at scale while their peers are explaining incidents to their boards.
Enterprise AI agents’ Identities are not NHIs. They are something new. And they deserve governance infrastructure designed for what they actually are.
Amir Ofek is CEO and Co-Founder of aizome, an Enterprise AI Agent Control Platform. He previously co-founded and led AxoniusX within Axonius and has held leadership positions in cybersecurity for over 20 years.
The latest news, technologies, and resources from our team.
By the end of 2026, most large enterprises will operate a digital workforce of over 1,600 AI agents, according to IBM's Think 2026 survey. That number sounds like progress. It is progress. But it comes with a question most enterprises cannot answer.
Roee Salomon
I've spent a significant part of my career thinking about incident response. Not the playbook version - the real version. The version where something has already gone wrong, the pressure is high, the timeline is compressed, and the team is trying to answer a deceptively simple question: what happened, and how do we stop it from getting worse. With enterprise AI agents, it's about to get categorically harder.
Chris Cochran
If you were working in enterprise security in the early 2010s, you remember the BYOD moment. We are at that moment again. But this time, the thing employees are bringing into the enterprise isn't a device. It's an agent. And the governance gap is significantly larger.
Chen Pipek
OAuth 2.0 is a well-designed protocol. It solved a real problem elegantly, it scaled across the internet, and the patterns it established are genuinely good engineering. It was also designed for a world that no longer describes what enterprise AI agents actually do.
Roee Salomon
SailPoint launched Agentic Fabric. Okta launched its AI Agents blueprint. The message is consistent: extend your existing identity controls to cover AI agents. It's a reasonable instinct. It's also incomplete in a way that matters enormously.
Static policy cannot see context. It can tell you whether an action is permitted. It cannot tell you whether a permitted action is appropriate, right now, in this workflow, for this data, at this moment in the chain. That gap is not a failure of NemoClaw. It's a structural limitation of policy-based security applied to systems that reason and adapt.
Chen Pipek
Occasional, substance-first notes on making enterprise AI agents accountable. No spam; unsubscribe anytime.
