Remember when REST APIs first exploded across the enterprise? Teams spun up endpoints everywhere, shared API keys in Slack channels, and bolted on authentication as an afterthought. It took a decade of breaches, an entire OWASP API Security Top 10, and a lot of painful lessons before API security became a real discipline.

I’m watching the exact same pattern play out with MCP servers right now — except the stakes are higher.

What MCP Actually Is (and Why AppSec Should Care)

Model Context Protocol is Anthropic’s open standard for connecting AI agents to external tools, databases, and APIs. Think of it as a universal adapter that lets an AI assistant query your database, read files, send emails, or call any tool — all through a single protocol.

MCP servers are the middleware that makes this happen. They sit between the AI model and your infrastructure, holding OAuth tokens, executing system commands, and brokering every tool call the agent makes.

Here’s the problem: the MCP specification explicitly states that it “does not enforce security at the protocol level.” All of it — authentication, authorization, sandboxing — is left to whoever deploys the server.

Sound familiar? It should. That’s exactly how early APIs worked. And we know how that went.

The Attack Surface Nobody Is Testing

MCP introduces threat categories that your current AppSec testing probably doesn’t cover. Three stand out.

Tool Poisoning — This is the one that keeps me up at night. An attacker embeds malicious instructions in a tool’s metadata — the description field, the input schema, even the parameter names. The AI agent doesn’t need to use the poisoned tool to be affected. It just needs to read the tool list. The moment the agent evaluates available tools, those hidden instructions enter its context and can alter its behavior across the entire session.

Invariant Labs demonstrated this with a proof-of-concept where a poisoned tool caused Cursor to silently read and exfiltrate SSH keys — without the developer ever invoking that tool directly.

Rug Pull Attacks — A tool passes your initial security review, gets approved, and works perfectly for weeks. Then the server owner silently updates the tool definition to include malicious behavior. Most MCP clients don’t alert users when tool descriptions change after approval. The first malicious MCP package appeared in September 2025 and operated undetected for two weeks, exfiltrating email data the entire time.

Confused Deputy — MCP servers execute actions with their own privileges, not the requesting user’s. An attacker who can influence the agent’s reasoning — through prompt injection or context manipulation — can leverage those server-level permissions to access resources the attacker was never authorized to touch. It’s privilege escalation through the AI layer.

Why This Hits Harder Than APIs

With APIs, at least the caller was deterministic. A client sends a request, you validate it, you respond. With MCP, the “caller” is an AI model making autonomous decisions about which tools to invoke, with what parameters, in what sequence. The inputs to your MCP server aren’t coming from a developer’s code — they’re coming from an LLM that may have been manipulated three steps upstream.

Cisco’s State of AI Security 2026 report found that 83% of organizations plan to deploy agentic AI, but only 29% report being ready to secure it. That gap is where MCP vulnerabilities live.

What You Can Do on Monday

If you’re running MCP servers in production — or your developers are connecting to them from their IDE — here are the controls that matter right now:

Authenticate everything. If your MCP server is accessible without credentials, stop reading and fix that first. CVE-2025–49596 showed what happens when MCP Inspector runs unauthenticated — arbitrary command execution.

Scope permissions aggressively. An MCP server that requests files:* and db:* is the AI equivalent of granting admin. Request the narrowest OAuth scopes possible and review them regularly.

Pin tool definitions. Hash the tool descriptions and schemas at approval time. Alert if anything changes. This is your rug pull detection.

Sandbox server execution. Run MCP servers in containers with restricted file system access and no outbound network unless explicitly required. Treat them like you’d treat a third-party service running inside your perimeter.

Log every tool invocation. You need full traceability — which agent called which tool, with what parameters, and what came back. If you can’t reconstruct an agent’s decision chain, you can’t investigate an incident.

Scan for tool poisoning. The mcp-scan tool exists for exactly this purpose. Add it to your CI pipeline. OWASP just released an MCP Security Cheat Sheet and a Secure MCP Server Development guide — both are worth reading this weekend.

Final Thoughts

We already learned these lessons with APIs. Authentication, authorization, least privilege, supply chain verification, input validation — none of this is new. What’s new is the context: an autonomous AI agent making tool calls with your credentials, against a protocol that leaves security entirely to the implementer.

The organizations that figure out MCP security now will be the ones who avoided a breach later. The ones who treat MCP servers like they treated early APIs — convenient, fast, and someone else’s problem — are going to learn the hard way.

OWASP has given us the playbook. The question is whether we’ll use it before or after the first major MCP breach makes headlines.