The exploitation of Model Context Protocol is inevitable (or, how to prevent LLM leakage that could give away your company secrets)

This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our time.

Teams are adopting AI at a breakneck pace, and one of the ramifications of that is the need to standardise the way teams connect AI, data sources and humans.

Anthropic’s Model Context Protocol (MCP) is the answer to that problem, standardising how large language models (LLMs) interact with data, promising greater interoperability and streamlined workflows. Its extremely rapid adoption is, for that reason, not entirely surprising.

But MCP was primarily designed for functionality, not security. And make no mistake, Agents speaking ‘MCP’ will be exploited trivially, not because securing protocols is hard – that’s simple – but because bad implementation is inevitable. So, in this article, I’ll explore why it’s important to secure MCP itself to avoid unauthorised user or bot access to sensitive data.

Identity fragmentation is the real enemy

One of the biggest benefits that MCP introduces is placing guardrails on what an LLM can and cannot do. It establishes a secure client-server architecture where AI systems request only relevant context from data repositories or tools. The issue is that this doesn’t stop the AI system from relinquishing sensitive data to an identity that has been spoofed. And if we’ve learned anything from the last decade, it’s that computing infrastructure is rife with identity fragmentation that makes spoofing easy.

When identities are siloed across systems – AWS, Kubernetes, databases or AI agents -that makes it a cakewalk for attackers to exploit the chaos by spoofing one of those identities. This point is worth stressing because the spoofing doesn’t actually need to occur on the LLM side of things. If identities in your infrastructure are spoofed, then the LLM is exposed. All an attacker needs to do is trick the LLM into thinking that they’re someone – or something – that they’re not. An obvious example of this is someone pretending to be the CEO of your company to obtain financial records they shouldn’t have access to.

Understand, too, that phishing is just one of many forms of identity-based attacks. An attacker could pretend to be a database, too. That means the LLM can be tricked into sending valuable data, thinking it’s part of your company’s infrastructure. Access is then granted when it shouldn’t be.

In other words, what we’re really talking about preventing here is human error. You can have secure protocols, but you have to implement them properly, in a foolproof way. Attackers, at the end of the day, don’t attack protocols directly. Rather, almost all attacks begin with targeting human mistakes.

Standardisation isn’t enough

MCP gives agents a common language to communicate in, but unless identity is unified across all actors – humans, machines and AI agents – the protocol’s benefits are moot.

Imagine an intern asking an LLM for the top ten highest-paid employees. If the LLM’s access controls aren’t tied to the same identity system as the rest of the company, there’s nothing stopping it from disclosing sensitive data. The only way to enforce meaningful guardrails is to ensure that every entity, whether human or AI, operates under a single source of truth for identity and access.

This is perhaps the most crucial element, in my view, that’s been missing from most enterprises’ security approach. Very few can confidently say they have that single source of truth on who’s who, what they’re allowed to access, from where, and when.

I would not be surprised if we start seeing startups emerge that are entirely dedicated to managing AI identities. As far as I’m concerned, they shouldn’t survive, because they would merely be contributing to the same identity fragmentation already plaguing enterprises. The much better approach is to not put AI on an island (which goes for any other technology, too). If you have AI agents operating in isolation, they’ll not only be unaware of broader access policies, but overprivileged access will persist, creating more attack surfaces.

What enterprises need is a strong, unified identity that can’t be spoofed. When you have all your identities in one place, you get a single source of truth. You can then apply access policies across all your identities — AI, cloud, servers, Kubernetes, microservices, remote desktops, databases, etc. This is what enterprises need to prioritise at a time of relentless data breaches.

Technology complexity is outpacing enterprises’ ability to secure it

I’m not saying that if you unify identities, all your complexity goes away and AI systems are forever secure. That would be irresponsible. But a lot of the complexity in securing not just AI but computing infrastructure at large goes away. The more complex the system, the greater the chance that someone will make a mistake. And when that happens, attackers are ready to exploit it.

You can see a good example of how these mistakes manifest by looking at role-based access controls (RBAC). Almost every company uses them to assign roles for groups like admins, regular users, etc. But almost every time I speak to a customer prospect, I learn that their organisation has more roles than they do employees.

Think about that. If you’re creating role groups, it’s because you want to save time on assigning privileges separately to identities. But if you have more groups than employees, you’re doing it backwards. Suddenly, you have a group for AWS access, for Kubernetes, for database access, for LLMs interacting with databases, etc. Eventually, the operational overhead will go through the roof, which means someone will make a mistake. That’s how you open yourself up to an identity-based attack. But if all your identities are in the same system, on the same level, all that complexity goes away.

Consolidate your identities

So, if you take nothing else away from this article, take this: consolidate your identities, then extend your existing investments in identity and access management to cover AI as well. You want your AI to only have privileges when they’re actively needed, and no standing access when idle.

I’d also be remiss to not mention: ditch static credentials! Luckily, our industry is starting to shift away from these and toward cryptographic authentication – TPMs, biometrics – because static secrets are a magnet for human error. If an API key or password leaks, an attacker can impersonate anyone. MCP deployments, too, must embrace this shift, eliminating standing secrets for agents and relying on strong, ephemeral authentication instead.

Consolidating identity and access is no longer optional. The cybersecurity industry keeps spitting out new solutions, and yet breaches keep trending upwards. The complexity of technology is outpacing security teams’ ability to keep up – they don’t always understand the intricacies of the technology they’re trying to protect. But consolidating identity and access controls is a good start to putting a dent in that complexity. By treating all identities the same in the same place, you won’t need to buy a new solution for each technology.

The choice is ours. Let’s not wait for headlines about the first major MCP breach to act.