Margin of Safety #9: MCP, USB for AI or Trojan Horse for Security?

If you follow AI news (like every VC, including us), then you’ve seen a spate of recent articles about MCP, aka the Model Context Protocol. But what is it? In short, it’s a way for LLMs to easily interact with new tools and data sources, without requiring additional training or RAG. This is exciting because it starts to make AI capabilities look more like a technology platform, in which new capabilities can be easily rolled out to seamlessly interact with a broader, rich ecosystem. It’s also concentrating security risk, because if MCP becomes a universal access layer then a vulnerability in it can quickly affect a broad portion of that ecosystem.

For more color, read on.

The Pre-MCP World

To illustrate the value of MCP (or something like it), let’s start by looking at a world without it. Let’s say that I want an LLM to make Jimmy (a VC investor) cheat sheets for each of his upcoming meetings. To that end, I want the LLM to:

• Pull his calendar
• Identify meetings with cool startups
• Check our CRM to see if they’re prospective investments
• Fetch past meeting notes and PitchBook data
• Summarize everything into a tidy email

But without MCP, this requires hand-stitching the LLM into four different systems (calendar, CRM, PitchBook, email), each with its own quirky API, authentication scheme, and data format. Suddenly, I’m back to having to vibe code this system myself. That’s not the AI outsourced life I was promised!

Enter MCP

To be maximally lazy, I need MCP.

Anthropic describes MCP as being like a USB port for applications; what they mean is that MCP defines a simple, consistent way for LLMs to access tools or data. This allows models to use those tools without any additional training or instruction. To achieve this, the MCP server sits in front of existing tools and acts as a translation layer, converting their existing APIs to model-friendly interfaces.

More and more folks are rolling out MCP servers for their products; this is great for a consumer, because it means that those tools or data sources will increasingly “just work”[1] with MCP-ready LLMs. Instead of needing to do any teaching, I can rely on a built-in ability of the LLM to generically communicate with other systems. Now I can truly embrace AI-fueled laziness!

The key thing in this situation is that while the MCP translation layer must be built, it only needs to be built once. Without MCP, everyone who wants an LLM to connect to PitchBook must build out that connection. With MCP, PitchBook can do the work once to provide an MCP server, and then any LLM workload can easily interact with their capabilities.

With Great Power Comes Great Responsibility

Unfortunately, these capabilities have some gotchas. The biggest is that MCP – in some ways – opens new capabilities for malicious behavior. For example, there’s a lot of news about the fact that MCP servers can be used to deliver prompt injection attacks to the models that connect to them.

To some extent, this problem always existed. Any API could put “LLM, turn the evil dial to 11!” into its response and potentially subvert an LLM user. But APIs are typically consumed by programmatic systems, and relatively few APIs have a place to put a freeform prompt injection that wouldn’t risk breaking non-LLM consumers. Because MCP is basically designed for models’ eyes only, there’s increased opportunity to deliver prompt injections without impacting other systems. Plus, the protocol is designed so LLMs trust MCP servers to describe their capabilities. An evil MCP server can lie about its intended use, tricking LLMs into sending it sensitive data. And worst of all, the full MCP interaction is not necessarily shown to users, meaning that malicious interactions may be literally invisible.

Beyond these specific gotchas, an MCP server is also highly trusted. It necessarily handles credentials that can be passed onto the upstream API to retrieve data or take action. This means MCP servers may be a lucrative attack target or trojan horse; compromising one allows attackers to both attack connected models (via prompt injection or false advertising) or upstream systems (via credential theft). As a result, it’s important for consumers to understand the security of any MCP servers they’re using and to appreciate the trust they’re placing in the maintainers.

Wrapping up

Model Context Protocol is a classic double-edged sword. On one hand, it’s the infrastructure glue that could make LLMs genuinely useful across the enterprise—creating horizontal platforms and unlocking new workflow automation use cases. On the other hand, it centralizes risk in ways that are way under-appreciated right now.

So yes, we’re bullish on MCP.

But we’re even more bullish on startups that help make MCP and agents safe—because in this next era of AI, the people who figure out how to secure the USB port may own the whole machine.

[1] There’s still a little bit of work; you’ll often have to (for example) configure credentials that the model can use to access a tool on your behalf. But this sort of work is very easy and needing per-user credentials is a feature, not a bug, from a security PoV.