In this post I want to share some insights gleaned from an enlightening conversation between Scott Clinton, Jason Ross, Akram Sheriff, Ophir Dror, and Or Oxenberg regarding the security implications of agentic systems that leverage Model Context Protocol (MCP).

This post is a summary of their conversation, you can find the entire webinar here which was hosted by the OWASP GenAI Security Project.

What is Agentic? What role does MCP play?

At a high level, agentic systems are software systems that use AI to pursue some goal by completing tasks. Unlike traditional LLM systems they have the ability to reason, plan, and have some memory component. Think of the traditional LLM as the brain and the agentic architecture as the body - allowing systems to think, act, memorize, and enable more sophisticated operations.

MCP is a standardized way for agents to communicate and connect with external data sources - you can think of it as a unified abstraction layer to connect agentic flows to real world data. In the same way that an API allows developers to interact with systems, MCP allows agents to interact with systems in the new era of agentic workflows.

MCP can also be used in a multi-agent system, allowing agents to interact with each other and share contextual data/tools/resources that enable real-time agentic workflows. In this way, agents can be used as tools in the world of MCP - though we haven’t seen a lot of this yet in production. We’re still in the early stage where people are figuring out how to connect it to data and resources. But this is far from its final evolution - agents as tools will enable very complex and powerful ecosystems.

The challenges of non-determinism

The most glaring problem from a security perspective is that these systems are inherently non-deterministic. We’re used to thinking about application security in a static world where we can review the code and approve a golden image that we know is going to be the same in production. MCP is the exact opposite. It’s highly dynamic. Agentic decision-making inherently means you don’t know what tools are going to be called at runtime.

In the security world, a non-deterministic security control is a BIG no-no. However, that’s the reality of agentic AI, and MCP in particular, in its current form. We’re essentially saying “hey LLM you are now our security control figure out what makes sense” while it has access to all our critical infrastructure.

Can we just apply the same approaches to MCP as we do APIs?

Traditional API security is applicable for a deterministic API workflow. In this system we have well defined endpoints, authorization specifications, and dataflow that can be reliably assumed by a developer. With MCP all of this goes away. The developer would not know ahead of time which resources are being accessed or which specific tool calls will be executed.

There are some agentic tools which are purely API based, and for these specific tools you can leverage existing methods like fingerprinting or heatmap based analysis. But this only solves 30% of the problem. The other 70% lives in the agentic tool functionality that is achieved via Python decorator functions within the MCP implementation. Existing API security solutions are not applicable here.

The LLM uses the tool descriptions, tool schemas, and contextual nature of the incoming language prompt to decide which tool to use. Since the developer would not know ahead of time which agentic tool will be invoked at any given time, you need custom MCP based security solutions which can address real-time agentic tool calls which the LLMs are invoking themselves.

Industry must recognize that there is real up front cost associated with developing this 70% solution.

Agentic systems introduce brand new attack surfaces

With all the hype around agentic systems, industry is rushing to implement solutions immediately and everywhere without truly understanding what the risks are. Everything about this domain is so new, especially MCP. At a high level, MCP is a dumpster fire from a security point of view. You’re taking the worst of AI and software development and merging them together in a shiny new wrapper that everyone wants to use. In reality, leveraging agentic systems and MCP means the erasure of the production boundary. Your boundary becomes whatever someone decides to put in their MCP server implementation. Whether that’s a remote server, some tool they’re running locally - whatever it may be. Securing this kind of environment is almost impossible.

On top of this, MCP at its core is just Python code so you’re not able to leverage most existing tooling like EDR. You’re not able to point to a malicious binary as the source of your problems. Moreso it’s just language, and what does input sanitization look like when the exploit is enveloped in natural language? It’s a really difficult problem to solve.

New attacks require new solutions and broader awareness

If you take the first generation of LLM based applications back in 2023, most of the security concerns could be solved by using an AI firewall. If there is a prompt manipulation or prompt poisoning related attack then you can have some kind of workflow which can detect and apply remediation either at the input layer or the output layer in order to solve the problem.

With agentic design patterns you have tools, short-term memory, and then the LLM call which is just one component within the entirety of the agentic runtime. The existing AI firewall related products/solutions are not applicable to solving these agentic related security problems. There might be some overlap for basic use cases, but when it comes to real-time autonomous agentic workflows (which is where its true power lies), the current products cannot address these gaps.

MCP touches many different layers from application to presentation to network to transport. Building out a comprehensive full-stack approach might be a viable method of security and there are people working on preventing agentic-related security attacks at runtime from this perspective.

While building new solutions and implementing better security measures within MCP are good, they’re nothing if nobody knows how and when to use them. Awareness in this domain is key to effective security. For example, say you’re super security oriented and you’ve done an in depth review of the MCP code. You’ve determined that the code is doing exactly what you want it to do and you approve it for use. Three days later that server gets compromised. The attacker changes the tool descriptions and does some prompt injection on it. Most people aren’t going back and checking for changes in their tool descriptions. That’s a new problem for the security community. One that can only be addressed if you have a greater awareness of the MCP protocol and your specific implementation.

Best practices are going to look different depending on if your concern is users consuming MCP servers in their tooling (something like cursor) or if you’re a developer who’s implementing a system that allows your users to leverage MCP servers. Both of these scenarios have concerns with the security tooling changing underneath the platform, which is a new novel attack scenario that MCP has introduced. Right now there is no existing tooling that, once added to the server, notifies you if the tooling changes or if the tool descriptions change. The protocol itself has a mechanism that allows the server to send a signal that indicates the tooling has changed but it’s on the server to implement the notification and it’s on the client to do something with that notification if it’s received.

There are many facets to security in the new era of agentic systems. For instance, your agentic tooling needs to have precise and clear documentation. Within agentic tool calls there’s something called a docstring - the LLM looks into these docstrings and makes a decision as to which particular agentic tool caller to use at runtime. Developers must be aware of the heightened degree of complexity this introduces. You not only have to evaluate the docstrings of the MCP server you’re planning to integrate, but also the docstrings of every other MCP server you’ve already installed and think about which tools the agent will call if there is an overlap in the descriptions.

It’s important to be aware that although the protocol supports security measures, they aren’t necessarily built into existing tooling. If you’re in the process of developing these tools its incumbent upon you to make sure you’re implementing proper security measures. Something like hashing the tool descriptions to check for changes, or if the server is sending a notification that the tooling has changed - you’re handling it correctly and prompting the user to confirm continuity of the workflow given the tool change.

Education about these techniques and capabilities for agentic systems is essential if we want to create more trust in the protocol and community solutions. There is plenty of room for more thought leadership and people should understand that the problems we are facing in this domain are vastly different from what we’ve been accustomed to so far. Traditional methods like API based security and supply chain security are not enough anymore.

Conclusion

It’s too early for generalized best practices specifically for MCP, but for agentic systems as a whole the basics remain the same. At minimum you should have exceptional visibility into the system. Being able to monitor and see how people are using the system is very important. It can give you good intuition about what kinds of risks you are facing. Traditional security concepts such as IAM, zero trust, detection and response, and sandboxing are still just as important.

It is important to recognize that the space is still very new and the security tooling has not caught up to the pace of innovation. We don’t have clear answers on how to properly secure these systems yet. If you’re going to implement agentic systems, it’s imperative you go in with your eyes open and be critically aware that we don’t understand all the risks right now.

However there are still things we can do to protect ourselves and our businesses. Things like sandboxing, using validated and trusted community servers, implementing open-source scanning tools that can protect you from things like invisible Unicode attacks, basic security principles, etc. are still a solid foundation for building comprehensive security around this emerging domain.

The OWASP GenAI Security Project recently released their updated guide for securing agentic applications, definitely recommend checking it out here

Thanks for reading, see ya in the next one :)