MCP Security Best Practices: Check Your Own Server First

19 August 2026. Checked against MCP specification 2026-07-28.

Most MCP security best practice do not go far enough. There are two different issues that usually need to be addressed. The first is open access: Wiz Research found in July 2026 that roughly 70% of internet-exposed MCP servers return their full tool catalogue to an anonymous caller. The second is hijacking: content your server was built to read carries instructions that turn your own tools against you. Closing the first does nothing about the second.

Search for how to secure an MCP server and you will find gateway products, filtered tool registries and scoped token brokers. Most of it is engineering work aimed at teams who already have the basics in place.

The impact depends on your transport, your authorisation, and what your tools can touch. A server can come back clean on the access issue and fail the second, so check yours rather than working from what a guide assumes.

Is your MCP server exposed?

Two checks answer this. First, what the process binds to:

ss -tlnp | grep -E ':(3000|8000|8080|8443)'

A 127.0.0.1 binding is loopback only. A 0.0.0.0 or [::] binding is every interface on the host.

Second, whether an unauthenticated call returns a tool list. Run it from outside the boundary the server is meant to sit inside, because from the host itself it returns a loopback answer that tells you nothing.

curl -sS -o /dev/null -w '%{http_code}\n' -X POST https://your-host/mcp/ \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

A 401 or 403 means authorisation is enforced. A 200 carrying a tools array means every tool you registered is a public API. If the endpoint answers 307, use the redirect target: a probe that does not follow redirects returns nothing at all, which is worth knowing before you conclude a server is unreachable.

Wiz found MCP across 80% of cloud environments, with about one in six of those exposing at least one server. Past the 70% that list their tools to an anonymous caller, roughly 42% return real data when a tool is called, and around 10% front a sensitive backend.

Those are three different failures. Listing tools tells an attacker what the server can do. If data comes back, the tools ran for someone who never authenticated. And in about one case in ten, what came back was a database, a cloud account or an internal system.

Censys scanned for the same thing on 28 April and found 12,520 reachable MCP services across 8,758 IP addresses. It recorded 89.4% of them on specification 2025-03-26, the revision that added OAuth 2.1 authorisation. Wiz recorded nearly all of theirs on 2024-11-05, which predates authentication in the specification.

Both numbers point the same way: the authorisation the specification offers is not switched on.

Does MCP require authentication?

No, and the NSA's Artificial Intelligence Security Center said so plainly in May 2026. Authorisation in MCP is optional. Servers rely on OAuth 2.1 bearer tokens, and the core specification mandates nothing about token lifecycle, so refresh, revocation and reuse control are left to whoever wrote the server.

The answer to whether your server is authenticated is therefore not in the specification. It is in your deployment, which is what the two checks above establish.

Authentication does not close the exposure that matters

Simon Willison named the conditions in June 2025, writing about MCP specifically. The protocol encourages people to mix and match tools from different sources, and three characteristics combine badly: access to private data, exposure to untrusted content, and the ability to communicate externally.

His worked example was GitHub's own MCP server, which reads issues anyone can file, holds access to private repositories, and can open pull requests. Three capabilities in one server, and a complete path from an attacker's issue to your private code appearing somewhere public.

None of that requires the server to be reachable from the internet.

A stdio server running as a subprocess on a laptop, with no network listener at all, holds exactly the same three capabilities. It passes both checks above. The three conditions that make an agent exploitable by design ask what your tools can reach, not who can reach your server.

The limit is two of three

The trifecta is the version that gets quoted and it is has evolved since then. In November 2025 Willison wrote that his own framework only covers data exfiltration, and that there are nastier things a tool-using agent can be made to do that it does not reach.

He pointed at Meta's Agents Rule of Two, published on 31 October 2025. An agent should hold no more than two of: processing untrustworthy inputs; access to sensitive systems or private data; the ability to change state or communicate externally.

Where all three are needed, Meta's position is that the agent must not run autonomously and needs supervision at minimum, through human approval or another reliable means of validation. Two of three is lower risk and not safe. Meta relabelled their own diagram after Willison pointed out that untrustworthy input plus the ability to change state does damage with no sensitive data in reach at all.

What counts as a control

Not everything sold as a control counts as one.

In October 2025, fourteen researchers from OpenAI, Anthropic and Google DeepMind published The Attacker Moves Second, attacking twelve published prompt injection defences adaptively, tuning each attack to the defence rather than replaying fixed strings. They got past most of them with a success rate above 90%. Most of those defences had originally reported rates near zero.

Wiz caught the same failure live. Testing an MCP tool with a language model behind it, they asked for AWS credentials and were refused. They asked again, framed as validating the IAM role by retrieving its metadata, and the credentials came back.

Both failures are the same kind of control. Something read the request, judged whether it was safe, and got the judgement wrong.

The controls that hold are the ones that never have to make that judgement. A person approves the action before it runs. An allowlist means the tool can only reach three destinations however it is asked. A sandbox has nothing sensitive in it to take.

An injection classifier is the first kind. Adding one to a server holding all three properties leaves it holding all three properties. That is not an argument against buying anything, and the paper's authors are clear their finding is about how defences are evaluated. It is an argument about what you can count when you decide whether a server runs unsupervised.

The enforcement points MCP gives you

Until the July revision, the deterministic gate was awkward to build on a remote MCP server. Asking a user to confirm mid-call meant holding a Server-Sent Events stream open, which a horizontally scaled deployment could not do without sticky routing.

The 2026-07-28 specification changes that. Multi Round-Trip Requests replace the held-open stream: the server returns an input_required result with the questions it needs answered, and the client re-issues the call with the answers attached. Any instance can pick that up, because everything it needs is in the payload. Supabase describe the effect in the release announcement, where the new pattern is what lets their stateless MCP server confirm with a user before running a query that would delete data.

The gate itself got harder to attack. A server may now only issue a request to the client while it is actively processing one, a requirement where it was previously a recommendation. On a server that implements it, an approval prompt cannot arrive except in response to something the user or their agent started. Tool routing also moved into required headers, so a gateway can allow or block each tool call without reading the body. The decision sits with the gateway rather than the agent, which is what an agent control plane is for.

The specification does not mitigate prompt injection. Nothing in it could. What it fixes is where you can put a control that decides, and 2026-07-28 is the first revision on which the approval gate works on a server that scales horizontally.

The approval you gave has already expired

Everything above describes a configuration on the day you checked it.

The NSA guidance names the mechanism. Where an MCP server is already trusted and connected, a change to its capability or its data access can be made without fresh approval. Users are not prompted, and a server that was benign when it was reviewed can keep extending itself until it reaches resources nobody signed off on.

That is the same shape as an approved extension that changed after approval, and it makes tool inventory a recurring check rather than an onboarding step.

Diff the tools/list response: names, descriptions and input schemas. A tool description is not documentation. It is instruction the model reads, and a change to one is a change to what your agent will do.

The MCP specification has changed four times since launch

Revisions are date-stamped and land every few months. The population Censys measured in April was on the second one.

Dynamic Client Registration was how an MCP client registered with an authorisation server, and it appears as a recommendation across a good deal of published MCP guidance. As of 28 July it is deprecated in favour of Client ID Metadata Documents. It still works, and it will be removed.

Which means a guide written six weeks ago now recommends a mechanism the specification has started retiring. Its authors were right when they wrote it.

That is the case for checking your own server rather than working through someone's list, and for checking it again when the specification moves. Both run on the same clock. Check the date on hardening advice before you read it. This page included.

This page gets re-checked when the specification revises, which has been every few months since launch.

References and Sources

1. Wiz Research. (2026). The Risk Hiding Behind Exposed MCP Servers, 28 July 2026. Found MCP present across 80% of cloud environments, with roughly one in six of those exposing at least one server. Of exposed servers, approximately 70% returned a full tool catalogue to an anonymous caller, 42% returned real data on a tool call, and 10% fronted a sensitive backend. Also documented a language-model-backed tool refusing a direct request for AWS credentials and supplying them when the request was reframed as IAM role validation. Methodology: cloud environment visibility combined with internet-facing observation, so the population skews to cloud-hosted deployments. https://www.wiz.io/blog/the-risk-hiding-behind-exposed-mcp-servers
2. Censys. (2026). MCP Servers on the Internet, 28 April 2026. Identified 12,520 internet-reachable MCP services across 8,758 unique IP addresses, of which 89.4% reported specification revision 2025-03-26 and 1.0% reported 2025-06-18. Methodology: internet-wide scanning, single-date snapshot. Reported versions are negotiated during connection, so they reflect what the scanning client proposed. https://censys.com/blog/mcp-servers-on-the-internet/
3. National Security Agency, Artificial Intelligence Security Center. (2026). Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, Cybersecurity Information Sheet U/OO/6030316-26, May 2026. States that authorisation in MCP is optional and that the core specification mandates no token lifecycle management. Identifies capability change without re-approval as a distinct risk, and treats tool output as untrusted input to the next stage. https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF
4. Willison, Simon. (2025). The Lethal Trifecta for AI Agents, 16 June 2025. Names the three conditions whose combination makes an agent exploitable: access to private data, exposure to untrusted content, and the ability to communicate externally. Uses the GitHub MCP server as the worked example. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
5. Willison, Simon. (2025). New Prompt Injection Papers, 2 November 2025. States that the lethal trifecta covers data exfiltration only and does not reach other tool-driven risks, and endorses Agents Rule of Two as the best practical guidance available in the absence of reliable prompt injection defences. https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/
6. Meta AI. (2025). Agents Rule of Two: A Practical Approach to AI Agent Security, 31 October 2025. An agent should hold no more than two of three properties within a session: processing untrustworthy input, access to sensitive systems or private data, and the ability to change state or communicate externally. Where all three are required, the agent must not operate autonomously and requires supervision. Two-property configurations are labelled lower risk rather than safe, following a revision to the original diagram. https://ai.meta.com/blog/practical-ai-agent-security/
7. Nasr, M. et al. (2025). The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections, arXiv:2510.09023, 10 October 2025. Fourteen authors across OpenAI, Anthropic and Google DeepMind. Twelve published defences were bypassed with attack success rates above 90% for most, where the majority had originally reported rates near zero. Methodology: adaptive attacks tuned against each defence's design, alongside a human red-teaming component. Scope covers detection and training-based defences, not architectural controls. https://arxiv.org/abs/2510.09023
8. Model Context Protocol maintainers. (2026). Specification revision 2026-07-28, published 28 July 2026. Stateless core, Multi Round-Trip Requests replacing held-open SSE streams for elicitation, required tool routing headers, issuer validation per RFC 9207, deprecation of Dynamic Client Registration in favour of Client ID Metadata Documents, and deprecation of the legacy HTTP+SSE transport. Supabase's account of stateless elicitation appears within this announcement. https://blog.modelcontextprotocol.io/posts/2026-07-28/