What Is Model Context Protocol (MCP) Security?
Model Context Protocol (MCP) security focuses on protecting AI agents and connected systems from cyber risks. Because MCP connects LLMs directly to local files, databases, and tools, it creates vulnerabilities like untrusted third-party servers, credential exposure, and excessive permissions. MCP security measures include robust authentication, sandboxing, and strict least-privilege policies.
MCP acts as a bridge between the model, user inputs, and external environment, managing tasks such as API connections, data retrieval, autonomous agent commands, and contextual memory for the model. Given that these processes often involve sensitive operations, like retrieving private information or executing commands in third-party environments, ensuring robust security for the MCP is critical to preventing abuse, data leaks, and compromised operations.
This is part of a series of articles about AI security
MCP Security Risks and Issues
MCP security refers to the measures organizations must take to address a range of issues in connected systems and AI agents. Here are some of the main risks and security concerns associated with the MCP protocol.
Authentication and Authorization
A key risk in MCP systems is the confused deputy problem, where an MCP server executes actions with its own privileges instead of the user’s. If the server lacks proper mechanisms to act strictly on the user’s behalf, a user could indirectly gain access to resources they shouldn’t control. This violates the principle of least privilege.
MCP uses OAuth for authorization, but some elements of the current spec don’t align with enterprise-grade access control practices. Ongoing community efforts aim to revise the spec to better reflect secure, modern implementations.
Supply Chain Risks
MCP servers depend on software components and build pipelines, which makes them vulnerable to supply chain attacks. Developers must sign MCP components to allow users to verify integrity, and build systems should include static analysis (SAST) and software composition analysis (SCA) to catch vulnerabilities in both code and dependencies.
Cloud-hosted MCP servers should implement cryptographic server verification to allow clients to verify they’re connecting to the correct server, not a potentially malicious server. Developers also need to scan all dependencies for tampering or malware.
Unauthorized Command Execution
If MCP servers are not carefully implemented, they can expose command injection vulnerabilities. A common issue arises when user-supplied data is passed into system-level commands without proper sanitization. This could allow an attacker to inject and execute arbitrary commands on the server.
To mitigate arbitrary code execution, developers must sanitize inputs before execution and consider sandboxing MCP servers to limit their access and reduce the blast radius of potential exploits. This is especially important for remote MCP servers that accept remote commands without explicit user approval.
Prompt Injection
Prompt injection attacks target the decision-making of LLMs in MCP systems by embedding harmful instructions in inputs or external data. Even well-meaning users can unknowingly submit prompts that trigger unintended or malicious actions. For instance, a copied prompt could create a user account as intended, but also silently provision one for an attacker.
To reduce this risk, MCP connecions should either require explicit user confirmation or be constrained to only safe operations. Otherwise, malicious MCP server actions could be executed.
Tool Poisoning
Tool poisoning involves tampering with tool metadata—such as descriptions or parameters—so an LLM misinterprets a tool’s true function. These changes may be subtle and difficult to detect, especially during tool updates. A seemingly benign weather tool could be modified to exfiltrate sensitive data without user knowledge.
Defenses include validating all tool metadata, pinning MCP server versions, and alerting users to changes in code or behavior post-installation.
Tool Shadowing and Shadow MCP
Tool shadowing occurs when attackers register tools that impersonate legitimate ones. Without strong validation, these rogue tools can be selected by LLMs or users, leading to compromised operations. Shadow MCP risks grow when entire fake MCP servers are deployed that appear valid.
Mitigation involves maintaining a verified registry of approved tools and scanning for untrusted or unexpected additions in the tool ecosystem.
Related content: Read our guide to shadow AI
Operationalizing CTEM Through External Exposure Management
CTEM breaks when it turns into vulnerability chasing. Too many issues, weak proof, and constant escalation…
This whitepaper offers a practical starting point for operationalizing CTEM, covering what to measure, where to start, and what “good” looks like across the core steps.
Top MCP Security Best Practices to Protect AI Models
Here are some of the security practices that organizations and security teams can use for safer MCP implementations.
1. Enforce Per-Client Consent Before Third-Party Authorization
MCP proxy servers must implement a consent layer that prompts the user to approve each individual client before forwarding authorization requests to third-party services. Without this, attackers can exploit previously granted consent cookies—tied only to the proxy server’s static client ID—to bypass user consent via dynamic client registration. The consent flow must check whether the user has explicitly approved the requesting MCP client and only then allow the third-party OAuth flow to proceed.
2. Store and Validate Consent Decisions Securely
Consent approvals should be tracked per client and user. Servers must maintain a secure registry that maps user IDs to the client IDs they’ve approved. These decisions can be stored in a secure backend or cryptographically protected cookies with appropriate flags (e.g., HttpOnly, Secure, SameSite). On every authorization attempt, the MCP server must validate whether the requesting client has a stored consent record before initiating communication with the third-party authorization server.
3. Harden Consent UIs Against Abuse to Secure the MCP Ecosystem
Consent interfaces must be designed to protect against manipulation and user confusion. The UI should clearly display the name of the requesting client, the specific third-party API scopes being requested, and the exact redirect URI where tokens will be delivered. To defend against clickjacking attacks, the UI must include anti-framing headers such as X-Frame-Options: DENY or a Content-Security-Policy that sets frame-ancestors to ‘none’. CSRF protections should also be in place, using state tokens or anti-CSRF headers to verify the integrity of user approvals.
4. Validate Redirect URIs With Exact Matching to MCP Clients
MCP proxy servers must enforce strict validation of redirect URIs during the OAuth flow. The URI provided in an authorization request must match a pre-registered URI exactly—no substring matches, wildcards, or domain-only checks. This ensures that authorization codes are only sent to known, trusted destinations. Only vetted metadata endpoints should be permitted within the MCP ecosystem. Any deviation from the registered URI, even minor, should result in rejection of the request.
5. Use OAuth State Correctly and Defensively
The state parameter in OAuth is critical for preventing CSRF and authorization code injection. MCP servers must generate a secure, random state value for each request and only store it after the user approves the client consent screen. This prevents attackers from crafting requests that reuse valid state cookies. At the callback endpoint, the server must validate that the returned state parameter matches the stored value. The state should be one-time use and expire after a short period (e.g., 10 minutes). Requests with missing or mismatched state values must be rejected.
6. Prohibit Token Passthrough Entirely
MCP servers must never accept access tokens from clients and pass them directly to downstream APIs without validation. This breaks core security boundaries and prevents the server from applying critical controls like rate limiting, auditing, and claim verification. It also enables impersonation and makes it harder to detect abuse or breaches. Instead, tokens or API keys must be explicitly issued to the MCP server and used only by that server when making requests to third-party APIs.
7. Avoid Using Sessions for Authentication
Session-based authentication introduces vulnerabilities, especially in distributed systems. Attackers can hijack session IDs to impersonate users, particularly when multiple MCP servers handle requests using shared identifiers. Instead, each request should include verifiable credentials (e.g., tokens with proof-of-possession or mutual TLS). Sessions, if used, must not be relied on as a standalone authentication mechanism.
8. Secure Session Identifiers and Bind Them to Users
When session IDs are necessary (e.g., to track ongoing operations or long-polling events), they must be securely generated using strong random values (e.g., UUIDs with cryptographically secure entropy). These session IDs should also be bound to user-specific information—such as combining the session ID with the authenticated user ID—so they cannot be reused across contexts. For example, using a key format like <user_id>:<session_id> ensures that only the rightful user can act on that session.
9. Sandbox and Gate Local MCP Server Execution
Local MCP servers, running on user machines, can become high-risk targets due to their elevated access. These servers should be sandboxed to limit access to the host system and network. Developers must ensure that execution of any startup commands or actions is gated behind user approval. All actions taken by the server—especially those involving file access, shell commands, or package installs—should be transparent and require explicit user consent.
10. Minimize Scopes Using Least-Privilege Principles
When requesting access to third-party APIs, MCP clients should only request the scopes necessary for their task. This limits the potential impact if credentials or tokens are compromised. It also reduces user exposure to unnecessary data access and makes auditing easier. MCP servers should enforce this by constraining client-allowed scopes and requiring justification or additional approvals for broader access.
Tips from the Expert
Rob Gurzeev, CEO and Co-Founder of CyCognito, has led the development of offensive security solutions for both the private sector and intelligence agencies.
In my experience, here are tips that can help you better secure MCP deployments and reduce your agent-driven attack surface:
- Treat tool invocations as capability grants, not function calls: Issue per-invocation, user-bound capability tokens (tool + exact params + expiry) so the server can’t “upgrade” what an agent is allowed to do mid-flight.
- Put network egress on a per-tool leash: Give each tool an explicit outbound allowlist (domains/IPs/DNS) and block all other egress; most MCP data leaks become impossible when tools can’t phone home.
- Go “secretless” for agents wherever you can: Don’t let models ever read raw secrets; use short-lived workload identity + a broker/sidecar that injects credentials only at request time and only to approved destinations.
- Require strict schemas for tool inputs and outputs: Enforce JSON-schema (or protobuf) validation both ways; treat tool outputs as untrusted data and sanitize before they’re re-entered into the model context.
- Add provenance to every tool response: Stamp tool outputs with tool build hash, config hash, and execution environment ID (and sign it if feasible) so incident response can prove “what produced what” and spot tampering.
MCP Security with CyCognito
MCP introduces new risks and new operational complexity. It connects models and agents directly to tools, local resources, and third-party servers, and new externally reachable entry points can appear outside normal review cycles.
MCP security controls and reviews are often scoped and periodic. That approach is misaligned with MCP environments that change continuously (new MCP servers, new tool endpoints, new connectors, new routes to data and privileged actions).
CyCognito complements MCP security by adding continuous external discovery and monitoring for MCP-related entry points. If you already use AppSec tooling, vulnerability scanners, cloud security platforms, or periodic assessments, CyCognito strengthens your program by:
- Continuously discovering externally reachable MCP entry points (MCP servers, tool endpoints, agent services, and AI integration services), including unmanaged and newly deployed services
- Maintaining an up-to-date external asset inventory as services and configurations change
- Providing reachability context so teams can understand what is exposed and where it is reachable from
- Supporting prioritization by tying entry points to ownership and asset criticality, so the right team can take action faster
By shifting from periodic identification and coverage gaps to continuous visibility into externally reachable MCP entry points, CyCognito helps MCP security programs stay current as AI infrastructure changes.
