Name: Lessons from the Front-line: What Research Reveals about MCP Security
Uploaded: 2025-08-28T17:30:05.777Z
Duration: 34 min 32 s
Description: Lessons from the Front-line: What Research Reveals about MCP Security

Transcript for "Lessons from the Front-line: What Research Reveals about MCP Security": Hello, everyone, and a huge welcome to, our webinar today, what research reveals about MCP security. I'm Ziad Ghaloeb, the senior product marketing engineer here at Wiz, and, I'll be your host. We've got an incredibly, important topic to cover, and it's, timely to do it, especially for people, that are on cloud security, app security, and engineering teams. We're also joined by fantastic experts today, Rami McCarthy, who's a security researcher at Wiz. I'm sure you've seen his, avatar and name on some of our, bespoke research and and blog posts. And also, Andre Elizondo, principal solutions engineer at Wiz, who brings a wealth of experience with customers and AI adoption. So please, join me, and let's get started. So let's take a quick look first at our agenda for today. It's going to be packed. So for the next thirty minutes or so, first up, we're going to cover, what x MCP is. I'll briefly explain the protocol, even though I understand, none of us here live under a rock. But we'll see why it matters for cloud security engineers and also share some clear examples of how organizations are leveraging MCP today. Then we'll shift gears together and, talk about MCP security risks and cloud environments with, Rami and Andre. They will, guide us through how this technology is introducing some, familiar, old vulnerabilities, but also they will share some state of the art research and findings. And we will also discuss some of the recent MCP spec changes and what are the implications of these spec changes. And, lastly, we'll make sure to look at the future of MCP security and arm you with some practical guidance and key takeaways to secure your AI initiatives. So brief introduction, to what MCP is and why this piece of technology is very significant today. So it's this open, standard that is introduced by Anthropic, and it's quickly become the go to, for connecting large language models to external data sources and tools. Think of this as a bridge that allows AI applications to interact in a very seamless way with your enterprise databases, your APIs, and critical infrastructure. Now why does MCP matter specifically to cloud security, app security, and, all sorts of security engineers? Well, it's creating direct pathways between your AI model and your enterprise resources. So this is eliminating some of the traditional security boundaries that rely on isolation, and means that maybe a single compromised MCP server could give threat actors access to multiple enterprise systems at once. We also see that many MCP implementations actually require elevated privileges. They routinely handle sensitive data operations like, customer database queries or infrastructure commands, which can make them high value targets. So, we really ought to treat these MCP servers with the care they deserve, and as privileged and high components inside, our our stack. So, to give you a tangible example of MCP in action, let's talk about the, Wiz MCP that we recently introduced. We built our own server to enhance our security offering and, essentially delivering value in three key pillars. First of all, we have a unified security data source that can be queried, and we have cloud visibility through the MCB server and also contextual intelligence when it comes to investigating threats. So this allows customers at Wiz to essentially ask, posture questions in natural language, getting instant insights on the inventory or the cloud estate, exposure, or toxic combinations within the environment. And data sensitivity across the entire environment and workloads. Another use case that it also unlocks is helping fix code issues right from their IDE by translating some plain language queries into powerful AI generated fixes. And, of course, these fixes, are based on the context that we pull pull from the Wiz back end, where we have more details about the issue and the risk so that we can craft a, custom or a tailor pull request for the developers to remediate the risk. And lastly, we also have another use case, which is accelerating threat triage investigation. So here, we are helping security teams actually identify and contain active threats faster with AI generated insights and action paths thanks to the, Wiz MCP server. We can see a very quick example of how this looks like here. So typically, we're looking at the first use case here where we're asking posture questions. The first thing we want to do is see if we have any virtual machines with a MongoDB, technology or database attached. So the WizMCP, server helps us query the WIS security graph, which contains all this information about our cloud estate and, environment. And then we can ask if these instances have any Internet exposure. So this will be turned into a, query for the security graph. And once this query is executed, it will return examples here of virtual machines that have Internet exposure and, hosted MongoDB, servers. We have our first results here. And now we're checking whether any of these Mongo databases have actually sensitive data in them. So again, turning all these natural language questions into complex queries against the security graph and returning these results. So in this case, we didn't have the first, hit for sensitive data, but we see that there's a VM here that has a high data risk score and also contains sensitive data while being exposed to the Internet. And security engineers can then create a full summary of these issues and findings so that they can share with other teams or turn into, reports. Great. Now we have our full report here. So this is just an example of what the Wiz MCP server can help us accomplish. We also have examples of companies today using the Wiz MCP server in production. I can take the Grammarly example for which we have a a case study on on the Wiz website. So Grammarly leverages the WizMCP server to automate security and threat investigation at scale. First of all, it helps them focus on those tier one incident triage operations and help them cut investigation time from thirty to forty five minutes to just about four minutes per ticket. So that's nearly a, 90% efficiency boost here, and freeing engineers from routine monitoring and allowing them to focus on more strategic planning and innovation in in this case. Great. I will invite both my, speakers to to join me. Please, Rami and Andre. Hello. Hello. Hello. Hello. Perfect. Thank you for joining us. So, now let's get into, like, the nitty gritty details of of MCP security risks. This is a new technology, but, as we said in the introduction, we're seeing some of the many old flaws and and vulnerabilities, and MCP is echoing patterns we've encountered before. Can you maybe give us, like, a few examples of that based on your, research and experiences? Sure. I can hop in here first. Good to be with everyone today. I think what you said about MCP echoing old risks is, more than half of the equation. And so when I talk about MCP security, what we're seeing with customers, that's saying Andre will be able to speak to as well, is that, there's a mix of this innovation introducing more occurrences more commonly the same problems we've seen previously while also having a few things that are specific to MCP, and that are net new with this technology and introducing novel risk. And so on the, same old same old side, I think it's really interesting and important to pattern match MCP to past technology innovation waves. We saw this with mobile. We saw this with cloud. We're seeing it with AI. When we release MCP, we're seeing supply chain problems that reflect what we've seen historically. We're seeing problems with Internet exposed software that should be kept private that we've seen historically. We're seeing problems with not controlling access to data, not managing identities. All of the security domains that you're already paying attention to are getting increasingly motivated by the risks of MCP. And then we can also look at the novel risk side, and that's where you start to talk about, like, MCP protocol specific attacks, specification vulnerabilities, risks around tool poisoning, rug pulling. There are all these new terms that are being introduced that are variants on, historic vulnerabilities. So in the past, we had SQL. We had SQL injection where, an attacker was able to introduce, code through, an avenue they controlled. And with MCP, we're seeing the same thing where we're seeing command injection vulnerabilities through MCP servers. We're seeing SQL injection vulnerabilities through MCP servers, and then we're also seeing injection of tools and prompts that are much more native. To to sort of point to concrete examples, on the, old risk side, we can look at how application security stays the same. If you are building and serving an MCP server to customers like Wiz does, you have to consider classic application security risks. And one case that popped up early was actually Asana had an MCP vulnerability when they initially launched, and they were quick to market, quick to remediate here. But when they launched, they actually had a very traditional application security issue around caching that had nothing to do with MCP as a protocol. But I think we can see that when you're launching these, new tools and technologies, you have increased surface for risk. Another case would be public exposure of MCP servers inadvertently. There was some research done, that found, I think, around 400 servers put on the Internet without authentication. So these are MCP servers doing everything from allowing access to databases to interfacing with SaaS platforms, a lot of things tied to customer relationship management systems. We've done similar research internally and and worked with customers on this problem space and, have seen numerous cases where MCP is being deployed outside of the internal enclave you wanna have it in. And this is servers, portals, and gateways placed directly on the Internet. Because MCP is such an interoperable system, it means you're often tied into other sensitive data. You're often tied into other sensitive applications. And, frankly, because of how MCP is being rapidly built up, there's a desire to expose ways to customize MCP, add tools. And so what I've also seen is that some of these MCP systems that are being launched come with remote code execution baked in because it wants to let you use Python to define a new tool, for example. And so what we're seeing is we're seeing supply chain risks. We're seeing application security risks. We're seeing things being put on the Internet that shouldn't. That's all old news. And then simultaneously, we've seen a rash of prompt injections, whether indirect or direct, as well as, some maybe research oriented developments around how tools are are secured and managed that we might speak to a bit later. I think I wanna while I pause there and sort of pass it to Andre who who talks a lot with our customers about this and and sort of hear what he's been hearing from customers, and seeing day to day, to balance out my maybe research oriented perspective. No. I think you're you're very much, spot on, Rami. I think what we see a lot of is, you know, one, MCP emerged pretty much overnight for a lot of security teams. And so, even just understanding where MCP is, being used directly, like, teams are building their own MCP servers, but even more importantly, external adoption of either kind of known or community based, MCP servers. There's a there's a wide range of of trust and and basically understanding where those came from, how do they enter into the environment. So I think that, teams are really seeing the benefits of MCP in their own workflows like we saw with Grammarly. But they're also really starting to wake up to a lot of these core security problems of everything from, trust, exposure, vulnerabilities, a lot of the old problems, but then really just with a a a heightened sense of urgency there. And, you know, I think there is also something to be something to be focused on, which is that, you know, Rami, since we initially came out with that research blog post, the the ecosystem, the spec, there's been a lot of different changes for MCP. So, you know, we're we're seeing things like, hey. There's been a a revision in the spec since then, where now we have the ability to, actually utilize MCP, with our own identity systems. It it, kinda clarify the, the workflow for utilizing OAuth with MCP, which is great. It really enables teams to use, you know, some of their existing IDPs. But I think what that's also done is really, widen the the adoption even further and and really, it's it's stabilized the protocol where now we have more consistent tool calls. We have kind of some some basic reliability things built into the protocol more and more now. But I think what what's interesting there is, you know, we've also seen more and more of, an expansion in the ecosystem to look at, okay, now we have agents that can call tools. MCP makes that really easy. So what happens when we start thinking about multiple agent interactions? And I think that's where we start to see, you know, a big focus on what's next past MCP with things like h two a. And then also since MCP can handle things like OAuth now, we're starting to see more and more of an emergence of remote MCP servers, originating from vendors. Right? So instead of having to trust the MCP server, you setting it up, you hosting it, you care and feeding it, you know, those remote MCP servers really help to solve, part of that problem in a in a particular way. I think that the other thing that we're starting to see more and more of in the ecosystem, in addition to, things like multi agent systems and remote MCP servers is there's a rising interest in utilizing things like MCP proxies or MCP gateways as a way to, standardize or secure adoption of MCP. And, maybe we can go ahead and oh, go ahead, Ziad. Sorry, Andre. I I I had a quick question for you too. So we're seeing this, ecosystem of MCP clients and and servers emerge almost equal to, open source packages, you know, coding, libraries. Are we also seeing the same, supply chain risks with typosquadding or maybe MCP naming confusion, also spreads to the MCP ecosystem, or is it still too early for that? Is it is it happening? Yeah. I can I can start? I think we're seeing a lot of research and a lot of proof of concept and, examples that demonstrate that it's certainly viable. However, there aren't a lot of examples that come to mind of actual attacker exploitation of, you know, tool oriented attacks, whether that's, tool poisoning, rug pulling, line jumping, whatever you wanna call it. I think we haven't really seen that in the wild. If I had to hazard a guess, I would I would pause that there's a lot of low hanging fruit for attackers. And while we've seen attackers lean on AI to power their attacks already, there was a great report from Anthropic just today or yesterday on that. We have less so seen AI internals targeted and much more so AI systems. And, like, this is the the classic, Wiz View on security is that, a lot of your security is actually about your systems and how they interconnect into relay, then it's where Wiz got toxic combinations from. And I think with AI, we've seen a lot of attacks focused on how you're managing the underlying infrastructure, how your AI systems connect to your non AI systems, and how you're governing all of that. And less so we've seen, you know, even on the classic, m, like, ML side of things, we see a lot of interesting research on model poisoning and and attacks on models. We see far fewer real world examples. And so to date, the attacks have focused more on those supply chain issues that maybe are easier to model after MPM style attacks for attackers and less so in my, from my vantage point at least on the internals of, you know, MCP spec and tooling. But Andre Elizondo, I don't know if you've if you've seen differently or have an example to mind. Yeah. I think there's definitely a a hype a heightened awareness of the problems like typosquatting or even just understanding, you know, hey. If I'm using the Jira MCP server, is that actually the Jira MCP server? Like, there's, there's not really a a great way currently, and I think that's where the community is expanding more into. But just like a centralized registry or a way to kinda validate which ones are, trusted, you know, which ones have, you know, kind of a a known origin. And so I think that's a that's a, definitely a big risk in the ecosystem right now is really just, those types of problems that do originate with just traditional, you know, supply chain concerns or just traditional software. They're you know, MCP is not immune to that, and so, I think that's where, you know, we we really have to be cautious and and use kind of a a a heightened sense of awareness that we have right now with the urgency around MCP to really kinda think about how do we safely adopt, how do we safely expose, how do we safely enable teams to, use MCP as securely as early as as possible there. Awesome. I guess we should, maybe hop to the next slide and and talk about some of the things that have merged more recently. Yep. Great. So, yeah, wondering, like, what has changed, in the specs since we last wrote our MCP research briefing. Andre, you started talking about the authentication, specs, but was was there anything else, like, major changes that, you see have improved posture and can help, adoption accelerate for MCP servers today? Besides the the focus around OAuth and and remote MCP servers, I think that's you know, the the OAuth, improvements there in the last revision have have definitely benefited. I think just, you know, making it easier to run those remote MCP servers like I mentioned before, I think that's also kinda where, even just some of the, not not just the last spec revision, but even right before that with, introducing h HTTP streaming and, making it a little bit easier to, run MCP servers in a kind of a shared model. I think we're we're starting to see more of that where, hey. And instead of MCP just being, that kinda sidecar process running over standard IO, you know, there's a lot of benefits in being able to host that as, you know, a web server as a as a shared tool that can be consumed by, maybe a lot of different agents if that's a common functionality, or we wanna be able to just build that and ship that once and host that and scale that. But, obviously, with that, the the changes in the spec make it easier to, you know, have kind of a reliable interaction over things like HTTP streaming. And then with OAuth, now we can kinda handle some of the identity components there. But I think one of the one of the challenges we'll we'll probably talk about this more, going forward. But, you know, when we see things like, what's been solved so far with OAuth and what's been so, solved so far with, with identity for MCP, it's really just, you know, can, can the the request actually talk to the server? But there's still, you know, a lot of room for improvement around, you know, what are we going to do as far as, RBAC. I think there's a lot of focus within the MCP community for figuring out how that should look, and how we control access to specific tools, specific types of workflows and things like that, where the MCP server again just becomes more and more of a shared thing versus, hey, it's easy to, you know, start up my, my IDE on my desktop, run a standard IO MCP server, and just kinda utilize it in more of a one off win. Now I think more and more teams with the kinda iteration of the spec and what we see more and more now, are really looking at, hey. How do we scale this? How do we make this standardized? How do we, make this easier to adopt for multiple different teams? Rami, anything you would add there? Yeah. I I think we're we're in a lot of agreement. I would also just to, like, sort of passively respond to some of the things I've seen flowing by in chat. There are questions about registration and supply chain, and I think a lot of the improvement is actually, just as this ecosystem matures. We're seeing, the norm going from independent entrepreneurial developers creating MCB servers for SaaS companies to SaaS companies owning those servers themselves, which decreases the noise in the ecosystem that would lead you to accidentally install something malicious. Of course, it's still pretty scary. But as you move from a default of, I go to a company and ask for their MCP server, from what used to be, I go to GitHub and search the company name and then pull whatever I find. I think that improves a lot. There's also some discussion of, like, standardization of tool permissions, ISOFLOFI. One thing I have seen getting introduced to spec is decoration, which would be the first step towards tool permissions. So, like, adding a little bit of metadata that clients can use how they wish. My understanding is that the spec doesn't actually have a a full permissioning system yet, but it's clearly on folks' radar. And that to me resembles what we've seen with, you know, Versus Code extensions and Chrome extensions previously as extension marketplaces get more mature, as extension protocols get more mature, you do see a move to tool permission. And finally, to to tie it to one more question I had seen flow by, about, like, the emergence of gateways, There is a lot of emergence of both gateways as a product, gateways as a project in the open source, and also companies internally building and serving gateways to centralize usage of MCP. And with those gateways, often, we do see bundled consistent sandboxing and, maybe more consistent permissioning, whether that's, you know, OAuth by default and for everyone, which gets you a little bit more per user permissions instead of a service account that's shared, or alternatively, just permissioning in terms of scoping down what MCP can do because maybe in your company, you want to, you know, expose a a billing system via MCP so you can do revenue analysis without, you know, pulling in a whole MCP server that also lets people, send off money wherever they want. So that's a few of the things we're seeing. I think some of this is about professionalization of usage of MCP. Some of this is about, the protocol itself evolving, and some of it is just about people very rapidly building on what was a viral sensation to bake in some of the same security practices we need to use everywhere else. And I think that as those practices develop, we'll be able to also have a flywheel of more adoption as enterprises feel more comfortable with adopting, MCP in in whole or in part. Yeah. I'm I'm seeing a comment here. Is it okay to say that don't use MCP at all if, you haven't figured it out, like, the the threat model or or the risks? Well, what's what's our take on that? I think that it is okay to say that for your own purposes. I think it's really challenging in a lot of organizations to say that, especially if you're sitting in a security seat in your company. If you're shutting the door entirely on MCP or or any AI or innovative technology, you're going to have to, think through the organizational culture and consequences. And if you're in a if you're in a very innovative culture where people are commonly adopting new tools, trying to block off MCP specifically could prove really challenging from a technical controls perspective. And so if you accept that, you know, this, is something that developers are going to use, that engineers are gonna adopt, Finding an outlet for that that's managed is a really common pattern in onboarding these innovative technologies. So, thing I've seen successful at at many companies right now is, internal registries for MCP servers that allow the security team to manage the capabilities and sourcing of those servers. And by giving a paved road and outlet to the desire to adopt and play with some of these technologies, whether because people want to move themselves forward or whether people want to, you know sorry. Whether they wanna better their own knowledge or whether they wanna improve things for the company. I think that, we're seeing, that adoption is gonna happen, and so you have to find a way to help it happen safely that gives you a little more power to say no elsewhere in the business. Yes. And just to add on that, before we keep going, I think the the other thing is just be aware of the worst case scenario. Right? I mean, even where we are with, with OAuth being able to, enable access to an MCP server potentially securely, just knowing, like, hey. You know, if I give access to read tools and I know that that MCP server also has right capabilities to whatever it's accessing, you know, just kinda understanding that from kind of a a blast radius perspective, understanding, you know, what's what's ultimately behind that MCP server, I think can can really help to, drive safe adoption even in as right now, we're still seeing the the ecosystem evolve. That's a great answer. And maybe we can show some of the capabilities, that was has developed in order to help organizations safely adopt new technologies in the AI realm, starting with visibility into, the usage of of these technologies and making sure that security teams are, aware and maintaining that that oversight. Do we want to move to demo maybe, Andre? Yeah. Sure. If you go ahead and stop sharing, I'll go ahead and pull up my screen. Yes. So like I mentioned, teams initially are really starting to understand that their developers are already starting to use MCP, either creating their own MCP servers or adopting different MCP servers from the community. And so, you know, step number one, visibility, understanding where MCP is in your environment, that's really a great starting point. And, you know, even, utilizing this to understand maybe where MCP already is that you didn't know about, because the other thing is that MCP, is a library. It's a framework, and that could be shipped with other frameworks that you may already be using. So understanding where that is, in your environment. And then the other thing is really understanding, you know, in addition to where it's at, what it's, what it's maybe found on as part of the workload scan, being able to understand, hey. This particular MCP server, I can see that it's exposed, right, when we start talking about things like shared MCP servers or MCP servers that, are exposed, on the network. Being able to map that exposure to the discovery technology and ultimately the resource that's behind it. Again, understanding, hey. If that MCP server is exposed, if that MCP server is running, you know, a a particular MCP from the community that that has some of those kind of, potentials for, for for exploit, then understanding the the types of permissions that maybe this is running on, what are the what are the potential path from this MCP server into my environment. And that's really where things like the dynamic scanner can help me to understand the exposure itself. And then the graph can really help me to understand, how is that actually running in my environment? How is that validated? How is that related to kind of the underlying resources that can ultimately help me to understand its blast radius? So I think that's really where, you know, most teams are starting is really just understanding visibility, using that visibility, using the graph to understand the relations to, identity data, things behind that MCP server, and ultimately using that to, understand where they wanna focus their time on the most critical risk related to that MCP server in their environment. Thank you. I'll yeah. I'll send it back over to you. Yes. Thank you, Andre. I'm seeing a lot of questions, which will, we will get back asynchronously after, this webinar. But thank you, Rami. Thank you, Andre. This was really an insightful session. Lots of interactions, lots of questions. I truly appreciate your time and attention. Thank you to all our participants, and I hope that this discussion has, equipped you with a clearer, thinking now for adopting MCP servers and the risks surrounding this new technology. And, again, we'll reach out individually to folks in, the chat here to make sure that all your questions are answered after, this webinar ends. Yes. This is also recorded in case you were asking.