Ricardo Goncalves - The Model Context Protocol: A Deep Dive into the New AI Security Attack Surface

This talk provides an in-depth analysis of the Model Context Protocol (MCP) attack surface and emphasizes the security challenges associated with using MCP in AI applications. The speaker discusses the architecture of MCP, detailing its components such as the MCP client and server, and highlights the vulnerabilities linked to these layers. He presents alarming statistics indicating the prevalence of insecure MCP SDKs, along with specific examples of attack scenarios, including prompt injections, tool registry poisoning, and broken authorization. The speaker stresses the importance of security measures at every layer of MCP implementation, advocating for practices like input sanitization and the principle of least privilege. By showcasing a demonstration application designed to illustrate these risks, the speaker aims to equip developers with the knowledge to safeguard their agentic applications against potential threats.

Um, thumbs up if you can hear me. Okay, great. >> [laughter] >> So, today um, I bring you a deep dive into the the model context protocol attack surface. And to that, first I would like to to understand who's familiar with with MCP. So, if you can raise your hand. Okay, good. Um, and now beyond familiarity, uh, do you use it in your daily tasks? Okay. And

on top of that, are you familiar with with the the security issues that this protocol brings? Raise your hand if you so today my goal is to give you a I would call it a glimpse of the attack surface that translate into this uh, protocol into And at the end of the day, it's ti- uh, trying to give you something to take home to when developing your

applications, agentic applications, or using MCPs to try to to make it more secure or be more conscious of the potential attack surface. these stats kind of resonates of what we what we've seen and what we uh, what I asked, which is the- there's a a rapid development of things and we are adapting to these new technologies. So, these stats are are for end last year, but uh,

from Antop- Antropic, so 97 million plus downloads per month related with MCP SDKs. And then out of these uh, um, more than 10,000 are um, are publicly available. And by being publicly available it means that they are out there. They are exposed and someone [snorts] some a threat actor can look into them and try to find some some flaws, some issues. And that brings it to the

other stats that we can see that 150 million plus out of these SDKs may be potentially vulnerable to uh, um an MCP architectural flaw. And as a consequence of it, security researchers identified that more than 200,000 of these instances are indeed vulnerable. So, this is kind of our background to go forward. And given that most of you know what MCP is, this is kind of a recap

for that. Or for those who don't know, let's bear with me. Uh so, it's kind of a protocol that will enable your AI application or agent to interact with external tools and data. So, the APIs, for example, give you the the interface, and and you will need to have to program the communication to the to the API. The agents uh just need to know the the context,

the protocol to interact with your tools. So, I'll like to drill down the components hard here. And first, we have the MCP client um that pretty much negotiates the capabilities and dispatch the calls. And then, on the other side, we have the servers. These servers expose the different tools, resources that you may use. It can be accessing file systems, databases, or even reach a reaching external service

like web and API interfaces. And those two uh talk between each other uh using JSON RPC over either STDIO or or or streamable HTTP, uh the latest uh version. And and then, we can see that servers then reach other external system access. And then, the client also needs uh a model, an LLM, to reason about and to operate within a host. And this host, you are typically

familiarized with either cloud desktop or your favorite IDE with some integrated extension. And this kind of creates this ecosystem that it's just no longer the protocol MCP, but it's this all environment where you need to care for because if there's a new environment, there's new attack surface and potentially new attacks. kind of as a recap, I like to see it as three layers, the host, kind of

the AI application that will orchestrate the the more than one MCP clients, will enforce it to some extent some security policies, and holds the kind of the global context and memory. So, the full conversation that you may have or your agent will lay here on the host section. Then the client will be the bridge between the model and the external service. Will keep one-to-one stateful sessions and

and will operate between send the host thing to the server. And then the server, where most of the potential misconfigurations may happen, it's the the components that will expose your tools, resource, and prompts via these MCP primitives. These can be either local or remote, and both can also contain risks that we should account for. So, each layer has their distinct role and functionality, and it's important to

understand where things can go wrong. So, why MCP security matters? So, this is not just another API. There are other things involved over here. So, these MCP services access private or public data, and they mix it directly within LLM prompts. And we are no longer into deterministic scenario, which in APIs it's the case. We are in something that it's more dynamic and volatile. Each question may be

answered differently. If you don't give context enough, you can get or access resource that are not uh supposed to be for you to access. So, we need to account that the security matters here. So, to to to to do these accesses, the MCP, this protocol, is kind of standardized these methods for this, but there are others, and more and more we hear about skills uh uh and

the markdowns will be with the instructions, the plugins, function callings. All of these things, in terms of threat modeling, we can look at them in in the same way. So, here I'm I'm exposing like the the attack surface or trying to glimpse over it for MCP, but when you are thinking your agentic applications, you may apply the the the same model to reason about its security aspects.

And I like to think them into three different box. So, the traditional application security risks that you are hopefully familiar with, like when you are coding, potentially you may introduce a weakness there. You may uh fail to validate the input, and then a malicious user can introduce uh a malicious interaction that will compromise your application. So, this is one of the box that I like to to

look as affecting the these all ecosystem. Another is the supply chain risks that more and more are getting trendy. So, when you are building your application, you have your first party code, but you also collect information or use libraries from from the external world. And uh it here comes the security supply chain risks. So, you also need to account for those that come without your knowledge. And

then, the third one, it's the things that can be specific to this new uh protocol, to this new technology. In this case, we are looking MCP, but it can even be uh a different thing like skills. So, they will have their specific functionalities, and as a consequence, they will have their specific risks. So, it's it's okay to think about vulnerabilities as general, but it's also better to

look at them into different boxes to see okay, where and which stage could I enforce the security to my application and ecosystem. And to that, let's go back to our diagram. And let's try to map a little bit of the So, if we start at the client level, and here it's not that the root cause it's always at the client, but the client can can suffer some

threats like identity delegations or OAuth proxy flaws. Because if you don't configure this, for example, at your MCP server, then the client will don't know exactly if something is legitimate or not and will suffer some what's called deputy confusion or identity delegations and will forward things or do things out of outside of its intended intentions. Other things like tool schema manipulation or privilege escalations, they all come

from other layers that when reach MCP client without proper configurations will put you at risk. And I'm here highlighting, for example, which of the boxes usually accounts for the root cause because then when you are look when you are focusing into making it secure, you should see okay, this I should fix it at my code level. This is at the supply chain, so I should account for

what I had into my ecosystem. This is protocol related, so I should set the secure boundaries for the protocol. So, this is why also I'm highlighting here the different points. Also, this is not an exhaustive list. It's just to give you a glimpse of the full of the attack surface. So, at the host layer, so when you are using cloud, for example, or your IDE, things can

happen. Things like the context poisoning. If you are interacting with your host, but if he's pulling data from somewhere else that was tempered, then eventually it will not do what you are asking it to do because maybe tempered. The insecure health also in fact affect this component. And at the LLM, the model layer is where threats that probably you are familiarized with such as prompt injections, which

in this case are more contextualized or inject prompt injections. And I like to think of them as like social engineering for agents because what you're trying to do is giving instructions that will manipulate the intended behavior. And in this case, affect the the layer of the models because they will be the one interpreting these cases. And then at the server level is the one that I added

more because it's usually where you you have your tools and the code for your tools. And this you have a lot of the traditional issues like the if you don't if you are calling a database and you are not preparing the statements or sanitizing the data, you will end up creating a potential SQL injection. Or if you are loading a model and you are not being careful

enough to to do it securely, you may incur into an insecure deserialization. And and and there are all these other types of things. Another that it's it's very common it's all these supply chain ones and things like if you are pulling a library into your into your ecosystem and then you for a a simple human error, you you do a typo, there are these things like typosquatting

and then you bring a library that it's not the the the official one and it's polluted and then it's game over for your application. And this is a typo. In some case, you don't even need a typo because the malicious actually compromised a trustable package. And examples like that can can connect with things like called rug pulls. In rug pull pulls, for example, a threat actor tries

to create and maintain a package and a library that that that that gains your trust. It it looks legitimate. It gains popularity. But then with time, when it gets like thousands or millions of downloads, this person, which is not a trustable maintainer, but you think it it is, changes something in the library, make it vulnerable, and then again your your whole ecosystem and and and and application

will be compromised. So, all of these different threats are are very important to have in mind when developing agentic and AI applications and specific specifically using the the the model context protocol. this is mainly the theory, and I like the the thing I see that best translate and resonates is to us is to also trying to see it in action in practice. So, to that I I

I kind of develop a an application that it's it's vulnerable and is a an MCP server application. And and here from now on, I will guide you through to three main scenarios where where it will showcase you what can go wrong in your in your AI architecture application that uses MCPs. So, this application it's um it's like an event system, if you are familiar with, but it's

for for security teams. So, if you if you know what a SOC team is, a security operation center, they they have these these applications that they see the security events, and if something it's wrong, they can investigate it further. So, this is kind of in a nutshell what I configured for for this demo application. And here it it also and as uses the two protocols available, it

can operate via stdio or HTTP, and it tried to be realistic enough for educational purpose. So, we can use it in in in two modes. The The first mode using like the web application interface that will serve as your MCP client. And then this application will communicate to your MCP server and do all the interaction. It will call the tools that will search for cases, notes, files,

and all of that. This is convenient because it's it's easier for us to watch and understand what's what's the the the the use case. Another case it's using it agentic. So, you have your cloth or your agent IDE, and and then you connect it to the MCP server and use the stdio to to get the same thing. So, instead of using the UI and see all the

cases, you just use your your your desktop application, it will connect and will bring all the tools available. Two different modes, but the two represent different potential issues. So, in the first case that I'm going to to show you here, it's uh >> [clears throat] >> it's a prompt-driven prompt injection that then ultimately will um become an unintended tool call and potentially generate data exfiltration. we can

see here the application. So, this is the UI. It's um um event management system. And in here, we have the the the a case a specific case that contains an event that the analyst is investigating, and there's all these notes. And within these notes, there's one that it's malicious, the second one that says execute this this tool call, which will read the files from a specific location

that it shouldn't. But the analyst, when going over all the cases, may miss this thing, or in a realistic it will be just so many nodes or we can even use techniques to to do not expose it. So, it will miss potentially this thing. So, what happens is that okay is is working and then wants to do the agent call by running a task. So, he puts

okay summarize me the case and when the the agent is going to call the MCP and do this operation, we will see will do the tool call as expected. But then will between the legitimate answer that summarizes the case, we will also see it it shows the content of the file. So, this is a confidential sensitive file and we can see that this file it's in it's

in the server side and shouldn't be accept accessed by the the application. So, a compromised node in this case when an agent tries to do a task, it will unwillingly do this operation and will be exfiltrating information to some place. In this case, I'm just showing you that the information can be accessed. Other techniques could be applied to exfiltrate the information. So, this is this is kind

of the the tool driven prompt injection that I like to see it as impacting both application security and MCP related issues. And you >> the attack as we saw had a malicious note. Then then innocent looking agent task is triggered. Then the server call this tool and then the output is injected into the LLM prompt and the information gets exfiltrated. So, how do we kind of defend

about this this case? There are different layers that we can look at. So, for the when attacker adds a note or the innocent looking agent task is triggered, we should treat all the user-supplied content as untrusted. So, similar as in traditional security where you don't trust input and you apply sanitization, in this case, you do you should treat the the user inputs that goes into notes similar.

You should not trust them and separate them that what's go to the actual agent instruction. That way, when the when the things are combined, they will not be interpreted as being a agent task, but will be something outside and should not be executed. Then, when the server calls this this tool, that's another issue. It's more architectural in this particular application because you should not embed the the

input of the note directly into the tool call. It's not It's not the best architecture at all. So, in this case, you should avoid using it like that and and just call specific authorized uh tool calls instead of direct user input. And then, at the output part, this is a traditional security issue, which is a path traversal. So, you should make sure that you do not allow

the the application to go outside of your defined boundaries. So, if your application should only access the documents files, you should not go to the other roots within your your system. So, those are those are kind of the the ground rules for this case. There are additional controls that should be headed in place like logging all your tool calls and implement human in the loop to validate

any of of these things. Another example here is the tool registry poisoning because in MCP, you you you give the protocol to communicate with the different tools. So, if a tool is poisoned, then it's it's an issue because you your your agent will operate with the with untrusted and malicious, and that's not good. So, in this case, I again, I represent a chain to better show you

how potentially could be poisoned a tool which starts in this case by a cross-site request forgery. Uh and then it will inject it and and will manipulate the tool. So, in this case, we have um a user that is navigating their Uh and then they receive uh either via social engineering a link um something uh that that that calls their attention and looks related with their day-to-day

tasks. Uh and that it's the Uh and that it's this this site over here. So, he navigates to this site, which is pretty similar to the the traditional application. And and the moment they navigate to this site and and and and they try to even understand or review the case, they were already compromised. For the sake of the demo for of of the demo, I'll I'll make

them click the the open thing. But you don't even need to click because if you are going to the untrusted site, and if you are vulnerable to the cross request cross-site request forgery, you will be compromising your application. So, in this case then, he navigates back to the application, goes to the register tools, and then you we can see here this register tool that it wasn't created

by by this person. It was created by a malicious user. So, what's the problem here? So, the problem is that with this chain of vulnerabilities, we are introducing poison tools. And then when you are using your your agent to communicate with the tools that are available, he will have this untrusted tool. And then you can do with it whatever you want. You can make it execute code,

you can make it look for sensitive files. So, everything can go wrong. So, the the tool poisoning it's really um a thing that should be accounted for and validated. So, this just summarize what we just saw. The victim visit attacker sends the post request, the tool is poisoned, and then when you are trying to negotiate this capability, you are negotiating a a compromised and poisoned capability. how

to defend this case? So, as as I explain you, there's this CSRF thing, the cross-site request forgery that I used just to to show better the impact, and you should of course in this case mitigate the cross-site request forgery by implementing the tokens that validate the the the trustability of the request. So, all the state-changing requests should have these tokens. Uh but then, for the actual poisoning,

you should make sure that you don't put tool registry in in functions available for any user. So, it should be restricted between specific Uh hold on. Okay. Should be restricted between um between authenticated endpoints. And and the LLM should follow the instructions that you define properly to to avoid untrusted input. So, other things as I remember mentioned before, it's that audit logs and and all of So,

the the last example I have, it's it's the a broken authorization case, broken object level authorization or insecure direct object reference. And here, we are operating in the mode where we are using cloth to communicate with our application. And as you can see, this user as these four cases, and then it asks the the agent to list its own cases. And we can see it responds correctly.

But then, if you also ask the agent to display all the other all the other cases it will give you all the other cases. So this shows that you did not correctly implemented your your authorization things and and the agent will give you back everything. You can then even try to to delete other user cases and this is a a very interesting detail which in this first

example that I show you you asked to okay can we delete the case and then the cloud says that it's not something that is intended and you ask it to proceed. You say yes and it says that >> it's not authorized so I will not do it. And this is happening because the the the model was able to understand the context and and understand that this is

not an authorized action. But this is scenario A. So in scenario B what can happen and I'm skipping the the scenario is that instead of start by asking to list my my cases we will do something different which is starting by asking to list all the cases available in the application. And so the the agent will do that will list you all the cases and then you

following that narrative you will ask okay now delete me case X and Y. So it will delete the cases because in this case for the agent the context that you are giving to him it's that uh it's it's kind of acceptable to ask all cases not do only the ones allowed by and because it assumes that as something trustworthy will then do the execution action of deleting

other cases. So never trust only the judgment of the model because again prompt injections and context manipulation will result into manipulating their behavior. So this is >> kind of the summary of the scenario B that similar that in A but instead of asking first list me all my own cases, you said list all the cases and everything changed completely and the agent will give you everything. So,

different uh questions, uh different outputs. The difference for this, so you we have here the authorization issue. So, you should make sure that you enforce for all the object level authorizations that you validate the ownership. So, if you want to list all cases, you should make sure that these cases are only listed for your your for the users that should access them. Uh and then for the

LLM used as the only authorization gate, we saw that that's not that should not be the case. So, never rely on the LLM for the sole access control decisions and make sure that you apply in the server side. Additional things could be again to to log all data review and apply ownership and all of those things. So, the control surface has shifted as and so what what

changed specifically? So, we can look at inputs, um actors and trust. Uh I'm about to finish. Yeah. Uh and and the inputs have expanded the the scope. Now, we have the tool outputs, the fetch content and no longer just the user output. The actors no longer are deterministic, it's the agents. So, things can change and the trust now it's cannot be delegated to the models alone. So,

the same principles that we had before should be applied now but to this new attack surface. Make sure you inventory everything, you evaluate the security of this new scope, you manage uh all the sessions and you monitor everything. So, the attack surface changed but the principles did not. So, I'll bring you with this last with this last slide which is defense patterns that you should use when

implementing. So, never trust input same as before. Use the concept of least privilege, ensure that the MCP only does the least privilege things first and then scale from there. And then apply things like secret hygiene, schema and config integrity, and monitor and audit everything. So, thank you for your time. Um I'll be available in case of any questions and to dive deep in any specific details. Thank

you.