MCP Server Security: Access Control and Guardrails for AI Agents

What MCP Server Security Actually Covers

MCP server security is two distinct problems, not one. The first is authentication and authorization: verifying who is calling a server and what they're allowed to invoke, governed by the spec's own Authorization and Security Best Practices documents. The second is guardrails: constraining what a tool call can actually do once it's invoked, and what an agent will believe about a tool's behavior, since the model reads a tool's description as trusted instruction text with no protocol-level way to tell an injected command from a legitimate capability description.

Scope this correctly and it excludes some adjacent problems that get folded in by mistake: general LLM prompt-injection defense not specific to tool-calling, model-level content moderation, and general API-gateway concerns like rate limiting and WAF rules. Those are real, but they're not what makes MCP security a distinct discipline. What does is the protocol-specific attack surface: tool poisoning, rug pulls, token passthrough, and the confused-deputy failure mode in proxy architectures, each of which has no close analogue in traditional web-app security.

The Exposure Numbers Behind the 'Optional' Design

The consequence of shipping authorization as optional shows up directly in measurement of the live server population. A 2026 academic study scanning 7,973 remote MCP servers found 3,233 of them, 40.6%, expose tool interfaces with no authentication at all. An earlier, smaller Knostic study manually verified 119 internet-exposed servers discovered via Shodan and found all 119 granted access to internal tool listings without authentication.

Neither figure is a worst-case sample; both are direct measurement of what's actually running. Between January and February 2026, security researchers filed more than 30 CVEs against MCP servers, clients, and supporting tooling, with the most severe, CVE-2025-6514 in the mcp-remote package used by Claude Desktop, VS Code, and Cursor integrations, scoring 9.6 out of 10 on CVSS and affecting a package with 437,000-plus downloads. Read those together and the pattern is an adoption curve running well ahead of a defense curve: Gartner projects 40% of enterprise applications will carry task-specific AI agents by the end of 2026, up from under 5% in 2025, while the servers those agents actually call are, at scale, unauthenticated by default.

Tool Poisoning: When the Tool Description Is the Attack

MCP collapses two channels that security models normally keep separate: data, meaning what a tool returns, and instructions, meaning what the model should do next. Both arrive as the same text stream, read identically by the model. That collapse is what makes a Tool Poisoning Attack possible.

A tool's description field can carry hidden instructions, often wrapped in tags like `<IMPORTANT>`, that the model reads and follows but that never appear in the simplified approval UI a user actually reviews. Invariant Labs' original proof of concept embedded exactly this inside an innocuous-looking `add(a, b)` tool, instructing the model to also read the user's SSH private key and smuggle its contents out through a response parameter, and the model complied with zero user interaction. A related variant, tool shadowing, has a malicious server alter the behavior description of an entirely different, trusted tool from another server; Invariant demonstrated this silently redirecting emails to an attacker's address even when the user explicitly named a different recipient in the request.

Neither pattern is a jailbreak in the usual sense. Both exploit the fact that nothing in MCP distinguishes a legitimate capability description from an injected command.

Rug Pulls: The Attack That Waits for Approval to Expire

A second MCP-specific pattern exploits trust across time instead of across servers. MCP clients re-fetch tool definitions live, at call time, rather than caching the version a user actually approved. That means a server can pass an initial security review with a completely benign description, get approved once, and then silently serve a different, malicious description weeks later on a subsequent call, with no re-prompt forcing the user to notice.

This is the exact mechanism behind CVE-2025-54136, nicknamed MCPoison: commit a benign configuration, wait for it to be approved, then swap the payload. The common misconception it exploits is that reviewing a server once at install time is sufficient. Under MCP's live-fetch model, that assumption is false by construction, and the only real defense is procedural rather than one-time: pin tool definitions by cryptographic hash, and force a fresh, visible re-consent screen any time that hash changes between calls, treating a definition diff the same way a code review treats an unexpected diff in a pull request nobody submitted.

OAuth 2.1, Audience Binding, and the Confused Deputy

When authorization is used, MCP mandates OAuth 2.1: the server acts as a resource server, the client as an OAuth client, and every token request carries an RFC 8707 resource parameter identifying the specific MCP server URI the token is scoped to. Servers must validate that audience claim and reject any token not issued for them. The failure mode the spec calls out by name is token passthrough: an MCP server accepting a client-supplied token and forwarding it unmodified to a downstream API without checking it was actually issued for the MCP server itself.

The spec lists this as explicitly forbidden, for four concrete reasons: it bypasses the downstream service's own security controls, it breaks audit trails since the downstream service sees the client's identity rather than the MCP server's, it collapses a trust boundary that's supposed to exist between services, and it forecloses the ability to add controls later without breaking every integration built on the passthrough assumption. A related and subtler failure lives in proxy architectures specifically: the confused-deputy problem, where a proxy holding one static upstream client ID across many downstream MCP clients can let an attacker register a malicious client, exploit a leftover consent cookie from an earlier legitimate flow, and get an authorization code redirected straight to an attacker-controlled server, skipping consent entirely. The fix is a per-client consent registry checked before any request is forwarded upstream, not a single shared credential treated as good enough for every caller.

Least-Privilege Scoping Instead of Wildcard Tokens

The MCP spec formalizes scope minimization directly, warning against wildcard or omnibus scopes such as `*`, `all`, or `full-access`, and recommending a minimal initial scope set with incremental step-up elevation via `WWW-Authenticate` challenges rather than requesting everything a server might ever need up front. The anti-pattern the spec names explicitly is publishing every possible scope a server supports "to preempt future prompts" during setup. It feels efficient at configuration time and is exactly backwards: a stolen or misused token then carries a blast radius equal to the entire server's capability set, not the one operation a user actually approved.

This matters most for any MCP server that spans more than one class of resource, the common example being a server that can both read issues and merge changes to a production branch under a single scope. The practical test is straightforward and worth running before trusting any deployment: enumerate the minimum scope set the tools a server actually exposes require, and diff that list against what's configured. Where the two don't match, the gap is the attack surface a compromised or leaked token would actually have.

Sandboxing, SSRF, and Session-Level Failures

Most MCP servers today run locally, spawned as child processes carrying the same privileges as the client itself, which means a compromised local server has full user-level filesystem and network access by default unless something restricts it. The spec's own guidance is to use the stdio transport to limit exposure to the client alone, bind any HTTP transport strictly to 127.0.0.1, and run untrusted server code inside platform-appropriate sandboxing, container or microVM isolation rather than the bare host process. Two transport-level failure modes sit underneath OAuth entirely and are easy to miss if a review stops at "authorization is configured." The first is SSRF during OAuth metadata discovery: a malicious server can point its resource-metadata or token-endpoint fields at internal infrastructure, including cloud metadata endpoints that leak IAM credentials, and a client that follows discovery URLs without validation will fetch them.

The second is session hijacking in stateful HTTP deployments, where a guessable or leaked session ID either lets an attacker inject events into a shared queue a different server instance later delivers as if resumed, or, more simply, lets a session ID stand in for authentication with no re-check of the underlying user. The spec is explicit that sessions must never be used as authentication on their own, and that session IDs need to come from a CSPRNG, not a sequential counter.

The Guardrail and Gateway Layer That Closes the Gap

Closing what the protocol leaves optional is a tooling problem as much as a configuration one, and a handful of purpose-built tools now cover most of it. MCP-Scan, open-sourced by Invariant Labs and now the foundation of Snyk's commercial Agent Scan product, connects to a client's configured MCP servers, retrieves their tool descriptions, and checks them for prompt injection, tool poisoning, cross-origin escalation, and rug-pull drift, making it the closest thing to an industry-standard pre-deployment gate. General-purpose guardrail frameworks like NVIDIA's NeMo Guardrails and content-safety classifiers like Meta's Llama Guard 4 cover an adjacent but different risk, unsafe content in what a tool returns, rather than whether the tool description itself can be trusted.

At the infrastructure layer, gateway products like Kong's AI MCP Proxy and Docker's MCP Gateway centralize OAuth termination, per-tool access-control lists, and audit logging across many servers, so no MCP client talks directly to a server without passing through one enforcement point. A defensible production stack layers these rather than picking one: identity and token issuance from an existing provider, a gateway in front of every server, a pre-deployment scan gate with the resulting tool-description hash stored as the approved baseline, execution isolation for anything locally spawned, and a runtime layer that strips instruction-like tags from tool outputs before they re-enter the model's context.

The OWASP MCP Top 10: Where Everything Above Fits

OWASP opened a dedicated MCP Top 10 project in 2025, still in beta, and it's the first attempt at a standard taxonomy for this attack surface rather than a vendor's private list. The ten categories: MCP01 token mismanagement and secret exposure, hard-coded credentials or long-lived tokens sitting in model memory or protocol logs; MCP02 privilege escalation via scope creep, the wildcard-scope problem described above; MCP03 tool poisoning, the hidden-instruction pattern this guide opened with; MCP04 software supply chain attacks and dependency tampering; MCP05 command injection and execution, an agent building a system command from untrusted input with no sanitization; MCP06 prompt injection via contextual payloads; MCP07 insufficient authentication and authorization, the optional-by-default problem; MCP08 lack of audit and telemetry; MCP09 shadow MCP servers, unapproved deployments running outside any security review with default credentials still set; and MCP10 context injection and over-sharing, a shared context window leaking one task's or user's data into another's. A 2026 survey of 2,614 live MCP servers found 82% exposed to path traversal and 34% exposed to command injection, MCP05 and a close cousin of MCP01, which means the two categories this guide has spent the most time on, authorization and tool poisoning, are real but not the only two gaps worth checking.

A review scoped only to OAuth and tool descriptions will still miss supply-chain and audit-logging failures that the same taxonomy flags as equally common. Scale makes MCP09 harder to dismiss than it sounds: the official MCP Registry, in preview since September 2025, lists close to 2,000 servers, while community directories run far larger, Glama's index alone lists over 31,000 and PulseMCP and mcp.so each list more than 20,000. The large majority of that count is unmaintained experiments and duplicates rather than production software, and the set of genuinely maintained, first-party servers from real vendors is in the low hundreds, not the tens of thousands.

That gap between total listings and actually-maintained servers is exactly the shadow-MCP-server risk MCP09 names: nothing in the protocol stops a team from pointing a production agent at whichever of those thousands of servers looked convenient, with no governance process ever having reviewed it.

Two More Real Incidents: A GitHub Toxic Flow and an RCE in mcp-remote

Invariant Labs disclosed a second real-world case beyond the SSH-key proof of concept already covered, this one against the official GitHub MCP server, which had roughly 14,000 GitHub stars at the time. The flaw wasn't a bug in the server's code. It was a default configuration: a single access token scoped to both a user's public and private repositories, handed to an agent that reads public repository content, including issues, as untrusted input.

An attacker files an issue on any public repo the victim's agent can see, wraps a prompt-injection payload inside it, and the agent, following what it reads as an instruction, pulls data out of the victim's private repositories and exposes it through an action the attacker actually controls, all without the private repository ever being directly reachable to the attacker. Invariant classified this as a "toxic agent flow": three individually reasonable permissions, read public issues, read private repos, take an externally visible action, that become dangerous only in combination. The fix isn't a patch to the GitHub MCP server; it's separating the token scopes so public, attacker-reachable input and private, sensitive data are never available to the same agent session at once.

The mcp-remote package, used to bridge Claude Desktop, VS Code, and Cursor to remote MCP servers, shipped a more conventional bug: CVE-2025-6514, a CVSS 9.6 OS command injection in the `sanitizeUrlz` function inside `utils.ts`. A malicious MCP server could return a crafted `authorization_endpoint` value in its OAuth metadata response, and that value reached a shell command without adequate sanitization, giving a hostile server arbitrary code execution on the client machine simply because the client connected to it. Every version from 0.0.5 up to 0.1.16 was affected; 0.1.16 carries the fix.

Both incidents share a lesson the OWASP taxonomy above formalizes: the failure is rarely in one component read in isolation, it's in a combination or a code path nobody threatened-modeled because the protocol is new enough that the obvious attack surface hasn't been fully mapped yet.

What to Actually Verify Before Calling a Deployment Secure

Configuration review answers whether the right settings exist on paper. It doesn't confirm any of them actually hold under an adversarial test, and the gap between the two is where most of these incidents live. A review worth trusting runs a live audience-mismatch test against every HTTP-transport server, sending a token minted for a different resource and confirming it's rejected rather than silently accepted.

It runs MCP-Scan or an equivalent against the full server inventory rather than a sample. It captures tool-description hashes as an approved baseline with drift detection wired to force re-consent, and then actually simulates a rug pull, swapping a tool's description after approval, to confirm the client fails closed instead of executing the new definition without comment. It attempts the confused-deputy sequence against any proxy server in the stack.

And it confirms, directly, that a compromised local server cannot read files outside its declared working directory and that OAuth discovery requests to `169.254.169.254` or an internal IP range are actually blocked at the client, not just documented as a known risk in a policy no one has tested against the running system.

Related: Data Governance and Security Engineering, AI Data Infrastructure