The MCP Security Guide: What Access Control Misses

Sep 17, 2026

In May 2026, Cyera's research team discovered a flaw in OpenClaw, an open-source agentic platform that went viral. The flaw let a locally running process upgrade its permissions to take full control of the AI agent without a jailbreak or even touching the model.

OpenClaw trusted the permissions the client claimed to have rather than actually verifying who should (and should not) have access. This type of security breach is an MCP (Model Context Protocol) breach.

Introduced by Anthropic in late 2024, MCP is a standardized way to connect AI agents and assistants to external tools and data sources.

MCP security is the set of controls that govern those connections: what data an agent can reach, and what actions it's cleared to take. It does not ship with the protocol. Authentication, access control, and monitoring are yours to build, and most teams building on MCP haven't yet.

The real challenge is knowing exactly where the protocol's responsibility ends and yours begins.

Key takeaways

MCP security encompasses four key pillars: identity and authentication, network and transport, supply chain, and runtime data access.
MCP does not automatically manage security; teams still have to implement their own protections for authorizations and monitoring.
OWASP's MCP Top 10 has emerged as the industry framework for categorizing the biggest security risks associated with MCP.
Common MCP attacks include weak permission controls, mishandled tokens, and unauthorized access.
Compromised MCP servers are dangerous because they implicate servers and also allow servers to access credentials and data sources that it’s connected to.

How Does MCP Security Work?

MCP has three major components and each has its own vulnerabilities to attacks.

The host is actual AI application which the client then connects to external tools.
The server is where those tools actually run and carry out requests.
The credentials that are needed to access the necessary tools and data.

A request typically moves through a series of steps. First, the user prompts AI to do something. Next, the client checks which tools are available on the server. Finally, the model selects a tool and then the server carries out the request prompted by the client. The breakdown in this workflow is that the MCP does not ever automatically verify who the client is unless there have been access controls already implemented by the team. If they don’t, it requires organizations to build out those security checks themselves.

When we think of MCP security, there are three major areas to secure (with the caveat that where a server lives changes which one matters most):

The connection
The protocol i.e. the communication between systems
The tools and data being exposed

A local server, invoked over stdio, can execute arbitrary code and touch the filesystem directly, so a compromise means a foothold on that machine. A remote server carries less code-execution risk but still exposes whatever it's connected to over the network.

Are MCP Servers Secure?

The biggest risk with MCP security is that they often hold access to several systems at once, and can act as a massive hub for stored credentials, access points, and sensitive data. If these servers become compromised, this has the potential to open the floodgates and enable access to everything it’s trusted to reach.

The cost of incidents like this are significant. In 2025, IBM identified that a $670,000 increase in breach costs can be directly attributed to high exposure to unauthorized AI tools. This data underscores that MCP servers are increasingly creating vulnerabilities in sensitive systems (and as we’re observing, it comes at a high cost).

The implications of AI risk and the need for trust also has regulators paying closer attention. In May of 2025, CISA, the NSA, the FBI, and cybersecurity authorities in Australia, New Zealand, and the UK published joint guidance on AI data security. One of the most significant takeaways was that AI tools are essentially only as trustworthy as the data they rely on. While MCP security isn’t explicitly mentioned by name, the same principles directly apply.

OWASP is also developing the MCP Top 10 (currently in beta), which outlines the major and most common security risks. Some of these risks include but are not limited to excessive permissions and access, token misuse, malicious tools, and shadow servers.

These risks are already playing out in real-time.

In under a year, three different teams with distinguished examples of these MCP security risks were uncovered namely by the postmark-mcp incident, MCP Inspector, and Cyera’s own OpenClaw research which are all covered below.

Key MCP Security Risks and Threats

An overview of key MCP security risks and threats, what they are, real-world examples, and how to mitigate them.
Risk	What it is	Real example	Mitigation
Confused deputy	A trusted server is tricked by a malicious user into using its own permissions to access or perform actions they shouldn't have.	MCP.io's authorization spec has documented this as an identifiable attack pattern.	Require explicit consent, permissions, and approval for each individual client to perform sensitive actions instead of assuming they should receive the same trust as the system.
Token passthrough	A server passes along a client's token to another API without confirming that it's actually meant to be used there.	The MCP authorization specification explicitly prohibits this.	Verify each token is intended for the system receiving it, and exchange tokens instead of reusing the original.
Tool poisoning	Malicious instructions are embedded in a tool's metadata and the model mistakes it as trusted and safe context.	Invariant Labs' poisoned "math" tool concealed hidden instructions in its description field.	Treat tool descriptions as untrusted input; scan and sign approved metadata before deployment.
Rug pull attacks	A tool passes initial review, but later an update silently adds malicious behavior.	The `postmark-mcp` incident: a trusted package's sixteenth version added a one-line BCC backdoor.	Use approved tool versions and continuously review for unexpected changes after post-approval.
Tool shadowing	A compromised or malicious tool is used by an attacker to trick the model into misusing a trusted tool.	This is a known and documented form of attack that exploits trust between tested tools.	Don't let one server's metadata influence another's tools, and instead keep them isolated.
SSRF via tool connectors	A malicious server manipulates the system into sending auth or metadata requests to sensitive internal systems.	Commonly targets the cloud metadata address `169.254.169.254`.	Restrict server connections to only allow approved destinations and block access to other internal systems unless they've been explicitly approved.
Session hijacking	Predictable and easy-to-guess session IDs allow an attacker to impersonate a legitimate client.	Some early MCP servers didn't properly bind sessions to the right client or transport.	Link sessions to correct transport and user and use long, unpredictable random tokens to keep them more secure.
Rogue server registration	Servers without authentication allow anyone who finds the endpoint to connect.	Scans through 2025 and 2026 repeatedly found that somewhere around ⅓ to 40% of public-facing servers require zero authentication whatsoever.	Require authentication by default and reject access if security settings are not properly configured.
Local server compromise	A compromised startup command or dependency gets code execution with the same permissions as the client.	MCP.io flags this as a primary risk of local, stdio-based servers.	Sandbox local servers to isolated environments and only grant them access and permissions to what they need.
Scope creep	Servers request broad access like `files:` or `admin:`, instead of more narrow permissions focused on what they actually need.	A common finding usually uncovered during MCP security assessments of production deployments.	Define permissions for each individual tool instead of per server and regularly audit and revoke permissions over time to keep them limited in scope.
MCP loopback privilege escalation	A server trusts the identity a client claims to have without checking who it actually is.	Cyera Research found that a process running locally could tell OpenClaw that it was the owner, and OpenClaw would then grant it full control.	Never trust client-asserted privilege claims. Validate every decision against the server's own session state.

How Do You Secure MCP?

Authentication and Authorization

Run on OAuth 2.1 with PKCE, using token exchange under RFC 8693 instead of passing client tokens straight through to downstream APIs, with scopes defined per tool rather than per server.

Transport and Isolation

Require TLS 1.2 or higher, mutual TLS for server-to-server connections, sandboxed or containerized servers, egress allowlists, and a fail-closed default when a policy decision can't be made.

Supply Chain

This is where current guidance is thinnest, and where the postmark-mcp incident did the most damage. Sign approved tool packages, pin versions instead of tracking latest, run SAST and SCA scanning before deployment, and alert on any change to a tool's description after it's been approved.

Credentials and Logging

Route credentials through enterprise vaults like AWS Secrets Manager or HashiCorp Vault, using short-lived, rotated tokens instead of static keys in a config file. Logging needs full parameters on every invocation, correlated into the SIEM and watched for anomalous access sequences, not just individual suspicious calls. For high-risk tool calls, a human-in-the-loop approval gate remains the most reliable control available.

Some security vendors now publish their own MCP servers as reference points for governed implementations. Cyera's own MCP server, launched at RSAC 2026, is one example: it scopes agent access to a managed data warehouse instead of exposing raw credentials to the systems behind it.

Most current guidance stops short right here. Every framework above scopes least privilege by function: what a tool can do. Read email, write files, call an API. Almost none of it scopes by what data that tool can reach. A tool with a narrow, well-reviewed function, something as innocuous as "search the knowledge base," can still expose regulated data if nobody classified what's sitting behind that search index. Function-level scoping tells you a tool is doing what it's supposed to do. It doesn't tell you what it's touching.

MCP Governance and Compliance

MCP governance starts with a centralized gateway: one enforcement point that allows approved servers and reviews capability negotiation before a new server reaches a production agent. New server registrations should go through the same change-management process as any other infrastructure change, not get spun up ad hoc by whichever team wants to move fast.

Inventory is the harder problem. Most security teams can't answer "which MCP servers exist across our organization, and what can each one reach?" That's the shadow MCP server problem, structurally identical to shadow SaaS and shadow data: risk you can't manage because you don't know it exists.

The compliance angle follows directly. Regulated data, PII, PHI, financial records, doesn't stop being regulated because an AI agent touched it instead of a human. It needs the same audit trail either way, which means extending DLP-style controls to agent pipelines rather than exempting tool calls from rules that already govern human access. Cyera's Microsoft Copilot Studio integration shows that policy layer in practice, evaluating tool calls, MCP included, against data sensitivity before execution. SentinelOne's phased benchmark is a reasonable pace: inventory and logging within 30 days, gateway and approvals within 90, full governance within 180.

What Makes MCP's Security Risk Unique?

Concept	How it differs from MCP security
API security	Traditional API security assumes a fixed, known set of endpoints reviewed in advance. MCP tools are discovered dynamically at runtime, so the trust boundary moves every time an agent connects to a new server.
LLM and prompt injection security	This is the broader discipline covering any adversarial input to a model. MCP security is the narrower slice specific to how tool descriptions and server metadata enter the model's context.
Agentic AI security	Covers an agent's autonomous decision-making and action-taking broadly. MCP security is the integration layer underneath that: how the agent reaches its tools and data.
Data security posture management (DSPM)	DSPM focuses on discovering and classifying sensitive data across an environment. MCP security focuses on the access layer connecting AI to that data. The two are converging fast, since agents are becoming a primary consumer of the data DSPM was built to track.

‍

Real-World Incidents

The postmark-mcp incident in September 2025 is the clearest case of MCP-specific supply chain risk to date. A package impersonating the legitimate Postmark email service built trust over fifteen versions before its sixteenth silently BCC'd every outgoing email to an external domain, exposing invoices, password resets, and internal correspondence for anyone who'd installed it.

CVE-2025-49596, disclosed in July 2025, hit Anthropic's MCP Inspector tool: a critical, unauthenticated remote code execution flaw, CVSS 9.4, exploitable by getting a developer to visit a malicious website while the tool ran locally.

Cyera Research's own work adds a third data point, and it's the one with the most direct bearing on where this is headed. In May 2026, Cyera disclosed four chainable vulnerabilities in OpenClaw, a widely adopted open-source AI agent platform. One of the four, CVE-2026-44118, is a pure MCP problem: OpenClaw trusted a client-controlled ownership flag called senderIsOwner without checking it against the authenticated session, letting a locally executing process with a valid bearer token elevate itself to owner-level control over gateway configuration and scheduled execution. Chained with the other three findings in the same disclosure, that single unvalidated flag became a path from a supply-chain-style foothold to full runtime persistence. The most dangerous MCP vulnerabilities aren't always exotic. Sometimes it's a flag nobody checked.

See Your MCP Data Risk

MCP adoption will keep expanding, and the fastest-moving teams are the ones pairing that growth with data-layer visibility from day one, not adding it later. Access control and identity are already maturing quickly, since those controls are straightforward to build into existing frameworks. The next real advantage goes to teams that also know exactly what each tool their agents touch can reach, not just what it is allowed to do. That visibility is what lets an agent rollout scale with confidence.

See what's behind your MCP servers today, and deploy your next agent knowing exactly what it can reach.

Frequently Asked Questions

What is MCP security?

MCP security is the set of controls, architectural decisions, and operational practices that protect Model Context Protocol implementations, covering identity and authentication, network and transport, supply chain integrity, and runtime data access.

What are the biggest MCP security risks?

Supply chain compromise, tool poisoning, token passthrough, and privilege escalation through unvalidated client claims have the most real-world evidence behind them.

How is MCP security different from API security?

Traditional API security assumes a known, reviewed set of endpoints. MCP tools are discovered dynamically at runtime, so the trust boundary shifts with every new server an agent connects to.

What is MCP governance?

The organizational layer on top of technical controls: a centralized gateway that allowlists approved servers, change-management review for new registrations, and a maintained inventory of which servers exist and what they can reach.

What is tool poisoning in MCP?

Malicious instructions embedded in a tool's metadata or description, which the model reads as trusted context rather than untrusted input.

Does MCP support authentication by default?

No. The specification doesn't mandate it. Implementers are responsible for adding it, which is why independent scans keep finding a large share of public MCP servers with none at all.

How does MCP security relate to data security?

Every MCP tool call is, functionally, a request to reach some underlying data source. Most current guidance scopes access by what a tool can do, not by what data it can touch, so a narrowly scoped, well-reviewed tool can still expose regulated data if nothing behind it was ever classified.

Heading 2