[TeMPOraL]

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.)

[Gerardo1]

I don't think that's a useful lens to view the problem through, or a useful way to have a conversation about MCP security.

That a system is hard to secure doesn't negate the need for it to be secure.

Though I agree about third-party MCP services. They're in a weird spot and I'm not sure that they're viable for many use cases.

[TeMPOraL]

I disagree. I think this is one of the most important lenses to inspect the problem through, as the current set of articles and discussions about MCP security I saw here over the last weeks, seem mostly oblivious to the fact that the vulnerabilities they're complaining about are also MCP's main features.

> That a system is hard to secure doesn't negate the need for it to be secure.

Correct. However, security is a spectrum - there's such a thing that "secure enough", especially when making it more secure eliminates the very reason for system's existence. Additionally, we can and should secure different parts of a system to a different degree.

For an analogy, consider utensils and workshop tools. We secure them as much as we can against accidents, but not so much as to make the tool worse at its job. We add further security by means like access controls, or laws making people responsible for use and misuse, etc. - i.e. we're making the larger system secure, without burdening the inner core.

(For comparison, fully secure version of utensils and all kinds of tools are also available on the market - you'll find them in toy stores.)

[AlexCoventry]

It seems to me that the solution is to run this stuff in a securely isolated environment such as a VM, dedicated machine, or VPC, where you don't care about the secrets it has access to, and don't really care about corruption of the data in the environment. Then you have to carefully audit any products you take from that environment, if you want to run them in a more sensitive context.

I don't think this is really an MCP problem, it's more of an untrusted-entity problem.

[vlovich123]

Except the article is about an untrusted tool doing things like tool shadowing or otherwise manipulating it’s output to trick the LLM into executing unintended tool actions. Isolated environments don’t help here because by definition MCP is crossing those environments.

[lsaferite]

Legit question, why would you be using an untrusted tool in the first place?

Why are people surprised they are vulnerable to a malicious tool when they are using untrusted and/or remotely hosted tools?

Without some method to tag context as sensitive and an LLM model/service that respects said data tagging, you'll likely never have a scenario where you can trust that the LLM isn't sending some sensitive information to an untrusted endpoint. If you accept that, then you have to design your system around not using untrusted endpoints. Just adding untrusted endpoints is kinda like running untrusted applications on your machine. It's fine until it isn't.

At the very least, your agent should have some way to mark the entire session as 'tainted' in such a way that calling out to untrusted sources is forbidden once sensitive context enters the loop. And that would need to live outside the LLM calling loop since the LLM could be tricked before the sensitive data was introduced. With the tool annotations being added to the spec, your internal tools could provide those flags the the agent to facilitate such a blunt security process. And I am aware there are likely holes in such a plan, hence my first question.

[vlovich123]

For the same reason people use untrustworthy extensions in browsers or IDEs. Those extensions need not even start out untrustworthy - they change hands and become malicious after establishing popularity.

[sanderjd]

At that point, what is the benefit of MCP over just what we've been doing for decades of putting services behind network-accessible APIs?

[lsaferite]

Benefit: A standard and purpose driven protocol for connecting agents (MCP Host/MCP Clients) to tools, resources, and prompts (MCP Server) that also exposes LLM services to said MCP Servers.

The alternative you suggest is manually integrating each set of tools or data?

Or maybe there's some misunderstanding about MCP? MCP currently has 2 transports, stdio and HTTP+SEE. The second one is, in fact, a "network-accessible API" as you call out.

[sanderjd]

No, the alternative I suggest is "can't agents figure out how to use existing kinds of APIs if they are documented well?". I think the answer is that in the current state of the art, it's very useful to give them a nudge to help them along.

But I feel like eventually I should be able to publish an API spec or a well documented interface / protocol / whatever my programming language calls it, and an agent should be able to grok that and use it without a separate protocol.

[lsaferite]

Sure, "eventually" you'll be able to point an agent at an arbitrary API and have it figure things out. We have a ways to go before we get there, but we will get there.

[sanderjd]

Fair enough!

[AlexCoventry]

Having a robot perform increasingly sophisticated tasks in your development environment still seems like a win in certain circumstances.

[sanderjd]

So it is only for software developers?

[sanderjd]

Yeah it strikes me that if you want to provide MCP tools as a hosted service, the way to do that is to put them behind a web API.

I'm a little surprised there is so much hype for MCP rather than just "put your tools behind a web service with good machine-readable documentation, and agents can use them easily".

[hinkley]

Doesn’t “behind an api” still have Bobby Tables problems?

How do I put it behind an API without dumbing it down to inutility?

[sanderjd]

On the "bobby tables" thing, my point is basically that all the same rules for API services still applies. You still have to sanitize sql and all the other stuff we've already been doing for decades.

> How do I put it behind an API without dumbing it down to inutility?

I dunno, I'm still feeling this out and just asking honest questions. But so far, most of the MCP functions I've seen have struck me as "this could be done behind an auto-generated RPC service running in a sandboxed environment".

[lsaferite]

MCP currently has two transports, one of which *is* a web accessible API.

[never_inline]

A. Implement guardrails (like already done against prompt injection).

Invariant blog post mentions this:

> Conclusion: Agents require extensive, highly-contextual guardrailing and security solutions

> As one of our core missions at Invariant, we absolutely cannot stress enough how important it is to rely on extensive guardrailing with AI models and their actions. We come to this conclusion repeatedly, as part of our research and engineering work on agentic systems. The MCP ecosystem is no exception to this rule. Security must be implemented end-to-end, including not only the tool descriptions but also the data that is being passed to and from the AI model.

B. Version the tool descriptions so that they can be pinned and do not change (same way we do for libraries and APIs).

C. Maybe in future, LLMs can implement some sort of "instruction namespacing" - where the developer would be able to say any instruction in this prompt is only applicable when doing X, Y, Z.

[turnsout]

Here's the better design: have agents communicate via Mastodon. Take a basic JSON payload, encrypt it using basic public key encryption, and attach it to a DM.

This is far better than designing an entirely new protocol, as ActivityPub and Mastodon already have everything you need, including an API.

Now, that's just transport security. If you expose a server that will execute arbitrary commands, nothing can protect you.

[turnsout]

If you're downvoting, can you explain why you disagree?

[never_inline]

Because it's not an encryption problem. It's a "you can override instructions from other servers" problem.