MCP servers give AI agents direct access to your internal systems—databases, APIs, file systems—through a standardized protocol. That's powerful for building agentic workflows, but it also creates attack vectors that traditional security tools weren't designed to handle. Gartner predicts 25% of enterprise breaches by 2028 will trace back to AI agent abuse.
The MCP specification doesn't include authentication or authorization. Every server you deploy inherits whatever permissions it's granted, and every agent request flows through without verification unless you add controls externally. This guide covers the critical vulnerabilities, supply chain risks, and Zero Trust practices that development teams can apply to secure MCP deployments.
MCP servers pose significant security risks because they connect AI agents to sensitive internal systems—databases, APIs, file systems—without built-in authentication or authorization. The biggest concerns are prompt injection, unauthorized command execution, over-permissioned access, and the "confused deputy" problem where servers act on requests without verifying who's actually asking. Policy-driven access control addresses these gaps by checking every request against identity and context. Pomerium Zero provides this layer for free, with full audit trails for every agent action.
The Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools, data sources, and APIs through a single interface. Instead of building custom integrations for every tool an AI might call, MCP gives you a consistent way for agents to discover what's available and invoke it.
Model Context Protocol (MCP): A specification that standardizes how AI applications request context and take actions through external servers
Why teams adopt it: MCP enables agentic workflows—AI assistants that query databases, trigger jobs, or interact with internal apps
The architecture flows from host to client to server to external tools. Understanding this chain helps clarify where vulnerabilities show up.
Three components make up the MCP stack:
MCP Host: The AI application making requests—Claude Desktop, an IDE plugin, or a custom agent runtime
MCP Client: The protocol handler that manages connections between the host and servers
MCP Server: A lightweight program exposing tools, resources, or prompts to the AI
The server is where most security concerns concentrate. It's the bridge between what the AI wants to do and what your systems allow.
MCP servers run either locally on a developer's machine or remotely in cloud infrastructure. Local deployments risk network exposure if misconfigured. Remote servers introduce supply chain concerns around third-party code. Both deployment models share the same core vulnerabilities, though the attack surface differs. — Trend Micro has identified 102 MCP-specific CVEs — though the attack surface differs.
MCP servers create attack vectors that traditional perimeter security doesn't address. The protocol lacks built-in authentication or authorization—servers often run with broad permissions, and the trust model assumes agents behave predictably.
That assumption breaks down fast. Prompt injectionThat assumption breaks down fast. Prompt injection, ranked #1 on the OWASP Top 10 for LLM Applications, can manipulate agent behavior in ways developers didn't anticipate. Once an agent has access to an MCP server, it typically inherits whatever permissions that server holds. This differs fundamentally from human-driven API access, where request patterns are more predictable and scoped.
Five primary attack vectors affect MCP deployments.
Improperly sanitized inputs from the LLM can lead to arbitrary code execution on the MCP server host. When servers have shell access or can run scripts, a single malicious prompt could compromise the underlying system.
MCP servers often have broad access to file systems, APIs, and databases. If compromised, attackers can steal data or move laterally through your infrastructure. The server maintains access whether or not it's actively needed—a standing privilege problem.
The "NeighborJack" vulnerability occurs when servers bind to all network interfaces (0.0.0.0) instead of localhost. Anyone on the same network—a café, a shared office—can connect and execute commands. This misconfiguration appears in hundreds of MCP server implementations.
A confused deputy attack tricks an MCP server into using its legitimate authority on behalf of a malicious actor. Because MCP lacks strict authentication, servers may act without verifying the requester's identity. The server has permissions; the attacker exploits them indirectly.
Many MCP implementations don't log tool calls, inputs, or outputs comprehensively. When something goes wrong, teams can't reconstruct what happened—making incident response difficult and compliance audits nearly impossible.
Beyond direct vulnerabilities, third-party dependencies introduce their own attack surface.
"Rug pull" attacks happen when third-party MCP servers change behavior after initial approval. A server that looked safe during review can initiate malicious actions later. Typosquatting—registering server names similar to legitimate ones—compounds this risk.
MCP servers often depend on external packages. Without code verification and an approval process, organizations inherit security flaws from upstream dependencies unknowingly.
Two injection vectors exploit the unique characteristics of AI-driven systems.
Prompt injection embeds malicious instructions in data that manipulate LLM behavior. An attacker might poison a document or database entry that the agent later retrieves, tricking it into performing unintended actions or revealing sensitive information.
Tool poisoning targets the tool definitions themselves. A malicious MCP server provides poisoned descriptions that alter how the LLM interprets and uses the tool. Unlike prompt injection (which targets data content), tool poisoning targets metadata the agent trusts implicitly.
Five practices reduce exposure across the vulnerabilities described above.
Limit each MCP server's access to only the files, tools, and APIs it actually uses. Scope access by task or workflow, applying the principle of least privilege rather than granting broad permissions by default.
Run MCP servers in containers, sandboxes, or restricted environments. Limit network access from within the isolation boundary so a compromised server can't reach other systems.
Verify MCP server source, review code, and establish an approval process before connecting servers to production. This addresses supply chain risks proactively.
Avoid binding servers to public interfaces. Use local sockets, authenticated connections, or private networks. A few lines of configuration prevent the NeighborJack vulnerability entirely.
Log every tool call, input, and output. Logs support incident response, compliance requirements, and forensic analysis when something goes wrong.
General best practices help, but treating MCP servers as untrusted conduits requires per-request verification.
Agents benefit from federated identities—just like humans and services—so access can be scoped, traced, and revoked. This contrasts with static API keys or shared secrets that persist indefinitely and can't be attributed to specific actions.
Every MCP tool call can be evaluated against context-aware policies: identity, task, time, source IP. This prevents over-permissioned sessions and limits blast radius. Pomerium applies this same model across humans, services, and agents through a single policy engine.
When anomalies are detected or credentials are compromised, immediate revocation stops the damage. Long-lived tokens persist after compromise—sometimes for days before anyone notices.
Observability for MCP deployments extends beyond traditional application monitoring:
Tool call frequency and patterns: Detect anomalous usage that might indicate compromise
Input/output validation: Identify injection attempts before they succeed
Access logs with full context: Support compliance and forensic analysis
Policy decision records: Show who accessed what, when, and why
Centralizing logs across human, service, and agent access simplifies governance. The questions are the same regardless of identity type: what happened, who did it, and was it authorized?
Addressing MCP security risks requires a unified access layer that applies consistent policies to AI agents, services, and humans. Pomerium's Secure Agentic Access provides self-hosted, per-request authorization with full audit trails.
Per-request authorization: Every MCP tool call evaluated against policy
Context-aware controls: Decisions based on identity, task, time, and environment
Self-hosted deployment: Traffic and policies stay in your environment
Unified governance: Same policy engine for humans, services, and agents
Start Free with Pomerium Zero to apply Zero Trust controls to MCP deployments without re-architecting your infrastructure.
MCP security accounts for AI agent autonomy and prompt-driven behavior. Traditional API security assumes predictable, developer-defined request patterns. MCP requires continuous authorization per action, not just initial authentication at the start of a session.
Yes. MCP servers can run in air-gapped or isolated networks. Teams still enforce least-privilege access and monitor for insider threats or compromised local agents—network isolation alone doesn't eliminate all risk.
With identity-based access and per-request authorization, teams can immediately invalidate an agent's session or credentials without redeploying the MCP server or rotating shared secrets across the environment.
No. The MCP specification does not enforce authentication or authorization standards. Organizations deploying MCP servers implement these controls externally—which is why policy-driven access layers are essential.
MCP deployments handling sensitive data may fall under SOC 2, HIPAA, GDPR, or industry-specific regulations. These frameworks typically require audit trails, access controls, and data protection measures that MCP doesn't provide natively.
Apply output filtering, scope tool permissions to specific data sets, and use policy-based controls that restrict what data agents can access or return based on context. Logging all outputs also helps detect exfiltration attempts after the fact.
Stay up to date with Pomerium news and announcements.
Embrace Seamless Resource Access, Robust Zero Trust Integration, and Streamlined Compliance with Our App.
Use Cases
Quicklinks
Stay Connected
Stay up to date with Pomerium news and announcements.
