The “S” in MCP Stands for Security

Here's a challenge: sketch a better design, that:

1. Is properly secure, to whatever standards will stop people writing "S Stands for Security" articles, and

2. Allows programs implementing it to provide the same set of features the most useful MCPs do now, without turning automatic functionality into one requiring manual user confirmations, and generally without defeating the purpose of the entire idea, and

3. Doesn't involve locking everything down in a proprietary Marketplace with a corporate Gatekeeper.

I'd be interested to see a proposal, because so far all I've seen is "MCP is not sekhure!!!111" in general and non-specific sense. I guess it's not that easy, especially when people forget that security and usefulness are opposing forces.

(Also, AFAIK, MCP was not intended for its implementations to be hosted by third parties and provided "as a Service". If that cannot be secure, then don't do it. Find some other business to be in, instead of trying to nerf MCP through "solving" something that isn't a problem with the protocol.)

I'm using claude code a lot more than I expected I would. And, it has these problems exactly. It does not appear to log anything, anywhere. I cannot find a local log of even my prompts. I cannot find anything other than my credits counts to show that I used it. The coding conversation is not stored in my conversation in the webui.

I wonder if this is by design. If you are doing contracting work, or should I say, claude is doing contracting work by proxy for you (but you are keeping the money in your bank account) then this gives you a way to say "I don't know, maybe Claude did 12% of the work and I did the rest?"

openwebui and aider both have ways to log to something like datadog. So many layers of software.

I've been looking at ways to script my terminal and scrape all the textual data, a tool that would be outside of the subprocesses running inside the terminal. I really like to keep track of the conversation and steps to build something, but these tools right now make it really difficult.

The post highlights and cites a few attack scenarios we originally described in a security note (tool poisoning, shadowing, MCP rug pull), published a few days ago [1]. I am the author of said blog post at Invariant Labs.

Different from what many suspect, the security problem with MCP-style LLM tool calling is not in isolating different MCP server implementations. MCP server implementations that run locally should be vetted by the package manager you use to install them (remote MCP servers are actually harder to verify).

Instead, the problem here is a special form of indirect prompt injection that you run into, when you use MCP in an agent system. Since the agent includes all installed MCP server specifications in the same context, one MCP server (that may be untrusted), can easily override and manipulate the agent's behavior with respect to another MCP server (e.g. one with access to your sensitive database). This is what we termed tool shadowing.

Further, MCP's dynamic nature makes it possible for an MCP server to change its provided tool set at any point or for any specific user only. This means MCP servers can turn malicious at any point in time. Current MCP clients like Claude and Cursor, will not notify you about this change, which leaves agents and users vulnerable.

For anyone, more interested, please have a look at our more detailed blog post at [1]. We have been working on agent security for a while now (both in research and now at Invariant).

We have also released some code snippets for everyone to play with, including a tool poisoning attack on the popular WhatsApp MCP server [2].

[1] https://invariantlabs.ai/blog/mcp-security-notification-tool...

[2] https://github.com/invariantlabs-ai/mcp-injection-experiment...

We are indeed forgetting history, with most important lesson being:

How do you write a web tool that lets users configure and combine arbitrary third-party APIs, including those not known or not even existing at the time of development, into a custom solution that runs in their browser?

Answer: you don't. You can't, you shouldn't, it's explicitly not supported, no third-party API provider wants you to do it, and browsers are designed to actively prevent you from doing such a thing.

That's the core problem: MCP has user-centric design, and enables features that are fundamentally challenging to provide[0] with a network of third-party, mutually mistrusting services. The Web's answer was to disallow it entirely, opting instead for an approach where vendors negotiate specific integrations on the back-channel, and present them to users from a single point of responsibility they fully control.

Doing the same with MCP will nerf it to near-uselesness, or introduce the same problem with AI we have today with mobile marketplaces - small number of titans gate-keeping access and controlling what's allowed.

--

[0] - I'd say impossible, but let's leave room for hope - maybe someone will figure out a way.