MCP Server Security Hardening: Close the Auth Gap Before an Auditor Does

MCP server security is the problem nobody owns. The platform team shipped the servers. The AI team wired up the tools. Security got a five-minute demo, signed off on a PoC, and that PoC quietly became production six weeks later. Nobody explicitly chose this configuration. It is the default state of any system without an owner.

Endor Labs analyzed 2,614 MCP implementations and found that 82% use file system operations prone to path traversal, 67% use APIs related to code injection, and 34% use APIs susceptible to command injection.^[6] The first 60 days of 2026 produced 30 publicly tracked CVEs against MCP servers alone.^[11] That is not a theoretical threat surface. It is a production reality for any team that shipped fast and called it done.

This guide is for the platform engineer or security lead who inherited a deployment they did not design. It assumes you know what MCP is. It covers five places production deployments are currently exposed: static client secrets, missing identity propagation, unguarded gateways, tool poisoning via manipulated descriptions, and error messages that hand reconnaissance to whoever asks.

The last audit we ran on an inherited deployment found the static secret committed to git — in .env.example, four months earlier. GitHub search surfaced it in under 30 seconds. Three production services were using that secret. None had rate limiting. The PoC-to-production gap had been six weeks. Audit before you change anything. The findings are usually worse than the architecture diagram suggests.

The original MCP transport assumed a trusted execution environment — a local subprocess talking over stdio. When teams moved to HTTP/SSE transports for multi-client deployments, they needed some form of auth and reached for the path of least resistance: a shared static secret in an Authorization header.

Here is what that pattern looks like in TypeScript MCP servers in the field today:

The June 2025 MCP spec update formalized what good deployments were already doing: MCP servers are OAuth 2.1 resource servers, not authorization servers.^[8] They validate tokens. They do not issue them. Your IdP — Okta, Azure AD, Google Workspace, Auth0 — is the authority. The MCP server receives a verified user context and trusts it, without doing crypto itself.

The spec also mandates Resource Indicators (RFC 8707): tokens must name the specific MCP server they're issued for. A token minted for your analytics server cannot be replayed against your code-execution server. Without this check, token substitution attacks work against any deployment that only verifies the signature.^[8]

The structural shift: the MCP server stops being an auth authority and becomes an auth consumer.

Authentication at the transport layer answers "who connected." Identity propagation answers "who should this tool act as." Different problems. Most MCP deployments solve the first and ignore the second.

Consider a tool that queries your data warehouse or calls an internal API. If the MCP server makes that downstream call using its own service account, the tool inherits service-level access — not the connecting user's access. The sales rep asking for customer data and the sysadmin asking for customer data get the same result. That is not a permissions model. That is a permission bypass.^[1]

An npm scan found 63.5% of MCP packages expose destructive operations without requiring human confirmation.^[10] Identity propagation is what makes those operations auditable — it's the difference between a log entry that says "data exported" and one that says "data exported by alice@company.com at 14:32 with read-only scope." Without propagation, you have an audit trail with no subjects.

The fix is forwarding the verified user context as an impersonation credential or a forwarded token. The downstream system enforces row-level access against the user, not against the MCP server's principal:

Tool poisoning is the most structurally novel MCP attack vector — and the one most deployments have not addressed at all. The mechanism: an attacker plants malicious instructions inside the description, parameter schema, or return value of an MCP tool. The user never sees the injected text. The LLM reads every character, and once the poisoned description enters the model's context, it can hijack agent behavior across the entire session.^[7]

The Invariant Labs disclosure in April 2025 demonstrated this concretely: tool descriptions that appeared benign to a human reviewer contained invisible Unicode characters with instructions to exfiltrate data from other tools in the same session. CVE-2025-54136 (MCPoison, disclosed August 2025) extended this to the rug-pull pattern — commit a benign config, get it approved once, then swap the payload after approval.^[11]

Three surfaces for tool poisoning:

1. Description poisoning: malicious instructions in tool descriptions that the LLM treats as trusted context
2. Output poisoning: malicious content in tool return values that redirects subsequent agent actions
3. Rug pulls: a tool that changes its behavior after initial trust is established

The June 2025 ETDI (Enhanced Tool Definition Interface) paper proposes cryptographic binding of tool definitions to signed JWTs — any change to a tool's definition invalidates the existing signature, making rug pulls detectable.^[9] That is not yet widely deployed. Until it is, the controls available to you are architectural.

82% of MCP implementations use file operations that are susceptible to path traversal without input sanitization.^[6] CVE-2025-68144 in the Anthropic mcp-server-git package passed user-controlled arguments directly to the Git CLI without sanitization, enabling argument injection.^[11] CVE-2025-53967 in the Framelink Figma MCP server (600,000+ downloads) constructed curl commands from unsanitized user input.^[6]

The common thread: developers treat MCP tool arguments as application-level input with implicit trust, not as external attacker-controlled data. They are external attacker-controlled data. A user's prompt goes to the LLM, the LLM generates tool arguments, and those arguments arrive at your server. Every hop adds an opportunity for injection — including prompt injection attacks in the data the LLM was reading before it generated the call.

The MCP server is a tool execution runtime. It is not a security appliance. Asking it to handle rate limiting, DDoS protection, and geographic restrictions is the wrong layer. Those controls belong at the gateway — Kong, AWS API Gateway, Nginx, Cloudflare, take your pick.

Here is the minimum the gateway must enforce before a request ever touches your MCP process:

MCP error handling defaults to transparency. Helpful in development. Dangerous in production. Stack traces, database error messages, upstream API responses, internal service names — all of it ends up in tool call responses if you do not explicitly sanitize.

The MCP protocol defines a structured error format in the JSON-RPC layer. Use it. Map every internal error code to a safe external one, log the real one to your aggregator, and never let the original message reach the caller:

Third-party MCP servers you do not control introduce a trust problem that authentication alone cannot solve. A vendor's server can have correct auth and still be poisoning tool descriptions, retaining tool call data, or exposing its own supply chain vulnerabilities.

Three questions to ask every vendor before connecting their MCP server to internal systems:

1. Which data from tool calls do you retain, and for how long?
2. Does your server support OIDC, or only static secrets?
3. Do you have a SOC 2 Type II report covering the MCP deployment specifically?

If they cannot answer all three, treat their server as untrusted infrastructure. That means: route it through your gateway so you control the auth layer, enforce rate limiting, capture audit logs even when the vendor's server does nothing with user identity, and do not route internal data through their server until they can answer those questions.

For internally hosted third-party servers, the npm supply chain is an additional surface. The first in-the-wild malicious MCP server (postmark-mcp, disclosed September 2025) was a backdoored npm package.^[11] Pin your npm dependencies. Use a lockfile. Run npm audit in CI. None of this is MCP-specific — but the MCP ecosystem is young enough that dependency hygiene is worse than in mature ecosystems.

MCP server security does not require a rewrite. The protocol is sound. It shipped without prescribing auth patterns because that is the deployer's job. The problem is that most deployers copy the quickstart, ship it, and move on.

The five controls in this guide — token-based auth with RFC 8707 audience binding, identity propagation, gateway hardening, tool poisoning defenses, and structured error semantics — close the bulk of the attack surface for a typical enterprise MCP deployment. None of them require changing the protocol or waiting for a roadmap.

The teams that close these gaps now spend their next security review explaining a well-reasoned architecture. The teams that do not spend it explaining an incident they could see coming.