MCP and security

What this guide covers ​

MCP is how an agent reaches beyond its chat window: files, databases, your terminal, remote services. Every one of those connections is exactly what makes the work valuable, and at the same time a door you are propping open. This cluster is about those doors: what fits through them, who else knows they exist, and how to close them without throwing the tooling away.

To be clear, I use MCP every day and my own workflow leans on it heavily. That is exactly why I take the weak spots seriously. If you dismiss the protocol as hype, none of this concerns you. If you actually work with it, all of it does.

What you are actually handing an agent ​

Start with the basic question: what can an agent do with the permissions you give it? Usually more than you assumed. Censys found thousands of MCP servers open on the internet, and an open MCP server is worse than an open database explains why that is no exaggeration: a database leaks data, a tool server executes. These are lessons the industry learned for databases fifteen years ago and is now learning again.

The supply chain ​

The second layer is where your servers come from. The MCP supply chain is the new npm is the overview piece: a config-to-command RCE in every official SDK, poisoned registries, and an ecosystem replaying the npm playbook at double speed. And the playbook is in active use. In they moved your version, someone rewrites hundreds of existing git tags to point at malicious code without ever publishing a new release. Your lockfile stops helping you at that point.

Audits and hardening ​

Then the hands-on part. How to vet an MCP server is the checklist I run myself: who actually publishes it, what the tool descriptions say to the model, which permissions it asks for. For the most sensitive case, an agent near your data, giving Claude safe access to your SQL database shows how to do it with SELECT-only access, query validation and field redaction. The pattern is always the same: constrain permissions at the system level, because a rule in a prompt is a suggestion and a wall is a guarantee.

The incidents are already here ​

None of this cluster is theoretical. Nobody was driving documents the first recorded intrusion executed by an agent on its own, from CVE to drained database. And attackers now target agents explicitly: even the malware is AI slop covers an npm package that went straight for Claude's working directory. The agent is the most trusting, most credentialed process on your machine. Attackers have noticed.

Where this touches what you build ​

Security starts before there is anything to patch, with the question whether a server should exist at all. Every server you don't run is attack surface you don't have to defend. That is why build an MCP server, then ask if it should exist belongs to this guide as much as to agentic coding: the cheapest hardening is a tool list that stays short.

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