AI agents are no longer just chatbots. They’re executing multistep workflows across tools and data sources, and the Model Context Protocol (MCP) standardizes these interactions. MCP gives agents a common language for coordinating actions across diverse resources. But that standardization also creates a new attack surface that demands deliberate security controls.

The official MCP specification identifies six critical threat vectors that every implementation must address. If you’re deploying MCP, you need to understand where the real risks are and implement controls that prevent compromise before it occurs.

The Six Critical MCP Threat Vectors

The MCP Security Best Practices specification defines six primary threats. They represent attack patterns that exploit specific weaknesses in how agents, servers and resources interact.

The Confused Deputy Problem

The confused deputy attack is the most significant MCP-specific security challenge. A malicious actor exploits trust relationships by tricking a legitimate client into performing unauthorized actions on their behalf.

A user authorizes Application A to access enterprise data through an MCP server. Without proper per-client consent validation, a malicious Application B could use the same user credentials to access that data, effectively impersonating Application A. The MCP server becomes the “confused deputy” because it has legitimate authorization but applies it incorrectly.

The server assumes that user authentication implies authorization for all clients. That assumption is the vulnerability.

Token Passthrough Vulnerabilities

Token passthrough occurs when an MCP server forwards authentication tokens through intermediaries rather than validating them directly. This practice creates multiple opportunities for token theft.

If an attacker compromises any intermediary in the chain, whether that’s a logging system, proxy server or middleware component, they can capture valid authentication tokens and use them to impersonate legitimate users or services. The MCP specification explicitly forbids token passthrough. Every MCP server must validate tokens directly against the authorization server, and tokens must never be forwarded or relayed through intermediaries.

Server-Side Request Forgery (SSRF)

SSRF attacks target MCP implementations that use OAuth metadata discovery. A malicious MCP server can populate discovery fields such as resource_metadata, authorization_servers or token_endpoint with internal network addresses, tricking the client into making requests to infrastructure it should never reach.

An attacker can exfiltrate cloud credentials from instance metadata endpoints such as the AWS, GCP and Azure metadata services, access internal Redis instances or admin panels, or trigger mutations on internal services through DNS rebinding. Mitigations include validating all URLs in OAuth metadata responses against an allowlist, blocking requests to private IP ranges and link-local addresses and never forwarding raw metadata URLs to downstream components without sanitization.

Session Hijacking (and Why MCP Restricts It)

Traditional web applications use session cookies to maintain user state, but these cookies become high-value targets for attackers. If an attacker steals a session cookie through cross-site scripting or man-in-the-middle attacks, they can impersonate the legitimate user. In MCP’s multiserver environments, the threat is more specific: an attacker who obtains a valid session ID can send a malicious event to a different MCP server, which enqueues it into a shared stream that the original client then consumes, delivering the malicious payload back without any further interaction from the attacker.

The MCP specification addresses this threat with an absolute prohibition: MCP servers must not use session-based authentication. This removes the primary session hijacking attack vector by taking the session-management layer that attackers would target out of the authentication model. All authentication must be performed using tokens that are validated on each request, never through server-maintained session state.

Local MCP Server Compromise

When MCP servers run locally on user systems, they gain access to local resources, including the file system, system commands and local network services. A compromised or malicious MCP server could exploit this access to read sensitive files, execute arbitrary commands or pivot to other systems on the local network.

Local MCP servers require explicit user consent for file system operations and command execution, additional validation to prevent directory traversal attacks and protection against command injection even in local contexts. Engineers must not assume that local operations are inherently safe.

Scope Minimization Failures

Scope minimization failures occur when MCP implementations grant excessive privileges beyond what is necessary for legitimate operations. An MCP server that requests broad OAuth scopes such as “read all user data” when it only needs access to specific resources exposes users to unnecessary risk.

If that server is compromised, the attacker inherits all the excessive privileges rather than only the minimum necessary access. Each MCP implementation should carefully analyze required permissions and request only the minimum scopes needed.

Five Mandatory Authorization Patterns

The MCP specification defines five authorization patterns that must be implemented without exception. These patterns work together to create layered authorization security.

1. Per-client consent: Explicit authorization is required for each client application. A user’s general authentication does not imply authorization for any specific client to act on their behalf. The MCP server must maintain a consent registry mapping user identifiers to approved client identifiers with granted scopes, and all consent validation must occur server-side.
2. Token audience validation: Every token validation operation must verify that the token’s audience claim matches the MCP server’s identifier. Even if a token is properly signed and unexpired, it must be rejected if the audience claim specifies a different service as the intended recipient.
3. Rejection of token passthrough: The MCP server must never forward tokens through itself to backend services. If the MCP server needs to access downstream services on behalf of the user, it must obtain its own tokens through appropriate delegation mechanisms rather than passing through the user’s original token.
4. Exact redirect URI matching: OAuth redirect URI validation must use exact string matching with no wildcards, partial matches or pattern matching. This prevents open redirect attacks where attackers register similar URLs to redirect users to malicious sites.
5. OAuth state parameter validation: The state parameter must be validated on every authorization callback to prevent cross-site request forgery attacks. The state value must be cryptographically random, stored securely by the client and verified to match when processing the callback.

Transport Security and Authentication Requirements

The MCP specification establishes strict requirements for transport security and authentication.

HTTPS is mandatory for all communication. HTTP connections expose all data in transit to network eavesdropping, including authentication credentials, authorization tokens and sensitive data. MCP servers must reject HTTP connections entirely at the network level, enforce TLS 1.2 as the minimum version (with TLS 1.3 preferred), use strong cipher suites and implement HTTP Strict Transport Security headers.

For local deployments, the specification recommends stdio transport, which communicates through standard input/output streams. This mode eliminates network exposure entirely, reducing the attack surface.

OAuth 2.1 provides the recommended authentication mechanism for MCP implementations. It consolidates security best practices from OAuth 2.0 and incorporates guidance from RFC 9700. Engineers should implement Authorization Code Flow with PKCE for client applications and Client Credentials Flow for server-to-server authentication.

Input validation is also mandatory. All input parameters must be validated according to schema definitions. File paths must be sanitized to prevent directory traversal attacks, and system commands must be sanitized to prevent command injection. Validation errors should be returned as Tool Execution Errors per the protocol specification.

Applying Zero-Trust Principles to MCP

Traditional perimeter security doesn’t work when your workflows span multiple clouds and environments. Zero trust for MCP means never trusting an agent, tool or request by default. Every interaction requires continuous verification.

Treat every agent, server and tool as a first-class identity that needs verification. Each nonhuman identity must present cryptographic proof of its legitimacy before gaining access. MCP servers should validate agent identities at every interaction, not just during the initial connection. Identities should be secretless or ephemeral, continuously updated and dynamically requested.

Enforce least privilege through granular policies that specify exactly which tools each agent can access under specific conditions. An agent authorized for database reads shouldn’t be able to escalate to writes, even if the tool supports both operations. Access policies ensure that workloads receive only the permissions they need for their specific function.

Capture all MCP interactions for detection and forensic analysis. Your security team needs complete audit trails showing which agent accessed which tool, what parameters were provided and what actions resulted. When an incident occurs, these logs accelerate investigation.

Securing MCP With IAM for Agentic AI

The six threat vectors above demand controls at multiple layers. Aembit’s Workload IAM platform for agentic AI addresses the most critical ones directly.

The confused deputy problem exists because the MCP server grants access based on user authentication without verifying which client application is making the request. Per-client consent enforcement closes that gap. When an IAM platform maintains a registry of approved clients per user and validates that registry on every request, the server can reject unauthorized applications even if they present valid user credentials. Verified workload identity adds a second layer: each agent proves who it is through cryptographic attestation, and no ambiguity remains about which application is acting.

Token passthrough creates theft opportunities at every intermediary in the chain. Issuing scoped, just-in-time credentials directly to each workload removes the need to forward tokens through intermediaries. Secretless access eliminates the long-lived API keys and stored tokens that persist as attack surfaces between interactions.

Scope minimization failures are a policy enforcement problem. Granular policy-based access control restricts each agent to only the permissions its specific task requires. An agent authorized for database reads cannot escalate to writes, even if the underlying tool supports both operations. Policies evaluate at the moment of access, keeping permissions aligned with what each interaction needs.

SSRF and local server compromise require additional controls at the network and endpoint layers, including URL allowlisting, input sanitization and filesystem access restrictions. MCP’s prohibition on session-based authentication removes the primary session hijacking attack vector by design. Consistent identity enforcement across AWS, Azure, GCP and on-premises environments means the controls above apply uniformly regardless of where workloads run.

Aembit IAM for Agentic AI is generally available with a free tier.

Implementing MCP Security Controls

MCP accelerates agentic AI adoption by standardizing how agents coordinate across tools and data. But this power comes with expanded risk. Without understanding the six critical threat vectors, the five mandatory authorization patterns and the absolute requirements around transport security and authentication, you’re exposing yourself to confused deputy attacks, token theft, privilege abuse and operational disruptions.

The organizations that deploy MCP successfully will treat it as production infrastructure and secure it accordingly. That means implementing per-client consent, enforcing token audience validation, rejecting token passthrough, using exact redirect URI matching and validating OAuth state parameters on every callback.

MCP can deliver on its promise of standardized agent coordination, but only if you apply the same security discipline you’d bring to any other protocol handling sensitive data and privileged operations.

Related Reading

• MCP Security: Mandatory Auth/Auth Patterns for Agentic Systems
• MCP, OAuth 2.1, PKCE, and the Future of AI Authorization
• Agent Authentication
• Model Context Protocol (MCP)