Helmwart

← All primers

Primer

MCP

Model Context Protocol (MCP) is a protocol that standardizes how an agent (the MCP client) connects to external tools and data sources (the MCP servers). The agent discovers a server's tool catalog and exposed resources, then invokes those tools through a uniform interface. The protocol is open, with implementations available in several languages, and OWASP treats it as a primary protocol surface alongside A2A.

The shape of the trust relationship

MCP creates a three-party trust relationship: the user, the agent, and the MCP server. The user has authorized the agent. The agent has connected to the MCP server. The MCP server's authority over the agent's behaviour is larger than first impression suggests, because:

Three parties, three trust edges

Each edge of the triangle is a distinct trust relationship. The threats that sit on each edge are different. The MCP-named threats (T2 · T11 · T16) all sit on the server-to-agent edge where the response payloads carry the agent's reasoning input.

USER consents · authorises AGENT MCP client MCP SERVER tools · resources · prompts authorises T15 Human Manipulation: Attacker turns the agent into a fluent, personalised social-engineering vector trusted by the user. T15 connects to T17 Supply Chain Compromise: Compromised upstream models, prompts, plugins, or framework updates land in the agent. T17 exposes tools · resources · prompts T2 Tool Misuse: Agent uses authorized tools in unintended ways via deceptive prompts or chained calls. T2 T11 Unexpected RCE and Code Attacks: Code-execution paths in agents accept attacker-influenced input and run as arbitrary code. T11 T16 Insecure Inter-Agent Protocol Abuse: MCP/A2A protocols abused via consent-flow manipulation, MCP response injection, or weaponised tool descriptions. T16 Server-provided descriptions and results can become agent context.

In practice, MCP prompts, tool descriptions, and results can enter the model's reasoning context. That makes server-provided content an input trust boundary: it needs validation, provenance, and scope controls comparable to other untrusted or externally administered inputs.

The threats that show up here

OWASP T16 Insecure Inter-Agent Protocol Abuse targets this directly: consent flow manipulation, context hijacking via MCP response injection, and tool misuse via overly broad or misleading tool descriptions. T2 Tool Misuse and T11 Unexpected RCE and Code Attacks often manifest through MCP. The protocol is the delivery mechanism; the OWASP threat is what gets delivered. T17 Supply Chain applies because each MCP server is a supply-chain dependency.

The MAS Threat Catalogue identifies additional threats specific to the MCP protocol surface. On the agent framework layer, an autonomous agent can enter a loop and trigger T39 Unintended Resource Consumption via MCP, repeatedly invoking tools far beyond what the task requires. An attacker who steals client credentials can commit T40 MCP Client Impersonation, gaining access to server resources as if they were the legitimate agent. Ambiguous or inconsistently implemented schemas produce T41 Schema Mismatch errors where client and server interpret data differently, leading to silent data corruption. When multiple clients share one server, a bug in isolation lets one client interfere with another's operations via T42 Cross-Client Interference.

On the deployment layer, an MCP server exposed without network controls becomes reachable from unauthorised networks (T43 Network Exposure of MCP Server). Inadequate logging on either side blocks incident detection (T44 Insufficient Logging in MCP). Excessive operating-system permissions granted to the server itself mean that a compromise gives the attacker wide access (T45 Insufficient Isolation of MCP Server Permissions). In open ecosystems, an attacker can publish a malicious server that masquerades as a legitimate one, returning manipulated data or stealing client credentials: T47 Rogue MCP Server in Ecosystem.

Implications for deployment

The honest deployment posture is: treat each MCP server you connect to as a third-party dependency with read access to your prompts and write access to your agent's behaviour. Apply the controls you would apply to any privileged third-party integration: vetting, version pinning, signed artifacts, sandboxed execution, and audit logging. Then add the agent-specific layer: validation of tool descriptions before they enter the catalog, isolation between MCP responses and the trust context they return into, and tight scoping of what tools can actually do.

Where this fits in Helmwart

Read this primer if you are connecting agents to MCP servers operated by anyone other than yourself, and probably even if you operate them yourself. The trust model is easy to misjudge.

Where to go next

Sources: OWASP Agentic AI — Threats and Mitigations v1.1 (Dec 2025), §AI Agents (MCP described under Action and Tool Use) and §T16 Insecure Inter-Agent Protocol Abuse; OWASP MAS Threat Modelling Guide v1.0 (Apr 2025), §T39–T45, §T47.