Security, Permissions, and Trust in MCP

Recall Module 5’s own real tools — a genuine action, with genuine, real consequences. Every module in this course has been building toward this one, deliberately, because MCP’s real power — letting an LLM take real actions on real systems — is precisely, structurally, the same thing that makes it genuinely dangerous when trust is misplaced.

Real incident 1: the Supabase and Cursor breach

This happened for real, in mid-2025, and it’s worth understanding precisely, because it maps almost exactly onto a genuine, structural MCP risk. A real AI agent, connected through MCP with privileged, service-role database access, processed a real customer support ticket. That ticket contained hidden, malicious instructions — a form of prompt injection — embedded in what looked like an ordinary, real support request. The agent, reasoning over that untrusted content as if it were a genuine, trusted instruction, executed a real SQL query that exfiltrated sensitive integration tokens, leaking them into a public support thread.

flowchart TD
    A[Untrusted input:\na support ticket] --> B[Agent with\nprivileged DB access]
    B --> C[Hidden instruction\ntreated as genuine]
    C --> D[Real, sensitive data\nexfiltrated]

The real, structural lesson: privileged access plus untrusted input is a genuinely dangerous combination, regardless of how good the underlying model is.

Real incident 2: the WhatsApp MCP vulnerability

Recall Module 5’s own emphasis on tool descriptions — this real, documented incident from November 2025 shows exactly why that emphasis matters at genuine security scale. A malicious MCP server exposed a tool whose real description contained hidden, embedded instructions — invisible to a casual, human reading, but genuinely readable by the LLM reasoning over it. Those hidden instructions silently redirected real message exports to an attacker-controlled phone number, enabling large-scale exfiltration of real, private conversations.

This is worth naming precisely: a tool’s description is itself untrusted input, the moment it comes from a server you don’t fully control.

Real CVE 1: MCPoison — trust bound to the wrong thing

Check Point Research disclosed a real, named vulnerability — CVE-2025-54136, in Cursor — in August 2025. The genuine, structural flaw: a user’s approval of an MCP server was bound to that server’s name, not its actual contents. A real, malicious actor could modify a shared, team configuration file after approval, silently swapping in different, real behavior, while the server’s approved name stayed identical.

The real, honest lesson: trust needs to be bound to actual content, not a label that content can change without your knowledge.

Real CVE 2: a critical vulnerability in Anthropic’s own tool

This is worth stating plainly, because it’s genuinely important, honest context: CVE-2025-49596 was a critical remote code execution vulnerability found in Anthropic’s own, official MCP Inspector tool — the very company that created MCP. Even the protocol’s own creator wasn’t immune to a real, serious security flaw in its own tooling. This is worth remembering directly: security in this ecosystem is a genuine, ongoing, shared discipline, not a solved problem you can simply trust any one vendor to have handled.

Real, structural safeguards worth implementing directly

Recall Module 13’s own allowed_tools filter — this is precisely the real, deliberate discipline this section builds on.

We’ll build a genuine, deliberate permission layer, rather than trusting a server’s full, unfiltered tool list.

ALLOWED_READ_TOOLS = {"get_order_status", "search_documentation", "get_customer"}
ALLOWED_WRITE_TOOLS = {"create_support_ticket"}  # a real, deliberately smaller, more scrutinized set

def filter_tools_by_risk(tools: list, allow_writes: bool = False) -> list:
    allowed = ALLOWED_READ_TOOLS | (ALLOWED_WRITE_TOOLS if allow_writes else set())
    return [t for t in tools if t.name in allowed]  # a real, structural safeguard, not a hopeful one

Recall your LangGraph course’s own real interrupt() mechanism — for any real, write-capable MCP tool with genuine, consequential impact, that same human-in-the-loop discipline applies directly. A real refund, a real database write, a real message sent — these deserve the same, genuine pause-for-approval pattern your LangGraph course already taught you to build.

Real, protocol-level protections worth knowing about

Recall Module 4’s own real capability negotiation — current MCP genuinely builds security into the spec itself, not just as an application-level afterthought. The real, current spec classifies MCP servers as OAuth Resource Servers, and requires Resource Indicators (RFC 8707) specifically to prevent a malicious server from misusing a token meant for a different, legitimate service. Real, production deployments — recall Module 8’s own Streamable HTTP transport — should enforce genuine OAuth 2.1 with PKCE, not a simpler, weaker authentication scheme.

What real, academic research confirms about this risk

It’s worth grounding this module’s own real incidents in more than isolated stories. A real, peer-reviewed threat-modeling study, using the genuine STRIDE and DREAD frameworks, evaluated seven major, real MCP clients for their vulnerability to tool poisoning — precisely the WhatsApp incident’s own real attack category — and found this to be a genuine, systemic, cross-vendor risk, not an isolated flaw in one specific product.

Common mistakes worth avoiding

Granting an agent privileged, service-role access without any real, deliberate scoping. Recall the real Supabase incident directly — the genuine root cause wasn’t the model’s own intelligence; it was privileged access combined with untrusted input, with no real, structural boundary between them.

Trusting a tool’s name or description without treating it as genuinely untrusted input. Recall the real WhatsApp incident — a description can hide real, malicious instructions invisible to casual, human review.

Binding approval to a server’s name instead of its actual, real content. Recall the real MCPoison CVE directly — this exact, structural mistake is what let a modified, malicious configuration slip past a user’s own, prior approval.

Assuming any one vendor, including MCP’s own creator, has fully solved security. Recall CVE-2025-49596 directly — even Anthropic’s own official tooling had a real, critical vulnerability; treat security as an ongoing, genuine discipline, never a solved checkbox.

What you should take away from this module

• Real, documented incidents — Supabase, WhatsApp, MCPoison, and even Anthropic’s own MCP Inspector — show this is a genuine, structural risk category, not a hypothetical concern.
• Privileged access combined with untrusted input is the real, recurring root cause behind the most serious, documented incidents.
• allowed_tools filtering, human-in-the-loop approval for write actions, and OAuth 2.1 with Resource Indicators are real, structural safeguards worth implementing directly, not optional extras.
• A real, peer-reviewed academic study confirms tool poisoning is a systemic, cross-vendor risk, affecting seven major real MCP clients studied.

Where this goes next

The next module covers Errors, Debugging, and Observability — the real, systematic discipline for understanding exactly what a connected MCP system is actually doing, which matters directly for catching the same, real risks this module just covered before they become genuine incidents.