Non-Human Identity Management for AI Agents
Ask three vendors how an agent should prove who it is, and you'll get three different answers, each incomplete in its own direction. Delegated access means the agent acts on behalf of a specific human, inheriting a scoped slice of that person's permissions. Autonomous identity means the agent carries its own non-human identity, no human anywhere in the chain, while hybrid means both, sometimes in the same session, which means the agent has to keep those two contexts from bleeding into each other. An off-the-shelf IAM tool that manages that separation cleanly has yet to cross my desk. Most don't manage it at all, they just paper over it and hope nobody asks.
Then there's the credential itself. Static API keys are easy to hand out and miserable to rotate; they're also the ones that end up sitting in a GitHub commit or a Slack thread somebody meant to delete and didn't. OAuth 2.0 client credentials are better understood at this point, but the client secret is still a long string of characters sitting somewhere, waiting to be found by whoever looks. Workload identity tokens, the cloud-provider OIDC pattern, offer cryptographic proof of what the workload is at the moment it asks for access, with no stored secret at all. Building something new today means starting here, since everything else is a compromise you're making for legacy reasons, and you should at least know that's what you're doing.
The Salesloft/Drift breach from 2025 is the case everyone in this space keeps circling back to, mostly because it's such a clean illustration of the failure mode. Attackers got hold of OAuth tokens linking the two platforms and walked into Salesforce environments belonging to hundreds of enterprise customers. Nobody had scoped the integration down, nobody had compartmentalized the credentials, and nobody was watching for a token behaving strangely, which is really the whole story in one sentence: the absence of least-privilege scoping and runtime visibility. The same old hole caught an agent walking through it this time, instead of a person.
Permission accumulation is the slower version of the same problem, and it's the one that keeps me up more, honestly. An agent stitching together access across five or six applications can end up holding more combined reach than any single engineer on the team. If nobody assigned ownership up front, nobody can say who signed off on that, or who answers for it when the agent wanders outside its lane. Agentic AI doesn't invent new risk categories so much as inherit the old ones, credential exposure, lateral movement, secrets sprawl, and turn the volume way up. A compromised credential in human hands gets misused once or twice before someone notices something's off, while in an agent's hands, it gets misused a thousand times before lunch.
The governance vacuum most enterprises are operating in right now
IBM's 2025 Cost of a Data Breach report has the number, and it's not subtle: 97% of organizations hit by an AI-related breach had no proper AI access controls in place, and 63% had no AI governance policy at all. Read those together and you get an industry sprinting on adoption while crawling on the plumbing meant to keep any of it from catching fire.
Shadow AI makes the picture worse. The 2026 Verizon Data Breach Investigations Report found employee use of unapproved AI tools nearly tripled year over year, touching close to half the workforce. Every one of those tools spins up its own non-human identities in the background, quietly, without asking permission from anyone in security. Nobody provisioned them, nobody's watching them, and in a lot of cases, nobody even knows they exist.
The lifecycle gap underneath all this is structural. Human access reviews get triggered by onboarding, role changes, an employee leaving, the ordinary churn of running a company, but agents never generate any of those signals on their own. Fire an employee and a deprovisioning workflow kicks off automatically for their accounts; there's no equivalent workflow for the service accounts and API keys that same employee spun up along the way, the ones nobody remembers exist until an auditor asks. Plenty of non-human identities sit unchanged for over a year without review. Roughly half of organizations can't tell you who owns their AI identities, and a fair number aren't even logging when new credentials get created in the first place. Ask most companies running agents today, which is nearly all of them at this point, for their documented strategy on managing the identities those agents generate, and you'll get a shrug, maybe a nervous laugh.
Gartner's forecast draws a straight line from here to there: by 2028, roughly a quarter of enterprise generative AI applications will see multiple security incidents a year, a sharp climb from where things sit now. That's what happens when a gap this wide stays open long enough. Security teams already know this, but what's missing is the infrastructure to close it, and that's the actual subject of everything below.
What a governed AI agent identity lifecycle actually looks like
Start with discovery, since governing something you can't see is a contradiction in terms. The inventory has to cover service accounts, API keys, certificates, OAuth clients, workload tokens, and agent-specific credentials across cloud, SaaS, and whatever's still running on-prem. It has to run continuously, too, because teams are standing up new agents without central review on something close to a daily basis now.
Provisioning should start at least privilege and stay there, rather than wander toward it eventually once someone gets around to tightening things up. Task-scoped grants, permission for one operation against one resource, valid only for the duration of that operation, beat a standing grant every time I've seen the two compared. Swap static secrets for short-lived credentials wherever the stack allows it, with workload identity federation as the default for anything cloud-native. For delegated access specifically, OAuth 2.0 token exchange (RFC 8693) lets an agent trade its own identity token for a scoped access token without ever touching the user's primary credentials, giving you a real cryptographic chain of trust in place of the hope-and-a-handshake most integrations are still running on.
Ownership can't be optional, and I mean that literally. Every non-human identity needs a named human or team responsible for its scope, its behavior, and its eventual shutdown. Skip this step and you end up right back at "who approved this," a year later, staring at a credential nobody remembers creating.
Review and rotation need to run on a calendar, since the triggers that prompt human access reviews simply don't exist for agents. Quarterly reviews, at minimum, stand in for the lifecycle signals agents can't produce on their own, and any credential that can't be made short-lived needs an automated rotation policy sitting behind it, full stop, no exceptions carved out because a legacy system makes it inconvenient.
Deprovisioning ties back to two triggers, and only two: an agent gets retired, or an employee leaves. Offboarding a person should automatically launch an audit of every identity that person created or owned, and sunsetting an agent should revoke every credential and integration it ever touched, immediately, not on some cleanup sprint that keeps getting pushed to next quarter.
Why traditional RBAC falls short and what authorization models actually fit AI agents
RBAC assigns permissions to roles and roles to identities. It works fine as long as the identity has a stable, predictable job, which is exactly the problem: agents don't have stable jobs. Their scope shifts by the minute as they call new tools, chain together sub-agents, and react to whatever a user just typed into a chat box. A role called "data-reader" grants identical access whether the agent is summarizing an internal memo or exporting a customer list to some external API, because the role has no concept of intent whatsoever. It sees a label, hands over the keys, and that's the whole decision process.
Two other models actually fit how agents behave in practice. Relationship-based access control, ReBAC, grants permission based on the relationship between the agent, the resource, and the human the agent's acting for. Give an agent a "viewer" relationship to a project and it can summarize documents all day long, but it has no path to exporting anything external, because that path was never part of the relationship. Attribute-based access control, ABAC, layers in conditions, time of day, data classification, whether a human's actually watching, expressed as policy instead of hard-coded into a role. AWS IAM condition keys, Azure's ABAC expressions, and OPA-based policy engines all handle versions of this, some more granular than others depending on how much time you're willing to sink into the policy language.
Wiring agent authorization into identity providers you already run is more solvable than people expect, at least on the plumbing side. OAuth client credentials and OIDC workload tokens map onto service principal constructs in Entra ID and Okta reasonably well. Okta for AI Agents federates through OIDC and SAML with whatever identity provider a company's already using, so organizations extend agent governance across existing infrastructure instead of ripping it out and starting over. Microsoft Entra offers per-agent IDs and scoped access policies along similar lines.
The real gap sits one layer up, and it's the one nobody's solved yet: neither platform ingests the application-layer telemetry that would confirm an agent's actual behavior at runtime matches what it's registered to do on paper. A separate observability layer needs to watch what the agent actually does against what it's supposed to do, because the identity provider will happily authenticate an agent that's gone completely off-script.
The credential type you pick determines which part of the IAM stack can even govern that agent later on, which is easy to miss when you're just trying to ship something by Friday. Choosing a credential is an authorization decision that deserves the same scrutiny as any other design choice, not something left to whoever's closest to the deploy button that afternoon.
MCP servers as the new identity perimeter, and why they need a governed distribution layer
Anthropic put out the Model Context Protocol in late 2024 to fix one specific headache: how an AI agent finds and calls the right tool without every integration turning into a custom, one-off build. It worked, and it worked fast. SDK downloads hit a very large monthly volume by late 2025, and the protocol now sits under the Linux Foundation.
Enterprise security was never part of that original scope. The original spec shipped with no real authentication framework at all. OAuth 2.1 got bolted on in the March 2025 revision, with more fixes in June, but implementation quality across individual MCP servers still swings wildly depending on who wrote the code that week. The protocol also has no concept of usage limits, so an agent can call the same tool a thousand times in a row, running up real API charges, with nothing anywhere in the spec to say "stop, that's enough."
The math gets uglier fast once you scale it. Ten agents, each needing five tools, produces dozens of point-to-point integrations, and every one of those needs securing, monitoring, and maintaining on its own separate track. Every one of those is also a credential that could leak, a door shadow AI could walk through unnoticed, a hole in an audit trail that everyone assumes exists but nobody actually built.
An MCP gateway is the fix, and there's nothing new about the concept. It's the same problem API gateways solved a decade ago, wearing a different badge this time around. The gateway sits in front of every MCP server, authenticates and authorizes each request an agent makes, routes it, logs it, and enforces rate limits along the way. One choke point turns shadow AI into sanctioned AI, because every connection has to pass through infrastructure someone's actually watching for once. It gives you the audit trail MCP never shipped with: which tool, which agent, on whose behalf, at what time, no guessing involved. And it adds the budget controls the protocol left out entirely, usage caps, cost telemetry, per-team or per-agent quotas. MCP servers need this layer for the same reason APIs needed gateways in the first place: direct, ad hoc connections don't scale, don't audit themselves, and fall apart the moment anyone tries to enforce a policy against them.
What to look for in NHI and MCP governance tooling in 2025 to 2026
Grand View Research pegged the solutions segment at 81.8% of NHI access management revenue in 2025, the biggest share by a wide margin. That tells you what enterprises are actually buying: integrated platforms rather than five point tools duct-taped together and held up with hope. Once you count the moving parts involved in doing this right, that preference stops being surprising and starts looking like common sense.
A few things separate tools built for agent governance from generic NHI products with an AI label slapped on the box. Discovery needs to run continuously and cover service accounts, API keys, OAuth clients, workload tokens, and MCP connections in one inventory, rather than scattered across five dashboards nobody checks at the same time. It needs to plug into the identity providers already in place, Okta or Entra ID through OIDC and SAML, instead of asking a company to rip out infrastructure it already trusts. Authorization needs real ABAC or ReBAC support, not static roles wearing a fresh coat of paint. Runtime threat detection, prompt injection defense, PII and secrets leak prevention, anomaly alerting, needs to live inside the tool itself rather than get bolted on after the fact as an afterthought. Full audit logging of every tool call, every credential use, every access decision is the record a compliance team or incident responder actually reaches for when something breaks at 2am.
A few platforms are worth naming, since "buy something" isn't actionable advice on its own. Kong AI Gateway's v3.12 release, October 2025, added MCP proxy support, OAuth 2.1 aligned to the June 2025 spec, and MCP-specific metrics, which fits anyone already running Kong as their API layer and wants one control plane governing LLM, MCP, and A2A traffic instead of three. Bifrost, built by Maxim AI, is an MCP gateway with audit logging aimed at SOC 2, GDPR, HIPAA, and ISO 27001, and it holds up at high request volumes with real token efficiency gains across multi-server setups, which matters more than it sounds like once your bill shows up. IBM's ContextForge takes a federation approach, built for large organizations whose MCP footprint spans multiple regions or business units. Operant AI keeps showing up across Gartner's AI security coverage on TRiSM, API protection, and MCP gateways specifically, which is its own kind of signal.
Speakeasy belongs on this list too. It's an enterprise AI control plane built to connect, govern, distribute, and watch agents, MCP servers, and agentic skills across an organization. It enforces RBAC and identity through providers companies already run, Okta and Entra ID among them, flags shadow AI and prompt injection as they happen rather than in a report three weeks later, and surfaces cost and usage data for the security, IT, and platform teams who end up owning this problem whether they signed up for it or not. Nobody volunteers for this job, and somebody always gets stuck with it anyway.
For teams that want to build their own layer instead of buying one, open-source options exist: Obot, Microsoft's MCP Gateway, IBM's ContextForge MCP Gateway. The trade-off is the one it always is with build-versus-buy: more control for your team, and more weight on that same team's shoulders to keep it running at 3am when it breaks.
The 2025 numbers put the ratio of non-human identities to humans at 82 to 1 inside the average enterprise. That ratio isn't shrinking on its own, and the tooling gap and the governance vacuum won't close themselves just because everyone's busy shipping the next agent by Friday.
