Non-Human Identity Management for MCP Agents

MCP agent identity needs its own playbook, because MCP flips who's in charge of what. MCP, the open standard Anthropic released in late 2024 to connect AI assistants to enterprise tools and data, reverses the usual client-server relationship, with servers now executing actions on behalf of clients in ways that old client-server assumptions weren't built for. That inversion is where old identity assumptions stop holding up. What matters now isn't who's behind a request, it's what this agent is allowed to do, to what, and under what conditions, right now.

The standard runs on JSON-RPC 2.0, uses a shared schema for describing tools, and picked up a formal OAuth 2.1 authorization framework in its 2025 spec updates. Adoption moved fast: more than 16,800 public MCP servers now sit on MCP.so, and Copilot Studio users have collectively built over a million AI agents. Every agent connecting through MCP holds credentials and calls tools on its own, which makes it an identity principal in its own right. It runs a session in its own name.

Non-human identities already outnumbering and outpacing human ones in the enterprise

KPMG's Cybersecurity Considerations 2026 puts the non-human-to-human identity ratio above 80 to 1 in the average enterprise, with machine identities climbing from roughly 50,000 in 2021 to 250,000 in 2025. Other counts land lower, around 45 non-human identities per human, but the direction never changes: that number climbs as agentic AI spreads through the org chart.

The count matters less than the mess causing it. Research cited alongside those figures found that 97% of non-human identities carry excessive privileges, meaning broad access is the default, not the exception. Only 20% of organizations have a formal process for offboarding or revoking API keys, and fewer still bother rotating them. 78% of organizations have no formal policy for AI agent credentials, and IANS Research found 92% doubt their existing IAM tools can even manage the risk. Most security teams aren't behind on a hard problem here. They haven't started it.

MCP agents don't just add to that count, they multiply it. A single agent might hold live credentials for multiple systems at once, so compromising one credential opens doors nobody thought were connected in the first place.

Traditional IAM's design gap for identities that never log out

Human identity management runs on a lifecycle: log in, do something, log out, or time out after sitting idle. None of that applies to a service account or an API key. Nothing expires a credential just because nobody's watching it anymore, and that's the whole problem in one sentence.

Access reviews, in most organizations, get triggered by human events: onboarding a new hire, offboarding someone who quits. AI agents don't generate those events, so permissions pile up quietly and nothing forces anyone to look.

A sales-automation agent holding credentials for a CRM, an email system, a document store, a calendar tool, and an external data provider all at once is a normal setup, not a hypothetical one. Compromise one of those credentials, and an attacker doesn't get a foothold in one system. They get a foothold in all five. That's what happened in the 2025 Salesloft-Drift incident, documented by Obsidian Security: attackers who got hold of OAuth tokens belonging to the Salesloft-owned Drift integration used them to reach Salesforce and Google Workspace environments across hundreds of customer organizations. No scope restrictions, no compartmentalization. The blast radius was about as wide as it could get.

The real gap is structural, and it's the one most teams get backwards. Legacy IAM was built around human identity and role assignment, not around governing autonomous action, so patching it with more roles and more policies doesn't fix the gap, it just adds paperwork on top of it. Shadow AI widens the ungoverned surface further still. The Verizon DBIR found employee use of unapproved AI tools tripled, now touching 45% of the workforce.

The specific threats that emerge when agents hold credentials and call tools autonomously

The MCP specification admits it can't enforce security at the protocol level, that job falls on whoever implements it. NSA guidance goes further, warning that the spec's own security recommendations aren't sufficient on their own. That guidance flags Arbitrary Code Execution as a high-severity risk class in MCP environments, appearing wherever user-supplied logic runs without real constraints (tracked under CWE-77, CWE-78, CWE-94, and CWE-95).

Tool poisoning is the sharpest example, and it's worth understanding in detail because it breaks the exact tool everyone assumes will catch it. OWASP classifies it as MCP03:2025 with a Critical DREAD risk score of 46.5 out of 50. The attack works because a tool's description gets treated by the agent as trusted system metadata, not as user input, so standard scanning tools walk right past it looking for the wrong thing. Invariant Labs demonstrated the danger with proof-of-concept work showing a single poisoned tool description could exfiltrate sensitive data with zero user interaction required. Testing across more than 45 real-world MCP servers found attack success rates above 60%, and the best-performing model in that testing hit 72.8%.

Then there's the rug pull, cataloged as CVE-2025-54136 (CVSS 8.8, disclosed August 2025). The MCP spec doesn't require re-approval when a tool's description changes after the fact, so a host can silently load a new, more dangerous version of a tool the user already trusted once.

Confused deputy attacks follow the same logic from a different angle. An MCP server holds a token authorized by a real user. An injected instruction, buried in a tool result, a GitHub issue, or a Slack message, asks that server to act on the attacker's behalf using the user's own token, and the server has no way to tell the two requests apart. Invariant Labs proved this against the official GitHub MCP server, hijacking an agent into leaking private repository data through a crafted malicious GitHub issue. Between December 2025 and January 2026, a single attacker reportedly used Claude and MCP tools to breach at least six Mexican government agencies.

Infrastructure risk stacks on top of that application-layer risk. CVE-2025-6514 (CVSS 9.6) is an OS command injection flaw in mcp-remote, a package with more than 437,000 downloads, and JFrog Security Research confirmed it as the first fully working remote code execution chain found in a real-world MCP setup. OX Security separately identified architectural design flaws touching more than 7,000 publicly reachable MCP servers. Secrets management isn't helping either: research has found large numbers of credentials sitting exposed in MCP-related configuration files.

What scoped, just-in-time credentials mean for an MCP agent

Scoped credentials mean an agent only holds the minimum token surface its current task needs, nothing more. Every confused-deputy attack described above depends on an over-scoped token sitting around waiting to be abused. Restricting scope isn't a governance nice-to-have, it's the mechanism that actually contains the damage once something goes wrong, and treating it as optional is the mistake that turns a stolen key into five compromised systems instead of one.

Just-in-time access pushes that further: issue the credential the moment a specific tool call happens, then expire it right after. That kills the standing access that makes a stolen API key valuable in the first place, because most of the time, there's nothing standing there to steal.

Agent identity also has to stand apart from the human who set the agent in motion. A credential should trace back to the agent itself, its role, its task, the workflow it came from, rather than just inheriting whatever access the authorizing human happens to have. Two proposals moving through the IETF point this way. One, an individual submission from March 2026 (draft-niyikiza-oauth-attenuating-agent-tokens-00), proposes Attenuating Authorization Tokens: credentials designed so derived tokens can only be more restrictive than the original, never more permissive. Another, from Kasselman and others in 2026 (draft-klrc-aiagent-auth-01), sketches a model for authenticating AI agent interactions using existing OAuth 2.0 and WIMSE standards, covering delegation and agent identity without inventing new protocols from scratch.

Authorization needs to happen at the level of the individual tool call, evaluated continuously rather than fixed once at connection time. Rug pull attacks and silent description swaps are built specifically to slip past that earlier checkpoint. None of this means ripping out the identity providers organizations already run: machine-to-machine authentication for scheduled or triggered agent workflows still flows through Okta, Azure AD, or Google Workspace. The November 2025 MCP spec update (version 2025-11-25) made OAuth 2.1 the formal authentication standard for remote MCP servers and introduced Cross-App Access, extending enterprise identity provider reach into agent-to-application connections alongside the usual user-to-application logins.

The governance layer that makes tool-call-level authorization operational

Every tool call an agent makes should carry the agent's identity, the identity of the human who delegated authority to it, the scope it's operating under, and a timestamp, all recorded somewhere tamper-proof and searchable. OWASP calls the absence of this its own risk category, MCP08, lack of audit and telemetry, because so many MCP deployments leave no forensic trail of what an agent called, with what inputs, and what came back.

A separate IETF effort underway in 2026 proposes an AI Agent Resource Extension for SCIM, treating agent provisioning (creation, scope assignment, deprovisioning) as a formal identity lifecycle instead of something a developer handles ad hoc when they remember to.

Shadow MCP servers are OWASP's MCP09, and they matter here because an employee standing up their own server without security review creates identity surface the security team can't see, let alone govern. A centralized gateway is the fix: it allowlists approved servers, applies one policy across all of them, and inspects every tool invocation passing through, so an unauthorized server can't reach enterprise resources no matter how a developer configured their local setup. Re-consent on tool description changes needs to be a governance policy too, since the spec doesn't require it and the rug pull vulnerability exists precisely because of that gap.

Skipping all this raises the numbers eventually. Research has found that 97% of non-human identities carry excessive privileges, meaning most environments are already out of position before a breach happens. Gartner projects that by 2028, a quarter of enterprise generative AI applications will rack up at least five minor security incidents a year, up from 9% in 2025. Waiting to react is a delay before the incident report lands on someone's desk on that trajectory. It's just a delay before the incident report lands on someone's desk.

Building an NHI management architecture for MCP in practice

Start with discovery, because governance can't cover what nobody's found yet. Credentials found exposed in MCP-related config files represent a discovery failure before they're anything else.

On authentication: OAuth 2.1 with PKCE for remote MCP servers, capability-level scoping so no token covers more than it needs to, short-lived tokens instead of static API keys, and credentials stored in an enterprise vault rather than an environment variable or a config file sitting in plain text. On transport: TLS 1.2 or higher as a floor, mutual TLS between servers, and DNS rebinding protection turned on explicitly, since the MCP TypeScript SDK doesn't enable that by default (per GitHub Security Advisory GHSA-w48q-cv73-mx4w).

Tool validation works best as a pipeline with three stages. Pattern-based filtering catches command and prompt injection. Semantic or neural analysis catches tool description poisoning, which pattern matching misses entirely since the attack targets metadata the model interprets, not user input. LLM-based arbitration handles the edge cases that fall between the two. Agents should get provisioned like any other identity principal, with a formal create, scope, and deprovision cycle, tied into the enterprise directory through SSO and SCIM, with JIT credentials issued per tool-call session instead of sitting around as standing access.

Every tool invocation needs a log entry: parameters, authentication context, what resource got touched, what scope applied. Correlate those events against identity behavior inside the SIEM, and use OTEL tracing to keep a full lineage of requests across workflows where multiple agents talk to each other.

Bolting together a separate agent builder, a separate gateway, and a third-party security tool after the fact is the wrong way to build this. It recreates the same visibility gaps that caused the problem in the first place, just with more vendors billing for the privilege. A single platform that handles enablement and control together does better: broad support across thousands of MCP servers with OAuth and credential handling built in, SSO and SCIM already wired up, JIT credentials as the default, and real-time detection for tool poisoning, prompt injection, and intent drift, all backed by audit logs nobody can quietly edit. The Salesloft-Drift breach and the access-control gap IBM documented share the same root cause: identity governance wasn't part of the integration's foundation from day one. Adding it after deployment always costs more and catches less.