Enterprise at Scale: MCP’s Emerging Identity and Governance Foundation

What Enterprise Problems Must MCP Deployments Address?

Run an agent-heavy workflow inside a real organization, and you immediately hit questions that per-user, per-tool authorization fails to address:

• How does an agent get credentials without asking the user, especially when the agent needs to access hundreds of systems?
• Who audits what an agent accessed for compliance rather than debugging?
• How do you revoke an agent’s access if it’s compromised? Centrally, not per tool.
• What if an agent needs to run 24/7 without a human present? Who manages its identity?
• How do you enforce policy across agents? “This agent can access production, but only on Tuesdays, and only to read nonsensitive data.”

At their core, these are infrastructure challenges that MCP deployments must address, even when the protocol does not solve them directly.

The 2026-07-28 specification and stable Enterprise-Managed Authorization extension provide stronger building blocks for addressing them.

Is Enterprise-Managed Authorization the Main Inflection Point?

In June 2026, MCP stabilized Enterprise-Managed Authorization, or EMA, a mechanism that lets organizations use an existing identity provider, such as Okta or Microsoft Entra ID, to control employee access to MCP servers.

Here’s the model:

1. An employee signs in to the MCP client through the organization’s identity provider.
2. The client retains the identity assertion issued during that login.
3. The client uses that assertion to request an Identity Assertion JWT Authorization Grant, or ID-JAG, from the identity provider.
4. The client exchanges the ID-JAG with the MCP server’s authorization server for an access token.
5. Policies defined through the identity provider govern whether the employee can access that MCP server and what permissions apply.

The result: centralized control over employee access to approved MCP servers, without requiring each user to complete a separate OAuth flow for every server.

Before EMA, users generally had to authorize each MCP server independently. Repeating that OAuth flow across dozens of services creates significant operational overhead and makes centralized policy harder to enforce.

With EMA, access to approved MCP servers is tied to enterprise user identity and centrally managed policy, shifting server connection from a repeated consent flow into a governance workflow.

EMA is built primarily for employees accessing MCP servers through an approved client. It does not, by itself, establish the workload identity of an autonomous agent running without a user present. The MCP OAuth Client Credentials extension addresses unattended client authentication, while standardized agent identity and delegation remain active areas of development. For a deeper look at these distinctions, see MCP, OAuth 2.1, PKCE, and the Future of AI Authorization.

Why Are Audit and Observability Critical to Infrastructure?

Identity is only half the story. The other half is observability.

EMA centralizes authorization decisions through the identity provider and creates an auditable trail of employee access to MCP servers. But enterprises also need transaction-level visibility into what agents do after access is granted.

In a traditional system, you audit user actions. You log “Alice accessed File X at 2:34 p.m.” Straightforward.

With agents, it’s different. You need to know:

• What did the agent attempt? The action.
• Under what identity? The agent’s OAuth token, workload identity, or other credential.
• Why? Which human request triggered it, or was it an event?
• Did it succeed? What was the outcome?
• Did policy allow it? Was the action compliant?

The stateless architecture of 2026-07-28 helps here. Because requests are independent and carry protocol metadata, infrastructure intermediaries that terminate TLS can use headers such as Mcp-Method and Mcp-Name to identify the operation and, where applicable, the tool or resource involved without parsing the full JSON-RPC body.

Those signals provide useful building blocks for observability, but they do not establish the agent’s identity or create a complete audit trail on their own. Teams still need to correlate MCP activity with the agent or workload identity, represented user, policy decision, downstream action, and outcome.

How Does the Centralized Credential Management Pattern Work?

Here’s where this ties back to Aembit’s domain.

Imagine an organization with 200 agents, 300 backend systems, and a compliance requirement: Every agent action must be auditable and revocable, and agents must never hold static credentials.

A common but risky pattern involves giving each agent its own stored credentials, creating significant work around configuration, rotation, and revocation. If one of those credentials leaks, the blast radius can be difficult to determine because audit records are scattered across 300 systems.

An identity and access platform can address these gaps around MCP:

1. The agent runs with a verifiable workload identity.
2. The agent requests access to an MCP server or another enterprise resource through an identity-aware enforcement point.
3. A platform such as Aembit verifies the agent’s identity and evaluates policy and runtime context.
4. If access is allowed, the platform provides short-lived, scoped credentials for the target resource.
5. The agent uses that access to complete the approved action.
6. The identity, policy decision, credential event, and transaction context are recorded for audit.

MCP standardizes how agents connect to tools and services, while an identity and access layer governs which agents may connect, under whose authority, and with what credentials.

What the Roadmap Implies

MCP’s updated roadmap makes agent identity and enterprise-ready security a priority for the next specification cycle. It acknowledges that MCP authorization today assumes a person approving access in a browser, while more callers are agents running as cloud workloads, acting for users who are not present, or delegating narrower authority to subagents.

Planned work includes Workload Identity Federation, Demonstrating Proof of Possession, or DPoP, ID-JAG, and standard token exchange. These are roadmap priorities rather than current protocol capabilities. EMA is already stable for centrally managing employee access to MCP servers, while standardized agent identity and delegation remain under development.

Together, these efforts show MCP becoming a stronger foundation for enterprise agent connectivity. Identity and access platforms will still be needed to verify agents, combine agent and user context, enforce runtime policy, and govern credential access.

Connecting Back to the Series

We’ve now seen four dimensions of MCP’s evolution:

1. Technical: Stateless and web-native (Part 1)
2. Conceptual: From tools to full agent capabilities (Part 2)
3. Operational: Commodity infrastructure patterns (Part 3)
4. Governance: Enterprise security, identity, and audit (this post)

The final post ties them all together.

Learn More

• Enterprise-Managed Authorization Specification (https://modelcontextprotocol.io/specification/2026-07-28/extensions/enterprise-managed-authorization)
• MCP 2026 Roadmap: Enterprise Readiness Section (https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/)
• Authorization and Security: Latest Updates (https://modelcontextprotocol.io/specification/2026-07-28/#authorization)