Zero-Trust Agentic Flows: OAuth 2.1 in Remote Tool Execution

A July 2025 internet scan found at least 1,862 publicly accessible MCP instances responding to unauthenticated requests — and that was before the protocol hit mainstream adoption. Today the attack surface is exponentially larger.

The Security Crisis in Remote MCP Deployments

The Model Context Protocol has become the connective tissue of agentic automation in under 18 months. But the security posture of most deployments hasn’t caught up. Research from Clutch Security shows that 53% of deployed MCP servers still rely on insecure long-lived API keys, even though the specification mandates OAuth 2.1 with PKCE for HTTP-based transports. Only 18% implement access scoping for tool permissions. That means the vast majority of remote MCP endpoints are effectively open doors with a “trust me” sign.

The problem runs deeper than lazy configuration. The MCP STDIO transport executes operating system commands without sanitization, enabling remote code execution on vulnerable hosts — a design choice Anthropic has confirmed is intentional and declined to modify. Meanwhile the authorization specification defines an OAuth 2.1 framework but explicitly marks authorization optional, leaving servers exposed without authentication. An April 2026 architectural flaw exposes an estimated 200,000 vulnerable instances across a supply chain encompassing more than 150 million package downloads. These aren’t coding errors in individual products. They’re systemic design defaults embedded in every official SDK.

If you’re running MCP servers beyond localhost, you’re not managing a developer convenience anymore. You’re operating an untrusted execution boundary that needs zero-trust controls by default.

Why OAuth 2.1 Is Now Mandatory, Not Optional

The November 2025 MCP specification mandates OAuth 2.1 with PKCE for all HTTP-based remote servers. This isn’t a suggestion — it’s the protocol’s baseline for any server accessible over the network. OAuth 2.1 with PKCE (S256) is mandatory for all MCP client types, eliminating implicit grants entirely per QubitTool. The practical effect: you can’t just drop a Bearer token in a header and call it done. The flow requires proof-of-possession, short-lived access tokens, and refresh token rotation that actually works.

For teams coming from the “API key in .env” world, this feels like overengineering. It’s not. The alternative is what we’re seeing now: hardcoded credentials in config files, shared service accounts across teams, and zero auditability when something goes wrong. The spec moved to OAuth 2.1 precisely because the previous model couldn’t support enterprise requirements like scoped permissions, token revocation, and compliance-grade audit trails.

The Architecture Shift: Resource Servers, Not Auth Servers

Here’s the architectural principle that separates production deployments from prototypes: production MCP servers must operate as Resource Servers that validate externally-issued tokens, never as Authorization Servers themselves per QubitTool. Your Identity Provider (Azure AD, Okta, Auth0) handles user authentication, consent, and token issuance. Your MCP server focuses exclusively on token validation and scope enforcement.

This separation matters for three reasons. First, it keeps your auth logic out of the MCP server codebase — reducing the blast radius of any vulnerability. Second, it enables centralized policy: when security rotates keys or revokes a compromised token, every MCP server picks up the change without redeployment. Third, it satisfies compliance frameworks (SOC 2, ISO 27001, HIPAA) that require machine-to-machine communication to authenticate both parties and authorize each operation.

Token validation must include JWKS caching with forced-refresh fallback to handle key rotation without downtime per QubitTool. Without this, a routine key rotation at your IdP becomes an availability incident for every agent depending on your MCP servers. The RFC 9728 Protected Resource Metadata endpoint at /.well-known/oauth-protected-resource publishes your server’s requirements so clients can discover them automatically — a small detail that eliminates entire classes of integration bugs.

Enterprise-Managed Authorization: Zero-Touch at Scale

Enterprise-Managed Authorization for MCP reached stable status on June 18, 2026, enabling zero-touch OAuth via IdP-issued JWTs. The technical foundation is the Identity Assertion JWT Authorization Grant (ID-JAG): the client obtains a JWT from the IdP during single sign-on, then exchanges it for an access token from the MCP server’s authorization server — with no per-server consent screen involved. Anthropic implemented it across Claude, Claude Code, and Cowork; Microsoft added support in Visual Studio Code; Okta is the first supported identity provider through its Cross App Access protocol.

What this means in practice: an admin authorizes a connector once through the company identity provider, and every user inherits access on first login, scoped to the groups and roles they already have. The end user does nothing. Their tools are simply there the first time they open Claude. Ramp reports that 2,000 employees are now provisioned across every approved MCP connector through a single Okta policy — with zero additional steps required of any of them.

Zero-standing trust requires agents to request scoped, short-lived credentials for each task, authenticated through OAuth 2.1 and verified at the API gateway. Based on an estimated 10 OAuth grants per agent, an enterprise with 1,000 employees each running 5 agents would manage approximately 50,000 active OAuth tokens [1,000 × 5 × 10] per Netskope. Per Netskope’s estimate, that’s the scale at which manual token management collapses. The EMA flow handles this by making token issuance, rotation, and revocation a centralized IdP function rather than a per-server operational burden.

Mediation Layers and CIMD: Replacing Shared Secrets

CIMD (Client ID Metadata Documents) replaced Dynamic Client Registration (DCR) for MCP client registration by late 2025 per tanhdev. Instead of pushing registration data to the IdP, the agent simply hosts a static JSON file on its domain (e.g., https://agent.example.com/.well-known/oauth-client.json). When the agent requests a token, the IdP pulls this JSON file to verify the agent’s identity. This flips the trust model: the IdP only trusts agents hosted on domains previously whitelisted by the admin.

MCP Server Mediation eliminates shared credentials by placing a governed layer between agents and third-party MCP servers per Gravitee. The agent does not hold a long-lived shared secret. The user authenticates through the enterprise IdP. The mediation layer handles the upstream credential flow required by the third-party MCP server. That means the enterprise keeps control of identity and policy, while the upstream system still receives a valid token it can trust. In practice, this helps organizations use enterprise IAM as the front door for MCP access, avoid shared API keys in agent workflows, enforce authorization at the tool-call level, preserve user and agent accountability, and maintain an audit trail across MCP interactions.

This pattern is essential when connecting to SaaS MCP servers you don’t control — GitHub, Slack, Jira, Salesforce, and internal enterprise systems. Without mediation, every agent connection becomes a credential sprawl problem waiting to happen.

MCP 2.0 and the Stateless Future

MCP 2.0 (2026-07-28 release candidate) makes the protocol core stateless and hardens OAuth 2.1 authorization. The original MCP kept a session per client, requiring sticky sessions, a shared session store, and deep packet inspection at the gateway just to route a request. MCP 2.0 makes the core stateless — each request carries what the server needs, so a remote MCP server can now sit behind a plain round-robin load balancer and scale horizontally like any normal web API. This is the single biggest operability win in the spec: it turns “host an MCP server” from a special-case deployment into a boring one.

Six proposals in the release candidate harden authorization to match how OAuth 2.0 and OpenID Connect are actually deployed: proper refresh-token handling, scope accumulation, and standard client registration (Dynamic Client Registration and Client ID Metadata Documents). The practical effect: connecting an MCP server can be a single Google or GitHub login — no claude_desktop_config.json to edit, no API key to copy and rotate.

Three new building blocks ship as first-class extensions: MCP Apps (server-rendered UIs), Tasks (long-running work), and Server Cards (capability discovery via a .well-known URL). These aren’t security features per se, but they reduce the temptation to build custom auth workarounds when the protocol doesn’t support a use case.

Approach	Auth Model	Scalability	Auditability	Enterprise Ready
Local STDIO	OS-level only	Single machine	None	No
Remote + static keys	Bearer tokens in config	Horizontal (with session store)	Minimal	No
Remote + OAuth 2.1	External IdP, short-lived tokens	Horizontal (stateless in 2.0)	Full	Yes
EMA + Mediation	IdP-issued JWTs, zero-touch	Horizontal, governed	Centralized	Yes

Practical Implementation Checklist

If you’re deploying remote MCP servers today, here’s the minimum viable zero-trust baseline:

1. Enforce OAuth 2.1 with PKCE on every HTTP endpoint. No exceptions for “internal” tools — the July 2025 scan proved internal tools become external exposure fast.
2. Operate as a Resource Server only. Delegate all token issuance to your enterprise IdP. Validate JWKS with caching and forced-refresh fallback.
3. Implement fine-grained scopes (e.g., mcp:tools:read, mcp:tools:write, mcp:admin) and reject wildcard permissions.
4. Deploy a mediation layer for any third-party MCP server connections. This is where tool-call-level authorization and audit logging live.
5. Adopt CIMD for client registration. Host .well-known/oauth-client.json on your agent domains; whitelist those domains in your IdP.
6. Enable RFC 9728 Protected Resource Metadata so clients discover your auth requirements automatically.
7. Plan for MCP 2.0 statelessness. Design your deployment for horizontal scaling behind a standard load balancer — no sticky sessions.

The protocol is moving fast. Amazon WorkSpaces for AI agents became generally available on June 30, 2026, and works with any agent framework using MCP per AWS — a signal that cloud providers are baking MCP into their managed service stacks. Google launched a remote MCP server for Gemini Enterprise the same week. The enterprise control plane is arriving whether you’re ready or not.

The question isn’t whether to adopt zero-trust for agentic workflows. It’s whether you’ll build the governance layer now or retrofit it after the first incident. Given that 53% of servers still ship with hardcoded credentials, the retrofit path is going to be very expensive.

What’s your current MCP auth posture — and which of these controls would break your existing deployments if you enabled them tomorrow?