Only 8.5% of MCP Servers Use OAuth

The Model Context Protocol has a security problem that no RSAC keynote is going to fix. It is not a theoretical vulnerability buried in an academic paper. It is arithmetic.

Out of 5,200+ MCP servers cataloged across public registries, community repositories, and enterprise deployments, 88% require some form of credentials to function. More than half — 53% — rely on static API keys passed through environment variables or configuration files. And the number that implement OAuth, the authentication standard that every security team insists on? 8.5%.

That gap between what the industry demands and what the ecosystem delivers is where the real risk lives.

The numbers behind the gap

The data comes from scanning MCP server manifests, README files, configuration schemas, and actual runtime behavior across the major registries: the official MCP server list, Smithery, Glama, PulseMCP, and OpenTools. The methodology counted any server that references API keys, tokens, OAuth flows, or credential configuration in its setup documentation or transport layer.

Here is what the scan revealed:

• 88% require credentials of some kind to connect to their backing service (database, SaaS API, cloud provider)
• 53% use static API keys — hardcoded in environment variables, passed through stdin transport, or stored in plain-text config files
• 8.5% implement OAuth — meaning they support proper token exchange, refresh flows, and scoped authorization
• 35% use other credential patterns — basic auth, service account JSON files, connection strings with embedded passwords
• 12% need no authentication — these are local-only tools (filesystem, SQLite) or read-only public data sources

The 30+ CVEs filed against MCP implementations in the past 60 days reinforce these numbers. Prompt injection leading to credential exfiltration. Server-side request forgery through tool arguments. Rug-pull attacks where servers modify their tool descriptions after initial approval. The common thread is not clever exploitation — it is that the authentication and authorization surface was never properly locked down in the first place.

Static API keys are the biggest offender. When an MCP server expects OPENAI_API_KEY or STRIPE_SECRET_KEY as an environment variable, that key typically has the same permissions regardless of which agent calls the tool, which user initiated the request, or what operation is being performed. There is no scoping, no rotation, no audit trail, and no revocation path that does not involve redeploying the entire server.

Why RSAC vendors are solving the wrong half

RSA Conference 2026 brought a wave of MCP security announcements. At least six vendors — spanning identity providers, API security platforms, and dedicated agent governance startups — announced products targeting MCP. The common pitch: policy engines that sit between your AI agents and the MCP servers they call, enforcing rules about which tools can be invoked, what arguments are acceptable, and how results are filtered.

This is valuable work. But it addresses agent-to-gateway governance while largely ignoring the gateway-to-server authentication problem.

Consider the typical architecture these vendors propose:

Agent --> [Policy Engine] --> MCP Server --> External Service

The policy engine validates that the agent is allowed to call a particular tool. It might check that the tool’s arguments do not contain SQL injection patterns or that the agent’s role permits write operations. But when the request reaches the MCP server, that server still authenticates to its backing service using the same static API key it has always used. The policy engine has no opinion about — and no control over — how that last-mile authentication works.

This means:

1. No per-agent credential isolation. Ten agents calling the same Slack MCP server all share one bot token. If any agent is compromised, the blast radius is every channel that token can access.
2. No credential rotation without downtime. Rotating the API key means updating the environment variable on every server instance and restarting. In practice, keys do not get rotated.
3. No audit trail linking actions to agents. The external service sees one set of credentials regardless of which agent — or which user behind that agent — made the request.
4. No scoping by operation. The same key that reads a Jira ticket can also delete one. The policy engine might block the delete at the gateway, but the credentials themselves permit it.

The RSAC vendors are not wrong. Agent governance matters. But governance without proper authentication is a guardrail on a bridge with no foundation.

The gateway architecture: centralizing authentication

The pattern that addresses both halves of the problem is the MCP gateway — a proxy layer that terminates agent connections on one side and manages server authentication on the other.

Agent --[OAuth/token]--> Gateway --[per-server credentials]--> MCP Server --> Service

In this model:

• Agents authenticate to the gateway using OAuth 2.1, short-lived tokens, or mTLS. The gateway knows who the agent is, who the user behind the agent is, and what permissions they hold.
• The gateway authenticates to each MCP server using server-specific credentials that agents never see. Keys are stored in a secrets manager, rotated on schedule, and scoped to the minimum permissions each server needs.
• Policy enforcement happens at the gateway with full context: agent identity, user identity, tool being called, argument values, and the credential profile being used for the downstream call.

This is not a novel architecture. It is exactly how API gateways have worked for a decade. What makes it newly relevant is that MCP’s stdio transport model — where servers run as local child processes inheriting environment variables — makes centralized credential management almost impossible without an intermediary.

The gateway pattern converts the problem from “every agent needs every credential” to “only the gateway needs credentials, and agents get scoped access through it.”

What changes in practice

Credential isolation. Each MCP server connection uses its own credential set managed by the gateway. A compromise of the GitHub MCP server’s token does not affect the Slack or database servers.

Per-agent scoping. The gateway can map agent identity to credential profiles. Agent A gets read-only GitHub access; Agent B gets read-write. Same MCP server, different effective permissions, enforced at the credential level.

Rotation without disruption. Credentials live in the gateway’s secrets store. Rotating a key means updating one location. The MCP servers and agents do not need to restart or reconfigure.

Unified audit trail. Every tool call passes through the gateway with a full identity chain: user, agent, tool, arguments, credential profile used, and response. This is the audit trail that compliance teams actually need.

Open-source gateways doing this today

Several open-source projects implement variations of this gateway pattern. Each takes a different approach to the authentication problem, and the right choice depends on your deployment model.

MCPProxy

MCPProxy is a Go-based gateway that focuses on OAuth 2.1 for agent authentication and per-agent token isolation. Agents connect to a single SSE or streamable-HTTP endpoint, and MCPProxy routes tool calls to the appropriate upstream MCP servers. Credentials for upstream servers are configured centrally and never exposed to agents. It also implements BM25-based tool discovery, so agents only see tools relevant to their current context rather than the full catalog of every connected server.

The OAuth 2.1 support means agents authenticate with proper token flows rather than static keys, and the gateway can enforce different permission sets per agent based on their token claims.

agentgateway

Cisco’s agentgateway (formerly Arch Gateway) approaches the problem from a networking perspective, supporting both MCP and A2A (Agent-to-Agent) protocols. Its authentication story centers on mTLS — mutual TLS where both the gateway and the connecting agent present certificates. This is a strong fit for enterprise environments that already have PKI infrastructure and want to leverage existing certificate management.

agentgateway also supports server-side streaming and provides a unified interface for agents to discover and call tools across multiple MCP servers. Its Rust implementation emphasizes performance for high-throughput deployments.

Sentrial

Sentrial takes a policy-first approach, implementing OPA (Open Policy Agent) integration for fine-grained access control. Rather than focusing on a specific authentication mechanism, it provides a framework for defining who can call what under which conditions. This makes it particularly flexible for organizations that already have OPA policies governing their API access and want to extend the same model to MCP.

Sentrial’s policy engine can evaluate tool calls against arbitrary rules — time-of-day restrictions, argument value constraints, rate limits per agent — and it provides a web dashboard for security teams to manage policies without touching configuration files.

Choosing between them

The decision is not which gateway is “best” but which authentication model matches your environment:

Concern	MCPProxy	agentgateway	Sentrial
Agent auth model	OAuth 2.1	mTLS	Policy-based (flexible)
Credential management	Centralized config	Certificate-based	OPA-governed
Protocol support	MCP (SSE, streamable-HTTP)	MCP + A2A	MCP
Tool discovery	BM25 search + quarantine	Catalog-based	Policy-filtered
Best fit	Multi-tenant, SaaS-facing	Enterprise PKI	Compliance-heavy

All three share the fundamental insight: agent-facing authentication and server-facing authentication are separate problems that need separate solutions, and the gateway is where they meet.

What the MCP spec still needs

The gateway pattern works today, but it is a workaround for gaps in the MCP specification itself. Three additions would make the ecosystem significantly more secure without requiring every server to adopt OAuth.

Mandatory auth negotiation

The current MCP spec treats authentication as transport-level concern, largely punting it to the deployment environment. A server’s manifest does not declare what authentication it requires or supports. Clients discover this through trial and error or by reading documentation.

The spec should require servers to declare their authentication requirements in the initialize response or in a discoverable manifest field. Something as simple as:

{
  "auth": {
    "required": true,
    "methods": ["oauth2", "api_key", "bearer"],
    "oauth2": {
      "authorization_url": "https://...",
      "token_url": "https://...",
      "scopes": ["read", "write"]
    }
  }
}

This would let gateways and clients negotiate authentication automatically rather than relying on humans to configure credential mappings.

Credential rotation standards

There is no standard mechanism for an MCP server to signal that credentials are expiring, have been rotated, or need re-authentication. When a key expires, the server simply starts returning errors. The client has no way to distinguish a credential failure from a service outage.

A rotation protocol — even a simple one where the server sends a credential_expiring notification with a timeframe — would let gateways proactively rotate credentials before they cause failures.

Gateway auth profile

The spec should acknowledge that gateways are a legitimate and common deployment pattern by defining a standard way for servers to accept delegated authentication. When a gateway connects on behalf of an agent, the server should be able to verify both the gateway’s identity and the original agent’s identity. This is the on-behalf-of pattern from OAuth, and it maps directly to the gateway use case.

Without this, gateways have to pretend to be the agent (losing the gateway’s identity in audit trails) or authenticate as themselves (losing the agent’s identity). Neither is acceptable for enterprise security requirements.

The path from 8.5% to something better

The MCP ecosystem will not jump from 8.5% OAuth adoption to 100% overnight. Individual server authors have limited incentive to implement OAuth when their users just want to paste an API key and move on. The realistic path is:

1. Gateways normalize good auth practices by handling OAuth on the agent-facing side regardless of what servers support. This gives organizations a single point where they enforce authentication standards.
2. Spec improvements reduce the burden by making auth declaration mandatory and providing standard negotiation flows. Server authors are more likely to implement OAuth when the spec provides clear guidance and client libraries handle the complexity.
3. Registry pressure raises the bar as MCP registries start flagging or penalizing servers that only support static API keys, similar to how package managers warn about deprecated dependencies.

The 91.5% of MCP servers that do not use OAuth are not going to be rewritten. But they do not need to be. The gateway layer exists precisely to bridge the gap between the authentication reality of today’s ecosystem and the security requirements of production deployments. The question is not whether your MCP servers support OAuth. It is whether your architecture ensures that it does not matter.