Model Context Protocol (MCP) server security best practices

Enterprise AI adoption is accelerating. Governance has not kept up. The explosion of AI agents deployed across corporate environments creates a massive, unmanaged shadow AI attack surface. When a CVSS 9.4 critical vulnerability surfaced in Anthropic’s MCP Inspector developer tool, allowing attackers to execute arbitrary code on developer machines simply by having them visit a malicious website, it demonstrated exactly how fragile the boundary between autonomous agents and core infrastructure truly is.

In this guide, you’ll learn about: 

• The new threat vectors targeting MCP architectures
• Core best practices for authentication and authorization
• How to harden local and remote server environments
• The critical steps for building a proactive incident response plan

Why MCP server security demands a new approach

Securing an MCP server requires shifting focus from human users to autonomous, credentialed non-human identities. Traditional application security focuses on static boundaries and human behavior. An MCP server introduces a dynamic environment where AI models independently plan, request access, and execute operations across multiple integrated systems.

The rise of non-human identities and shadow AI

AI agents, particularly those integrated via integrated development environment (IDE) plugins or conversational interfaces, act as autonomous entities. Once authorized, these non-human identities operate on behalf of the human user, executing commands and retrieving data without direct oversight.

This autonomy accelerates the rise of shadow AI. Developers and business units frequently deploy AI agents and connect them to internal APIs without central IT governance. When a developer installs an AI coding assistant and grants it access to private repositories, they introduce a credentialed, non-human identity that security teams cannot monitor or govern. This expands the corporate attack surface dramatically.

The credential aggregation problem: A single point of failure

An MCP server exists to connect large language models (LLMs) to external tools and data sources. To function, the server centralizes OAuth tokens, API keys, and session cookies for numerous downstream services. A single MCP server might hold concurrent credentials for GitHub, Jira, AWS, and internal databases.

This credential aggregation turns the MCP server into a high-value target. Compromising the MCP server effectively compromises the user’s entire digital work environment. An attacker doesn’t need to breach AWS, GitHub, and Jira separately. They simply need to exploit the MCP server managing those connections to gain lateral access across the organization’s ecosystem.

How traditional security models fall short

Legacy security architectures fail when applied to MCP deployments. Network-level controls like firewalls are ineffective because the traffic originates from an authorized internal agent. If an AI agent has legitimate access to an internal API, the firewall allows the traffic, completely blind to whether the agent’s prompt was maliciously manipulated.

User-centric policies enforced by CASBs also fall short. CASBs monitor human interaction with cloud applications. They cannot parse the semantic intent of an LLM tool call or recognize when an agent is exhibiting anomalous behavior at the API payload level. Securing MCP requires policy enforcement and granular access control specifically designed for machine-to-machine communication.

Understanding real-world MCP threat vectors and exploits

MCP threat vectors exploit the trust boundary between autonomous agents and internal infrastructure, primarily through semantic manipulation and authorization bypass. Because MCP servers bridge natural language processing with executable code, attackers use novel techniques to trick the server into misusing its aggregated authority. This has accelerated the need for AI risk management frameworks significantly. 

Threat #1: Tool poisoning and semantic attacks

Tool poisoning occurs when an attacker embeds malicious instructions directly inside a tool’s description or metadata. The instructions are invisible to the user but fully visible to the AI model, which treats them as legitimate directives. This allows an attacker to manipulate the agent into exfiltrating data, accessing sensitive files, or executing unauthorized actions, all while the tool appears completely benign in the user interface.

The scale of this threat is already measurable in the wild. A 2025 large-scale empirical study analyzing 1,899 open-source MCP servers found that 5.5% exhibited tool poisoning vulnerabilities, where modified or malicious servers had altered tool descriptions, injected false responses, or redirected data flows to unauthorized endpoints. The MCP server executes these commands because the request appears to come from the authenticated agent, bypassing standard network defenses entirely.

Threat #2: The confused deputy and OAuth proxy attacks

The confused deputy attack is a classic authorization flaw that is particularly dangerous in MCP architectures. In this scenario, the attacker tricks the MCP server into using its higher-level authority to perform an action on their behalf.

If an MCP client initiates an OAuth flow to connect a new downstream service, an attacker can intercept the flow. They can inject their own authorization code into the callback. The MCP server, acting as the proxy, exchanges the code and binds the attacker’s service account to the victim’s agent. The agent then unknowingly writes confidential enterprise data into the attacker’s repository. Preventing this requires mandatory enforcement of the state parameter and exact redirect URI matching to guarantee the flow originated from the legitimate user.

Threat #3: Credential exfiltration via rug pull and tool shadowing

Security researchers at SentinelOne use specific terminology for supply chain attacks targeting AI ecosystems. A rug pull attack occurs when a developer installs a seemingly benign MCP tool or plugin. After the tool gains popularity and trust, the maintainer pushes a malicious update designed to harvest the environment variables and API keys stored on the MCP server.

Tool shadowing involves an attacker registering a tool with a name or description nearly identical to a legitimate internal tool. If the LLM router selects the shadowed tool instead of the legitimate one, it hands sensitive input parameters directly to the attacker’s endpoint.

Threat #4: RCE via unauthenticated endpoints or SSRF

Misconfigured MCP servers frequently expose endpoints that lack proper authentication, leading directly to remote code execution (RCE). CVE-2025-49596 in the Anthropic MCP Inspector demonstrated exactly this risk. The vulnerability stemmed from a lack of authentication between the Inspector client and proxy, which when combined with a known browser behaviour affecting how Chrome and Firefox handle the IP address 0.0.0.0, allowed an attacker to execute arbitrary code on a developer’s machine simply by having them visit a malicious website. No additional access, downloads, or user interaction were required. The vulnerability affected all versions of MCP Inspector below 0.14.1 and was patched by adding session token authentication between the client and proxy.

Server-side request forgery (SSRF) is another critical threat. If an MCP server features a tool that fetches URLs based on user input, an attacker can prompt the agent to request internal IP addresses. This allows the attacker to pivot from the MCP server to hit internal cloud metadata services, instantly extracting the host’s temporary AWS identity and access management (IAM) roles or Google Cloud Platform (GCP) service account tokens.

Core authentication and authorization best practices for MCP

Authentication for an MCP server demands cryptographically verifiable client identity and explicit, scoped authorization protocols. You can’t rely on static API keys or long-lived session cookies when dealing with autonomous agents.

Enforce modern OAuth 2.1 with PKCE

It’s essential to mandate modern OAuth 2.1 protocols across your MCP infrastructure. For local or desktop MCP clients, such as IDE plugins, Proof Key for Code Exchange (PKCE) is an absolute requirement.

PKCE prevents authorization code interception attacks. When an IDE plugin starts the authentication flow, it generates a cryptographically random secret. It sends a hash of this secret to the authorization server. When exchanging the authorization code for an access token, the client must present the original secret. If an attacker intercepts the redirect, they cannot obtain the access token because they do not possess the initial secret. Older OAuth flows like the Implicit flow or simple session-based authentication are unacceptable and highly vulnerable in agentic workflows.

Why you must reject the token passthrough anti-pattern

Token passthrough is a dangerous architectural anti-pattern where the MCP client handles the entire OAuth flow and simply passes the final access token to the MCP server.

This completely breaks the chain of trust. The MCP server cannot verify if the token actually belongs to the client presenting it. It forces the server to blindly trust any token it receives. If an attacker compromises a single IDE client, they can inject stolen tokens from other users, manipulating the server into executing actions under false identities. The MCP server itself must securely manage the token exchange process to guarantee identity integrity.

The key point to remember? Never use token passthrough. The MCP server must securely manage the token exchange process itself to mathematically guarantee the client’s identity and prevent token reuse attacks.

Secure client registration: The shift from DCR to CIMD

Managing how AI agents register with the MCP server requires modernization. Legacy Dynamic Client Registration (DCR) requires servers to maintain a registration database, creating operational complexity, unbounded client record growth, and open registration endpoints that malicious actors can abuse.

The MCP specification has moved toward Client ID Metadata Documents (CIMD) as the preferred default for client registration. Rather than requiring servers to maintain a registration database, CIMD allows a client to identify itself using a URL it controls, which hosts a small JSON document describing the client. The server fetches and validates that document on demand, with no prior coordination required. This is particularly important for MCP where a single AI client like Claude Desktop or VS Code may connect to thousands of servers it has never encountered before.

For stronger token security, pair CIMD with Demonstrating Proof of Possession (DPoP). DPoP binds access tokens to a specific client by requiring a cryptographic proof of possession on every request. Even if an attacker steals an access token, they cannot use it because they do not possess the private key bound to that specific token.

Implement progressive scoping and fine-grained authorization

Do not provision AI agents with a single, god-mode token. You must implement progressive scoping and fine-grained, role-based authorization.

When an agent initializes, request the minimum necessary read-only scopes. Prompt the user for explicit consent only when the agent needs to escalate privileges, such as attempting a write operation to a database or a commit to a repository. This limits the blast radius if an agent is poisoned. Building this requires a dedicated authorization server and an API gateway capable of managing granular scopes. Using a platform such as Tyk to route and validate these fine-grained token scopes ensures that your API gateway enforces the exact boundaries of what your MCP agent is permitted to do.

How to harden the MCP server environment (local vs. remote)

Infrastructure hardening for an MCP server dictates strict process isolation for local environments and gateway-enforced zero trust for remote enterprise deployments. The deployment model entirely changes the necessary security controls.

Securing local deployments (IDE plugins)

Local MCP servers, typically running as background processes for IDE plugins, run directly on developer workstations. Securing these environments requires extreme client-side sandboxing.

You must isolate the MCP server process using containerization technologies like Docker or runtime isolation tools like gVisor. This restricts the server’s access to the host filesystem, the host network interface, and other running processes. If a local MCP server is compromised via prompt injection, the sandbox prevents the attacker from reading SSH keys from the host machine or pivoting into the corporate virtual private network (VPN). Furthermore, local deployments require mandatory, un-bypassable user consent dialogs. Any attempt by the local server to request a new scope, access a new local directory, or execute a terminal command must pause execution and require explicit human approval.

Securing remote deployments (enterprise integrations)

Remote enterprise MCP deployments introduce additional security considerations. An enterprise MCP server is a standardized interface layer that allows LLMs to securely access and interact with internal tools, data sources, and services, handling context, permissions, and orchestration. You should protect this infrastructure with an API gateway (such as Tyk Gateway).

Tyk provides the centralized control plane needed to secure remote MCP traffic. You must: 

• Enforce mTLS for all service-to-service communication, ensuring only verified internal microservices can contact the MCP server. 
• Configure strict rate limiting at the gateway level to prevent automated abuse or denial-of-service attacks from rogue agents. 
• Never store downstream credentials in the MCP server’s environment variables. 
• Integrate the gateway with a central secret vault like HashiCorp Vault, injecting credentials into the payload only at the moment of execution.

Mitigating server-side request forgery (SSRF)

SSRF is the most direct path to full infrastructure compromise in remote deployments. Hardening the environment against SSRF requires defense-in-depth at the network layer.

First, maintain a strict allowlist of egress domains. The MCP server must drop any request to a domain not explicitly approved for tool execution. Second, rigorously validate and sanitize all URLs passed to tools by the LLM. Reject any payload containing localhost, 127.0.0.1, or internal subnets. Finally, configure your cloud provider’s network rules, such as AWS security groups or Kubernetes network policies, to explicitly block the MCP server from accessing cloud instance metadata endpoints like 169.254.169.254.

Ensuring tool integrity and safe execution guardrails

Preventing malicious tool execution requires strict schema validation at the input boundary and runtime human oversight for state-changing operations. You can’t trust the LLM to format safe execution commands.

Enforce strict JSON schemas for tool inputs and outputs

The primary defense against prompt injection leading to tool poisoning is enforcing strict, immutable JSON schemas for all tool inputs. If an agent wants to execute a tool, the MCP server must validate the payload against the schema before invoking the backend service.

If an LLM attempts to inject an additional bash command using a semicolon or pipe operator, the strict regex validation within the schema will reject the request.

{

  “$schema”: “http://json-schema.org/draft-07/schema#”,

  “title”: “Execute Shell Command Tool”,

  “type”: “object”,

  “properties”: {

    “command”: {

      “type”: “string”,

      “enum”: [“ls”, “cat”, “git status”],

      “description”: “The specific allowed command to run.”

    },

    “target_directory”: {

      “type”: “string”,

      “pattern”: “^/var/app/data/[a-zA-Z0-9_-]+$”,

      “description”: “Restricts execution to specific safe directories.”

    }

  },

  “required”: [“command”, “target_directory”],

  “additionalProperties”: false

}

By setting additionalProperties to false and enforcing strict pattern matching, you mathematically prevent the agent from executing arbitrary instructions.

Implement human-in-the-loop (HITL) for high-risk write operations

No AI agent should have unilateral authority to execute destructive or high-risk write operations. You must implement a human-in-the-loop policy at the MCP server level:

• Classify all registered tools into read and write categories. 
• Define a policy where actions like delete_repository, drop_table, or provision_infra trigger an execution halt. 
• The MCP server must send a notification (such as via a Slack integration or an IDE popup) detailing the exact payload the agent intends to execute. 
• The operation remains in a suspended state until it receives an explicit, real-time cryptographic approval token from the authorized human user.

Integrate SAST/SCA for AI plugins into your CI/CD pipeline

Treat AI tool manifests and plugins as critical application dependencies. Allowing developers to dynamically register unvetted tools with the MCP server invites rug pull and tool shadowing attacks.

Integrate static application security testing (SAST) and software composition analysis (SCA) specifically for AI plugins into your CI/CD pipeline. Add a mandatory pipeline step that parses the JSON schema of every new tool before it is added to the internal registry. The scanner must flag overly permissive scope requests, wildcard domain targets, and vulnerable dependencies within the tool’s execution script. Only tools that pass the automated pipeline checks and receive security team approval should be merged into the production MCP environment.

Building an incident response plan for MCP servers

An effective incident response plan for an MCP server relies on capability-level auditing and automated downstream credential revocation. When an agent acts maliciously, you need the infrastructure to detect the anomaly and cut access instantly.

Centralize logging: Auditing agent behavior at the capability level

Simple access logs tracking IP addresses and timestamps are useless for auditing AI agents. Instead, implement centralized logging that tracks agent behavior at the capability level.

Log every single tool execution, with the audit trail including the specific scopes utilized, the exact JSON input parameters generated by the LLM, the output returned by the tool, and the distinct non-human identity of the agent. Store this confidential data securely in a centralized, append-only security information and event management SIEM system. This granular forensic trail is the only way security teams can accurately understand the blast radius of a compromised agent and determine exactly what data was accessed or modified.

Your incident response playbook: How to systematically revoke downstream tokens

When you detect a compromised agent, shutting down the MCP server isn’t enough. The attacker may have already exfiltrated the active OAuth tokens, so you need a systematic playbook to revoke downstream credentials.

1. Isolate the compromised MCP server. Disconnect it from the network to halt active agent communication.
2. Identify active sessions. Query your capability-level logs to identify all downstream services (GitHub, AWS, internal APIs) accessed by the malicious agent in the last 48 hours.
3. Programmatically revoke tokens. Use the administrative APIs of the downstream services to instantly revoke the specific OAuth tokens and API keys associated with the compromised sessions.
4. Force user re-authentication. Invalidate the session tokens for all connected client applications, forcing human users to manually re-authenticate and establish a clean chain of trust.

Configure alerts for anomalous activity

Proactive incident response requires detecting threats before data exfiltration occurs. Configure your SIEM or API gateway to trigger alerts based on anomalous agent activity.

Set alert thresholds for rapid scope escalation, such as an agent requesting five different write scopes in under a minute. Flag the execution of any dormant tool that has not been used in the past 30 days. Monitor network traffic for unusual data exfiltration patterns, like a summarization tool suddenly returning gigabytes of payload data. Finally, trigger a critical alert if an agent experiences a high rate of tool execution failures. This often indicates an attacker is actively brute-forcing prompt injections to bypass schema validation.

Frequently asked questions

What is the difference between MCP server security and traditional API security?

An MCP server aggregates credentials for many APIs, making it a much higher-value target than a single, standalone API endpoint. Its security architecture must account for semantic attacks like prompt injection and the unpredictable behavior of autonomous AI agents. Traditional API security focuses on static rate limits and human user authentication, which do not protect against an authorized agent executing a poisoned prompt.

How does PKCE help secure an MCP server?

Proof Key for Code Exchange (PKCE) is critical for authenticating MCP clients, especially local desktop implementations like IDE plugins. It prevents attackers from intercepting the authorization code during the OAuth redirect phase. By requiring a cryptographically hashed secret, PKCE ensures only the legitimate client that initiated the flow can exchange the code for an access token.

What is tool poisoning in the context of MCP?

Tool poisoning occurs when an attacker embeds malicious instructions directly inside a tool’s description or metadata. The instructions are invisible to the user but fully visible to the AI model, which treats them as legitimate directives, potentially causing it to exfiltrate data, access sensitive files, or execute unauthorized actions without the user’s knowledge. 

Can an API gateway such as Tyk help secure an MCP server?

Yes, an API gateway is essential for securing remote and enterprise MCP server deployments. Tyk enforces critical security policies like mutual TLS for service authentication and applies strict rate limiting to prevent infrastructure abuse. It manages fine-grained, role-based access policies and provides the detailed observability required to audit all machine-to-machine agent traffic.

Why is token passthrough a bad practice for MCP servers?

Token passthrough is a severe anti-pattern where the client application handles the authentication flow and merely passes the final access token to the MCP server. This breaks the security model because the server has no mechanism to verify the client’s actual identity. It forces the server to blindly trust any token it receives, leaving the entire architecture vulnerable to compromised clients.

How do you sandbox a local MCP server?

A local MCP server running on a developer machine should be strictly sandboxed using containerization technology like Docker or process isolation tools like gVisor. This restricts the server’s execution environment. It limits access to the host filesystem, network interfaces, and other local processes, containing the damage if the server is compromised by a malicious prompt.

Conclusion

The transition to agentic AI introduces the unique risk of non-human identities and massive credential aggregation. Securing an MCP architecture requires a fundamental shift in posture, moving far beyond traditional perimeter defenses and static API keys.

Enterprise MCP security demands a multi-layered approach. It starts with modern authentication frameworks like OAuth 2.1 and PKCE to establish cryptographic trust. It requires heavily hardened infrastructure, utilizing strict process sandboxing for local deployments and robust API gateways for remote enterprise integrations. Finally, it depends on strict application-level guards, including immutable JSON schema validation and mandatory human-in-the-loop policies for sensitive operations.

As AI agents become increasingly autonomous and deeply integrated into core enterprise workflows, mastering these security principles will be the foundation of safe AI adoption. Implementing this level of control requires a platform designed for the task: One gateway that puts every API, model, and agent under your control. 

Tyk Gateway and Tyk AI Studio provide the centralized policy enforcement, observability, and granular security controls needed to protect your critical MCP infrastructure. Find out more here.

Further reading

Staying up to speed with the latest MCP server security best practices is an ongoing task. The NSA regularly publishes guidance for deploying AI systems securely, as does the Cybersecurity and Infrastructure Security Agency. And the Tyk team is always on hand to help.