The complete guide to MCP security: How to secure MCP servers & clients

The Model Context Protocol (MCP) is one of the most important evolutions in AI infrastructure today. It allows large language models (LLMs) to interact with external tools and APIs in a structured way, turning them from passive text generators into active agents that can fetch data, trigger workflows, and execute tasks on behalf of users.

But this power comes with risk. Each MCP connection creates a bridge between untrusted model-generated inputs and sensitive systems. A single weak point (a poisoned prompt, an overbroad permission, or an unverified endpoint) can turn that bridge into a pathway for exploitation.

This article lays out the security risks unique to MCP and provides best practices for both servers and clients. The goal: help builders design systems that unlock MCP’s potential without opening doors to abuse.

The core security risks of MCP

When you let a model issue tool calls and execute tasks, you’re effectively putting an interpreter between untrusted inputs and sensitive systems. That makes MCP powerful, but also uniquely risky.

The following categories capture the most important threats that teams need to guard against.

Prompt injection & tool poisoning

LLMs are easily manipulated. A cleverly written prompt can trick the model into issuing harmful tool requests. For example, telling the assistant to “ignore previous instructions” and execute a hidden command.

Similarly, maliciously designed tool descriptions (known as tool poisoning) can mislead the model into using them in unintended ways. Left unchecked, this can turn the model into an attacker’s proxy.

Researchers at Tenable demonstrated how malicious MCP tool descriptions could hijack model behavior to exfiltrate sensitive data or escalate privileges. Similarly, Invariant Labs documented tool poisoning attacks across providers, and in another case, a GitHub prompt injection tricked assistants into leaking private repository data.

These cases highlight just how easy it is for “innocent” inputs to become attack vectors.

Command execution & code injection

MCP servers often pass inputs directly into APIs, databases, or even shell commands. If these inputs aren’t sanitized, attackers can inject arbitrary code. Imagine a model asked to “list files,” but instead it runs rm -rf / because the string wasn’t validated. Code injection is one of the most damaging risks because it grants full control over the host environment.

A critical SQL injection flaw was uncovered in Anthropic’s SQLite-based MCP server implementation. The vulnerable repository had already been forked or copied more than 5,000 times before the GitHub repository was archived on May 29, 2025, spreading the flaw through the ecosystem. All these forks represent a major supply-chain risk to everyone who used the flawed server before Anthropic archived it, and to anyone running a forked version.

Token theft & credential leakage

MCP relies on tokens to authenticate clients and authorize tool use. If these tokens are logged in plaintext, cached improperly, or exposed in URLs, attackers can steal them. Even a short exposure (like in a debug log) can be enough to cause a breach, especially if tokens are long-lived or not tied to a specific audience. Stolen tokens allow adversaries to impersonate clients, escalate privileges, and maintain persistent access.

Invariant Labs showed that malicious MCP tools could exfiltrate WhatsApp chat histories by capturing leaked authentication data. This highlighted how mishandled tokens and secrets become an attacker’s entry point.

Excessive permissions & overexposure

Permissions are often granted more broadly than necessary, creating unnecessary risk. Referencing back to the principle of least privilege (one of the oldest and most fundamental security tenets), no resource should ever have more access than it needs to perform its intended task.

In the context of AI and MCP, this becomes even more challenging. To make AI systems adaptable and flexible, developers sometimes over-provision permissions so models can handle a wide range of tasks. But this flexibility comes at a cost: when scopes are too broad, a single exploit or misdirected tool invocation can lead to serious data leakage or unauthorized actions.

A paper titled “We Urgently Need Privilege Management in MCP” (arXiv, July 2025) highlights measurements across 2,500+ real-world MCP plugins, revealing that many had overly extensive access patterns. The study documents cases where insufficient privilege separation led to real-world risks like privilege escalation, data tampering, and misinformation propagation, demonstrating why strict access control is critical.

Unverified third-party endpoints

MCP allows clients to discover and connect to servers dynamically. If a malicious actor sets up a fake MCP server and tricks a client into connecting, that server can impersonate legitimate services. Without cryptographic verification, clients can’t distinguish friend from foe, and may hand over tokens or sensitive requests to the wrong party.

A systematic study titled “Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol Ecosystem” (arXiv, May 2025) examined thousands of MCP servers. Researchers successfully deployed malicious MCP servers via aggregator platforms and demonstrated that existing audit mechanisms failed to detect them. Their proof-of-concept servers executed harmful actions, like accessing private files or triggering unintended system commands, highlighting how unverified endpoints can seriously undermine MCP security.

Malicious or compromised MCP Servers

Even when servers are technically valid, they may not be trustworthy. A malicious or compromised MCP server can manipulate AI behavior, inject harmful outputs, or exfiltrate sensitive data under the guise of normal tool usage. Because MCP encourages plugging into many external services, the attack surface grows with every new server integration.

In one documented exploit, attackers set up a rogue MCP server masquerading as a WhatsApp integration. The AI believed it was using a normal messaging tool, but the server rerouted all messages to the attacker’s phone number, effectively hijacking conversations. In environments with multiple MCP servers, a malicious one could even shadow or override commands from trusted servers, making it nearly impossible for users to spot interference.

Confused deputy attacks in OAuth proxy flows

MCP servers often proxy OAuth authorization flows to third-party APIs. If these flows are misconfigured (for example, by using a static client ID without enforcing user consent), attackers can exploit this to bypass consent screens and obtain unauthorized access tokens. This is a classic confused deputy problem: the server unwittingly helps the attacker gain privileges it should not have granted.

Token passthrough anti-pattern

Some MCP servers incorrectly forward tokens from clients to downstream services without validating whether those tokens were meant for them. This creates serious risks:

• Attackers can circumvent controls like rate limits and payload validation.
• Audit trails lose clarity about which client performed an action.
• Trust boundaries collapse, since tokens are accepted across unintended systems.

Replay attacks & session hijacking

When session tokens or identifiers are exposed, attackers can capture and replay them. This allows unauthorized parties to “hijack” a valid session and act as if they were the real client.

Without safeguards like nonces, token binding, or strict session expiry, the system may accept repeated requests, giving attackers a simple but powerful way to replay sensitive actions.

Security best practices for MCP servers

Servers sit at the heart of MCP: they expose tools, enforce access, and execute actions. If they’re compromised, the attacker gains direct control over sensitive systems.

1. Authentication & authorization

Without strong identity checks, attackers can impersonate clients, use overbroad tokens, or replay credentials meant for another system. This is the classic “confused deputy” risk, where the server executes a malicious request under the guise of a legitimate client.

Best practices:

• Enforce OAuth 2.1 with proper token validation.
• Apply least-privilege scopes, mapping each tool to only what’s essential.
• Use sender-constrained tokens such as mTLS or DPoP (Demonstration of Proof-of-Possession) to prevent token replay.
• Audit client registration and discovery metadata to block spoofed auth servers.
• Prevent confused deputy issues by enforcing consent for every OAuth proxy flow.

2. Input sanitization & prompt safety

Model-generated inputs are inherently untrusted. If a malicious string makes it through unchecked, it can trigger shell escapes, SQL injection, or other command exploits.

The solution is simple enough, which makes it surprising that we keep having vulnerabilities of this kind. OWASP’s SQL Injection Prevention Cheat Sheet has held the same #1 recommendation for over a decade: use parameterized queries.

Best practices:

• Validate inputs against JSON Schema or Protobuf definitions.
• Sanitize strings (escape shell characters, enforce length limits).
• Run tool executions in isolated sandboxes or containers to limit blast radius.
• Require human/policy approval for high-risk operations (e.g., file writes, deletes).

3. Token security & credential hygiene

Tokens often leak through logs, caches, or config files. If they’re long-lived and not scoped, an attacker can use them indefinitely.

Best practices:

• Use short-lived JWTs (with exp claims) scoped to specific audiences.
• Never log tokens or pass them in URLs (prefer headers like Authorization: Bearer).
• Store tokens securely, away from userland processes.
• Rotate and revoke credentials regularly.
• Only accept tokens explicitly issued to the server, and validate the audience (aud) claim rigorously.

4. Scope management & exposure control

Tools with broad scopes give attackers more leverage. A single compromised tool can cascade into cross-system exposure.

Best practices:

• Audit tools regularly for scope creep.
• Apply least privilege for every tool and endpoint.
• Separate read and write scopes; avoid mixing them in one token. Define granular scopes (e.g., crm.read, crm.write) instead of broad crm.*.
• Audit scopes in CI/CD with policy-as-code (e.g., OPA or Conftest).
• Enforce deny by default, requiring explicit grants.

5. Endpoint verification & tool integrity

Spoofed MCP servers or tampered tools can masquerade as legitimate ones. Without integrity checks, servers load malicious code into trusted environments.

Best practices:

• Use signed registries and cryptographic verification for tools. Verify tool registries with Ed25519 or RSA signatures.
• Pin package versions and use hashes (sha256sum) in manifests to prevent silent tampering.
• Enforce certificate pinning for TLS connections.
• Alert users when tools are updated or replaced.
• Reject endpoints that fail TLS or metadata verification.
• Audit tools periodically to prevent malicious or “poisoned” versions from being substituted.

6. Observability & auditing

Without visibility, malicious actions can go unnoticed. Servers that fail to log, monitor, and enforce limits won’t detect abuse until damage is already done.

Best practices:

• Centralize logging of prompts, tool invocations, and responses, for auditing and incident response.
• Monitor for anomalies like repeated failures or unusual sequences.
• Correlate logs with client IDs and timestamps for forensic clarity.
• Review logs regularly and feed them into SIEM/SOC pipelines for real-time monitoring.
• Apply regular patches and updates to both server runtime and dependencies.
• Apply rate limiting, timeouts, and cost controls to prevent resource abuse and runaway tool use.

7. Supply-chain security

MCP servers depend on libraries, packages, and tool modules that may be tampered with or maliciously substituted. A single poisoned dependency can compromise the server at build time or runtime.

Best practices:

• Use signed and verified packages for all server components.
• Integrate SAST (Static Application Security Testing) and SCA (Software Composition Analysis) into CI/CD pipelines.
• Monitor for new CVEs in dependencies and patch quickly.
• Prefer trusted, vetted registries; avoid pulling unpinned packages from public sources.

Security best practices for MCP clients

Clients are the gatekeepers: they decide which servers to trust, which tools to invoke, and how much of the model’s output to accept. If the client is lax, it may hand over power to the wrong server or execute malicious requests unchecked.

The following practices ensure clients enforce trust, maintain oversight, and protect against server abuse.

1. Secure discovery & trust anchoring

Clients that don’t verify servers risk connecting to impostors. A fake MCP server can capture tokens or trick the client into harmful actions.

Best practices:

• Verify servers using signed metadata: MCP servers should publish a metadata file (e.g., JSON) along with a digital signature (Ed25519, RSA, etc.). Clients verify the signature against a known public key before trusting the server.
• Use trusted registries: only connect to MCP servers or tools listed in vetted registries that enforce namespace isolation and signature checks, reducing the risk of rogue endpoints.
• Enforce TLS/mTLS on all connections to protect against man-in-the-middle attacks.
• Refuse connections to servers that lack cryptographic verification or are not part of an approved allowlist.

!!Note that these practices follow the same pattern used in package ecosystems like PyPI or Docker Hub, where integrity checks and signing are critical to prevent supply-chain attacks.!!

2. Authorization & trust

Even if a server is authentic, a compromised or spoofed authorization flow can trick clients into granting excessive access. If OAuth flows aren’t validated correctly, malicious servers may escalate privileges.

Best practices:

• Implement OAuth 2.1 client flows strictly (e.g., Authorization Code with PKCE).
• Verify authorization server metadata and keys before trusting tokens.
• Enforce scope checks locally. Reject requests outside approved scopes.
• Validate tokens on every request.
• Fail closed: if verification fails, deny access.

3. Connection security

Transport-layer weaknesses let attackers eavesdrop, tamper with, or impersonate servers. Clients that don’t enforce TLS are vulnerable to man-in-the-middle attacks.

Best practices:

• Always require TLS 1.2+ for all MCP communications.
• Enforce mutual TLS (mTLS) where possible to authenticate both server and client.
• Reject self-signed or untrusted certificates.
• Use certificate pinning for high-value environments.

4. Tool integrity

Malicious servers can advertise tool definitions that are tampered with or unsafe. If clients don’t validate these definitions, they may execute dangerous or corrupted logic.

Best practices:

• Validate tool definitions against schemas (e.g., JSON Schema).
• Require digital signatures on tool metadata.
• Maintain a whitelist of trusted tools; reject unknown or unrecognized ones.
• Warn users when tool definitions change unexpectedly.

5. Input validation & prompt safety

Prompt injection can make models request tools in unsafe ways. Without validation, the client becomes a blind executor of malicious instructions.

Best practices:

• Validate model requests against JSON Schema or Protobuf contracts.
• Reject unknown fields, excessive nesting, or overly long strings.
• Sandbox untrusted completions before execution.
• Require user confirmation for high-impact requests.

6. Token management & local isolation

If tokens are stored in plaintext on a client device, malware or rogue processes can steal them.

Best practices:

• Store tokens in system keychains (e.g., macOS Keychain, Windows DPAPI).
• Use ephemeral storage when possible.
• Isolate IPC with UNIX domain sockets or restricted gRPC channels.
• Rotate tokens automatically on short intervals (minutes, not days).

7. Session integrity & replay protection

Attackers can replay captured session identifiers to impersonate valid clients.

Best practices:

• Bind sessions to nonces or unique transaction IDs.
• Use short-lived session cookies with SameSite/HttpOnly flags.
• Reject stale requests and enforce clock skew tolerance.
• Regenerate session keys on re-authentication.

8. Tool use transparency & human oversight

If tool use happens silently, users can’t tell when models are overstepping.

Best practices:

• Display tool invocations in a user-visible UI before execution.
• Provide an audit dashboard of recent tool calls.
• Require explicit confirmation for destructive actions.
• Log completions with model + version identifiers for traceability.

9. Execution sandboxing

Clients may need to perform local operations, such as file handling, shell commands, or sampling requests. If these run without isolation, a single malicious request could compromise the environment.

Best practices:

• Run local executions in sandboxed environments (VMs, containers, seccomp profiles).
• Apply schema checks, policy filters, and user confirmations as layered defenses.
• Limit file system and network access from sandboxed processes.
• Use OS-level capabilities (AppArmor, SELinux) for extra isolation.

10. Sampling controls

MCP servers can request clients to perform sampling (LLM completions). Malicious servers could abuse this to inject prompts or drain budgets.

Best practices:

• Show completions to users for review/edit/reject before execution.
• Filter completions with content moderation or sanitization layers.
• Let users select the model family and version used.
• Apply rate limits, timeouts, and cost caps specific to sampling requests.

Best practices summary

How WorkOS can help secure MCP

Implementing MCP securely isn’t just about knowing the risks; it’s about having the right infrastructure in place. WorkOS provides security and identity building blocks that map directly to the best practices outlined in this guide.

• Authentication & authorization: Use AuthKit as the authorization server for your MCP deployments. AuthKit enforces modern OAuth 2.1 flows, supports PKCE, and issues sender-constrained tokens, helping ensure only trusted clients can connect.
• Granular permissions & limited scopes: Define and enforce fine-grained scopes across tools. With WorkOS, you can align every MCP tool or action with the principle of least privilege, reducing the damage a single compromised client can cause.
• Login monitoring & anomaly detection: Radar provides real-time monitoring for logins, flagging suspicious activity like unusual geographies, impossible travel, or repeated failures. This helps detect compromised MCP clients before attackers can escalate.
• Audit logs & observability: Use WorkOS Audit Logs to maintain a complete history of MCP-related actions: tool calls, authentications, scope requests. This gives your team the visibility needed for forensics, compliance, and continuous monitoring. You can also stream these logs directly to your SIEM provider for real-time analysis, correlation, and automated incident response, ensuring your security team has continuous visibility where they already work.
• Session revocation & control: WorkOS makes it easy to revoke sessions instantly. If an MCP client or server is compromised, you can cut off access in real time without waiting for tokens to expire naturally.

Together, these capabilities let teams move beyond theory and operationalize MCP security best practices with battle-tested infrastructure.

Final thoughts: A shared responsibility

The security of MCP depends on the server and the clients working in tandem. The server must enforce strict controls, sanitize inputs, and ensure tools remain trustworthy. Meanwhile, the client must act as a vigilant gatekeeper, ensuring that requests are authorized, transparent, and sandboxed before reaching the server.

Think of MCP as a dialogue between two guardians:

• The server protects the resources it exposes, standing as a fortified wall against abuse.
• The client acts as the conscience of the interaction, ensuring that the model does not overstep its bounds or trick its way into dangerous actions.

Together, they form a circle of trust that ensures AI systems remain not only powerful but also safe.

Security in MCP is not a one-time checklist; it is an ongoing practice of vigilance, monitoring, and adaptation. By embedding these practices from the start, developers and organizations can build MCP deployments that are resilient against today’s risks and prepared for tomorrow’s threats.