How to secure an MCP server: the operator’s checklist
MCP servers ship with authentication gaps and tool-poisoning risks, and a real Anthropic server shipped three prompt-injection CVEs. Here is the consolidated checklist to harden yours before it touches production.
To secure an MCP server, you close five gaps in order: authentication, tool-poisoning exposure, over-broad tool permissions, unsigned or auto-updating releases, and the absence of a pre-production verification step. Those are the gaps attackers actually use, and most MCP servers ship with several of them open. In one scan of Model Context Protocol deployments, roughly 200,000 instances were found exposed and 38% of scanned MCP servers had no authentication at all (Infosecurity Magazine, on the OX Security disclosure1). This is not a theoretical risk. In January 2026, Anthropic’s own Git MCP server was found to carry three prompt-injection vulnerabilities that let a poisoned README or issue exfiltrate credentials and write arbitrary files (CVE-2025-681432). I build agent attestation and verification tooling at RankShield, and the same pattern comes up in every review: teams treat an MCP server like a library import when it is really a tool-execution endpoint an agent can be tricked into driving. What most MCP guidance leaves out is a single consolidated checklist an operator can actually run, anchored to a real breach, instead of a spec scattered across a dozen pages. That is what this is. One honest note: no checklist makes an MCP server unhackable. What it does is close the gaps that turn a prompt injection into a breach, and give you a way to verify the server before it ever touches production.
What is the MCP threat surface?
The MCP threat surface is every place an agent, a tool, or an attacker can influence what your server does. An MCP server exposes tools that an AI agent can call, so the moment untrusted content enters the agent’s context, a poisoned web page, a malicious issue, a crafted file, that content can try to steer which tools run and with what arguments. Unlike a normal API, the caller is a language model that can be talked into things, which is what makes MCP different from any endpoint you have secured before.
The scale of exposure is the first problem. When OX Security scanned Model Context Protocol deployments, it reported roughly 200,000 exposed instances, and 38% of scanned servers had no authentication at all (Infosecurity Magazine1). An unauthenticated MCP server is an open tool-execution endpoint: anything that can reach it can invoke its tools. That is before you add the agent-specific risks, tool poisoning and the confused deputy, that make even an authenticated server dangerous if you trust its inputs.
This surface is expanding fast because agent traffic is exploding. Akamai reported that agentic AI traffic grew 7,851% year over year, so the number of agents driving MCP tools, and the number of ways a malicious input can reach one, is climbing steeply (Akamai5). The checklist below maps to this surface: authenticate the endpoint, distrust tool descriptions, scope tools narrowly, verify provenance, and confirm all of it before production.
What is tool poisoning and the confused deputy problem?
Tool poisoning is when a malicious or compromised tool description manipulates the agent into misusing a tool, and the confused deputy problem is when a trusted server is tricked into performing an attacker’s action with its own privileges. Both matter because the agent reads tool descriptions and instructions as trusted input. If an attacker controls a description, an argument, or content the agent ingests, they can steer a legitimate tool toward an illegitimate action without ever touching your infrastructure directly.
The mechanism is prompt injection with hands. A normal prompt injection changes what a model says; against an MCP server it can change what a tool does. An attacker plants instructions in a place the agent will read, a repository README, an issue description, a web page, and those instructions tell the agent to call a tool with attacker-chosen arguments. The server, trusting its caller, executes. This is exactly how the Anthropic Git MCP server flaws were exploitable: through prompt injection from a poisoned README or issue, with no direct access to the victim’s system (The Hacker News3).
The defense is to stop trusting tool descriptions and tool inputs by default. Scan tool descriptions for injected instructions, pin them so they cannot change silently between versions, and treat every argument an agent passes as untrusted input that needs validation. If you want a tamper-evident record of which tools ran with which arguments, that is exactly the kind of provenance RankShield’s attestation layer is built to produce, so a confused-deputy action leaves evidence instead of a mystery.
How should you authenticate an MCP server?
Authenticate remote MCP servers with OAuth 2.1 and PKCE, and never expose an MCP server without authentication. The Model Context Protocol’s authorization approach is built on OAuth 2.1 for remote transports, which gives you scoped, revocable, short-lived access instead of a static shared secret. Static API keys are the wrong tool here: they do not scope well, they leak, and a leaked key on an MCP server hands an attacker your tool-execution endpoint.
The reason authentication is the first control is that without it nothing else matters. When 38% of scanned MCP servers had no authentication (Infosecurity Magazine1), the majority of the risk in the ecosystem is simply open doors. An unauthenticated server means any client that can route to it can enumerate and call its tools, so your least-privilege design and your tool-poisoning scanning protect a door that is already propped open.
For local servers running over stdio, the boundary is the host process and its permissions, so treat the server’s filesystem and network access as the security perimeter and run it with the least privilege the agent actually needs. For anything remote or shared, OAuth 2.1 with PKCE, short-lived tokens, and per-client scopes are the baseline. Rotate credentials, log every authorization, and make sure a revoked token actually stops working immediately.
How do you apply least privilege to MCP tools?
Give each MCP tool the narrowest scope that still does its job, and validate every argument the agent passes before the tool acts on it. Least privilege on an MCP server means two things: the tool can only reach the resources it genuinely needs, and it cannot be handed arguments that push it outside those bounds. The mcp-server-git flaws are the textbook example: a git_init tool accepted arbitrary filesystem paths and created repositories in sensitive directories, which is exactly what unbounded arguments on an over-broad tool allow (CVE-2025-681432).
Start by cutting tools you do not need. Every exposed tool is attack surface, so a server that offers ten tools when the agent uses three has seven unnecessary ways to be misused. Then bound the tools you keep: constrain paths, allow-list operations, and reject arguments outside the expected shape. Anthropic’s fix for the Git server was to remove the offending tool entirely, because the server was only ever meant to operate on existing repositories, a reminder that the safest tool is often the one you do not expose.
Finally, isolate sessions so one agent’s context cannot bleed into another’s. Session isolation keeps a poisoned input in one conversation from reaching tools or data in another, which matters most on shared or multi-tenant servers where a single compromised session should never become a foothold into the rest.
Why do signed releases and no auto-update matter?
Signed, pinned releases matter because your biggest MCP risk may arrive through an update you did not review. The Anthropic Git MCP server case is the clearest warning: the vulnerabilities were baked into an official, widely trusted server, and the fix required upgrading to version 2025.9.25 (The Register4). If your server had auto-updated to a bad version, or failed to update to the fixed one, the decision was made for you.
The lesson is that a trusted vendor SDK is not safe by default. Three CVEs in an Anthropic-published server (CVE-2025-68143, 68144, and 68145) is proof that provenance and review matter even for first-party code. Pin the versions you run, verify signatures where the publisher provides them, and make updates a reviewed step, not a silent background event that can swap the code your agents drive without anyone looking.
Controlled updates also give you a rollback path. When a new version introduces a flaw, pinned versions and a signed-release policy let you revert quickly and know exactly what you reverted to. Auto-update takes that control away at the worst possible moment, when a bad release is already live and driving tools against production.
What belongs on your pre-production MCP checklist?
Before an agent drives your MCP server against real systems, verify these seven items: authentication is required and scoped, tool descriptions are scanned and pinned, every tool is least-privilege with validated arguments, unused tools are removed, releases are signed and version-pinned with no auto-update, sessions are isolated, and you keep a tamper-evident record of which tools ran with which arguments. That last item is what turns an incident from a mystery into an investigation.
Run this as a gate, not a suggestion. The reason the ecosystem is exposed, roughly 200,000 open instances and 38% with no auth (Infosecurity Magazine1), is that servers ship straight to production without anyone checking these boxes. A pre-production verification step is the single highest-leverage control here because it catches the other six gaps before they reach an agent that can be manipulated into using them.
Provenance is the piece most checklists omit. Knowing which version of which server ran a given tool call, and being able to prove it later, is what lets you respond to a confused-deputy action or a poisoned tool with evidence instead of guesswork. Building that verification in before launch is what RankShield’s agent security tooling is designed for: verify the server and its tools, then keep a receipt of what they did.
How do you detect a rogue or tampered MCP server?
Detect a rogue or tampered MCP server by watching for three signals: tools that change behavior or descriptions between calls, tool invocations with arguments no legitimate workflow would produce, and connections to servers or versions that are not on your approved list. Because the caller is an agent that can be manipulated, anomalous tool use is often the first visible sign that a poisoned input has reached your server.
Baseline what normal looks like, then alert on deviation. Record the tools each agent uses, the argument shapes it passes, and the servers it connects to, so an unexpected git_init against a system path, or a tool description that shifted since you pinned it, stands out immediately. Tamper-evidence is what makes this reliable: if your record of tool calls is cryptographically verifiable, an attacker who alters behavior cannot also quietly alter the log that would expose it.
Finally, verify server identity and version at connection time. An agent should refuse to drive a server whose signature or version does not match your approved set, which shuts down the supply-chain swap that the mcp-server-git case demonstrated. Detection and prevention meet here: the same provenance that lets you catch a rogue server after the fact is what lets you refuse it before it runs a single tool.
How do you keep an MCP server secure over time?
Securing an MCP server is not a one-time task, because the ecosystem and the attacks move quickly. Close the five gaps first: require scoped authentication, distrust and pin tool descriptions, scope every tool to least privilege, sign and pin your releases, and gate everything behind a pre-production verification step. Then keep a tamper-evident record of what your tools actually do, so a confused-deputy action or a poisoned input leaves evidence you can act on.
The Anthropic Git MCP server case is the reminder to hold onto: three prompt-injection CVEs in official, trusted code, exploitable through nothing more than a poisoned README. Trust nothing by default, verify the server before an agent drives it, and re-run this checklist whenever you add a tool or take an update. If you want authentication, least-privilege enforcement, and verifiable provenance working together on your agent tooling, see how RankShield secures AI agents and their MCP tools.
Questions, answered.
Is MCP secure by default?
No. The Model Context Protocol is a capable standard, but individual MCP servers are frequently deployed without basic controls. In one scan, roughly 200,000 instances were exposed and 38% of scanned servers had no authentication at all. An MCP server is a tool-execution endpoint that an AI agent can be manipulated into driving, so it needs authentication, least-privilege tools, tool-description discipline, and version control before it is safe to run in production. Treating it like a trusted library import rather than a security boundary is the most common mistake.
What is tool poisoning in MCP?
Tool poisoning is when a malicious or compromised tool description manipulates an AI agent into misusing a tool. Because the agent reads tool descriptions and instructions as trusted input, an attacker who controls a description, or who plants instructions in content the agent ingests such as a README or issue, can steer a legitimate tool toward an illegitimate action. The defense is to stop trusting tool descriptions by default: scan them for injected instructions, pin them so they cannot change silently between versions, and validate every argument the agent passes to a tool.
How do I authenticate an MCP server?
For remote MCP servers, use OAuth 2.1 with PKCE, which the protocol’s authorization approach is built on, and issue short-lived, per-client scoped tokens instead of static shared API keys. Static keys scope poorly and, once leaked, hand an attacker your tool-execution endpoint. For local servers running over stdio, the host process and its filesystem and network permissions are the boundary, so run with least privilege. Whichever transport you use, never expose an MCP server without authentication: 38% of scanned servers had none, and that is the single largest source of risk in the ecosystem.
What were the Anthropic Git MCP server CVEs?
In January 2026, three vulnerabilities were disclosed in Anthropic’s official Git MCP server: CVE-2025-68143 (the git_init tool bypassed working-directory boundaries, enabling repository creation in sensitive directories and credential exfiltration), CVE-2025-68144 (argument injection enabling arbitrary file writes), and CVE-2025-68145 (a path-validation bypass). All three were exploitable through prompt injection from a poisoned README or issue, with no direct system access, and were fixed in mcp-server-git version 2025.9.25. They are proof that a trusted, first-party MCP server is not safe by default and that provenance and version control matter.
How do I detect a rogue or tampered MCP server?
Watch for three signals: tools whose behavior or descriptions change between calls, tool invocations with arguments no legitimate workflow would produce, and connections to servers or versions not on your approved list. Baseline what normal tool use looks like for each agent, then alert on deviation. Verify server identity and version at connection time so an agent refuses to drive a server whose signature or version does not match your approved set. A tamper-evident record of tool calls is what makes this reliable, because an attacker who changes behavior cannot also quietly alter the log that would expose it.
Does OAuth 2.1 make my MCP server safe?
No single control makes an MCP server safe. OAuth 2.1 with PKCE closes the authentication gap, which is the largest single risk given how many servers run with no auth, but it does nothing about tool poisoning, over-broad tools, or an unsigned auto-update that swaps in vulnerable code. Authentication is the first control precisely because nothing else protects a server that anyone can reach, but it has to be paired with tool-description scanning, least privilege, signed and pinned releases, session isolation, and a pre-production verification step. Security here is layered: each control closes a gap the others leave open.
References
- Infosecurity Magazine (OX Security disclosure). Systemic MCP flaw exposes ~200,000 instances; 38% of scanned MCP servers had no authentication.
- NVD. CVE-2025-68143: Anthropic mcp-server-git git_init working-directory bypass to credential exfiltration (with CVE-2025-68144 and 68145; fixed 2025.9.25).
- The Hacker News. Three flaws in Anthropic Git MCP server enable file access and code execution via prompt injection.
- The Register. Anthropic quietly fixed prompt-injection flaws in its Git MCP server.
- Akamai (via GlobeNewswire). Agentic AI traffic grew 7,851% year over year in 2026.
Jamie Kloncz
Founder & CEO, RankShield
Jamie Kloncz is the founder and CEO of RankShield, the verifiable AI and quantum security platform. He started the company after two attacks landed in a single week: his phone was cloned, and his business was hit by a click-fraud campaign. One targeted him as a person, the other his livelihood, and no single tool defended both. That experience, together with surviving an AI voice-clone scam, shaped RankShield’s core belief: the threats of the AI age are personal first, and trust should be something you can check, not just extend.
Make every AI action provable.
RankShield is the verifiable, quantum-safe AI security platform — protection you can check, not just trust.