A few weeks ago I sat down to build something I had been putting off: a custom Model Context Protocol server that I could self-host on a public web server and connect to from authorized Claude clients. The idea was straightforward. The Claude client would call my MCP server, the MCP server would call a handful of internal tools, and the model would have access to capabilities I could not get out of the box.
The server part went smoothly. MCP is well documented as a protocol, the open source implementations are reasonable starting points, and Anthropic has done a decent job making the developer experience approachable.
The auth part did not go smoothly.
What I expected vs what I found
When I think about authenticating an HTTP-based service that lives on a public web server, I think about a fairly well trodden path. You pick an identity provider. You issue tokens. You define scopes. You handle refresh and revocation. There are battle tested libraries for every language. The shape of the problem is familiar even when the specifics are not.
MCP does not give you that shape.
The protocol does not require authentication. It does not define a session-to-identity mapping. It mentions OAuth as a possible model in some of its specification documents, but it does not mandate token lifecycle management. There is no protocol-level concept of refresh rotation, revocation, or reuse control. Whether your MCP server enforces any of this at all comes down to the implementer.
I spent more time than I expected piecing together what “auth on a public MCP server” was even supposed to look like. The protocol pointed in a general direction. The implementations I looked at all made different calls. The result felt less like building on a standard and more like building on a suggestion.
I shipped a working version eventually, but I was not happy with it. Something was off, and I could not quite articulate what.
”MCP’s rapid proliferation has outpaced the development of its security model”
That was the moment I read the NSA’s Cybersecurity Information Sheet on Model Context Protocol security, released on May 20, 2026. The opening line of the executive summary put words to what I had been struggling with:
“MCP’s rapid proliferation has outpaced the development of its security model. Much like early web protocols, MCP was released with a flexible and underspecified design, allowing implementers freedom of design but also introducing ambiguity for safe usage.”
The report walks through a list of concrete gaps. A few that lined up with what I had run into:
- Authorization is optional. “Authorization in MCP is optional (not every implementation uses it).” This is in the protocol’s own documentation, quoted in the NSA report.
- No protocol-level token lifecycle. “MCP servers rely on bearer tokens, as defined in OAuth 2.1, without specifying protocol-level token lifecycle management (i.e., refresh, revocation, and reuse control).” Expiration and rotation are recommended in some drafts. The core spec does not mandate any of it.
- Authentication is often skipped entirely. The report notes plainly that “many implementations omit authentication entirely.”
- Public MCP servers are a scannable risk. The NSA explicitly calls out MCP servers “deployed without hardened configurations” that “may be accessible on local or public networks without proper authentication, authorization, restrictions, or monitoring,” and names this as something security teams should actively scan for.
This was not a niche observation by a single security researcher. This was the NSA, in formal published guidance, describing the exact category of problem that had been chewing up my evenings.
The report’s closing position is the part I cannot stop thinking about:
“[MCP’s] current security posture remains uneven and highly dependent on implementation discipline rather than protocol guarantees.”
That sentence is the whole problem in one line. Every MCP operator running anything serious is currently inventing their own auth story, with no protocol obligating them to get it right.
What I changed
After reading the report I went back to my MCP server and made a fundamental shift in approach.
The original version had auth bolted into the MCP server itself. Tokens were issued by the server, validated by the server, and refreshed by the server. Everything ran inside the same process I was also trying to use to serve MCP traffic.
That is the version of the architecture that the NSA report essentially warns against. Not because it cannot work, but because it puts the entire weight of getting auth right on one developer (me) writing one piece of code.
So I stopped doing that.
The new version puts Cloudflare in front of the MCP server and offloads almost every auth concern to infrastructure that already takes these problems seriously. Cloudflare has been actively positioning Workers as the place to host remote MCP servers, and the supporting products line up cleanly with the gaps the NSA names.
Here is what each layer does, and which NSA-identified gap it addresses:
- Cloudflare Access sits at the edge as an identity gate. Every request to my MCP server gets identity-verified before it ever touches application code. The MCP server itself never sees an unauthenticated request, because the request gets rejected at the edge. This closes the “many implementations omit authentication entirely” gap by making auth structurally impossible to skip.
- Workers OAuth Provider handles the OAuth 2.1 flow with proper token lifecycle. Short-lived access tokens, refresh tokens that rotate on use, and a revocation endpoint. This is the piece that closes the “no protocol-level token lifecycle management” gap. I am not writing my own JWT logic or hoping the implementer of some library got refresh right. The product was built for this.
- Per-tool scopes give me RBAC at instantiation. Each MCP tool gets its own scope. The gateway checks the requesting token’s scopes against the specific tool being called on every invocation, not just at session start. This closes the “lacks RBAC permissions at instantiation” gap that the NSA specifically calls out.
- WAF, Bot Management, and Rate Limiting at the edge close the public exposure risk. Random scanners hitting the public hostname get blocked at the Cloudflare layer before any application logic runs. Token-bound rate limiting protects against the fatigue based and denial of service techniques the NSA names as exploitable.
- MCP server hosted as a Worker removes the public origin entirely. There is no IP address sitting on the open internet for someone to portscan. The only addressable surface is the Cloudflare edge, which is already hardened.
- Sandboxed tool execution with structured audit logging covers the report’s recommendations on isolation and observability. Each tool runs in its own constrained context. Every invocation gets logged with identity, parameters, and result hash.
The net effect is that the auth layer is no longer a piece of code I wrote. It is a piece of infrastructure I configured. That is a much better place for it to be.
What this does not solve
I want to be honest about the limits of this approach, because the NSA report is broader than auth.
This architecture closes the authentication and authorization gaps that the report leads with. It does not, on its own, solve the trust boundary problems between agents, the indirect prompt injection risks in tool outputs, the serialization vulnerabilities in MCP payloads, or the inconsistent behavior across MCP implementations. Those are deeper, more structural issues that the NSA frames as architectural rather than something a single deployment can fully patch.
So the honest position is this. The stack closes a specific category of high-severity gap, the one I personally hit, and the one the NSA report opens with. It does not make an MCP deployment “secure” in any broader sense. Output filtering, tool sandboxing discipline, and audit log review still belong on the operator’s plate.
The NSA’s own conclusion is worth quoting in full here:
“Adopters should therefore proceed with caution, drawing on lessons from prior distributed and plugin-based ecosystems while applying heightened scrutiny to the novel integration and automation patterns introduced by MCP.”
That is the right framing. MCP is not unsafe. It is early. The protocol’s security model is going to mature, and the implementations are going to harden, but right now every public-facing MCP operator is doing security work that the protocol probably should be doing for them.
The short version
If you are running an MCP server in production, especially one that is reachable from the public internet, the auth story is your responsibility in a way that should make you uncomfortable. The NSA has now formally written that down.
The way I closed the gap was to stop treating auth as something my MCP server needed to do, and instead put a layer of infrastructure in front of it that handles identity, tokens, scope enforcement, and rate limiting on my behalf. Cloudflare was the fit for my deployment. Other zero-trust platforms with similar feature sets would work equivalently.
The important point is not the vendor. The important point is the architectural decision. Stop building MCP auth inside the MCP server. Put it at the edge, on infrastructure designed for the job. Until the protocol catches up, that is the most defensible posture available.
If you are deploying anything on MCP for production use, the full NSA report is worth reading. You can find it here: Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (CSI U/OO/6030316-26, May 2026). It is the clearest articulation of the current state of the protocol’s security posture that I have come across, and it is going to age well.