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

An MCP server sits inside the trust boundary the moment you connect it – it can shape what the model sees and what it's told to do next. Four categories of risk show up consistently in practice:

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.

Frequently asked questions