Wiring MCP Gateway RBAC to Okta and Entra ID Without a Separate Identity Silo

MCP gateways that wire RBAC directly to Okta or Entra ID solve an access-control gap most enterprises haven't noticed they have yet: a gateway that holds its own user records, separate from the identity provider, can't be fully deprovisioned when someone leaves. Group membership and claims get read from the IdP at authentication time, every tool call gets checked against that membership at runtime, and the audit log attributes each call to a named person or agent. Speakeasy, FastMCP Gateway, Microsoft's MCP Gateway, Bifrost, and TrueFoundry all take a run at this problem, with real differences in how deep the enforcement goes.

Why a separate identity silo fails at enterprise scale

An employee leaves the company. But three weeks later, that same employee's credentials are still live inside an MCP gateway, because no one ever told the gateway to listen. This is the offboarding failure that defines the entire problem: a gateway-local principal, a key, a consumer record, a user account that exists only inside the gateway's own database, is fine for a demo and a liability the moment the company has to take someone's access away on short notice.

The root cause is structural. No single team can answer a basic question after an incident: which agent called which tool, under whose authority, touching what data. Autonomous agents now make the calls that used to require a human at a keyboard, and the blast radius of an orphaned credential has grown accordingly.

The MCP protocol's identity foundation

EMA, or Enterprise-Managed Authorization, stabilized in June 2026, and the protocol finally had an answer to this.

The mechanics run in a fixed sequence. Finally, the client exchanges that ID-JAG with the target MCP server's authorization server for an access token. Policy lives at the IdP: whether an employee can reach a given server, and what permissions apply once they're there, gets decided centrally rather than inside each individual server's own logic.

Each ID-JAG is scoped to exactly one destination server. EMA collapses that into one governed admission decision per server.

A related protocol change compounds the shift. The MCP 2026-07-28 specification moves the protocol to a stateless model: it drops protocol-level sessions, and requests now describe themselves through _meta fields, with a requestState token the server hands back to the client for flows that need multiple round trips. That change affects how sessions get tracked and carries security implications a gateway has to account for directly.

On the adoption side, Okta Cross App Access entered Early Access in August 2026, surfacing EMA's ID-JAG grant through the Okta Integration Network catalog for Workforce customers.

The gaps EMA leaves in the gateway's RBAC work

EMA answers one question well: who let the agent in. It says nothing about what that agent can touch once it's inside, or whose name goes on the record afterward. Enterprise MCP authorization ultimately has to answer three questions, and EMA closes out exactly one of them cleanly.

The gap is built into the protocol by design. It never inspects the MCP traffic that follows and has no visibility into the individual tool calls an agent makes once the connection is live. That's a deliberate boundary at the protocol level, and it means the job of watching what happens next falls entirely on whatever sits between the agent and the tools it's calling.

There's a second limitation, separate from the first: Microsoft's own guidance points toward Entra Agent ID, treating an agent the same way the directory treats a human joiner, mover, or leaver, with its own identity, its own permissions, and its own lifecycle.

Because the IdP's involvement ends once the ID-JAG is issued and has no visibility into individual tool calls that follow, the gateway must carry claims from the IdP into every tool call decision and write an audit record for every call. Nothing at the protocol layer does this automatically. EMA is the front door. What happens on every floor after that is the gateway's job, and the rest of this piece is about how that job gets done.

OIDC and SAML federation bringing IdP group membership into the gateway at authentication time

The gateway's first obligation is to consume IdP-issued tokens directly, at the moment of authentication, so that group membership and claims always trace back to the source of truth.

The flow runs on standard rails: OAuth 2.1 paired with OIDC or SAML federation. The gateway validates that token at the boundary and attaches the claims to the session directly, without re-issuing a separate gateway-local credential that would need its own lifecycle management.

Speakeasy's gateway, for instance, reads group assignments from Okta or Entra and treats them as the source of truth for which MCP servers each employee or agent can reach. Supported federation covers OAuth 2.1 with CIMD and EMA plus any SAML or OIDC provider, with joiners, movers, and leavers all handled through IdP sync.

Promote a user to a new role in Okta, and SCIM carries that change through to the gateway automatically, assigning them the right MCP servers without a manual provisioning step.

Mapping IdP claims to per-tool permissions inside the gateway

Getting claims into the gateway session is only half the job. The claim has to turn into a specific, enforceable permission, or the whole exercise is just better-organized paperwork. A group in Okta or Entra needs to translate into an allowlist of specific tools on specific servers, not a blanket pass to everything sitting behind the gateway.

The model runs IdP group to server assignment to tool-level allowlist. The gateway enforces that boundary on every single call, not just at the point of connection.

Speakeasy's implementation assigns a server to an Okta or Entra group, and every member of that group gets the server in their client automatically. Per-team registries carry this further: new joiners inherit access from their IdP group assignment the moment they're added, with the registry already filtered to the tools their role authorizes, so no one has to manually provision a new hire's tool access.

The strongest pushback on tool-level enforcement is that access is already scoped at the MCP server level, so why go deeper? But server-level scoping still leaves every tool inside that server open to every authorized user, so if a Sales employee has legitimate access to a CRM server, they can also call a data-export tool on that same server that their job never requires. Tool-level enforcement is the only way to apply least-privilege inside a server that bundles more than one capability, and most useful MCP servers bundle several.

One more piece belongs here. Each agent gets its own identity with its own scoped roles, and the gateway enforces RBAC against that identity the same way it would for a human.

Enforcing policy at the tool call boundary and catching threats the IdP never sees

Checking permissions at login time catches the obvious cases, but it misses almost everything that actually goes wrong. Runtime enforcement at each tool call is the only point in the chain where prompt injection, PII leakage, and parameter abuse can get caught before they reach a downstream system, because none of those threats appear as a failed login.

Tool poisoning is the threat specific to this protocol: an attacker embeds malicious instructions inside an MCP server's own tool descriptions, and the LLM reads those instructions as legitimate, leaking data or taking actions no one authorized. A gateway stops this: it validates the schema strictly, allowlists tool descriptions, and strips unexpected parameters before any of it reaches the agent's context window.

Catching and stripping that kind of leakage is exactly the kind of work a gateway sitting in the traffic path is positioned to do.

These risks aren't hypothetical. The worst of them, CVE-2025-6514, carried a CVSS score of 9.6 and hit the widely used mcp-remote proxy package, which had logged over 437,000 downloads.

Writing the audit trail so every tool call is attributed to a named identity, not a session token

Most teams have logs. Fewer have attribution, and the difference matters the moment a compliance auditor or an incident responder asks who actually did something. A log entry that records a session token instead of a named employee and a named agent identity is close to useless for either purpose, because a token tells you nothing about who was holding it.

The protocol gives some help here. Because MCP requests are independent and self-describing, intermediaries that terminate TLS can read headers like Mcp-Method and Mcp-Name to identify the operation and the tool involved, without parsing the full JSON-RPC body. Someone, or something, has to correlate the agent or workload identity, the represented user, the policy decision, the downstream action, and the outcome, and the gateway is the only component sitting in a position to join all five.

Speakeasy writes one record per tool call, ties it to a named employee, streams it as OpenTelemetry to whatever collector the team already runs, and exports it to the existing SIEM. There's no window where a deprovisioned identity keeps acting quietly in the background.

Shadow MCP discovery in the IdP-backed governance loop

Shadow MCP servers, the ones employees connect to their AI clients without asking anyone, are only visible if the gateway sits as the mandatory path for all MCP traffic, and only governed once the same IdP-backed RBAC applies to them from the moment they're promoted into the registry.

Speakeasy's flow surfaces every server in use, who's using it, and which tools it exposes, and it blocks unsanctioned servers by default until someone reviews them. The loop runs in sequence: a shadow server surfaces, an admin reviews it, it gets promoted into the registry with a tool allowlist, it gets assigned to an IdP group, members of that group inherit access automatically, and every call after that point is governed and audited.

MoonPay is the clearest production example of this working at scale. The company brought more than 200 MCP servers under an MCP gateway, moving from proof of concept to a company-wide rollout in 30 days, brokering every MCP connection through its existing Okta identity with permissions scoped per server, per tool, and per team. The security team could see across a large number of agent sessions, and unsanctioned shadow MCP servers got blocked by default.

Comparing the gateway options that wire directly to an enterprise IdP today

Most MCP gateways that claim enterprise IdP integration fall short in one of three ways: SSO and RBAC get reserved for a paid tier, enforcement stops at the server level instead of reaching individual tools, or the audit trail requires stitching together multiple separate components. The differences below are drawn from what each option's own documentation confirms.

Speakeasy reads group assignments from Okta or Entra ID as the source of truth for permissions, not just for identity, and supports OAuth 2.1 with CIMD and EMA alongside any SAML or OIDC provider, with joiners, movers, and leavers all handled through IdP sync. Runtime security catches prompt injection and PII in flight, quarantines a session on a policy trip, and surfaces shadow MCP automatically with unsanctioned servers blocked by default. The audit trail writes one record per tool call tied to a named employee, streamed as OpenTelemetry to Datadog, Splunk, or any OTLP collector. The network layer runs on a Tailscale tailnet at a stable private hostname, with MCP tunnels bringing internal servers onto the same governed path and public hostnames returning a 403. A free tier is available, and you can also get an enterprise deployment as a managed service with private network access through Tailscale.

FastMCP Gateway, part of Prefect Horizon, sits between every AI client and every MCP tool, keeping identity anchored in the IdP with OAuth 2.1 and RBAC built into the product. It fits best for teams already building on the FastMCP framework, where deployment is a single git push for FastMCP-built servers, though it also works with any spec-compliant MCP server. Its registry catalogs every internal and third-party MCP server with ownership, versioning, and approval status attached.

Microsoft's MCP Gateway is open source, built as a reverse proxy and management layer, and it targets Kubernetes environments primarily, but you can also deploy it locally or on Azure. SSO, deeper RBAC, and audit retention features vary by tier.

Bifrost, from Maxim AI, is a high-performance open-source AI gateway built in Go, and it's the only option here that handles both LLM routing and MCP tool orchestration from a single binary. Its enterprise tier runs identity-based governance off Okta, Microsoft Entra, Keycloak, Zitadel, Auth0, Google Workspace, or any OIDC provider, with SCIM 2.0 directory sync, and tool filtering per virtual key controls exactly which MCP tools each team, consumer, or workflow can reach. It suits teams that want a combined LLM and MCP gateway in one deployment, though SSO and RBAC sit in the enterprise tier and aren't available in the open-source version.

Across the open-source field generally, SSO, RBAC, and audit retention are the features most commonly held back for a paid tier.

A production-ready IdP-backed MCP gateway deployment end to end

Wiring an MCP gateway to an enterprise IdP correctly is a sequence of five decisions, not a single setting to flip, and the order matters because getting a step wrong creates exactly the kind of silo the whole architecture is meant to prevent.

The first step is to make the gateway the sole ingress point for MCP traffic, so you update firewall rules and service mesh configuration to block any direct agent-to-tool connection that bypasses the gateway. A gateway can't govern traffic it never sees. The second step federates authentication to the IdP, configuring OIDC or SAML so the gateway validates IdP-issued tokens at the boundary and attaches group claims directly to the session, with no gateway-local user record created in the process. The fifth step wires the audit trail to the SIEM or observability stack, confirming that every tool call record carries the named employee or agent identity, the tool, the arguments, the policy decision, and the outcome, streaming all of it to Datadog, Splunk, or any OpenTelemetry collector, and verifying that mover and leaver sync from the IdP actually ends access and logs the termination when it happens.

Before any of this goes live, the diagnostic question from the start of this piece is worth running one more time. If any call still traces back to a gateway-local key or a consumer record the gateway owns independently, the silo problem hasn't been solved. It's just been moved somewhere harder to find.