MCP 服务器认证在规范中为可选项：安全风险警示

The authorization section of the Model Context Protocol specification opens with a sentence that most security reviews never reach: "Authorization is OPTIONAL for MCP implementations." The capitalisation is the specification's own, in the RFC 2119 sense. A remote MCP server that requires nothing of the client that calls it is not a misconfiguration. It is a conformant implementation.

In May 2026, a measurement study put a number on what that permission produced in the wild. Zhou and colleagues identified 7,973 live remote MCP servers and found that 40.55% expose tools without authentication.

MCP server authentication is the boundary at which a remote MCP server decides whether the caller reaching it is entitled to the tools it advertises. The protocol places that decision entirely with the server operator, and defines a flow — OAuth 2.1 over HTTP transports — for operators who choose to implement one. Nothing in the protocol requires that they do, and nothing in the agent's view of a connected tool reports which choice was made.

Optional is a design decision, not an oversight

The specification is not careless here. For operators who implement authorization, the current revision is demanding. A protected MCP server acts as an OAuth 2.1 resource server. Clients MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707, sending a resource parameter identifying the target server in both authorization and token requests, whether or not the authorization server supports it. Servers MUST validate that access tokens were issued specifically for them as the intended audience, and MUST NOT accept or transit any other tokens. That is a careful set of defences against the confused-deputy and token-passthrough problems a broker-shaped protocol invites.

The architectural point is that all of it is conditional on a choice made by a party the enterprise does not employ. Authorization is a property of each server, negotiated between that server's operator and whichever client happens to connect. The organisation running the agent fleet is not a participant in that negotiation. It inherits the result.

That is the structural difference between MCP and the integration layers it is often compared to. An API gateway sits in the request path by construction; whatever policy it holds applies because traffic cannot route around it. MCP inverts the arrangement. Each server is its own perimeter, and the client's job is to comply with whatever each perimeter asks — including a perimeter that asks for nothing.

What the measurement actually found

The unauthenticated 40.55% is the headline, but it is the less interesting half of the study.

The researchers then examined the servers that did implement OAuth. They observed that MCP's OAuth deployments share three characteristics distinguishing them from conventional OAuth: open client environments, dynamic client registration, and delegated authorization. From those they derived a taxonomy of four categories and nine concrete flaw types, then built a semi-automated detection framework combining passive traffic inspection with active probing.

Applied to 119 testable real-world OAuth-enabled MCP servers, the framework found that every server exhibited at least one flaw, for 325 flaws in total. Dynamic client registration flaws affected 96.6% of servers tested. The authors report that many can lead to sensitive information leakage and account takeover, and that responsible disclosure yielded nine CVE identifiers.

Two caveats belong on those figures: this is a preprint rather than peer-reviewed work, and 119 servers is a sample of the OAuth-enabled population rather than a census. What it establishes is directional and hard to explain away. Implementing the recommended mechanism was not sufficient to be secure, and the most-affected mechanism was the one that lets a client register itself without a human ever approving it.

The specification moved. The deployed servers did not.

Here the timeline does something instructive.

MCP's current protocol revision, 2026-07-28, postdates the measurement by roughly two months. Its changelog deprecates the OAuth 2.0 Dynamic Client Registration Protocol as a client registration mechanism, in favour of Client ID Metadata Documents. The authorization page carries the reasoning inline: dynamic client registration is "deprecated and retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents."

The same revision tightens several other things that map onto the study's flaw categories. Authorization servers SHOULD include the iss parameter in authorization responses per RFC 9207, and clients MUST validate a present iss against the recorded issuer before redeeming an authorization code. Client credentials are now explicitly bound to the authorization server that issued them: clients MUST key persisted credentials by issuer identifier, MUST NOT reuse them with a different authorization server, and MUST re-register when the authorization server changes. Clients performing dynamic registration MUST specify an appropriate application_type to avoid OpenID Connect redirect URI conflicts.

This is a specification responding to its own security research, quickly and in the right direction. It is also the clearest possible illustration of what a specification can and cannot reach. The same revision adopted a feature lifecycle policy with a minimum twelve-month deprecation window, which means the deprecated registration mechanism remains a legal part of the protocol into at least mid-2027, by explicit policy. Deprecation is an instruction to people writing new implementations. The 7,973 servers already answering requests did not read it.

And the sentence that produced the 40.55% is unchanged. Authorization is still OPTIONAL.

The agent cannot see the difference

Consider what a connected tool looks like from inside an agent.

An ungoverned fleet connects a client — Claude Desktop, Cursor, a custom agent — directly to a set of remote MCP servers. Each connection is authenticated separately, or not, according to what each server asked for. The signal that returns to the operator is binary: the tool appeared in the list, or it did not. A server running hardened OAuth 2.1 with audience-bound tokens and a server that checks nothing produce the same green state in the client. Calls land on the upstream attributed to whatever credential was configured, which for a shared token is a bot account rather than a person. When someone leaves, those credentials are chased across each upstream's admin console individually.

A governed fleet moves the question somewhere it can be answered. Not because a control plane makes the upstream servers better — it does not, and no one operating them is obliged to care. Because authentication answers who is calling, while the organisation also needs an answer to what this caller is allowed to do, recorded somewhere it owns. MCP delegates only the first, to a party chosen by whoever wrote the config file.

One practitioner is arriving there without waiting. On Hacker News in July 2026, a commenter on a survey of MCP security described building an internal MCP proxy — upstreams behind Entra OAuth, per-tool RBAC via CEL expressions — for the relief of "not trusting other people's slopped out MCPs to do the right thing with authentication." That is an engineer independently deriving a chokepoint because per-server trust did not scale.

How Waxell handles this

The Waxell MCP Gateway is one MCP endpoint per tenant, and the agents point at it instead of at the upstreams. That placement is the whole argument: the gateway sits in the path by construction, so what it enforces does not depend on what any individual upstream chose to require.

Two published behaviours matter for this problem specifically.

Identity is resolved before the upstream sees the call. Every tool call through the gateway is resolved to a real user identity rather than a service account, with three auth modes available per upstream. Under on-behalf-of OAuth the gateway brokers the OAuth flow, stores the user's refresh token KMS-encrypted and never returns it to the agent client, and mints a fresh access token at call time — so the upstream's own audit log names the person who triggered the call. A shared service account and a bring-your-own-token mode cover upstreams without a standard OAuth flow. When someone is deactivated, every per-upstream OAuth grant they held is revoked in one transaction across every upstream at once, and the audit log records the event, the timestamp, the actor and the upstreams unwound.

Policy is evaluated on both legs. Every tools/call is evaluated against the tenant's policy rules before the upstream sees it, and again before the result returns to the agent. Rule changes propagate to the fleet within 30 seconds, with no restart. Waxell publishes 50+ policy categories across the platform. The audit log stores the resolved identity, the decision and the rules that fired, without retaining the argument values or result bodies that passed through.

One scope note, load-bearing for planning rather than decoration. The gateway governs the calls that traverse it. An agent holding a direct upstream credential, or a locally registered MCP server, sits outside that path, and nothing at the gateway applies to those calls. Coverage is a configuration property rather than a guarantee, which makes an inventory of what your clients are actually pointed at the prerequisite, not the follow-up. The Free plan includes one governed MCP upstream with 14-day retention — enough to put a real client behind the gateway and see what it has been calling.

FAQ

Does the MCP specification require authentication?

No. The specification's authorization section states that authorization is OPTIONAL for MCP implementations, using the term in its formal sense. Where implementations do use HTTP-based transports and choose to support authorization, they SHOULD conform to the OAuth 2.1-based flow the specification defines. Implementations using STDIO transport are directed not to follow that flow and to retrieve credentials from the environment instead. A remote server that requires nothing is conformant, which is why an unauthenticated endpoint is not evidence that anyone made a mistake.

How many remote MCP servers have no authentication?

A May 2026 preprint from Zhou and colleagues identified 7,973 live remote MCP servers and reported that 40.55% expose tools without authentication. Among the OAuth-enabled servers the same study could test — 119 of them — every server exhibited at least one authentication flaw, with 325 flaws found in total and dynamic client registration flaws affecting 96.6%. The work yielded nine CVE identifiers through responsible disclosure. Treat the percentages as a directional measurement of a moving population rather than a fixed statistic.

Is dynamic client registration still recommended for MCP?

Not for new implementations. Protocol revision 2026-07-28 deprecates the OAuth 2.0 Dynamic Client Registration Protocol as a client registration mechanism in favour of Client ID Metadata Documents, and the authorization page describes it as retained for backwards compatibility with authorization servers that do not support the newer mechanism. The same revision adopted a deprecation policy with a minimum twelve-month window, so deprecated features remain part of the specification for a defined period rather than disappearing on the revision date.

Does authenticating an MCP server mean its tool calls are governed?

They are separate controls. Authentication establishes which caller is reaching the server, and the server operator decides what that entitles the caller to. It produces no record on the calling organisation's side of which tools were invoked, by which person, under which policy. Token scope is a partial answer worth setting carefully — see MCP least privilege — but scoping a token constrains what a credential can reach, not what a specific call is permitted to do at the moment it is made.

What should a team inventory first?

Start from the client configs rather than the server list, because the configs determine reachability. For each agent client in use, enumerate which MCP servers it points at, which are remote versus local, what credential each connection carries, and whether that credential resolves to a person or a shared account. That turns an abstract question about the ecosystem into a specific list of upstreams your agents can reach today. Wider background is in MCP governance.

References

Huijun Zhou, Xiaohan Zhang, Haozhe Zhang, Haoyang Zhang, Mi Zhang, Min Yang, "A First Measurement Study on Authentication Security in Real-World Remote MCP Servers", arXiv:2605.22333, 21 May 2026

Model Context Protocol, "Authorization", specification revision 2026-07-28, accessed 12 August 2026

Model Context Protocol, "Key Changes", specification revision 2026-07-28, accessed 12 August 2026

Hacker News, "The State of MCP Security", discussion thread, July 2026

The specification did the part a specification can do. It named the weak mechanism, deprecated it, and tightened the flow around it. What it cannot do is reach 7,973 servers that are already answering, or make an agent's tool list tell you which of them asked for anything.

Originally published on the Waxell blog.

Start free with the Waxell MCP Gateway at waxell.dev/signup, and find out what your agents are already connected to.