The Model Context Protocol (MCP) was designed as an elegant solution to a real problem: give LLMs a standardized way to interact with external tools, file systems, and APIs through a common interface. By mid-2025, it was embedded in VS Code, Cursor, Claude Desktop, and dozens of enterprise coding environments.
It also became one of the most dangerous unauthenticated local attack surfaces in enterprise AI infrastructure.
The core issue is not a flaw in the protocol itself — it is in how practitioners deploy it. Developers grant MCP servers sweeping, persistent permissions during setup and never review them again. When an autonomous coding agent inherits those permissions, the blast radius of a compromised session extends from reading a file to exfiltrating credentials, pushing malicious commits, and calling external APIs — all without triggering a WAF alert.
// How MCP Trust Works (And Why It's a Problem)
When a user connects an MCP server — say, a filesystem tool or a GitHub integration — the local client grants it capabilities at configuration time. Those capabilities are typically:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"],
"roots": ["/Users/dev"] // ← entire home directory exposed
},
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "ghp_xxxxxxxxxxxxxxxxxxxx" }
// ← PAT with repo:write stored in plaintext
},
"shell": {
"command": "npx",
"args": ["@modelcontextprotocol/server-shell"],
"allowedCommands": ["*"] // ← unrestricted bash execution
}
}
}
This is not a theoretical worst-case. This is a real configuration pattern copied from official quickstart guides. When an autonomous coding agent — given a task like "refactor this module and push a PR" — runs inside this environment, it inherits all three permissions simultaneously.
// The Attack Chain: Tool Poisoning via MCP
The most sophisticated MCP attack vector is tool description poisoning. A malicious or compromised MCP server can inject hidden instructions directly into the tool manifest that the LLM reads to understand what tools are available.
Tool poisoning attacks require zero interaction from the developer. The compromised tool can be a legitimate npm package with a malicious update, a third-party MCP server added to a shared dev environment, or a local server process replaced by a supply chain attack.
// Rug-Pull Attacks: When Tools Change Mid-Session
A second attack pattern exploits the fact that most MCP clients cache tool descriptions at session start but don't re-verify them mid-session. An attacker who can modify an MCP server's response — through a compromised process or MITM on localhost — can perform a "rug-pull": the tool behaves normally for the first several calls, then escalates privileges on a later call when the developer's attention has shifted.
This is particularly dangerous in long-running agent loops where a developer sets a task and monitors results asynchronously.
// The 4-Layer Defense Architecture
MCP Server Allowlisting & Cryptographic Signing
Maintain an enterprise-approved registry of MCP servers. Require cryptographic signatures on tool manifests — any unsigned or unregistered server should be blocked at the client layer, not just warned about. Treat MCP servers with the same supply chain rigor as npm dependencies in production CI/CD.
Scoped Permission Sandboxing
Replace wildcard roots and unrestricted shell access with per-task permission scopes. A coding agent working on a frontend component has no legitimate need for filesystem access beyond that module's directory or network access beyond the local dev server port. Enforce this at the MCP host layer.
Tool Description Sanitization Layer
Before any tool manifest reaches the LLM context, run it through a lightweight sanitizer that strips imperative verbs, injection markers, and out-of-band instruction patterns. Do not rely on the model to self-police what it reads — that's the architecture mistake that created this attack class.
Immutable Audit Telemetry
Log every tool call with full argument payloads and raw responses to an append-only telemetry store that the agent process cannot access. Anomaly detection on tool call frequency, argument patterns, and outbound network destinations will surface rug-pull attacks that pass all other layers.
Live: AI Agent Red Teaming Labs
Watch senior AppSec researchers exploit live MCP environments — then reverse-engineer the exact controls that shut each attack down. Hands-on lab seats are limited.
RESERVE YOUR LAB SEAT →// Hardening Checklist: MCP Deployments
- Audit all active MCP servers and revoke filesystem roots broader than project directories
- Replace plaintext PATs in mcp config with short-lived, scoped tokens rotated per session
- Block shell MCP servers in production-adjacent environments entirely — no exceptions
- Implement manifest signature verification before any tool is exposed to the LLM context
- Set outbound network allowlists for MCP server processes at the OS firewall layer
- Enable append-only tool call telemetry with argument-level logging for incident forensics
- Schedule quarterly MCP permission reviews tied to your existing access review cycle
// The Bigger Picture
MCP is not going away — it's becoming the standard interface layer for agentic AI in enterprise software development. The question is not whether your engineering teams will use it, but whether your security posture will keep pace with the permissions those tools accumulate over time.
The attack surface is expanding faster than the tooling to audit it. Treating MCP servers as trusted local processes — the way developers intuitively approach local tooling — is the mental model that attackers are counting on.
MCP tool poisoning is the delivery mechanism. The execution layer — where models call bash, SQL, and email APIs without authorization checks — is covered in Autonomous Agent Tool-Calling Hijacks.