MCP and its 25 Security Flaws

Autonomous AI agents write code, query APIs, send emails and even execute shell commands, often without direct human oversight. To make this interoperability possible, MCP (Model Context Protocol) has become central to the agentic ecosystem.

MCP is meant to be the universal connector that lets AI agents safely access tools, data sources and contextual services. But it also opens a new attack surface which looks eerily similar to the early days of API and container security. This post explains what MCP is, how it’s structured, how the client-config.json defines its trust boundaries, and the Top 25 vulnerabilities that every AI security professional should understand.

What Is the Model Context Protocol?

MCP is a communication standard that allows AI agents to talk to external tools and environments in a consistent, structured way. Think of MCP as the “operating system layer” between a model and the real world. It defines how agents:

✔ Discover what tools exist (via server endpoints like /tools)
✔ Describe tools through structured metadata and schemas
✔ Invoke those tools safely with validated parameters
✔ Retrieve contextual data (from databases, files, or embeddings)
✔ Chain these operations into complex, autonomous workflows

In practice, the MCP sits beneath frameworks like LangChain, OpenDevin or Anthropic’s agentic integrations providing a universal grammar for tool use.

MCP Architecture

MCP Client‍

The runtime that uses the protocol, typically the agent process. It discovers and calls servers. Compare it with a browser or a SDK.

MCP Server‍

The service that exposes tools, data or context via standardized endpoints. Perfect analogy is a web API host.

Tools‍

Individual functions the server exposes (e.g., file_search.query, send_email, query_db). Each has metadata, parameter schema and auth rules. Compare it with APIs or microservices.

Context Providers‍

Data sources that add background context (documents, embeddings or memory). Similar to feeds or caches.

Registry/Discovery‍

Mechanism for listing available tools via /tools or /describe.

A Typical MCP Flow‍

1. Handshake: Agent connects to one or more MCP servers.
2. Discovery: The client queries /tools and receives a list of capabilities.
3. Selection: The LLM chooses a tool (based on reasoning).
4. Invocation: The agent sends an invoke_tool request with structured inputs.
5. Execution: The server runs the tool logic or API call.
6. Return: Results flow back into the model’s reasoning loop.
7. Chaining: Tools may invoke other MCP servers or context providers thereby expanding reach and complexity.

Where Tools Are Defined

MCP tools are defined on the server side using machine-readable metadata. Here’s a minimal example:

{
  "name": "file_search.query",
  "description": "Search project files by keyword.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {"type": "string"},
      "limit": {"type": "integer", "default": 5}
    },
    "required": ["query"]
  }
}

‍

This metadata is what the agent “reads” to decide which tool to use.  If this description is poisoned or altered, the agent can be tricked into calling a malicious or unsafe function. This is exactly the foundation for many MCP-level attacks such as tool metadata poisoning or look-alike impersonation.

The client-config.json

Every MCP client or agent runtime uses a client-config.json file to define which servers it can connect to and how. It’s essentially the root of trust for an agent’s operational world. A sample configuration might look like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "mcp-server-fs",
      "args": ["--root", "/data"],
      "env": { "READ_ONLY": "true" }
    },
    "weather": {
      "command": "mcp-server-weather",
      "args": ["--region", "US"],
      "env": { "API_KEY": "env:WEATHER_API_KEY" }
    }
  }
}

‍

When the client starts, it reads this config to spawn or connect to the declared MCP servers, then queries each for their /tools. From that point onward, those tools become available for the agent to use and no human in the loop is required.

If an attacker gains write access to client-config.json, they can:

✔ Replace legitimate servers with malicious binaries or URLs
✔ Inject rogue tools or hidden parameters
✔ Expose secrets by modifying environment variables
✔ Chain in remote servers that siphon data

This is why config integrity equals trust integrity in agentic systems.

The Top 25 MCP Vulnerabilities in 2025

Below is a synthesized list of the 25 most critical vulnerabilities currently affecting real deployments.

Prompt Injection / Hidden Instructions

Malicious text in tool metadata or context manipulates agent reasoning.

Tool Metadata Poisoning

Altered tool descriptions trick the model into unsafe calls.

Look-Alike Tools / Impersonation

Fake servers mimic legitimate ones.

Chaining / Composability Abuse

Malicious servers invoke others to bypass controls.

Confused Deputy

A privileged server performs unauthorized actions for a lower-privileged client.

Command Injection

Unsanitized inputs lead to arbitrary command execution on servers.

Tool Misuse

Legitimate tools exploited for lateral movement or data access.

Credential or Token Theft

Compromised tokens allow impersonation of agents or servers.

Malicious Updates‍

Benign tools become weaponized after updates.

Excessive Privilege‍

Servers or tools run with broader permissions than required.

Out-of-Scope Parameter Requests‍

Tools request or expose data beyond intended context.

Data Exfiltration via Legitimate Channels‍

Sensitive data leaked through outputs, logs, or tool responses without guardrails.

Shadow / Unlisted Tools‍

Hidden back-door tools not catalogued in /tools.

Objective Drift / Policy Bypass‍

Agents deviate from approved intent.

Identity Fragmentation‍

Weak identity binding across MCP components.

Missing Runtime Monitoring‍

Lack of telemetry or audit on agent–tool interactions.

Insecure Transport‍

Unencrypted JSON-RPC or unsigned requests.

Implicit Trust of External Servers‍

Clients skip signature or source checks.

Dependency & Version Drift‍

Unpinned or outdated components introduce exploits.

Tool Description Overshadowing‍

Malicious tools outrank legitimate ones by metadata manipulation.

Behavior Change in Updates‍

Tools silently change logic post-release.

Agent-to-Agent Trust Leakage‍

Cascading trust across agents without validation.

Preference Manipulation Attacks‍

Ranking logic manipulated to favor malicious tools.

Indirect Invocation Abuse‍

Hidden delegation or sampling to execute unauthorized workflows.

Mitigations

Principle of Least Privilege - Tools and servers should only have the minimum capabilities they truly need.
‍Signed Manifests & Configs - Treat tool definitions and configs as signed artifacts.
Runtime Monitoring - Log and analyze all invoke_tool events and flag unusual patterns.
Secure Supply Chain - Pin versions and verify updates.
Isolate Environments - Sandbox MCP servers per trust level.
Allowlisted Registries - Agents should only discover tools from vetted sources.
Human-in-the-Loop for Critical Actions - Require confirmation for sensitive operations like code execution or financial transactions.

Wrap

The Model Context Protocol is more than a connector. It’s the foundation on which the next generation of AI agents will operate. As these systems gain autonomy, every MCP tool, server and configuration file becomes a potential decision-maker inside your digital environment. Security teams should start thinking of MCP assets the same way they think about APIs or containers: review them, sign them, monitor them and isolate them. A single poisoned tool manifest or tampered client-config.json can silently redirect an agent’s logic, leak sensitive data or execute unintended commands without human awareness.