MCP Enterprise Authorization Improves Entra Access but Leaves AI Agent Audit Gaps

Duraphe's subject is the Model Context Protocol (MCP), the open standard that connects AI applications to tools and data. MCP recently gained a real enterprise identity feature. His point is that controlling an agent's access is not the same as keeping a record of what it did. For Windows admins running Entra ID, VS Code and GitHub Copilot, that difference matters.

What IAPP is arguing​

IAPP's summary says MCP improves AI agent access controls but lacks built-in tracing and logging standards, which leaves enterprises with accountability and compliance gaps. Duraphe gives the protocol credit first:

• MCP as plumbing. He compares MCP to a USB-C port for AI applications: one common connector for linking agents to internal and external data sources. Before it, each AI vendor wired agents into company systems in its own incompatible way.
• Not something you buy. MCP isn't a product or a vendor. Duraphe says it sits underneath most agent deployments today, whether or not anyone in governance has heard of it. That "most deployments" claim is his characterization, not a measured market share.
• The identity upgrade. He calls MCP's new enterprise-managed authorization "a real upgrade." Organizations can now control agent access centrally through identity providers such as Okta or Microsoft Entra ID, and grant or revoke it the way they would for a user or service account.

His summary of the change is that connecting an agent to company systems used to depend on trust, and is now an enforceable policy decision. The rest of the piece is behind IAPP's member paywall. Its stated thesis is the gap between that access control and actual accountability.

Section summary: IAPP's argument isn't that MCP security is broken. It's that the industry fixed the "who may connect" question and left the "what actually happened" question largely open.

The authorization change, verified​

The feature IAPP praises is real and recent. The MCP project announced that the Enterprise-Managed Authorization extension to the Model Context Protocol is now stable, enabling organizations to centrally provision MCP server access through their identity provider so users get connected servers on first login without per-app OAuth. Several outlets, MCP.Directory among them, report it was promoted to stable on June 18, 2026. The maintainers say the extension is being adopted by Anthropic, Microsoft, Okta and a growing number of MCP servers.

Here is how it works. Under the original model, every employee approved every MCP server with a separate OAuth consent. The extension, identified in the protocol as io.modelcontextprotocol/enterprise-managed-authorization, makes the company's identity provider the decision-maker. The documented flow:

1. The user signs in to the MCP client through the corporate identity provider.
2. The client keeps the identity assertion from that sign-in (an OpenID ID Token or a SAML assertion).
3. The client exchanges it with the identity provider for an Identity Assertion JWT Authorization Grant (ID-JAG). This is where the identity provider checks policy: group membership, roles and conditional access.
4. The client presents the ID-JAG to the MCP server's authorization server, which validates it and issues an MCP access token.
5. Later tool calls use that access token. The user never sees a per-server consent screen.

Microsoft's own Tech Community coverage puts it this way: EMA makes the organization's identity provider the policy decision point, replaces repeated server-by-server browser prompts with an identity assertion grant, and gives security teams a central place to grant and revoke access. The same post notes that the stable extension uses OAuth token exchange semantics from RFC 8693.

Where Windows and Microsoft shops stand​

Developers on Windows will see this first in VS Code. According to WorkOS, VS Code 1.123, released June 3, 2026, shipped enterprise-managed MCP authentication in preview: admins configure the IdP through a policy-managed mcp.enterpriseManagedAuth.idp setting, and individual servers opt in with "enterpriseManaged": true in their oauth block. Developer Hidde de Smet reports that the release shipped with Entra ID, Okta, and Auth0 all supported out of the box.

The Entra ID picture is less settled than IAPP's wording suggests:

• The MCP launch announcement named Okta, through its Cross App Access feature, as the first supported identity provider.
• MCP.Directory said at launch that Okta is the only shipped IdP integration.
• Microsoft's Tech Community post is framed as what Entra and App Service provide today, what ID-JAG adds. That suggests Entra customers may be working with a mix of existing capabilities and the new grant type, not a finished turnkey EMA integration.

Before you tell leadership that "Entra now governs our agents," check each client, each server and the identity provider in your actual deployment. The official extension documentation says client support varies, and that extensions are opt-in and never active by default. A server also has to participate: it must declare the extension in its authorization metadata, and its authorization server must validate ID-JAGs.

Section summary: For Microsoft-centric organizations the pieces exist, but some are in preview and support differs across products. Treat "supports EMA" as something to verify for each component.

Why access control isn't an audit trail​

This is the core of IAPP's argument. EMA answers an access question: was this user, through this client, allowed to get a token for this server? It doesn't, by itself, record:

• which tools the agent actually called during a task
• what the user originally asked for
• why the model picked each action
• what each call returned, and how the results shaped the final output

The MCP launch post itself promises centralized policy, with "one auditable trail across every connector." But that trail covers access decisions recorded in the identity provider's admin console, not agent behavior. In most identity systems, the log of who received a token is a different record from what the agent did with it.

MCP's design makes this harder to fill in afterwards. The latest specification revision, dated 2026-07-28, goes stateless, so servers can't infer context from earlier requests. Any link across a multi-step agent run has to be carried explicitly, through correlation identifiers and logging in the client, any gateway, the server and downstream systems. The protocol isn't completely blind to telemetry: it has a metadata envelope for this kind of context. But a field that can carry a trace identifier doesn't guarantee a retained record your incident team can query.

The project's own security policy sets the same expectations. It says the language model may invoke tools in ways the user did not explicitly request, and treats that as expected behavior, not a vulnerability. It assigns server developers responsibility for access controls and input validation, client developers for showing tool invocations to users, and operators for configuring restrictions. Put simply, the protocol leaves accountability to whoever implements it.

The community is working on it, slowly​

A public MCP GitHub discussion, #2704, proposes optional audit-context fields carried in request metadata:

The proposal comes with sensible caveats. The model name is client-asserted and can be spoofed. Free-text rationales can be inaccurate. User intent may contain personal data. None of these fields should be used as authorization evidence. One contributor added that this kind of input audit (what the AI said it was doing) needs to be paired with a server-side decision record (what was allowed, under which rule). Otherwise you can only show that the agent claimed it needed access. The author explicitly says the proposal is not driven by GDPR or a requirement from OWASP or NIST. It is still a discussion, not part of the standard.

What IT teams should do now​

The following checklist is my analysis, drawn from the documentation above. MCP does not mandate it.

1. Inventory your MCP clients and servers. Include VS Code, Claude clients, Copilot-adjacent tooling and any homegrown servers. Record which ones support EMA and which have it turned on.
2. Confirm your identity provider's real support level. If you run Entra ID, check whether the flows you rely on are generally available or still in preview.
3. Test revocation end to end. Revoke a test user in the identity provider, then check whether existing access tokens on live clients actually stop working.
4. Map where agent actions are logged. Cover the identity provider, the client or host, any gateway, the MCP server and the downstream system. Then ask whether one agent run can be joined across all of those layers.
5. Decide what you retain. Prompts and model rationales are both sensitive and unreliable. Set redaction, retention periods and reviewer access before you start storing them, not after an incident.
6. Don't rely on anything self-reported. A model name or a generated "reason" doesn't prove a person authorized an action.

The bottom line​

IAPP is right to separate permission from accountability. EMA is a real improvement and closes a gap enterprises have complained about since MCP arrived. But a centrally approved token tells you an agent was allowed through the door, not what it did inside. Until the protocol standardizes run-level audit context, or your vendors provide it, building that record is your job.