Updated June 2026

The Model Context Protocol team shipped Enterprise-Managed Authorization last week: a stable extension that lets organizations provision MCP server access through their existing identity provider. Users log in once with corporate SSO, and the servers their organization has approved are available automatically. No per-app OAuth prompts, no IT tickets for each new tool, and centralized revocation when someone leaves.

If you've tried to roll out MCP tooling to a team, you know how much friction individual OAuth flows create. EMA removes that friction in a way that scales, and solving it at the protocol level is the right approach.

But SSO is the entry point to governance, not governance itself. The real point of an identity provider is controlling what people can do, not just letting them in. After two months of running an MCP gateway in production across our own team, we've learned what it actually takes to govern access once a user is connected.

This blog covers what needs to exist above EMA to close that gap.

Agents should have less access than the humans who created them

When a user connects to an MCP server, EMA determines whether they're authorized. What happens from there is outside EMA's scope, and the specification says so explicitly:

"The visibility the IdP has between the MCP Client and MCP Server is limited to the process of issuing the access token, but does not extend to the actual MCP traffic between the MCP Client and Server."

That's a structural constraint, not an oversight; EMA is an authorization extension. The governance question it leaves open, however, is: once a user is connected, what can they (and anything acting on their behalf) actually do?

The default answer right now is that a user can access everything the server exposes. A Snowflake MCP server might expose tools for running queries, inserting rows, managing schemas, and administering permissions. Connecting gives a user (and any agent running under their identity) full access to all of it.

That creates two problems that need to be solved at different levels.

1. Human users should have different levels of access depending on their role. A data analyst should be able to run queries but not drop tables. A design contractor should have Figma access but not your production database. EMA can tell you who connected. It can't enforce those distinctions.

2. Some operations shouldn't be allowed to be delegated to AI agents at all, regardless of what the human user is permitted to do. A human engineer having production database write access is a deliberate decision made with accountability in mind. An AI agent inheriting that access automatically is a different thing entirely. Some destructive operations probably shouldn't be available to AI tools, period, even when the human who created the agent has those permissions themselves.

Your IdP sees a connection event from a human identity, and it currently has no way to distinguish that from an agent acting autonomously under the same identity. Separating agent permissions from human permissions requires a layer that sits between the user and the server (one that can evaluate not just who is connecting, but what kind of principal is making each call).

How we approached it

We treat human users and agents as distinct identity classes. Human users authenticate with Aptible JWTs; agents authenticate with per-agent API tokens. Robot users are restricted to shared-mode servers only and cannot access personal credentials. The audit log records who made each tool call, and can be filtered to human and robot identities. Without this MCP-specific audit log, it can be impossible to distinguish agent activity from human activity in the audit logs of downstream APIs.

EMA doesn't prescribe how clients should handle agent identity, which means teams deploying EMA still need to make that call themselves.

If this is a visceral problem for your team, we have a guide on how to create robot identities for agents.

Tool-level access, not just server-level access

EMA governs which servers a user can reach. The next layer is governing what they can do inside those servers.

A typical MCP server doesn't expose one capability: it exposes dozens, spanning read-only queries, write operations, and destructive or admin-level actions. Granting a user access to a server is an all-or-nothing decision at the EMA layer. Fine-grained control requires a gateway that can enforce policies at the tool level.

How we approached it

With enough MCP servers in play, even defining those policies becomes a problem. We connected our gateway to ten-plus servers covering GitHub, Notion, Shortcut, Snowflake, Pylon, Sentry, and Metabase. Reviewing every tool definition manually to set access policies isn't feasible at that scale.

We ended up building automated classification: tools are categorized (with help from the LLM) as read-only, write, destructive, or admin based on their definitions, so access policies can be set at the category level rather than per-tool. An analyst gets read-only access to Snowflake without any risk of write or destructive privileges leaking through.

The Authorization Interest Group inside the MCP org (co-facilitated by Anthropic, Okta, and Amazon) is actively working on the protocol-level answer to this: two active working groups on per-tool OAuth scope advertisement and fine-grained authorization using Rich Authorization Requests (RFC 9396). That work is ongoing with no committed delivery dates. In the meantime, it has to be solved at the gateway layer.

MCP tool call audit trails

Your IdP produces an audit trail showing connection events: who authenticated, when tokens were issued, and when access was revoked. EMA extends that to cover which MCP servers a user connected to.

What it can't capture is runtime behavior: which tools were called, with what arguments, whether the operation succeeded, and whether the caller was a human or an agent. Those are different artifacts, and they can only be captured at the point of tool execution.

Consider what you'd need to answer basic questions after an incident:

• Which agent called execute_query on the Snowflake server yesterday between 2pm and 4pm?

• Did the call to send_message include any customer PII in the arguments?

• Did a destructive operation succeed or fail?

• Was the caller a human or an automated agent?

None of those are questions your IdP can answer. Authentication telemetry doesn't include tool arguments, response payloads, or the distinction between a human session and an agent acting on behalf of that human.

For regulated industries this has direct compliance implications: HIPAA requires an audit trail of who accessed what, not just who connected to what. But it's not only a regulated-industry problem. Any organization that has run an incident investigation knows the difference between knowing someone had access and knowing what they actually did.

The MCP org's own published roadmap names this as an unresolved priority:

"Audit trails and observability: end-to-end visibility into what a client requested and what a server did, in a form enterprises can feed into their existing logging and compliance pipelines."

An Enterprise Working Group is expected to form to own this work, but it hasn't yet. WorkOS independently identified the same four gaps (audit trails, authentication, gateway patterns, and configuration portability) and called audit logging "pre-RFC problems requiring community input rather than finished specifications."

A dedicated security scan we ran on our own gateway after deployment reinforced why this matters: we found an audit log bypass where crafted User-Agent headers caused log records to fail silently: a tool call would execute and leave no trace. We also found a token scope issue where read-only credentials could still execute tool calls because the scope check was missing in the proxy layer. These vulnerabilities were in a production system built by a security-conscious team, and they weren't visible until we were actually logging.

How we approached it

Our audit log captures per tool call: who called it (user ID and email), which tool, the full arguments encrypted at rest, IP address, user agent, server name, and timestamp. The server name is stored as an immutable snapshot so records survive server deletion or renames. The log fires before the upstream tool call executes, so it records the attempt regardless of whether the call succeeds.

For a detailed walkthrough of how to implement MCP audit logging, see our guide to MCP audit logging.

Where the ecosystem is heading

Several active working groups inside the MCP org are building toward the same problems.

The Interceptors Working Group (chartered April 2026, led by engineers from Bloomberg, Saxo Bank, and Nordstrom) is building a standardized spec for validators and mutators that intercept tool calls, resource reads, sampling, and elicitation. Audit logging is one of their three named reference interceptors. Their charter describes the current state directly: "the ecosystem is developing a sprawling landscape of sidecars, proxies, and gateways for cross-cutting concerns that are largely non-reusable and non-interoperable."

The Security Interest Group (facilitated by Anthropic, chartered June 2026) explicitly scopes "auditability and observability: requirements for tamper-evident records of what a tool call did and under what authority, for compliance and incident review."

On the product side, several teams are converging on the same model. Bifrost combines an LLM gateway, MCP gateway, and on-device endpoint agent into an integrated governance suite. Prefect Horizon offers tool-level RBAC tied to enterprise IdPs. MCP Guardian is an open-source proxy that surfaces the developer-level need for per-call visibility, even if it's not enterprise-ready.

The protocol work to standardize these layers is underway. The open question is timeline: active specification work is not the same as shipped infrastructure, and none of the working groups building toward these primitives have committed delivery dates.

What to do now

Implement EMA if you have the means to do so. Centralizing server provisioning through your IdP is a real improvement over per-user OAuth, and it's the right foundation for everything that comes after. Start there.

Then build the governance layer above it. The questions that matter most in an enterprise MCP deployment (what tools each user and agent can actually call, and what record exists of what happened) require infrastructure that sits between your users and your servers.

If you're working through the design decisions, our MCP security guide covers tool-level access control, audit logging, credential management, and agent identity in detail, including the tradeoffs we encountered building this for our own team. The chapter on deploying MCP for teams is the most relevant starting point for enterprise deployments.

If you want to skip the build, we're inviting teams to join the waitlist for the Aptible MCP Gateway.