MCP (Model Context Protocol): the new attack surface for developers.

The Model Context Protocol, or MCP, is an open protocol — originated at Anthropic and since adopted much more broadly across the industry — for standardizing how an AI application connects to the outside world. Concretely: instead of a chat client, an IDE assistant, or an autonomous agent each shipping bespoke, one-off integration code for every filesystem, database, or API it needs to touch, MCP defines a common way for a "client" (the application hosting the model) to talk to a "server" (a small program that exposes a specific set of tools, data sources, or other context to the model).

The appeal is easy to see honestly, because it solves a real problem. Before a shared standard like this existed, every tool integration was custom glue code — different auth, different data shapes, different failure modes, rewritten for every model provider and every application that wanted the same capability. MCP turns that into something closer to a plug-in pattern: write one server that exposes "read files in this directory" or "query this database," and any MCP-compatible client can connect to it. That's a genuine engineering win. It's also, structurally, a new place where trust gets negotiated every time a connection is made.

Why standardizing the connection is also standardizing the risk

When every integration was bespoke, an attacker who wanted to abuse one had to understand your specific glue code — your particular API wrapper, your particular way of shuttling data into the model's context. That heterogeneity was accidental security through obscurity, and not something anyone should have relied on, but it did mean an attack technique rarely transferred cleanly from one system to the next.

Once integrations follow a shared protocol, that stops being true. A technique that exploits a weakness in how MCP servers commonly handle tool descriptions, or how clients commonly render tool output back to the model, can generalize across every server built the same way — not just one bespoke integration. This is not a flaw unique to MCP; it's the tradeoff every standardization effort makes. Common formats and common protocols are what make interoperability possible, and they are exactly what makes a single attack technique portable across many implementations at once. TCP/IP, HTTP, and USB all made this same trade before MCP did. The lesson isn't "don't standardize" — it's that the security work has to happen at the protocol and implementation level, not be left to each integration to reinvent.

Where the actual risk sits

• Malicious or compromised MCP servers. A server gets to describe its own tools to the client and return arbitrary data as the result of a tool call. Both of those are places a hostile or compromised server can smuggle instructions into what looks like ordinary output — a tool description that quietly tells the model to behave differently, or a data response with hidden text telling the model to take some further action. This is a protocol-specific flavor of indirect prompt injection: the attacker never talks to the model directly, they just control something the model reads through a channel it was told to trust.
• Overly broad permission grants. A server connected once for a narrow task — say, reading a single config file — often ends up with standing access to an entire filesystem, an entire database, or an entire API scope, because that's what the default connection offered and nobody went back to narrow it. The gap between "what the task needs" and "what the connection actually grants" is where a single mistake, or a single injected instruction, turns into a much bigger problem than it should be.
• Supply-chain risk from installing third-party servers you haven't audited. Connecting to an MCP server you found online and didn't write yourself is, in security terms, close in kind to installing an unreviewed npm package or a browser extension: you're granting a piece of code you didn't inspect the ability to run with some of your privileges, and its author's intentions and competence become part of your trust boundary whether you meant them to or not.
• Weak sandboxing on locally-run servers. Many MCP servers run as ordinary local processes, which means they typically execute with the same privileges as the user who started them — full access to that user's files, credentials, and network, not some reduced sandboxed subset. A bug or a malicious instruction inside that server isn't contained by anything the protocol itself provides.

What to actually check before connecting a server

None of this is exotic once you frame it correctly: an MCP server is third-party code you are granting access to your machine or your data, and it deserves exactly the scrutiny you'd give any other piece of third-party code in that position.

• Review the source if it's open. If you can't or won't read the code, treat that as a real cost of using the server, not a formality to skip.
• Prefer servers from maintainers you actually trust — an established project or organization with a track record, over an unverified script from an unfamiliar source.
• Scope its permissions to the minimum the task needs rather than accepting whatever default access the server asks for. If it only needs read access to one directory, don't grant it your whole home folder.
• Run untrusted servers in a sandboxed or containerized environment so a compromised or misbehaving server can't reach further than intended, even if it tries.
• Monitor and log what tools actually get called and with what arguments, so you have something to look at after the fact instead of just trusting that it behaved.

This is agentic security, one layer down

None of this is a separate problem from the one covered in agentic AI security basics. That article talks in the abstract about what happens once an agent gets tool access and can take actions in the world — the risk of over-permissioned tools, the need for human approval on consequential actions, the importance of logging what an agent actually did. MCP is one of the concrete mechanisms by which an agent gets that tool access in the first place. Every MCP server you connect is a tool grant, and the same mitigations apply directly, just scoped down to a specific question: which MCP servers are connected right now, and what can each of them actually touch? If you already think about agent permissions in terms of least privilege and approval gates, connecting an MCP server is where that thinking has to actually get applied, not just acknowledged.

Protocols that make integration easy always make trust boundaries easier to blur — that's not a criticism specific to MCP, it's what happens whenever "connect anything to anything" becomes a one-click action instead of a deliberate decision. Treating each MCP connection as a real access-control decision, not a one-click convenience, is the whole mitigation in one sentence.