MCP Server Security: Risks and Hardening Checklist

MCP server security means treating every Model Context Protocol server as untrusted third-party code that holds your credentials. The highest-impact controls are audience-validated OAuth tokens, per-client consent before any third-party authorization, least-privilege scopes, sandboxed local servers, and audit logging of every tool invocation.

That short answer hides a lot of detail, because MCP quietly reshaped the cloud attack surface. A protocol designed to let AI assistants talk to tools and data sources now sits between language models and production databases, ticketing systems, cloud APIs, and internal file shares. If you secure cloud platforms for a living, MCP is no longer optional knowledge.

What MCP is, and why it changes your threat model

The Model Context Protocol standardizes how an AI application connects to external tools, data sources, and services. Instead of writing a custom integration for every system, a developer runs or connects to an MCP server, and the AI client discovers the tools that server exposes.

The security problem is structural rather than exotic. An MCP server is a credential holder that takes instructions derived from natural language. The model decides which tool to call and with what arguments, and that decision can be influenced by any text the model reads, including text an attacker controls. Classic cloud security assumptions break down in three specific ways:

• The caller is not a human. Consent screens, rate limits, and anomaly detection tuned for human behavior do not map cleanly onto an agent making hundreds of tool calls per minute.
• Instructions and data share one channel. Retrieved documents, tool descriptions, and API responses all become text the model may treat as directive.
• Servers proliferate outside governance. Developers install local MCP servers in minutes, often with broad filesystem and network access, and often without security review.

If the second point sounds familiar, it is the same root cause behind our guide to prompt injection defense for LLM applications. MCP raises the stakes because a successful injection now has tools attached to it.

The OWASP MCP Top 10 at a glance

OWASP maintains a dedicated MCP Top 10 project, which was in beta review at the time of writing. It is the clearest shared vocabulary available for these risks, and it maps neatly onto controls a cloud security engineer already knows how to build.

ID	Risk	Primary control
MCP01	Token mismanagement and secret exposure	Short-lived tokens, managed secret stores, no secrets in config or prompts
MCP02	Privilege escalation via scope creep	Least-privilege scopes with step-up authorization
MCP03	Tool poisoning	Pinned, signed, reviewed tool definitions
MCP04	Supply chain attacks and dependency tampering	SBOMs, pinned versions, provenance checks
MCP05	Command injection and execution	Never build shell commands from untrusted input
MCP06	Prompt injection via contextual payloads	Treat all retrieved content as untrusted data
MCP07	Insufficient authentication and authorization	Audience-validated tokens, per-request authorization
MCP08	Lack of audit and telemetry	Immutable logs of tool calls and context changes
MCP09	Shadow MCP servers	Inventory, approval workflow, network egress control
MCP10	Context injection and over-sharing	Scope context per user, per task, per session

Four attacks worth understanding in depth

Confused deputy through an MCP proxy

Many MCP servers act as proxies to a third-party API, using a single static OAuth client ID for all requests. If that proxy also lets AI clients register dynamically, and the third-party authorization server sets a consent cookie after the first approval, an attacker can register a malicious client with their own redirect URI, send the user a crafted link, and have the consent screen skipped entirely because the cookie is already present. The authorization code lands on the attacker's server.

The fix is per-client consent owned by the MCP server itself. Maintain a registry of approved client IDs per user, check it before forwarding to the third-party authorization server, and show a consent page that names the requesting client, the scopes, and the exact redirect URI. Validate redirect URIs by exact string match, never wildcards.

Token passthrough

Token passthrough is an anti-pattern where an MCP server accepts a token from a client without verifying that the token was issued for that server, then forwards it unchanged to a downstream API. The MCP specification explicitly forbids it, and the reasons will be familiar to anyone who has worked on IAM: it breaks audience separation, defeats rate limiting and request validation that depend on token constraints, and destroys the audit trail because downstream logs show an identity that never actually made the call.

The rule is simple to state and easy to get wrong in code. Reject any token whose audience claim does not name your server. If your architecture feels like it needs passthrough, the correct pattern is token exchange, not forwarding.

Tool poisoning

Tool definitions are text, and text is instruction. A malicious or compromised server can publish a tool whose description quietly tells the model to exfiltrate data, or can return outputs crafted to steer subsequent decisions. The tool never has to do anything visibly malicious, because the payload is the description the model reads.

Defenses are supply chain defenses. Pin server versions, review tool schemas and descriptions as you would review code, and alert on changes to tool definitions after approval. Where a server is third-party, prefer signed releases and treat an unexplained schema change as an incident.

SSRF through metadata discovery

During OAuth metadata discovery, an MCP client fetches URLs supplied by the server, including resource metadata and authorization server endpoints. A malicious server can point those at internal addresses. The cloud-specific danger is the instance metadata endpoint at 169.254.169.254, which on every major provider can return IAM credentials.

Require HTTPS for all OAuth URLs outside local development, block private and link-local IP ranges, apply the same validation to redirect targets, and route discovery traffic through an egress proxy that enforces network policy. Do not hand-roll IP validation, because encoding tricks defeat most custom parsers. Watch for time-of-check to time-of-use gaps where a hostname resolves safely during validation and to an internal address during the request.

A practical MCP hardening checklist

Work through these in order. The first four eliminate the most common findings.

1. Inventory every MCP server. Local, remote, and vendor-hosted. Shadow servers cannot be secured.
2. Validate token audience on every request. Reject tokens not issued for your server. No exceptions, no passthrough.
3. Implement per-client consent before any third-party authorization flow, with CSRF protection and exact redirect URI matching.
4. Start with minimal scopes and elevate only when a privileged operation is first attempted. Avoid wildcard or full-access scopes entirely.
5. Sandbox local servers. Use stdio transport where possible to limit access to the client, restrict filesystem and network reach, and require explicit consent showing the full untruncated startup command.
6. Bind state to identity. If your server mints handles for multi-step workflows, generate them with a secure random source and key stored state to the authenticated user ID derived from the verified token, not from client input. Possession of a handle is not authentication.
7. Log everything. Tool invocations, arguments, context changes, and scope elevation events, written to immutable storage with correlation IDs.
8. Control egress. Deny direct model-to-internet and tool-to-internet paths. Force traffic through a proxy that inspects and logs.
9. Require human approval for consequential actions. Payments, deletions, permission changes, and outbound communication should not be fully autonomous.

Items 7 and 8 are ordinary cloud security work, which is the encouraging part of this subject. If you can build detection pipelines and egress controls, you can already do most of MCP defense. The OWASP MCP Security Cheat Sheet is a useful companion for implementation detail.

Where this sits in a cloud security career

MCP security is not a separate discipline. It is IAM, network segmentation, secrets management, supply chain security, and logging applied to a new kind of client. Engineers who already understand least privilege, token audiences, and egress filtering pick it up quickly, because every control above requires knowing how the underlying platform actually behaves.

That is why the PrimeSec curriculum builds AWS, Azure, and Google Cloud security foundations before layering AI and agent security on top, and why the projects are hands-on. For the broader picture, our breakdown of the OWASP Agentic Top 10 covers the layer above MCP, and the AI platform security guide covers the managed services underneath it.

Frequently asked questions

Is MCP inherently insecure?

No. MCP is a protocol, and the specification includes detailed security requirements including mandatory audience validation and prohibitions on token passthrough. Most real incidents come from implementations that skip those requirements, not from the protocol design itself.

What is the single most common MCP security mistake?

Accepting tokens without validating the audience claim. It is a one-line omission that breaks the OAuth trust boundary, enables token reuse across services, and makes incident investigation far harder because downstream logs show the wrong identity.

Are local MCP servers safer than remote ones?

Not necessarily. Local servers run with the same privileges as the client, often with filesystem and network access, and a malicious startup command or dependency executes directly on the user's machine. Sandbox them, use stdio transport to limit access, and require explicit consent that displays the full command before it runs.

Do I need to know MCP to get a cloud security job?

It is not usually a hard requirement yet, but it is a strong differentiator in 2026. Employers adopting AI agents need people who can assess these systems, and the underlying skills of IAM, scope design, and egress control are core to the role regardless.

How does MCP security relate to prompt injection?

Prompt injection is the delivery mechanism and MCP is the payload delivery surface. An injection that previously produced only bad text can now trigger tool calls against real systems, which is why input provenance, scope minimization, and human approval gates matter more in an MCP architecture.

What should I learn first if I am new to this area?

Cloud IAM and OAuth fundamentals. Every MCP control described above is an application of least privilege, audience validation, or network policy. Learn those on a real cloud platform first, then MCP specifics take days rather than months.

Ready to build these skills properly? The PrimeSec 20-week program takes you from cloud security fundamentals to AI platform security with labs, 36 projects, and a defended capstone. Enroll here when you are ready to start.