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. A commit hash cannot be moved like that, and Plugin4Shell shows why that is still not enough: four coding agents asked git for the pinned commit and never checked what they ended up with, and my own CI runner did the same.

The same playbook now runs a step earlier, at the name itself. Slopsquatting is what happens when a model invents a package name consistently enough that somebody registers it first. The defence everyone recommends is to check that the package exists, and that answers the wrong question in both directions.

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.

If a scanner is doing that checking for you, MCP server security scores is the measured account of what those grades are worth: 74,101 servers sorted by what actually backs each signal, an independent study finding fewer than half of scanner alerts hold up, and the state no dashboard shows you, which is that nobody read the source.

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 second machine that runs your code ​

Your laptop is not the only place your code executes, and nobody is sitting at the other one. CI runner security when an agent writes your workflow is this guide applied to the pipeline: why the hardening advice everyone repeats quietly assumes one platform, what a runner holding no credentials at all is still worth to an attacker, and the table in Anthropic's own documentation showing that a repository's restrictions are dropped in a headless run while the code that repository supplies still runs.

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.

A vendor can also collect through pages you built. You installed OpenAI's tracker yourself follows a ChatGPT cookie back to OpenAI from shops that load its ads pixel, and shows why the consent flag in the docs fires too late to help.

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.