What is model context protocol security?
Model context protocol security refers to the controls, practices, and architectural decisions that protect MCP deployments from attack. Because MCP operates as an integration layer between AI models and enterprise systems, securing it means addressing trust boundaries at every point in the flow:
How servers authenticate
How tokens pass between services
How tool definitions enter model context
How supply chain integrity gets enforced
MCP itself doesn't enforce security at the protocol level. The specification standardizes how models discover and call tools, but it leaves authentication, authorization, and transport security to whoever implements each host, client, and server. Closing that gap is what MCP security does.
That work spans identity, network, runtime, and supply chain domains, and it requires teams to treat the MCP integration layer with the same rigor they apply to APIs and cloud infrastructure.
How MCP changes your security model
Before MCP, AI agents operated with a fixed set of tools coded directly into the application. With MCP, the agent discovers tools at runtime from any server it can reach, and each server represents a new trust boundary.
This shift is already widespread. Wiz Research found MCP servers in at least 80% of observed cloud environments in early 2026, and 5% of those environments run at least one internet-facing MCP server, per the State of AI in the Cloud 2026 report. MCP has consolidated into a de facto standard faster than agent frameworks have, so the integration layer is now common enough that attackers can assume it's there.
The consequence is concrete: MCP grants the LLM runtime ambient authority across multi-hop trust chains that perimeter and identity controls do not cover alone. Because the protocol mandates none of these controls itself, an MCP server is only as secure as the team that deployed it. Your identity system knows who made a request. It does not know which MCP server that request transited, what tools that server exposed, or whether the tool description the model read at session start matched what you reviewed at deployment.
The Postmark MCP incident in September 2025 illustrated this directly. A widely installed email server MCP package pushed an update that silently BCC'd every agent-sent email to an attacker-controlled domain. The package passed standard review at install time because it behaved legitimately until a later version changed its behavior. No user did anything wrong. The attack surface opened when the tool description entered model context, and the risk compounded when MCP servers carried elevated privileges across multiple connected systems.
Get the Wiz Research Guide to MCP Security
A practical breakdown of the security risks in the Model Context Protocol, from supply chain vulnerabilities and prompt injection to remote server exposure.
MCP attack vectors: what can go wrong
The OWASP MCP Top 10, published in 2025, provides a reference taxonomy for MCP-specific risks. Prompt injection is the common thread. Most of these vectors are delivered by feeding malicious instructions into the model's context, whether through a poisoned tool description, a manipulated tool output, or untrusted data the model reads at runtime. Wiz Research frames this as one leg of the "lethal trifecta" for AI agents: untrusted input, access to sensitive data, and the ability to act.
The five vectors below map to that framework and represent the most likely paths attackers exploit:
Confused deputy: An MCP server with ambient authority gets manipulated into performing unauthorized actions. Preconditions include broad permission scopes and missing per-action authorization, allowing an attacker who influences model inputs to redirect the server's elevated privileges without authenticating directly.
Token passthrough: Forwarding upstream tokens to downstream tool calls, instead of using OAuth 2.0 token exchange per RFC 8693, lets a credential issued for one audience reach systems it was never meant to touch. A compromised intermediate service can then reuse those tokens against additional targets.
Tool poisoning: A form of prompt injection where malicious instructions embedded in tool metadata hijack the model's decision-making before any user action occurs. The precondition: no validation of tool definitions before they enter model context. Invariant Labs confirmed this in April 2025 when demonstrating a poisoned math tool that read SSH keys and exfiltrated them encoded in a math function parameter, with no user interaction and no persistent trace.
SSRF via tool connectors: Tool-supplied URLs that route requests to internal endpoints or cloud metadata services turn MCP tool calls into server-side request forgery (SSRF) vectors. Preconditions include missing egress allowlists and no URL scheme validation, and in cloud environments, this can expose instance metadata endpoints that agents should never reach.
Rogue server registration: Weak session binding combined with no server attestation enables session hijacking and untrusted server acceptance. Research on 500+ scanned MCP servers found that 38% lacked any authentication, making this vector practically accessible in many real deployments.
AI Security Sample Assessment
In this Sample Assessment Report, you’ll get a peek behind the curtain to see what an AI Security Assessment should look like.
Core components of the MCP ecosystem
MCP operates through three primary components, and each exposes a distinct attack surface:
MCP host: The host application, such as an IDE, AI assistant, or agentic workflow platform, manages top-level context and orchestrates client connections. Hosts that provide insufficient session isolation create conditions for context over-sharing attacks.
MCP client: The client manages connections to individual MCP servers and handles tool discovery by calling the server's tools/list endpoint and injecting descriptions into model context. This is the entry point for tool poisoning, because the model reads descriptions as trusted instructions and a compromised description is invisible at the UI layer.
MCP server: The server exposes external tools and sensitive data sources, executes tool calls, handles authentication, and manages transport. Servers are the primary targets for rogue registration and SSRF attacks.
The request flow connecting these components moves through five steps:
The user sends a prompt
The client calls
tools/listfor tool discoveryDescriptions inject into model context
The model issues a tool call
The server executes against external systems
Tool discovery is where tool poisoning enters, context injection is where the model's trust gets redirected, and server execution is where SSRF and confused deputy attacks land.
Model context protocol security best practices
Each control below maps to a specific attack vector from the section above. This reflects the actual preconditions that make MCP attacks viable, not a generic hardening checklist.
1. Enforce strong authentication and least-privilege access
Authentication gaps feed both the confused deputy and token passthrough vectors. Implement OAuth 2.1 with PKCE for user-facing flows and use token exchange per RFC 8693 rather than forwarding upstream tokens downstream. Token exchange issues a new credential scoped to the target audience, preventing a token for one MCP server from being reused against another.
Scope every token to the specific server and tool it needs to reach, using an OpenID Connect (OIDC) strategy with deny-by-default and per-tool scopes. Short-lived tokens reduce the window of exposure further. This directly addresses the confused deputy problem, as per-tool scopes prevent a server with ambient authority from acting outside call-specific permissions. For teams using Wiz AI-SPM, this means mapping MCP server identities to their actual permission requirements and prioritizing overprivileged servers first.
2. Secure transport, fail closed, and isolate MCP servers
Transport and isolation controls address SSRF and rogue server registration. Enforce mutual TLS (mTLS) for service-to-service communication, and require OIDC with explicit audience and scope validation for user-facing flows, so the server confirms it’s the intended token recipient before accepting any request.
Fail closed when MCP servers become unavailable, with predetermined fail-safe behavior tested before production. Sandbox each server in an isolated container with egress allowlists and URL scheme validation. An allowlist that permits only expected outbound destinations eliminates the precondition that makes SSRF viable, and URL scheme validation blocks tool-supplied URLs from referencing internal metadata endpoints or file:// paths.
3. Govern your MCP supply chain
Supply chain controls address tool poisoning and rogue server registration. The Postmark incident showed that a legitimate-at-install package can introduce malicious behavior through a subsequent update, so defense requires both pre-deployment and runtime layers. The exposure is structural, not hypothetical: at least 68% of organizations running self-hosted models pull them at least partly through third-party software, and 18% rely exclusively on these transitive components. A compromised upstream package can reach environments that never explicitly chose it.
Maintain a governed allowlist of approved MCP servers with cryptographic signing, attestation, and version pinning. Treat every new server registration as a change-management event requiring a security review. Hash tool descriptions at deployment and verify those hashes on every tools/list response before descriptions enter model context.
A description that changes between the version reviewed and the version the model reads is, by definition, unreviewed code executing with model-level trust. The Wiz MCP Security Best Practices Cheat Sheet provides a concise reference for these controls organized by risk category.
Real-world example: Grammarly used the Wiz MCP Server to cut SOC triage time by over 90%, bringing manual investigation from 30–45 minutes down to four minutes per ticket by automating workflows across Wiz, Jira, and Slack. Organizations like Infosys have also integrated Wiz MCP to consolidate security operations at scale.
Strengthen your MCP security posture with Wiz
MCP's integration layer introduces trust boundary risks that span identity, network, supply chain, and runtime. Those security risks compound when MCP servers carry elevated privileges across multiple enterprise systems, as the attack surface is not the protocol in isolation: it’s the combination of who the server connects to, what it can reach, and what permissions it inherits at runtime.
Wiz secures MCP through a wider approach:
Our AI-SPM capability discovers and protects customer-deployed MCP servers, giving teams visibility into how those servers are deployed, which agents and data sources they connect to, and where real exposure paths exist.
The Wiz Security Graph connects those findings to identity, network, and runtime context, so you can prioritize the MCP implementations that create actual attack paths rather than theoretical ones.
The Wiz MCP Server provides a secure way for AI agents to query the Security Graph safely, with security boundaries enforced at the protocol level.
Wiz also publishes original MCP threat research through the Wiz Research MCP security briefing.
To see where your MCP implementations create real exposure, schedule a demo or start with the AI Security Assessment for a baseline view of your current posture.
Develop AI applications securely
Learn why CISOs at the fastest growing organizations choose Wiz to secure their organization's AI infrastructure.
FAQs about model context protocol security
The questions below address the most common points of confusion teams encounter when moving from MCP awareness to MCP governance.