Non-Human Identity Management for Enterprise AI Agents

How the five agent identity types differ

Enterprise AI agents now outnumber human identities in most companies' access systems, and almost nobody built their controls with that math in mind. The average enterprise held roughly 50,000 machine identities in 2021. By 2025 that number hit 250,000. The ratio of non-human identities to human ones sits above 80 to 1 in a typical enterprise, north of 90 to 1 in plenty of others. Traditional identity and access management assumed whoever's authenticating is a person with a face, a laptop, and a shift that ends. Agents break that assumption completely, so a human-shaped governance model isn't something you stretch to fit them. It has to be replaced.

Enterprise deployments repeatedly show five identity types, and treating them the same is the mistake almost everyone makes. Not all agents carry the same risk, so handing them the same permissions template is wrong from the start.

Copilots sit next to a human who stays in the loop and makes the final call. Their permission surface can stay narrow, because someone's there to catch a bad suggestion before it becomes a bad action.

Autonomous agents don't get that safety net. They act on their own within a defined task, with no approval step in between. A misconfigured one has a bigger blast radius, because nobody's watching the output before it fires.

Orchestrators coordinate other agents, which makes their identity a trust anchor for everything downstream. Compromise an orchestrator and the damage spreads to every sub-agent that trusted it.

Ephemeral sub-agents spin up for a single workflow step and get torn down right after. The risk here is lifecycle. Nobody tracking when these things spawn and die is how orphaned credentials pile up fast.

Agent-as-a-service identities serve many users or teams at once. A breach in multi-tenant boundaries lets one tenant's data leak into another's session, and that's the exact failure mode to design against.

Collapse these five into one blob and risks that don't belong together get conflated. A shared credential across an orchestrator and an ephemeral sub-agent means a single leaked key compromises a coordination layer and a disposable task-runner in the same breath, and those are two very different categories of bad day. The fix follows directly from the taxonomy: every agent gets its own identity, no shared credentials, and a named human owner accountable for what it does. Default to deny. Give read-only access wherever the task allows it, and scope every permission to the intersection of what the user can do, what the agent is built to do, and what the specific task requires. Nothing wider than that.

What happens when agents are over-privileged and under-observed

An MCP server gets configured with broad permissions during development because it's faster to build that way, and nobody circles back to tighten it once the thing ships. That's the pattern behind most of the trouble that follows.

A code-generation agent gets write access to production repos when all it ever needed was read access to a single feature branch. A database agent runs with admin-level credentials when read access on three specific tables would've covered every task it's asked to do. A CRM agent holds full API access when its entire job is looking up contact records. None of these are exotic edge cases. They're the default state of a huge share of agent deployments right now. A small misfire turns into a large one because of that.

The visibility numbers explain why nobody catches this before it becomes a problem. Research has found that only a small fraction of MCP server deployments implement any form of access scoping for tool permissions. Worse, research indicates that more than half of MCP servers expose credentials through hard-coded values sitting right in configuration files, so anyone who can read the config can act as the agent. A Cloud Security Alliance survey found that 80% of IT leaders say they've watched an agent act outside its expected behavior. Give a system permissions wider than the task ever called for. That's the outcome you get, reliably, not occasionally.

Why MCP's architecture is the natural intervention point for NHI governance

Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI models to external tools and data. In December 2025, MCP moved to the Agentic AI Foundation under the Linux Foundation, making it vendor-neutral and governed by the community rather than any single company. The foundation was co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it as supporting members. That coalition says something about how central this protocol has become to how agents actually operate in production.

The detail that matters most for governance is architectural, and it's a simple one. An AI agent never touches a system directly. It asks the MCP server to perform the action on its behalf, and the server enforces every local security and permission boundary before it returns a result. That single fact makes the MCP server the natural chokepoint for scoped permissions: every tool call passes through a defined, inspectable interface instead of some one-off API integration nobody documented.

The architecture breaks into three tiers, and each one carries its own governance job. The host, the AI application or agent itself, initializes clients, enforces user-level permissions, and presents results back to whoever's using it. The client lives inside the host and acts as a protocol adapter, converting model calls into structured JSON-RPC 2.0 requests. The server is the capability provider: it executes the operation and hands back structured data, and it doesn't need to know or care which model sent the request. That separation is why governance belongs at the server layer. It's the one place where every request, regardless of source, has to pass through the same gate.

Authentication evolution: from API keys to Enterprise-Managed Authorization

API keys were the starting point for MCP authentication, and they were never built to carry this much weight. Static credentials create audit gaps that grow more serious as deployments scale. Once an organization mixes a static-credential auth method with OAuth-protected production servers, the audit trail develops gaps nobody notices until something goes wrong.

Mixing credential types is a real governance gap, not a cosmetic one. A community-built server authenticating with a bare API key sitting right next to a production server locked down with OAuth means one part of the system is far easier to compromise than the rest, and attackers go looking for exactly that kind of seam. OAuth 2.1 with PKCE has emerged as the stronger approach for remote, multi-user enterprise servers, offering tighter controls than static credential methods. Anything less tends to be a stopgap dressed up as a solution.

The protocol caught up to this reality on July 28, 2026, with a spec revision that Anthropic technical staff member David Soria Parra called the most substantial change to MCP since authorization was first added. The revision deprecated dynamic client registration in favor of Client ID Metadata Documents and made client credentials issuer-bound, so a credential minted by one authorization server can't get replayed against another. These sound like small technical details, but they close the exact gap that mixed-credential environments used to leave wide open.

What a purpose-built NHI governance layer for MCP-connected agents requires

Connectivity and governance are not the same thing, and they diverge across four capabilities. Skipping any one of these leaves an organization with a bunch of agents that can talk to systems, not a system anyone's actually governing.

Verification means the right people and the right models can call the right tools with the right permissions. No ambient access left over from a development sandbox, no capability inherited by accident because nobody turned it off.

Inventory means knowing, at any given moment, which MCP servers are running, what version each one is on, and what actions each is authorized to perform. Tracked continuously, not reconstructed once a year during an audit everyone dreads.

Security assurance means automated scanning, signing, and certification, confirming a server isn't malicious or misconfigured before it ever touches production. Checked once and left alone, it provides no assurance.

Observability means every tool call is visible and auditable in real time, not reconstructed after an incident from whatever logs happen to survive.

One principle connects all four, and it's the one that gets skipped constantly: permissions should be inherited from the source system, not redefined at the agent layer. When an agent queries a database or a document store, the response it gets back should reflect what the requesting user already has access to, not whatever broad credential the agent happens to be running under. Redefine access control by hand every time a new AI tool gets deployed, and permission drift sets in everywhere nobody's looking. Past a certain scale, keeping pace with it by hand is not a staffing problem; it's a mathematical impossibility.

Every agent action needs to be auditable down to specifics: who approved which tool call, under which version of which server, at what time. Without that level of detail, governance sits unread as a policy document in a drive somewhere, unable to function as an actual control. What makes this tractable at scale is a governed registry for MCP servers and agent skills, built around version control (a change to a tool's permission surface gets tracked and reviewed, not slipped in quietly), ownership (a named team or person accountable for how each server behaves), and access scoping (a skill published for the whole company doesn't automatically become available to every agent at every permission level).

How to evaluate NHI governance platforms for agentic AI

Most buyers ask which platform connects to the most MCP servers. Wrong question. What matters is which platform treats MCP as a surface to govern, rather than a feature that just makes connectivity easier, because connectivity was never the hard part.

Start with inheritance. Does the platform automatically sync access controls from source systems, or does it make administrators redefine permissions by hand for every new tool? The second answer amounts to a staffing problem disguised as a product feature, and it will lose the race against agent sprawl every time.

Scoping comes next. Can each department get its own scoped MCP server, with its own access boundaries, without someone building a custom integration to make that happen? If the answer involves engineering time per department, the platform doesn't scale past a handful of teams.

A registry is non-negotiable. Is there an actual, versioned system, owned by named teams, where skills and servers live and get discovered? Or does sharing still happen through a shared drive and a Slack message that gets buried in twenty minutes, which is how duplicate work multiplies across a large org?

Auditability decides whether an incident review takes an afternoon or a month. Is every tool call logged with enough context to answer who approved what, and when, without an engineering team building a custom observability stack from scratch?

Consistency across surfaces matters just as much as any single feature. Does governed context travel the same way across Claude, ChatGPT, Cursor, Slack, and whatever custom agents the organization built in-house, or does each surface need its own separate permission setup that nobody has time to maintain? And model agnosticism belongs on the list for a blunt reason: governance controls that only work with one model vendor become a liability the moment the organization wants to add or switch models, and that moment comes faster than most teams plan for.

A platform that gives every team its own scoped MCP server, backed by a shared registry, means a skill one team builds gets found and reused by another team, without anyone re-prompting the same task from scratch or re-permissioning it from zero. That's the direct fix for the duplicate-work tax that identity sprawl creates.

Infrastructure adoption is already settled. Infrastructure adoption is already settled, but governance of AI agents remains unresolved. 78% of enterprise AI teams with 50 or more AI and ML practitioners report at least one MCP-backed agent running in production, up from 31% just a year before, and 64% of large enterprises run a custom internal MCP server of their own. The build-out is happening regardless of whether governance keeps pace with it, and that gap, not the connectivity race, is the actual work left to do.