It’s been a year since Anthropic launched Model Context Protocol (MCP), an emerging open source standard that facilitates the connection of AI agents to numerous data sources and tools. Prior to MCP, those connections needed to be coded with LLM-specific frameworks, a resource intensive and costly exercise, so the standard has significantly contributed to the adoption by enabling MCP clients i.e. LLMs to connect with MCP servers, of which there are now thousands. To mark its first anniversary, Anthropic bequeathed the standard to the Agentic AI Foundation (AAIF), which falls under the remit of the Linux Foundation, ensuring it will remain available to all, but the past year has had some rocky moments, fraught with issues that threatened to undermine the standard.

As with any emergent technology, MCP has its fallibilities. Security researchers have put the standard through its paces, probing real world deployments to look for vulnerabilities and they certainly found them. Security flaws that have been discovered include remote command execution (RCE), path traversal and file system exposure, as well as gaps in authorisation and authentication.

Back in June, it was discovered that approximately half of the 15,000 MCP servers analysedwere misconfigured and that the most common issue was the ‘Neighbor Jack’ vulnerability. This saw those servers affected bound to all network interfaces, enabling anyone on the same network to access and potentially run the tools or operations via that server. Other servers were found to allowed arbitrary code execution due to careless use of subprocess, lack of input sanitisation or path traversal. And servers affected by both issues would enable an attacker to access and control not just the server but also the host user’s machine.

That same month, Asana, a project and task management SaaS platform, disclosed a cross-tenant flaw affecting the MCP server it had stood up in May. The flaw meant data was potentially exposed among those users who were accessing the same data type, prompting the company to recommend admins review Asana logs to see if they contained any data from another organisation and to report this.

Anthropic suffers issues

Issues then started to be identified in Anthropic’s own tools and servers. In June, its MCP Inspector, a developer tool for testing and debugging MCP servers, was found to be vulnerable to RCE. Then in July, mcp-remote, a tool that acts as a proxy connecting LLMs to connect via MCP clients to MCP servers, was found to allow arbitrary operating system commands. And in August, two CVE’s were disclosed pertaining to its Filesystem MCP Server. Dubbed EscapeRoute, the first CVE bypassed directory containment so that an attacker could use the AI to access directories using the same file path while the second CVE would have allowed an attacker to break free of the MCP server’s sandbox entirely and toread or write to anywhere in the filesystem.

In September, a CVE affecting the Cherry Studio MCP client was disclosed followed by a misconfiguration of the Smithery.ai MCP hosting service in October. This path traversal flawexposed 3,000 MCP servers and if exploited would have enabled the theft of API keys and secrets from thousands of customers. If exploited, the Smithery.ai would have become the first AI supply chain attack, according to the researchers.

What then became clear is that attackers don’t necessarily need to attack the MCP server at all. If the server is associated with a trusted brand, the attacker can simply stand-up a server pretending to be from that organisation, attract users and subvert the server to access their systems.

We saw this in September when an impostor Postmark MCP server hosted on npm (the legitimate project is on GitHub) was used to carry out the first known instance of a malicious MCP attack. The attackers released 15 legitimate versions of the rogue server before then installing a backdoor on the final version. The fake server was then used to steal user emails by BCCing these to an external server.

The attack served to highlight the need to verify the authenticity of the MCP server that the user or organisation is connecting to, as well as why it’s imperative that the organisation has access to a registry of trusted MCP servers. It also illustrates the need for agent validation and agentic AI architectures that adhere to zero trust principles. All too often, organisations are deploying AI projects without considering proper authentication, effectively blowing holes in their zero trust architectures.

The call to secure MCP

Then, in November, Anthropic announced it had observed the first example of an AI-orchestrated attack via MCP. Contentious because of the lack of detail it contained, the reportnonetheless showed how MCP had been subverted and used to attempt to infiltrate approximately thirty companies globally and saw Anthropic make a call to arms with respect to threat sharing, improving detection and stronger safety controls.

Defending against these attacks won’t be simple, however. That’s because the fundamental problem with MCP servers is that they are treated as a trusted conduit by LLMs with no checks or balances in place to verify outputs or validate permissions. The servers themselves typically lack authentication, rate limiting, or even audit trails. They don’t appear on asset inventories or risk assessments, and they skip security controls such as Data Loss Prevention (DLP) and email gateways. Yet they’re given direct access to sensitive data, allowing AI agents to call Application Programming Interfaces (APIs) to access documents from file systems or query databases, for example. So, if they’re compromised, they effectively hand over the keys to the kingdom.

The top priorities for securing MCP therefore have to be identity management and the authentication of everything, controlling the scope of MCP clients and servers to prevent overreach, and continuous monitoring and anomaly detection, so that every call is logged and unusual activity is flagged. But we can’t simply use the security tools we already have for this, which begs the question how can we police these exchanges, particularly given that many will be made autonomously in the future?

If we look to how applications and APIs are protected and the security issues unique to these, MCP shares many of the same challenges. MCP servers are similar in that it’s their vulnerabilities that potentially pose the greatest threat. Security tooling will typically scan for XSS or SQL attacks so will miss the behavioural indicators that show a server is performing tasks outside those expected. So, any security monitoring of AI traffic needs to use behavioural processing to look for anomalies and suspicious activity.

The new AI Gateway

This is just how application and API traffic is protected today, which means we can use what we know works for application/API security and use a similar approach with respect to MCP. Monitoring requires a proxy through which the traffic can flow and the concept of an ‘AI Gateway’ makes the ideal vehicle for this. However, next generation Gateways do more than act as a funnel for centralising workflows. It’s possible to create and stand up MCP servers as well as to maintain control and visibility over connections to third party or customer MCP servers, for example.

As the Gateway acts as a centralised form of management, it can also enforce network policies across all MCP endpoints. Enterprise-grade authentication and authorisation such as OAuth 2.0 can be used to ensure that access to systems and data is identity-based, preventing unauthorised access by AI agents.

In addition, admins can define allow and blocklists that only allow MCP access from specified IP ranges which, enabling the organisation to avoid rogue servers. This feature, when coupled with the zero trust principles followed by the AI Gateway (e.g., continuous authentication and authorisation) can also ensure only authorised users and agents are able toaccess the AI Gateway and connected MCP servers. Furthermore, if the AI Gateway were to automatically lock authenticated sessions to the originating IP address, this can prevent token theft and unauthorised reuse. So, if OAuth tokens were stolen and their use was attempted to bypass security controls they’d be blocked.

And finally, detecting whether or not AI exchanges are malicious is also going to be crucial as MCP use gathers pace. Monitoring and logging all AI-application interactions via the Gateway can allow the organisation to see which users and agents are interacting with applications and their actions, analyze behavior, and look for indications of business logic abuse, fraud or AI attacks against MCP clients or servers.

Therefore, protecting MCP doesn’t require us to reinvent the wheel. By applying many of the lessons we’ve learnt when securing applications and APIs, we can tame this new protocol and create a safe and secure ecosystem which doesn’t expose our data and systems. But crucially we can also guard against the threat of tomorrow, which is the prospect of abuse or attacks orchestrated by fully autonomous agentic AI.