Use of Model Context Protocol (MCP) has grown exponentially in the past year. Since its initial launch by Anthropic as a way to manage autonomous AI agents, MCP has become the de facto standard for connecting AI application components. With MCP, users can create AI agents that can move assets, alter data, and execute business processes – with or without human oversight. MCP relies on servers to connect and manage interaction between agents, processes, and data.

But like many developer-focused projects built to scale rapidly, MCP does not include much in the way of security out of the box. Given the kinds of data AI is often given access to, a lack of robust security can pose a massive risk – and with so much power available, MCP servers are a prime, high-risk target for threat actors.

This is a pattern we have seen before with application programming interfaces, or APIs. So, what can we learn from the ways we’ve learned to manage and harden APIs, and how can this be applied to MCP before potential threats turn into real risks?

Learning from API history

APIs have become the preferred way for developers to build their software. Using APIs, you can connect your software builds to third-party tools, or to cloud services, and create that experience faster. Using microservices, you can add more functionality into your components and APIs without taking down the entire application to achieve your goal. And from a security perspective, having those feature-rich APIs from vendors meant that you can get more data on what was happening, then use that insight to automate some of your security operations.

The logic then, with APIs, is the same as it is now with MCP servers – getting that integration to work fast makes things easier for developers. However, it also introduces new classes of risk. For example, a simple error in an application component attached to one API can affect the rest of the application, either leading to interruptions in performance or security vulnerabilities. While APIs made it faster to build, they also made it easier to scale up that mistake over time. Now, imagine this same potential risk amplified by autonomous agents acting at machine speed.

But MCP servers are not just APIs – they provide the operational backbone for agentic AI. Legacy APIs are deterministic and act in the same way time after time. MCPs don’t have that degree of control. Instead, they operate differently based on context in order to empower their large language models to take action. The protocol often assumes that both the requestor and the object requested are benign, so requests are not validated before they are acted on.

From a security perspective, this is a significant miss that can lead to unintended consequences. An attacker could trigger the MCP to leak data or move data to an unauthorised location. It could also trigger a workflow that should not be allowed, or attempt to sabotage operations altogether.

There are three security issues here: weak authentication, prompt injection, and broad authorization. In response, regulators in the EU and the US have stepped up to require organisations to address these risks directly under the auspices of both the EU AI Act and NIST’s AI Risk Management Framework. Developers should be aware that MCP security is something they will have to address sooner rather than later.

How to secure MCP deployments

To address this problem, developers and security teams must work together. The challenge is how to effectively solve these problems before deployment, but the opportunity is that any effort will improve your overall long-term approach. Doing so should reduce management overhead and simplify security over time.

To start, you must understand how to approach authentication and credential management. We all know that multi-factor authentication should be in place, but this should go one step further when it comes to MCP. Rather than using static tokens, look at how you can use short-lived tokens and credentials that rotate over time. This prevents attackers from stealing your tokens and using them for other attacks. On the security side, you should monitor for token misuse and revoke any credentials that you don’t actually need.

Permissions and access aren’t just a concern for humans, though. The biggest reason agentic AI has surged in popularity is that it can act on its own – a defining feature that opens up potential problems when the AI agents have free rein. How much are you willing to allow your systems to act independently, and how many processes will require a human to be in the loop? This is a business risk conversation rather than just one that developers should make on their own.

After defining those boundaries for agentic AI, you can look at tightening permissions around who gets to ask questions or provide prompts. Prompt injection is a proven attack approach, and attackers will use it if they can get access. To prevent this, use input validation and sanitisation at every layer. You can also route all prompt queries through a proxy to remove malicious requests before they reach the MCP server. This allows you to control all potential inputs into your system, even if you don’t have a standardised approach to follow.

You should also look at reducing permissions to control the impact of any attack getting through. If you have broad permissions and poor multi-tenancy controls, an attack will create more issues and affect more systems than one that is locked down. MCP servers have little to no standard authorisation controls in place, as this is not included in the protocol by default. As such, it’s crucial to ensure you have a robust and well-defined approach to managing access and permissions in place before you connect up any MCP server to your sensitive data.

Ensuring that security and development teams collaborate to enforce least-privilege access and role-based authorisation is critical. You should also isolate your contexts and tenants to reduce the potential impacts from any successful attack. In practice, this helps you contain any potential breach to a single workflow or user, rather than affecting your entire organisation.

Knowing you are in control

For developers, working with security teams on controls for MCP deployments is another task to add to the list. But with more and more AI application deployments happening, and so much demand for agentic AI systems, getting MCP deployments right from the start is an essential skill to develop.

Unfortunately, many of the previous static controls that worked around areas like APIs don’t work for MCP servers. Instead, your security controls have to work in real-time, just like your prompting and responses. Furthermore, your entire company will have to develop a sense of what is needed for security around AI systems. It’s not just the responsibility of the security team or you as the person who developed the application, but the whole organisation. This mindset shift helps the business innovate safely and deliver on impact.

Attacks on AI systems are already happening. From bad actors looking out for LLM service accounts that they can hijack and resell proxy access to, dubbed LLMjacking, to training data containing API keys, credentials, and user accounts that could be pillaged for access, AI systems are already under threat. As we consider how to innovate and move faster with agentic AI, we can’t underestimate its inherent risks. New standards, like MCP, should have security by design baked into them from the start – but when they don’t, other guardrails should be put in place.

As autonomous agents become inseparable from business operations, the MCP servers that run these services will be targeted. Putting in strong security principles in collaboration with security will be a necessary investment if agentic AI services are to deliver. For developers, thinking about this at the start will make your businesses more secure – and your life easier – in the long run, too.