MCP for AI is Hot. But Where's the Security?

(Editor's Note: This is Cloud Tracker Pro premium analysis that will be available for a limited time for free. To subscribe to CTP, go here.)

The model context protocol (MCP) is a huge topic in AI, but its presence felt subtle at this week's RSAC 2025 Conference. Companies are eager to talk about MCP, but the security discussion feels like it's just beginning to stir.

That reflects how new MCP is. The protocol attempts to standardize how agents and large language models (LLMs) can communicate with data sources, and while it has gone viral, it's still a new toy that people are figuring out. Multiple vendors used the show to launch their own MCP servers, among them Versa Networks (a member of the Futuriom 50) and security specialists including AppOne, Backslash, and Salt Security.

But having a server simply beings being able to accept MCP communications. As we'll discuss below, MCP is about scaling, not security. The next step, then, is to ensure that this scaling happens securely, keeping within the limits of authorized policy.

One company tackling that issue is Teleport (another Futuriom 50 member), which this week announced that its security platform will now secure MCP as well. The company demoed the concept on the RSAC expo floor but noted that the product is new and will be made available in the coming months.

Security for MCP Is New

To be fair, RSAC wasn't likely to be a hive of new MCP security products. Conference talks and product launches were all cemented a long time ago—and then MCP sprang into the picture. The protocol had existed for a while—vector database vendor Qdrant, for example, produced an MCP server in October—and other similar protocols were in the wild. But MCP didn't hit broad awareness until last November, when Anthropic open-sourced it. Even then, the tipping point arguably wasn't until March, when OpenAI adopted MCP, as did Cloudflare and Microsoft. It's been too sudden for most vendors to rev up an RSAC 2025 splash.

That seems appropriate, too, because MCP is the classic case of a new idea careening forward almost carelessly. Some MCP security does exist, but the protocol's adoption is ramping faster than security can keep up.

"The running joke here is Security is the S in MCP," said Diana Jovin, CMO at Teleport.

MCP as Universal Translator

Most of us first experienced LLMs as black boxes: Someone stuffs the model with data, and the LLM churns it invisibly. But better inferencing requires adding specialized information, even real-time data, and that often requires tapping many data sources. Agentic AI, in particular, could involve many tools contacting many sources without human intervention.

MCP provides a standard way to connect AI systems, including agents and LLMs, to data sources. The idea is that developers will no longer need to maintain APIs for every data source; they can just write to MCP, so to speak, as a universal translator.

As with any communications protocol, MCP must be supported by both sides of a connection. AI apps or agents use MCP to communicate to data sources, such as databases. On the latter side, an MCP server accepts those requests and exposes data to the client.

Alongside the November launch of open-source MCP, Anthropic provided a repository of MCP servers—reference implementations that work with apps and projects including Google Drive, Google Maps, PostgreSQL, Redis, and Slack. Of course, the launch also came with MCP server support in Anthropic's Claude Desktop apps, and the company noted that Claude 3.5 Sonnet was "adept at quickly building MCP server implementations," removing most of the learning curve for the new protocol.

MCP's Dark Side

What could possibly go wrong? Plenty. (That's always the correct answer.) The industry was quick to dream up malicious attacks related to MCP. SentinelOne outlined some of them in a blog earlier this month. An MCP tool (the function that's pinging a data source to retrieve information) could establish trust with a data source but then change its behavior—or it might simply not do what it says on the tin, executing actions that go unnoticed depending on how mature the user's observability environment is. A tool could also persist too long, giving a bad actor an open doorway into sensitive data.

The MCP community isn't ignoring security, to be sure. An update to the specification in March set OAuth 2.1 as the foundation for MCP's authorization (note, however, that authorization remains optional to implement). It's a significant step but hardly comprehensive.

Vendors are already filling the gaps, of course. Prior to RSAC, SentinelOne announced unified detection and response for MCP, especially the tasks listed above. It supports remote LLM usage as well as desktop LLMs. In the latter case especially, SentinelOne looks for signs of trouble, including odd DNS requests and memory injection attacks.

Teleport announced MCP security as well, approaching the problem from the standpoint of identity.

That's noteworthy, because Teleport's idea of "identity" revolves not around people and job functions but around infrastructure and tasks. It's an approach designed for the engineering and infrastructure world rather than conventional IT. To Teleport, access is inherently ephemeral, involving permission for a particular user (human or otherwise) to tap a limited amount of resources for a limited amount of time. In the case of human users, that access is based on biometrics or some other real-world factor—not passwords—and no credentials are static.

Teleport's announcement amounts to adding MCP to the sphere of infrastructure identity. The approach does away with the issue of overprivileged users (nobody gets to be overprivileged in the first place) and avoids the problem of leftover keys or certificates left lying around. Enterprises have used the company's platform to eliminate VPNs and make the concept of "zero trust" more robust. Because MCP is simply another protocol in the mix, MCP support isn't technically a "product" and doesn't incur any additional charges; it just becomes part of the platform.

Teleport's MCP security won't be available for a couple of months, but the company appears to be early in taking a more comprehensive approach to ensuring MCP security. Note also that Teleport developed its MCP security relatively quickly. Based on that, we would expect more vendors to start announcing MCP security for various segments of the communications chain. Teleport, though, might have already addressed many problems by simply locking down the permissions around MCP actions.

Aside: A2A

While MCP has become the de facto standard of the moment, it was never the only option out there, nor is it the last protocol to arrive. At Google Cloud Next, Google launched the Agent to Agent (A2A) protocol, which allows AI agents to communicate with one another.

The current thinking is that A2A and MCP are complementary. You can even see in the descriptions that they are built for separate purposes: A2A is about agents talking to agents (we can think of that as a many-to-many scenario) whereas MCP is a way for a given AI application to tap many data sources (when worded that way, we can think of MCP as one-to-many, although the truth is a lot more complicated).

Look how carefully we had to word that distinction, though. MCP and A2A can already overlap, and given the way protocols and standards tend to go, some kind of merger or mind-meld seems inevitable. A2A might even co-opt the discussion, given the big names supporting it. That includes Atlassian, Box, Cohere, Intuit, Langchain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, and Workday; and on the vendor and consulting side, you've got Accenture, BCG, Capgemini, Cognizant, Deloitte, HCLTech, Infosys, KPMG, McKinsey, PwC, TCS, and Wipro.

Futuriom Take: For now, the industry is just getting acquainted with A2A and is still seeking its footing with MCP. Security for MCP is an immediate concern, and it's good to see it getting attention.