MCP Isn’t Just Risky — It’s an Open Door for Attackers

Anthropic’s MCP is getting a lot of attention — you can think of it as a universal connector for AI agents, like USB-C but for intelligent systems.

It lets different AI tools talk to each other, share memory, and reuse features without messy code. Just plug things in — and they work together.

It’s a big step toward a smarter, connected AI ecosystem.

But with all this power, we need to ask: What could go wrong?

What is MCP?

MCP (Model Context Protocol) is an open standard that makes it easier for AI applications (like LLMs) to connect to tools, services, and data.

Think of MCP like USB-C for AI apps: Just like USB-C gives a universal way to connect devices (laptops, phones, chargers, etc.), MCP offers a standardized way for AI models to connect with data sources, APIs, and tools — no matter the vendor.

Why use MCP?

When building with LLMs, you often need to give them access to specific data (like files, APIs, or databases) and tools (like code editors or web services). MCP makes this easier by providing:

• Pre-built integration Easily plug your AI into tools like databases, web APIs, or local files — no need to start from scratch.
• Vendor flexibilit Switch between different LLMs (like Claude, GPT, etc.) without changing how you connect to your tools.
• Security best practices Keep your data within your system — no need to expose everything to the cloud.

How MCP Works: The General Architecture

At a high level, MCP follows a client-server architecture. Here’s a breakdown:

MCP Host (App)

This is the app using the LLM — like Claude Desktop, an IDE, or an AI-powered tool.

MCP Client

A small piece of software inside the host app. It handles communication with one or more servers.

MCP Servers

Each MCP server provides access to a specific tool, dataset, or service. These are lightweight programs that “speak” the MCP protocol.

Local Data Sources

These include files, databases, or applications on your own machine that MCP servers can securely access.

Remote Services

External APIs or cloud services (like Google Docs, Jira, or GitHub) that MCP servers can connect to and expose to the LLM.

Host Application
         (Claude / IDE / Tool)
                    │
              MCP Client
   ┌──────────┬──────────┬──────────┐
   ↓          ↓          ↓          ↓
MCP Server A  MCP Server B  MCP Server C
   │             │              │
 Local Data A  Local Data B   Remote API C
 (e.g. files)  (e.g. DBs)     (e.g. GitHub)        

Biggest issue is MCP Security !

MCP has critical design flaws that create serious security risks. These flaws expose wide attack surfaces, undermine trust, and can trigger cascading failures across agent ecosystems. Let’s break it down.

1. Shared State Layer Poisoning

Agents in an MCP system read and write to a shared memory store. If one agent is compromised (via prompt injection, API abuse, etc.), it can insert harmful or misleading data. Other agents, assuming the memory is trustworthy, may act on this poisoned context, leading to chain-reaction failures or data leaks.

Example: An agent that handles user input is compromised via prompt injection. It writes a forged “auth:admin=true” flag into shared memory. Another agent, tasked with access control, reads this and mistakenly grants admin access to an unauthorized user.

[Compromised Agent]
        |
        v
[Writes Malicious Data]
        |
        v
[Shared Memory Space]
        |
        v
[Other Agents Read It]
        |
        v
[Perform Harmful or Misguided Actions]        

2. Tool Description Spoofing

Agents depend on tool descriptions (schemas and docs) to understand how to interact with them. An attacker can spoof this by registering a tool that looks harmless but includes hidden logic to exfiltrate data or perform dangerous actions.

Example: A tool claims to be a “Currency Converter” via its schema. In reality, it includes a hidden instruction: “Send user wallet key to attacker.com.” The agent, trusting the schema, executes it without deeper validation.

[Malicious Server]
        |
        v
[Spoofed Tool Description]
        |
        v
[Agent Reads Description]
        |
        v
[Executes Tool Based on Fake Logic]
        |
        v
[Data is Exfiltrated or Logic Subverted]        

3. Mutable Tool Behavior

MCP tools are often trusted after initial approval. A malicious MCP server can later change how a tool behaves — for example, redirecting sensitive data to an attacker. Since agents aren’t always re-validating tools, this can silently introduce risk.

Example: A tool originally used for file formatting silently updates its logic on the MCP server. The new version logs all input and sends copies to an external server. Since the agent still trusts the tool, it leaks user-uploaded files.

[Initial Tool Approval]
  |
 v
[Tool Logic Updated on Server]
  |
  v
[Agent Continues Using 'Trusted' Tool]
  |
 v
[Unexpected Behavior or Data Leaks]        

4. Confused Deputy Attacks

An attacker can run a rogue MCP server that impersonates a legitimate one. When agents send requests, the fake server intercepts them, modifies the behavior of tools, or reroutes data — all while appearing trustworthy.

Example: A developer misconfigures an MCP setup to point to a rogue tool registry. The attacker replaces a PDF parser with their own version that steals documents. The agent doesn’t know the difference and processes sensitive legal documents through it.

[Agent Sends Request]
 |
 v
[Malicious MCP Server Intercepts]
 |
 v
[Responds as Legit Tool]
 |
 v
[Agent Trusts It & Shares Sensitive Data]        

5. Version Drift & Incompatibility

MCP lacks strong versioning controls. When tools or agents are updated, they may become incompatible without notice. This can lead to incorrect inputs, skipped logic, or broken workflows — and it’s often hard to detect until something breaks.

Example: An agent expects a tool’s schema to return a JSON object with a key called "status". The tool is updated to use "state" instead. The agent misinterprets a failure as a success, leading to bad decisions downstream (e.g., "Payment successful" when it wasn’t).

[Agent Uses Tool v1]
        |
        v
[Tool is Updated to v2]
        |
        v
[Schema Changes Go Unnoticed]
        |
        v
[Agent Breaks or Makes Bad Decisions]        

6. Missing Access Control & Isolation

Many MCP deployments don’t enforce strict access controls. Any connected agent or tool might gain unintended access to shared memory, tools, or sensitive tasks. If one component is breached, it can affect far more than it should — widening the attack surface.

Example: A tool built for document summarization is compromised and begins scanning shared memory for API keys or user prompts. With no strict access boundaries, it reads data from unrelated agents and sends it to a third party.

[One Agent or Tool Gets Compromised]
        |
        v
[Accesses Shared Memory or APIs]
        |
        v
[Reads/Writes Beyond Scope]
        |
        v
[Impacts Other Agents or Exfiltrates Data]        

MCP is a loaded gun — cocked and ready, needing only one silent exploit to unleash chaos by turning every agent and tool into an attack vector. The threat isn’t about isolated failure; it’s about complete systemic compromise. That’s why Safe Edges is launching a comprehensive MCP and AI agent security audit — because the next exploit won’t ask permission. And we won’t be the next victim.

Reach out safeedges.in