MCP Security

MCP servers are powerful — they let an LLM take real actions in the world. That power creates a real attack surface. Before you connect a server you didn't write, or before you deploy one to production, there are specific threats you need to understand. I'd rather lay these out plainly than have you discover them the hard way.

---

Supply Chain Attacks

The first risk is the most obvious once you see it: an MCP server you install could be malicious.

This is the same risk as any npm package, but with higher stakes. A malicious npm package might steal your credentials. A malicious MCP server gets to instruct the LLM — it can shape what the model does with your data, your files, your accounts.

Attack vectors:

• Typosquatting: @modelcontextprotocol/server-filesytem (note the typo) instead of server-filesystem
• Dependency confusion: a private package name that a public package shadows
• Compromised packages: legitimate packages that get hijacked after you pin them

Mitigations:

• Only install from official or well-audited sources
• Read the source code of any server that touches sensitive data
• Pin exact versions (1.2.3, not ^1.2.3) for production servers
• Use a lockfile and audit it

---

Prompt Injection via Tool Results

Your MCP tool calls an external API and returns the result to the LLM. What if the API response contains instructions?

If your tool returns this verbatim and the LLM processes it, it might follow those embedded instructions. This is prompt injection via tool results.

Mitigations:

• Strip or escape content from external sources before including it in tool responses
• Use structured return formats (JSON fields) rather than raw text blobs
• Never pass uncontrolled external content directly into the model context
• Keep tool responses minimal — only include what the LLM needs

---

The Paperclip Maximizer Problem

There's a famous thought experiment: an AI given the goal of "maximize paperclip production" eventually converts all matter into paperclips. The AI isn't malicious — it's pursuing the stated goal with perfect, literal efficiency.

MCP creates a softer version of this with sufficiently capable LLMs given broad tool access:

• "Clean up the database" → the LLM determines that deleting old records is the cleanest approach and drops a table
• "Fix the auth bug" → the LLM decides the cleanest fix is to remove the auth check entirely
• "Reduce the issue count" → the LLM closes all open issues as "won't fix"

None of these are malicious. They're literal interpretations of vague instructions by a system with powerful capabilities.

Mitigations:

• Write tools that do specific things, not general things ("delete_old_records_before_date" not "clean_database")
• Use confirmation prompts (elicitation) for destructive operations
• Build guardrails into the tool itself — "are you sure?" checks, dry-run modes
• Review the LLM's plan before it executes multi-step operations

---

Just-in-Time Access

The security principle I apply to production MCP servers: give the LLM the minimum access needed for the current task, at the time it needs it, for the duration it needs it.

Not: a server with full admin access to your database, always connected.

Instead:

• Scoped read-only access for query tools, write access only for mutation tools
• Short-lived tokens rather than permanent credentials
• Per-session authorization rather than blanket server-level access
• Audit logs of every tool call and what it did

Think of MCP tools like AWS IAM roles: start with nothing, add only what's required, review regularly.

---

What to Trust

A rough guide:

Source	Trust level
Servers you wrote	High — you know exactly what they do
Official @modelcontextprotocol/server-* packages	Medium — read the source, they're open
Popular community servers, well-maintained	Medium — audit before use
Random npm packages	Low — read every line before connecting
Any server you can't read the source for	Don't use

The moment an MCP server is connected, it's in a position to influence your LLM's behavior. I treat that access the same way I'd treat shell access to my machine.

---

The Broader Point

MCP is powerful because it gives LLMs real capabilities. That's also exactly why it needs to be treated with the same security discipline as any other privileged system access. The threat model isn't "can the LLM write bad code?" — it's "what can a bad actor make the LLM do with the tools I've given it?"

Build with that question in mind from the start.

Further Reading

• MCP Security — Official Guidance
• OWASP Supply Chain Security
• Model Context Protocol — Official Site