MCP and security

What this guide covers ​

MCP is how an agent reaches past its chat window: your files, your databases, your terminal, whatever service you connected last week. Every one of those connections is what makes the work worth doing, and a door you are holding open. This cluster is about the doors. What fits through them, who else knows they are there, and how to shut the ones you do not need without throwing the tooling away.

I use MCP daily and my own setup leans on it heavily. That is why I take the weak spots seriously, rather than in spite of it. If you think the protocol is hype, none of this concerns you. If you ship with it, all of it does.

What you are handing over ​

Start with the plain question: what can an agent do with the permissions you already gave it? Usually more than you pictured. Censys found thousands of MCP servers sitting open on the internet, and an open MCP server is worse than an open database is why that phrasing is not dramatic. A database leaks. A tool server executes. We learned this for databases fifteen years ago and are now paying tuition twice.

The same question points outwards. Your coding agent read your .env, then uploaded your whole repo follows what actually leaves your machine during an ordinary session, which is more than the file you had open. And the door does not have to be technical: in they just asked the bot nicely the support agent is the attack surface and the exploit is a polite sentence.

Where your servers come from ​

The second layer is supply chain. The MCP supply chain is the new npm is the overview: a config-to-command RCE in every official SDK, poisoned registries, an ecosystem replaying the npm playbook at double speed. That playbook is in active use. They didn't push a new version, they moved yours is someone rewriting hundreds of existing git tags to point at malicious code without publishing anything at all, which is where your lockfile stops helping you.

The scale of it is easy to wave away, so one in four puts a number on the security debt nobody is counting.

Vetting and hardening ​

Then the handwork. How to vet an MCP server is the checklist I actually run: who publishes it, what the tool descriptions tell the model, which permissions it asks for and why it claims to need them. For the sharpest case, an agent sitting next to your data, safe SQL access for Claude does it with SELECT-only access, query validation and field redaction.

Prompt injection defence covers the attack that needs no vulnerability whatsoever, only text your agent happens to read. And if you publish a server rather than consume one, MCP server authentication is the resource-server model the spec actually asks for.

The pattern underneath all of it: constrain at the system level. A rule in a prompt is a suggestion. A wall is a guarantee.

Sandboxes, and what still gets out ​

Sandboxing Claude Code is how I run mine. A box still full of live tokens only moves the problem, so credential masking is the settings walkthrough for handing the agent's shell a placeholder and letting the proxy re-attach the real secret on the way out, including what that control does not cover. Every agent sandbox has the hole that makes it useful is the week two of those boxes failed, one at Anthropic and one at OpenAI, where both escapes climbed a single privilege level inside a boundary that already held the prize.

The agents left notes for each other is the sequel and the more useful half: OpenAI's own 74-day timeline of the Hugging Face incident, where the channel the agents coordinated through was an internal package registry, and the boundary that gave way was time rather than space.

When it goes wrong anyway, you want the next hour to be boring. The incident-response runbook is that hour in five phases, starting with the session transcript and ending at the permission that allowed it.

That hour only starts once somebody notices, which is what audit logging for AI agents is for: the three trails Claude Code already writes to your own disk, why the compliance feed your security team queries contains none of them, and how to settle in advance what is allowed to wake a human up.

The incidents are not hypothetical ​

Nobody was driving documents the first recorded intrusion an agent ran by itself, from CVE to drained database, four pivots, under an hour. Even the malware is AI slop is the same story from the other side: an npm package that went straight for Claude's working directory. The friction was the feature is what happens when a vendor removes the clicking-through that was quietly acting as your last check, and ThePrimeagen was right is what atrophied judgement costs when the command you paste is poisoned.

The industry response deserves its own scepticism, which is what the arms race for your trust is for: security products sold on a fear the sellers are helping to produce.

The other risk is your vendor ​

Not every risk here is an attacker. The off-switch works both ways now is model access decided by a list you may not be on, and the Ferrari has a limiter is the day-to-day version of that, felt in a single working day. Both are the argument for taking back control of your data and for more control over your server.

Where this touches what you build ​

Security starts before there is anything to patch, at the question of whether a server should exist. Every server you do not run is attack surface you never have to defend. That is why build an MCP server, then ask whether it should exist belongs to this guide as much as to agentic coding. The cheapest hardening available to you is a tool list that stays short.

Below are three starting points, then everything I have written on this topic, newest first.