MCP security: the protocol as a new attack surface

"Model Context Protocol: Can it be the next carrier of AI Security Risks?" is the headline Security Boulevard ran with on 4 August 2026. The question is not new, but it lands at a specific moment: MCP is no longer a lab proposal, it is the route through which an assistant reaches the repositories, databases, email and file systems of real companies.

The framing is straightforward. If the protocol becomes the standard connection layer between models and tools, it also becomes the place where everything an attacker cares about passes through. It is worth unpacking why that concern has a basis, without turning it into panic.

It helps to size things up. MCP was published in late 2024 and today there are official and community servers for almost any commonly used service, from version control to spreadsheets and ticketing systems. Each one is, in practice, one more door in the perimeter of a team that probably has not inventoried it.

Where the real risk sits

An MCP server is not a plugin in a sandbox. It is a process running on your machine or your network, with your credentials, returning text that the model will read as context. Three families of problems come out of that:

Indirect prompt injection. If a tool returns content controlled by a third party, such as a GitHub issue, an email or a web page, that content enters the context window with the same status as the user's instructions. The model may end up executing whatever it says.
Excessive permissions. Many servers ask for a token with broader scope than needed because it is the fastest thing to configure. A read and write token across the whole workspace turns a minor fault into a serious incident.
Supply chain. Installing a community server is usually one command, and updating it is too. In between there is a package that can change hands without anyone reviewing it.

The most uncomfortable case combines two of them. A server with broad permissions that also consumes external content does not need a code flaw to cause harm: it is enough for someone to leave instructions in a ticket and for the agent to treat them as part of the job. It is the scenario that shows up most often in public demonstrations over recent months and the easiest to reproduce in a test environment.

None of these vectors is exclusive to MCP. What is specific is the combination: one command installs, long lived credentials in a configuration file, and a consumer that by default does not distinguish data from instruction.

What can be done today

There is no need to wait for a future version of the standard to reduce exposure:

Per server credentials with minimum scope. Reusing your personal admin token is the quick path and also the worst one.
Pin versions. Installing from a floating tag in an environment with production access is a conscious decision, not an oversight.
Human confirmation on destructive operations. Claude Code lets you insert PreToolUse hooks to audit or block calls before they run, and that hook is the natural place for a team policy.
Separate environments. The server that reads the CRM does not have to live in the same session as the one that writes to the repository.
Read the code. Useful servers tend to be small, and half an hour of reading is worth more than a dependency list.

Who this is for

For any team that has already moved from "let's try an MCP" to "we have four servers in production". That jump usually happens without a formal decision: someone connects the first one, it works, and within two weeks there is an infrastructure nobody has reviewed or documented. The Security Boulevard article works as a reasonable excuse to take that inventory and put a date on it.

Our reading

MCP is not less secure than the integrations it replaces. What it does is concentrate in one place risks that used to be scattered and worse documented, and that is an improvement if the inventory is maintained or a trap if it is left to grow on its own. The full piece is at Security Boulevard.