Integrating MCP Governance with Existing IAM Systems

Integrating MCP governance with existing IAM systems draws on the same access-control logic enterprises have run for twenty years, pointed at a new kind of identity: the AI agent. Treat MCP servers like first-class citizens in your identity stack, subject to the same policies, roles, and registries that already govern your human users, and you get governed agents without ripping out what you've spent a decade building.

Quick background: MCP, or Model Context Protocol, came out of Anthropic in late 2024, giving AI agents a standard way to call external tools, databases, and APIs instead of every integration being a custom, one-off job. The growth curve since then is hard to overstate: SDK downloads went from roughly 100,000 a month at launch to 97 million a month by March 2026. Infrastructure doesn't usually spread that fast, and security teams haven't caught up.

Here's the identity problem sitting underneath all of it. When an agent connects to enterprise systems through MCP, it becomes what's called a non-human identity, or NHI, and this NHI acts on its own, outlives the user session that spawned it, and moves faster than a person ever could. That breaks three things IAM has counted on for a long time. Access stops being predictable, because agents pick tools dynamically based on whatever reasoning chain they're running, not a fixed role assignment someone approved in advance. Then there's the "confused deputy" problem, where a perfectly valid MCP connection gets hijacked through prompt injection into doing something it was never supposed to do. And permissions stop being static: the same agent might need read access for one task and write access for the next, with nobody in the loop to sign off on the switch.

NHIs already outnumber human identities 17 to 1 in the average enterprise, and that population grew 44% year over year between 2024 and 2025. MCP agents showed up right in the middle of a fight IAM teams were already losing. A 2025 WEF analysis found that 51% of organizations have no clear ownership of AI identities, which is just how most companies are run right now.

Say it plainly: MCP is a connectivity standard, and it doesn't enforce centralized policy on its own. Anything that looks like governance gets bolted on from outside the protocol, by someone, later, usually under pressure.

How the MCP specification evolved to make IAM integration architecturally possible

Early MCP was a developer experiment, and you could tell just by poking at it. Three spec updates between March and November 2025 dragged it toward something you could actually run in production.

March 2025 swapped the original SSE transport for Streamable HTTP, which made remote server deployments workable at all. June 2025 mattered more: OAuth 2.1 with Protected Resource Metadata (RFC 9728) split authentication out from server logic entirely. After that, an MCP server just acts as a plain OAuth resource server, validating tokens issued by whatever authorization server your company already runs, Okta, Entra ID, something homegrown, instead of handling its own auth. November 2025 added OAuth Client ID Metadata Documents as a recommended registration mechanism, which cleaned up how clients identify themselves.

Worth knowing, too: Resource Indicators, from RFC 8707, bind tokens to their intended audience, closing a common confused-deputy vector before it ever reaches your gateway or shows up in your logs.

Here's the catch. Only about 8.5% of MCP servers actually implement OAuth 2.1 with PKCE, even though it's been mandatory for remote servers since November 2025, so most of what's deployed out there hasn't caught up to what the spec now demands. Dynamic Client Registration support across existing OAuth providers is uneven enough that the OAuth proxy pattern, an extra bridging layer nobody loves maintaining, still shows up constantly in real deployments. The spec points the way, but enterprise teams still have to build the bridge themselves.

One more thing that matters more than it sounds like it should: by December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Block, AWS, Google, Microsoft, Cloudflare, and Bloomberg signed on as founding or platinum members. The AAIF hit 170 member organizations within four months, more than double where CNCF stood at the same point in its own life. That's not a vanity number. It means MCP now has a neutral governance body behind it, which is exactly what makes enterprise security teams comfortable building on top of it for the long haul, not just for next quarter.

Enterprise-Managed Authorization: what centralizing MCP access through an IdP actually changes

Before EMA, the per-user model was genuinely rough. Every employee had to manually authorize every MCP server they wanted, one at a time, which turns onboarding into a slog nobody enjoys. Security teams had no central lever to pull; access was whatever each person happened to click "allow" on, with no consistent policy and no single place to check the audit trail. And because there was no forced corporate identity boundary, personal and work accounts blurred together constantly, with people connecting their personal Slack or Notion accounts to work agents without thinking twice.

Enterprise-Managed Authorization fixes the mechanics of that mess. It's stable now, and it lets admins provision MCP server access centrally through the company's identity provider. A user logs in once, and the servers they're entitled to are already connected, scoped to whatever groups and roles they already hold in the directory.

The plumbing works like this: the client gets an Identity Assertion JWT Authorization Grant, an ID-JAG, from the IdP during SSO, then trades that for an access token from the MCP server's authorization server. No consent screen per server, no manual click-through required. Revoke access at the IdP, and it takes effect immediately across every MCP client that user touches, not some scattered cleanup job across a dozen individual server settings.

Three things fall out of this directly. You authorize once and inherit access everywhere through groups and roles you've already set up. You get centralized policy and an actual audit trail sitting in the IdP admin console, instead of guessing. And the personal-versus-enterprise account mixup mostly disappears, since there's no interactive account picker for anyone to fumble.

Okta is the first IdP to support this, through Cross App Access. Anthropic built EMA into its shared MCP layer across Claude, Claude Code, and Cowork. On the server side, Visual Studio Code, Asana, Atlassian, Canva, Figma, Linear, Slack, and Supabase are actively adding support.

Now, the limitation, and it's worth sitting with. EMA governs whether a client can connect to a server, and at what scope, but it doesn't look at MCP traffic after the token gets issued. It's connection-level governance, not runtime authorization for individual agent actions. Once the door opens, EMA stops watching what happens inside the room.

Four integration patterns enterprises are using to extend IAM logic to runtime agent behavior

Because EMA stops at the door, real deployments stack four patterns on top to govern what happens after. These aren't competing choices; most production environments run more than one at once.

The first delegates authentication to the existing IdP. The MCP server acts purely as an OAuth relying party, and an external authorization server, Keycloak, Entra ID, Okta, Auth0, PingFederate, or Cognito, handles token issuance and scope enforcement. You reuse the SSO, MFA, and role assignments already sitting in place, no new identity infrastructure required. Azure AD, Okta, and PingFederate all follow the same OAuth 2.0 and OIDC semantics underneath, so this pattern travels across vendors without forcing you to rewrite your protocol logic every time.

The second puts a gateway in the middle as the enforcement point. It sits between the agents and the tool servers, acting as the single governed entry point for every tool call, authenticating against the existing IdP, enforcing fine-grained scopes, and producing the action-level audit trail that EMA alone never generates. Only a minority of organizations currently use their existing IAM or IdP as the authorization server for their agentic MCP infrastructure, which is exactly why the gateway matters: it closes that gap without rebuilding identity from scratch. Enterprise gateways typically support OAuth 2.1, SAML for SSO, OIDC, and API token management for service accounts. Some enterprise gateway implementations offer centralized access controls, guardrails, and observability sitting between agents and whatever they're trying to touch. Teams building their own stack also have open-source options on GitHub that follow the same single-entry-point, IdP-delegating design.

The third folds MCP into security tooling that already exists. Forward MCP logs into whatever SIEM the security team already runs, Splunk, Microsoft Sentinel, QRadar, so agent activity correlates with everything else instead of sitting in its own silo. Hook MCP output filtering into the enterprise DLP tool, over ICAP or API, so data protection policy applies to agent egress the same way it applies to email or file uploads. Store credentials in the secrets manager already in place, HashiCorp Vault or AWS Secrets Manager, rather than hardcoding them into a server config somewhere and hoping nobody finds it.

The fourth is just-in-time access, scoped tightly to the task at hand. Instead of standing credentials, you issue temporary grants that live only as long as the task itself, which shrinks the window an attacker gets to work with. Decisions weigh more than identity alone: device posture, location, time of day, behavioral signals all factor in. Permissions match the stated purpose of the call, and if risk signals shift mid-task, access gets pulled immediately. This matters most for agents that swing between read and write contexts in the same session; JIT stops a token scoped for reading a document from quietly getting reused to edit it.

AWS has its own variant worth flagging here. Its IAM for managed MCP servers uses context keys, aws:ViaAWSMCPService and aws:CalledViaAWSMCP, paired with VPC endpoint controls, to build layered defense. Organizations reuse the IAM policies they already wrote instead of inventing a parallel permissions model just for AI.

What the MCP server registry does for IAM that OAuth alone cannot

OAuth answers who this is and what token they're holding, but it has nothing to say about which MCP servers even exist in your environment, or whether a given one is sanctioned in the first place. That's a different problem, and it needs a different tool.

The numbers here are stark. Per Practical DevSecOps, 86% of MCP servers run locally on developer machines, and only 5% run in production environments, which means the population of ungoverned, undiscovered servers is large, and growing faster than most security teams can track. A server that isn't in a registry is, functionally, an identity nobody can account for. An IAM policy can't enforce anything on a connection to a server it doesn't know exists.

A registry fills that gap. It keeps an authoritative inventory of approved servers, their scopes, and who owns each one. It becomes the source of truth for which servers are even eligible to receive tokens from the authorization server. It lets policy attach to server identity, not just user identity, so access decisions factor in what the server itself is allowed to expose. And it surfaces shadow servers automatically: anything running that isn't in the registry stands out right away as ungoverned.

The registry-plus-gateway combination can work at scale through the same principle: admins define what's approved, and the gateway enforces it. MCP Manager builds registry in as a first-class piece too, treating every server an agent touches as a registry entry rather than something you inventory after the fact, once something's already gone wrong.

Here's the practical payoff. Teams that give employees a governed, visible path to the tools they actually want, discoverable in a registry and reachable through a gateway, cut down on shadow MCP adoption far more than teams that just try to block everything outright. Blocking creates workarounds, while governed access removes the reason to work around anything in the first place.

Where the integration still has gaps and what they mean operationally

EMA covers the connection, but not what an agent does once it's connected. Organizations that stop at EMA have built a governed front door attached to an ungoverned interior, and that gap gets worse the longer an agent session runs.

That 8.5% OAuth 2.1-with-PKCE rate deserves a second look. It means most of the MCP server ecosystem a team might want to plug into hasn't hit the spec's own security baseline yet, and every third-party server integration carries that risk until somebody actually checks it by hand. Uneven Dynamic Client Registration support across OAuth providers compounds the problem, forcing the OAuth proxy workaround into more deployments than anyone would prefer; that's another layer someone has to own and keep patched.

Adoption itself is still early. A December 2025 survey of 300 senior technical leaders found only 41 to 45 percent of software-industry leaders report even limited production use of MCP, and security concerns remain the top blocker cited. Most teams are pre-integration, and haven't hit these problems yet, though they will.

There's a subtler gap in the audit trail itself. A log you read after an incident gives you a different kind of visibility than real-time awareness of what an agent is doing right now, while it's doing it. Most SIEM integrations, unless the gateway is specifically configured to flag anomalies as they happen, give you the former, and forensics is a poor substitute for active defense.

Multi-agent setups make this harder still. When one agent calls another, you get delegation chains that standard OAuth scopes were never built to model cleanly. JIT access and per-invocation tokens help some, but the tooling for multi-agent delegation is still young, and if a vendor tells you this part is fully solved, ask them to show you the logs.

None of this is purely technical, either. That 51% of organizations with no clear ownership of AI identities points to a process failure, not a tooling gap. Without someone whose actual job is maintaining the integration, even a well-built system rots as new servers get added and old ones get forgotten.

How organizations should sequence the IAM integration work given where the ecosystem is today

Start with inventory, not policy. You can't enforce access controls on servers you don't know exist, so a full registry of every MCP server currently running in your environment comes before any policy gets written down. This is the step teams most want to skip, and it's the one they least should.

Assign an owner to every server in that registry before you write a single policy line. That 51% of organizations with no clear AI identity ownership is a process failure, and no amount of technology fixes a process failure.

Connect the gateway to your existing IdP before expanding the server inventory any further. Every server added after the gateway goes live is governed from the moment it exists, while every server added before it becomes retroactive cleanup, and retroactive cleanup always costs more than doing it right the first time.

Layer in EMA for human-facing MCP access as soon as your IdP supports it. Okta is live today, and Microsoft is actively building support. This alone collapses the per-server consent headache and gives you one place to check for the audit trail.

Add the runtime layer second: DLP integration, SIEM forwarding, JIT credential issuance. These depend on having a gateway to instrument and a registry to point at, so they can't come first, no matter how tempting it is to jump ahead.

And treat that 8.5% OAuth 2.1 implementation rate as a hard vendor evaluation criterion. Before connecting to any third-party MCP server, check its auth posture against the June 2025 baseline yourself, rather than taking a vendor's word for it.

The teams shipping agentic AI fastest right now are the ones who got the gateway and registry standing before the server sprawl started, so every new connection had a governed path to production from day one, instead of debt somebody has to pay down later.