Shadow MCP Servers: The AI Security Risk Hiding on Your Developers' Laptops

0:00makes powerful integrations extremely easy to create and adopt. So when it's easy, there is a saying by Spider-Man, with great power comes great responsibility. Convenience moves faster than the governance, but when we talk about security, it also comes with a gap, so you have to adopt.

0:19Chris RomeoVandana Verma is a security leader, speaker, and author specializing in application and AI security. She leads the OWASP MCP Top 10 Project and champions security education and diversity across the global cybersecurity community. Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, and as always, joined by Robert Hurlbut, the man who needs no introductions anywhere in the AppSec realm. And we have somebody else here who really needs no introduction, Vandana, who is so active in the OWASP world. And so, Vandana, let's just jump right into this question that we've been asking people that are repeat visitors of the podcast, and you've been with us a number of times before. What do you do that gets you away from technology?

1:07All right, that's an interesting question. And before I start, I'll say, hi, everyone. I'm gonna talk about what do I do when I'm away from screens. There's so much of my life happens through a screen— security research, community work, meetings, writing, mentoring and creating content. So what generally or genuinely takes me away from it? Spending time with my family and doing simple, ordinary things. I enjoy traveling, meeting people in person, and having conversations that are not scheduled around a calendar invitation. Also, I love working with children through InfoSec Kids. We had, we were running a campaign of 101 days. We asked the whole community to share their thoughts and inputs for the kids so that they can learn or the parents can learn from those. We just wrapped up that. Now, when I talk about InfoSec kids, their curiosity is refreshing because they ask very direct questions and they don't sugarcoat and do not care about all those complicated terminologies. That's what I love. And sometimes stepping away simply means listening to music. I love listening to the calm music and at times going for a walk. That's what takes me away from everything else.

2:29Chris RomeoThis episode is brought to you by Security Compass, a company I've worked with very closely in the past. They've recently put out a great guide on threat modeling for agentic AI. It breaks down what changes when you model an agentic system and what a complete model looks like end to end. The Security Compass platform brings continuous threat modeling, security requirements, and validation into one place. You'll find the guide at appsecpodcast.com/securitycompass. That's appsecpodcast.com/securitycompass. So, Robert, maybe cue us up here for our first topic about MCP and the security problem. Yeah. So, I know you've been working on MCP lately, but MCP, why is it a security problem? And for listeners new to it, what is MCP and why should AppSec teams care now rather than maybe next year?

3:25So the simplest way to put it, or if I explain it, is MCP or MCP is Model Context Protocol. And when an AI model can think and generate an answer, but by itself, it cannot necessarily access your company's files, query a production database, open a GitHub issue, send a message, or even think about the conversation. Like, I have a conversation with Chris, or I have a conversation with you, Robert. Agent cannot remember what conversation I had with each of that. MCP helps in maintaining that context or that clarity. So in simple words, it provides a standard way for AI applications to connect with those external tools, resources, and systems. You can think of it as a common connector for AI. I'm sure most of us have seen the Type-C. So you can say it's a universal connector. And before MCP, every AI application needed custom integrations. And MCP gives developers a more consistent way to expose capabilities to an agent. That is incredibly useful, but it also changes the security equation as well. And that's why MCP security is very important. The moment an AI system moves from answering questions to taking actions, we are no longer protecting only a chatbot that we've been thinking about, like, oh, I have a chatbot, it answers all my questions. Meta has a chatbot and it answers questions. No, we are protecting a new execution layer. Now, when I talk about AppSec teams, AppSec teams should also care because MCP adoption is already happening at developer speed. I have been speaking with a lot of developers. I'm active in both worlds. And Chris mentioned I'm very active in OWASP world, but at the same time, I am active now in developer world as well. And they are using it humongously. People are connecting AI assistants to source code repositories, terminals, databases, ticketing systems, or even for that matter, cloud platforms and internal documentations, like I have done it. Many of these integrations are being added locally by individual developers, sometimes with a formal review. Think about when you are doing that, how much of context is going outside of the actual system. Now, waiting until next year means something— means waiting until these connections become actually vulnerable in deep, or the workflows become an issue. MCP is not totally insecure or automatically insecure. I love it. And that's why I've been working on it and trying to understand. It's very useful. The problem is that it makes powerful integrations extremely easy to create and adopt. So when it's easy, there is a saying by Spider-Man, or you can say the whole Marvel, with great power comes great responsibility. And same goes with MCP as well. Convenience moves faster than the governance part. When we talk about security, it also comes with a gap. So you have to adopt. It looks fancy. When you start setting up an MCP server, it's super easy, but then it comes with its own security issues, which probably we can delve in, in the coming questions as well.

6:55Chris RomeoMCP seems to have been one of these things that developed faster than Everything, anything I've ever seen in technology as far as it went from an idea to an implementation. Seems like overnight. I know there was, it wasn't quite overnight, but it was, it was faster than anything we've ever seen before. And so what are some of the dangers in the fact that this thing has just been created and rolled out so quickly? Whereas past, like think about OAuth, how long it took for that type of a protocol to be developed and spec'd and discussed and tested. It seems like MCP doesn't have that. So like, what are your thoughts on how MCP was created?

7:35Now MCP was created majorly to make sure that we connect, we have those integrations which are seamless and easy by Anthropic. Now, when we talk about that, they are easy, they're nice, and how we are handling it, or they're being used at a very massive scale, I feel the scale is not the problem here with MCPs. If you ask me, I am running at least 6 to 7 MCP servers on my system itself. But I have containerized environment. Not everyone does it because I've seen cases where if you have an MCP server, which is just a small file, if you just put 4 lines of vulnerable code in that, somebody read about it. Who reads code these days? Even if everyone is asking AI agents to write a code. So those 4 lines will be missed. So the real challenge is visibility here. When I talk about organizations. They may believe that everything is going to be fine when we start using MCP servers, but then no. MCP servers could be connected to systems which we don't have complete visibility. One developer could, could, could have connected MCP servers to GitHub or could be a file system. Slack. I have connected MCP server to Slack to get a message about all the new conferences that are going to happen or that are happening. All those details, it's helping me, and it's easy, super easy. Now, the risk is very concentrated. A single compromised or overprivileged server may be able to read your source code, access credentials, because we are not having that kind of, like you mentioned about OAuth. So we don't have those boundaries yet. And that's where the whole problem lies. Where do you start? Are we vetting it? And even Are we checking it at the runtime? That becomes even more problem that you're running it and suddenly things change and your system become vulnerable. And many organizations still do not have an equivalent inventory for MCP servers. People are talking about bill of materials. I think supply chain security has been a big issue since Equifax breach happened. They fixed all these things. And after that, a lot of other things happened, but still Now we talk about AI bill of materials, but are we logging everything? No, we are not. An MCP server is not just the only thing. Now we have skills also added to that. And that becomes another beast here. So I think we can start asking questions. How many MCP servers exist in our environment? And if you ask me, I don't know. I need to ask developers. And that's a very big question. And who installed them? Again, if something goes wrong, there'll be a big question. And where did they come from? A lot of times, even if you are getting it from the right repository, you don't know if it might get vulnerable. So that's where all of the issue lies.

10:29Chris RomeoAnd I think we're at a point where we're slowly moving towards a point of no return when it comes to securing AI. And it just, it hit me over the last couple of days as I was thinking about the history of software security and how we weren't able to implement it in the early days. And then that led us to the whole idea of we have to shift left, we have to move back to the beginning, we have to try to influence all the stages a developer goes through. And it's tough to argue that we ever achieved that. We certainly, in AppSec and development and engineering and product, we We tried, but we never got there. And it just seems like with AI, we have an opportunity to do this right, and we have an opportunity to have security and privacy built in from the very beginning. But it almost feels like it's slipping through our hands to me. Like it's, it's, we're losing, we're losing a grip on the rope and the rope is pulling through our hands and it's going away. And like, I just want to say, can we just slow down for a minute and refactor this whole idea of security and privacy and what it means at the core of AI? And can we build this thing correctly for some— and build something that'll last generations? And I just, I don't, I think I might be, I might be dreaming too much because like with MCP, it was an idea, it was an implementation, and it's everywhere faster than anything that's ever happened in that I can remember in the world of technology. Cloud took 10+ years for from the time the idea was kicked around until the Amazons and the Microsofts had competing solutions. AI has been, what, this has only been 3 years and look how far we've come. And so that's just something that I keep reflecting on is like, are we missing the window again? And that's my biggest fear.

12:30Yeah, I agree. And as you mentioned, it's not even been 3 years. And we are seeing the change big time. And when you talk about AI, things are changing with lightning speed. Every day I hear some new term and I'm like, okay, what does that mean? And now recently I've heard about harness engineering that you need to have like a leash on the AI. And I'm still trying to understand in deep that what it is. Same goes with MCP as well.

13:01Chris RomeoPeople say— I've been playing with, um, Harnesses as a deterministic control for interacting with the agents as kind of a core principle. As I think about how does AI, you know, how do we do AI with security enabled from the beginning? And we've got to find a way to bring more determinism into the conversation. And the way you do that is with harnesses. Yes, the AI can write the harness. That's okay. We can do that. But the harness itself has to be deterministic. And how it interacts with the findings or whatever. And that's, I think, one of those core principles that has to be defined, written. I mean, we need a manifesto for AI security ultimately, and I haven't seen one yet. And so, I know some people that like to write manifestos from a threat modeling perspective, people, not from like general life manifestos that could get you in trouble because you want to take over the world or something. Not that kind. But it's almost like we need a foundational document now that says these are the things that have to be true for our multi-generational future to be good and safe. But I just don't think it's there. I don't think it's been created. Well, in Europe they have the AI Act. That's probably about as close as you can find right now. But even that, it still lacks some things, but that's probably about as close terms of safety and so forth. And the challenge with EU legislation is it's only ever made an impact in the United States if it can be tied to revenue or to fines in dollars. You know, think about GDPR. Everybody got GDPR compliant because we wanted to do business in Europe and we didn't want to write a check for, even for small companies, hundreds of thousands of dollars at a time. And so, yeah, that's a good point, Robert, though. That'll, that we'll see how that plays out. Can the EU drive us towards a more safe AI future? I don't know. I think it needs to be people like us at the core, at least writing down, here's the things that have to be true. And then we can measure them against, you know, whatever, whatever happens, whatever comes out in the industry.

15:10Yeah. Even our Singapore government has released beautiful information about or around AI agents. And just a few days back, I was reading about Australian government sharing multi-agent swarm security. So that's pretty interesting. It is coming and I think everyone is trying to do something about it, but it's a long shot. It's a very long shot the way we are using AI. Like I am using multiple things on my system. I'm using Codex, Cursor, Windsor, even I'm using Claude and I don't get answer from just one. I give the answer from this to other, this to other. So it's like a chain. And then in the middle, I don't realize, or maybe people like me don't realize, even being in security, the manifestation change and security intent change when you start moving or the details around. Same goes with skills. I use skills at multiple platforms, but how skills are being handled? I don't care, but there are security issues. Same goes with MCP. I don't like that skill. I want to have things easy for me. I want my life to be easier, right? I'll just create an MCP server so that it can sort my emails, delete the unnecessary emails, or put it into a particular folder. And it might start sending important emails to certain folders, which I don't even access. Or could be a spam folder, then what are we going to do about it? So those questions are still in the air right now. People are trying hard. There are so many acts which are coming. There's so much discussion happening. There are ISO standards which are coming, but I still feel it's a very, very initial stage. Even after using it for so, so many years, I think it's, it's an initial stage for AI security. We're still on a run right now.

17:10Chris RomeoThis episode's sponsored by Corgea. Design it, build it, ship it. Corgea secures it. Corgea is an AI-native app security platform covering your whole software lifecycle, from the first architecture diagram to code in production. It brings design reviews, AI-powered code scanning, and autonomous pen testing into one platform, so your team spends less Less time chasing noise and more time fixing what matters. Visit corgea.com. C-O-R-G-E-A.com. Corgia, one security platform for the entire SDLC. Yeah, we got a, we got a long, long way to go and a lot of work to do along the way. But let's, let's switch gears and talk about this OWASP MCP Top 10. Robert and I are always fans of any OWASP top 10 list that comes out. Doesn't matter which one it is. We're fans of all of them out there. But this one seems to be written in a crucial time where it can influence once again that multi-generational future that I keep coming back to. And so this— you're leading this OWASP MCP top 10. What was the gap that you saw that like, why do we need another top 10? We have a lot of them. I love them all, but we have a lot of them. Like, why did we need another one now?

18:32When we talk about OWASP MCP Top 10 or OWASP in general, OWASP Workaround, I started off seeing LLM Top 10, then Agentic Applications came, Application Security came, and recently Agentic Skills Top 10 was released. Now, these all gives an important foundation, but as we study MCP implementation from server, client, Everywhere we keep encountering problems that are specifically enough to have focused security vocabulary, because MCP in itself is so huge that it needs a vocabulary. We've released not just MCP Top 10, MCP Governance Framework. Then there is something called MCP Taxonomy so that there is a simple taxonomy for everyone to understand. And I feel there's so many terms there. But it's still incomplete. So MCP introduces its own architecture, lifecycle, trust relationships, discovery mechanisms, tool definitions, and the questions that comes with how do you identify. So I'll give you an example here. There could be a malicious tool description which is related to prompt injection, but the security problem is more specific, and that description may be discovered automatically, and then it can be added to the model context. Now, that'll be trusted, seen as trusted guidance, even though it's a prompt injection, but the context was given as trusted even before the users start using the tool itself. Now, what will you do about it? So we also saw the recurring problems involving token handling, scope creep, tool poisoning, supply chain tampering. As much as supply chain is an issue with traditional applications, it is an issue with MCP as well. Then I saw a lot of issues with command execution. I will share the list of MCP CVE vulnerabilities. I have a list till Monday last week, and we have over 550 CVEs. And major vulnerabilities that I've seen is around command execution. And there are so many other things that are there. So these issues overlap with existing OWASP projects, but team also need something operational around frameworks that developers, AppSec teams, and teams who are defending, and red teams, and they review MCP systems. So they need to have that. The goal is not to build—

21:03Chris RomeoSorry to interrupt. When you say command execution, are you talking about like the command that the MCP server runs as a result? Like, so I make a call, you know, my model reaches out to the MCP server. which has some amount of functions it can perform to help that model achieve its goal. So the command execution portion is in the MCP server when it runs a job or something. Is that, am I getting in the right place where that's happening?

21:33I'll explain from an AI agent perspective. Now, AI agent construct and execute system commands, or it could be shell scripts, could be API calls. Now, your user prompts are being used, context is being used, and third-party data is used without even proper validation. Now, in traditional command injection, how it happens is attacker directly controls the input fields. But with MCP, it is running through the model context layer or model layer itself when you're using any model from OpenAI or from Claude. So when you talk about model layer, the agent interprets the natural language instructions and translates that into the execution scripts. So that, that's where it becomes a big problem. And it leads to a problem like you and I are speaking, but suddenly models start treating it as, as a malicious input or start treating it as a problem. Or I see that there is something which is wrong. But I have told this, the model that everything is fine. So it starts approving that without even validation. So validation is a big challenge here with model context protocol. At least in traditional systems, you know, there is an input, there is somewhere processing happening. That's where attackers can play around. And then there is a server or attacker server. Now here, you don't know how many dots are being connected. And the context. If I am speaking with Chris, I don't know the answer. I will figure out 10 different places to get an answer, whether it's wrong. And that's what is happening right now. Without proper context, things are being used and being played on. And that's where all the issues arises. Prompt injection, tool poisoning seems to be a good one, but then the CVEs that have been reported. At least that's what stats says. For me, if you look at the top 10 list, command injection is not on the top list. It's on the 5th number. And think about tool poisoning, scope creep, token issues, all those are top 3. And I see that, or the people are not reporting those concerns yet, if I have to put it this way. Because when you see the top 10 list would come out, the next list in October end. I would make sure it is backed by the data. It does not have to be—

23:57Chris RomeoHow did you generate the list? Is it data-driven, like the flagship OWASP Top 10 is, or is it based on practitioner perspective, or how did the order— how did you derive the order?

24:12So, it was derived by taking feedback from the community. It is new for everyone. So, when you talk about data, backing with the data was a very big challenge because not many organizations were working. Not many practitioners were working at that time who could comment on this. So I spoke with a ton of people who actually are working in this area, created this list, and from my experience, then shared it with the community and then got their feedback that this is right. This is not the, this could be an example. This is what I've seen. And when it was published, I decided, okay, it is okay, but not bad like OWASP. Top 10, which we have got tons of resources from different companies, from researchers and whonot. That's when MCP Security Project came into existence, where we have list of awesome MCP list, all the new issues that are there, talks are there. Then you have MCP CVE Project, where you are— we are only talking about the CVEs that have been reported in any MCP. Like literally any MCP and trying to figure out what are the issues which still exist and why are people reporting only some issues which are very heavily. And before releasing the final one or the next one, I am going to get more details from the community.

25:34Chris RomeoYeah, I don't think most people could even derive that data for you if they wanted to share it. I think that's part of the challenge right now is like they don't have the data. They have no idea to your earlier point about inventory. They have no idea what MCP servers are being used across their organization. So, they might be like, we would love to share this data, but we don't even know what it is. Yeah. Or tools that are tracking it, or, yeah. So, I think that's part of the, maybe the difficulty as well of gathering that data.

26:07Yeah, I agree. I think it's a lot of, that's when, when I mentioned about MCP CVE project, that I wanted it to back with the CVE list. At least it should not be just a fluff, which is in the air. Because there are some people, some organizations who are open in sharing their names. And a lot of them, they said that do not take our name in public because this is a very initial stage and this is our perspective. So we don't want us to be quoted. Now with the CVE data, at least I have some kind of data to be backed. And if somebody wants to contribute. Or even Anthropic wants to contribute, we are more than happy to have that information from them.

26:45Chris RomeoLet's talk about MCP09, shadow MCP servers for that list. That sounds like shadow IT, maybe with a much sharper edge. How bad is that inside organizations?

27:00It is very bad. The description itself is accurate. It is shadow IT with direct access to action. Traditional shadow IT might involve an employee using just an unapproved SaaS platform, but with shadow MCP servers, which can run locally, access files, and have access to, like, admin access to anything and everything from credentials to whatnot. So they inherit those environment variables, connect to internal services, or execute commands with the developer permissions. So then it becomes even more dangerous. It may also be nearly invisible to the central security team. I have not seen many security teams actually finding that there is an MCP server running properly. That's still a big challenge. If somebody says that I can run a SaaS tool and find it, please do find it and tell me. Or if there is one, I would love to see that because we need such things. So a developer can find an MCP server online, could add small configuration entry, restart the client, and suddenly there is an AI assistant that has several new capabilities. So there could be, it could be so many other things that could be running at the same time on developer machine, which MCP server might have access to. There are commercial tools which are backing this, but again, I feel that this needs a lot of attention at the moment. Most of the developers are not doing this because they are, they want to do it intentionally, but they're just trying to move faster. I've seen security teams using it. And everyone sees that it's a very good integration, easy to install, and just so simple. So the problem is, is the security review. And then the moment I talked about the 4 lines of code that has happened with MCP server, who would read that? That becomes a big challenge. And that's when shadow MCP servers become an issue. And if something fancy is there, everybody wants to experiment with that. Like when ChatGPT came into existence. Everybody wanted to try it. And when DeepSeek came into the picture, I did not know that it had some restrictions or every organization has their own restriction. And suddenly my system started getting alerts, giving alerts. So that became a big challenge. But with MCP server, who has those restrictions? Because who knows what other MCP servers exist in the world? There are a ton of them. There are so many SDKs themselves on the Anthropic website. So how would you deal with them? So shadow MCP becomes a very, very big challenge for anyone, not just security team, but for the developers as well.

29:37Chris RomeoSo when we think about this new list, I used to joke about the OWASP Top 1. Like, why don't we just focus on one of these things, knock it out, and then we come back and, and, uh, try to pick, you know, fix the next one on the list. So if you had to pick one thing on this new OWASP Top 10 MCP that, which should be the first thing we focus on, which one out of the 10 would it be?

30:05So my favorite one would any given day would be scope creep, which is privilege escalation. And then shadow MCP server. So if you have to pick one, then scope creep is one for sure, because it is happening big time with MCP servers because we don't have those kinds of identity boundaries around it. So more than anything that I feel is, is kind of big killer for a lot of organizations. You would see a ton of issues coming up, which people wouldn't even expect. that they could have there in their organization, which was actually harmless and suddenly became a big critical vulnerability for them.

30:48Chris RomeoSo, how should authentication and authorization work when an agent invokes tools through MCP? I know it's the second-largest CVE category in your own data, but why is this so hard to get right?

31:02When we talk about authentication and authorization, they're Generally discussed together at any given point of time. But when you talk about MCP, it runs in a different way. It requires us to have separate security questions and several of them. So I'll start with the questions that I generally have in mind when I talk about MCP authentication or those co-creep questions. So who is the human who's using it? Which AI applications is actually trying to share information or acting. Which MCP client and servers are installed? Because there's not one, there are this client and server which is being involved. Which downstream identity is being used? Half of the time people don't even know about that. And what kind of actions are allowed on that MCP server or from that MCP server? What is the purpose? What resources being used? And When was it used? So difficult part is, is your delegated authority because an AI agent is acting on someone's behalf. We are giving them full access without even giving a single thought about it. And it should not automatically inherit everything that a person does. So with MCP, this is like a common anti-pattern and there's something called long-lived token, which we are giving it to MCP. which allow every user to request and run through to the whole system. And that's when it removes meaningful user-level accountability and a very attractive credential theft for attackers because there's no proper identity mechanism which people are aware of yet. So if I've been given access to the credentials, I would definitely play around with it. So a strong design for MCP would be a short-lived token. And when I talk about credentials, I'll tell you a funny thing. A friend of mine, because I know him and we were discussing about it, I can't name him. He was creating an MCP server and he actually added a token to it. Now, when you are doing it and you're putting it on GitHub, what do you expect people to do? Obviously use it. Now, remember when that's committed on GitHub or GitLab, That's going to be there forever. And then you remember, oh, I made a mistake. And then you remove it, but it's still there. So you have to change that token. So better use narrow tokens and remember that don't commit it and don't even put it in the files because you want to make it easy or you want to run it smooth. So you, you are doing it and that's when becomes the problem. And when you talk about authorization, it should be checked at any given point of time. You can't just give the full access to MCP because it's an MCP. And not only when the server connects, that's a big challenge. Also, there's another thing that I've seen is that at runtime, I have not seen many action controls. When it starts running, when MCP is running, nobody checks it because it's running and we forget about it. It's like old days I created, or with cloud, right? It took 10 years because people used to create cloud accounts and then forget about it. We're keeping those simple passwords and then forget about it. I remember doing a rigorous 1-year project because there were so many cloud accounts and they were using insecure passwords. They were not in under one org, even though there were 10 developers in an organization, they had their own accounts and they were using root keys. So how would you handle it? You need to be a little strict, but then that took 1 year. Now we're talking about AI again, which is moving fast like anything. We have AI agents, we have agents, we have MCP, we have RAGs, and we have so many top 10s. We have skills and whatnot. Maybe tomorrow there's new terminology that'll come. And we just talked about harness, right? So there'll be a ton of things. So how would you manage it? And there's a simple rule that I use, which is authenticate every action, authorize every sensitive action, but with the approval, human approval. People think about that when you're using an AI agent, you're gonna forget about it. Why don't you have human in the loop for all the critical or high-end transactions to avoid any kind of issues in the, in the future when you don't know the technology well?

35:23Chris RomeoThe challenge there is we've been hit by so many, uh, we've got consent fatigue cuz we, if you turn off auto mode and you put it into manual mode, You try to do something and you get 12 requests for permissions. And yeah, I understand you can configure some of those in your JSON settings files and things to make it a smoother experience. But I think that's an item that you just described on the top 10 list of problems using AI that are design patterns in AI that are being proliferated right now. And one of them is Prompt for— I can't say prompt because that's a double meaning, right? It's consent fatigue because we're not really asking for consent on the things that matter. We're asking for consent on everything. And so we need to identify, like, from an MCP perspective, deleting everything out of an account should fire a consent to me. And I, as a human, should have to go, uh, wait a minute, I don't want to delete everything out of my account.

36:31Oh yeah.

36:32Chris RomeoInstead of 17 different consents, with one of those, you're about to delete everything out of your account. And then I have the ability to turn it into auto mode and just accept the ones that the classifier says are good. Hopefully the classifier would catch a delete everything. But once again, so many moving parts and no cohesive security strategy and policy about how these pieces fit together. And that's really driving where we are right now.

37:00Right. I agree.

37:03Chris RomeoSo what about Secure MCP? So if somebody's out there listening here, and in the age of AI, you can build anything in a very short amount of time, I've learned. I just built an extension for Thunderbird because I was using Thunderbird on a Linux system because my other Mac died and I was struggling to do some development, and I wanted it to do grammar checking, and Grammarly doesn't exist on Linux. So, I literally built an extension that connects to my local inference server and does my grammar checks on my email, like 17 minutes. So, that's the age that we, that we sit in right now. So, if we're going to build an MCP, and I'm, I've been doing this myself, so I'm really curious to see what your answer is here, because I probably haven't done everything other than threat model at the beginning. What is this? What's the template that we should use for a secure MCP server?

37:53So if you ask me, then a secure MCP server for me should be boring in the best possible way. Its behavior should be very narrow, predictable, and easy to explain. That's where it should start. And trust me, when you have it boring, you know, you are at least somewhat secure, if not 100%, because right now there's, there are a lot of challenges. And if I have to make a list of it. Then let's start with clearly defined purpose of it. Why it exists. You need to have those documentation because a lot of times I want to use it and I create it and then I forgot about it. Or I started using something, or if there is a Thunderbird extension, you might start using that and then forget about that you created something that might have a vulnerable dependency, or there's something that it's giving access to. Or it's, it might want to escape the sandbox that where you have created. Scope creep or the least privilege is something which is important. Credentials with the short-lived and scope to the minimum resource and actions are the best. Like I was telling you about my friend who actually started coding the credentials and the code itself, let's not do that. We are not in the Stone Age anymore. We are in AI era and we don't want anything to be going anywhere, especially our keys, credentials, passwords. And everybody knows that AI is a smart parrot. Whatever you teach it, it's going to blub out somewhere with the right beautiful English, plain English grammar, no scripts, nothing, but just the plain English. And we've seen a lot of breaches happening because of that. And then comes the inputs. I remember when OWASP Top 10 used to get revisited or revived, SQL injection was a big problem. And I used to say that when we were kids, SQL injection was there. We have grown up, it's there, and probably our kids are going to grow up and it's still going to be there. And with AI, it's still an issue. So please validate. Tool arguments should also be checked against script schemas and validate properly. If you don't do it, I think we are still going to be in the same problem. Everyone will be seeing the same problem. And then when we talk about MCP specifically, tool metadata should be treated as security-sensitive code. You can't deny that. You need to look at the metadata. And I've seen cases where dangerous actions are not, or they do not have stronger controls. So they need to have those stronger controls depending on the impact that they are going to do. And there should be explicit user confirmation, like you mentioned about that for deletion. I want that because there is a fatigue out there. I don't want those things to go one by one. I'm approving 17, 18 approvals. No, but at least for the high-end action, I need that. And then my favorite part is logging. There should be proper audit and logging that should be there. For God's sake, nothing should happen, but we have seen cases. Things have happened and people were not able to find out how much was the impact. So let's figure out, let's log it. Those are simple, very non-negotiable things. And logging and monitoring auditing is something which everybody's saying it. And now when we have those AI acts coming in, I'm sure it's going to be grilling you even more. So why are we not doing it right now? Let's do it the right way. And these are very small, simple tasks. I think that's what we can do.

41:26Chris RomeoSo kind of wrapping up here, but how should AppSec teams engage developers building MCP integrations? And maybe even another one, a security review question teams should be asked or should be asking before connecting an AI agent to the MCP tool. Maybe a couple of those things to discuss here as we wrap up.

41:53Right. Now, as an AppSec person, what my responsibility should be, would be, or should be for this is to understand that everyone is experimenting with MCBs. Why? The simple reason is it is actually solving the real-world problems. And any problem that, or anything that connects it with, connects us with other tools, other technologies, and helps us getting more information. We love it. For example, in simple words, there is a weather app. It might not be able to give me an answer if I'm asking an AI agent or a chatbot, because it does not have that real-world information, real-time information. When you add MCP to just a simple weather application, it'll tell you what is the weather in Atlanta right now. And the same time, what is the weather in Bangalore at the moment or San Francisco or New York? So MCP does some amazing things. So at the same time, we need to make sure that as an AppSec person, we give a paved road to the developers. I remember with containers, we used to give a golden image to developers, which I totally loved. One of the organizations I was working, and I loved how they created that. So probably we can provide an approved MCP server template with secure authentication, input validation listed. There should be proper logging. And how do you handle secrets? That should be there. Then the review process should be easier. Not like earlier that we used to say that don't do it. Everybody is going to use it. So I like MCP integrations through simple practical questions. What can this tool do? What kind of data and credentials can it access? What would happen or what could happen if the instructions or outputs were malicious? Or even as an internal person, I am providing those malicious input. How would you even detect or stop them or even mitigate the misuse around it? That's where it starts. And AppSec teams can actually provide threat model. We were talking about threat modeling manifesto. So AppSec teams should build that threat modeling manifesto around MCPs, which we are not seeing. test cases. And so test cases comes with big responsibility. I'm working with a lot of people around MCP security testing guide, which is like, have taken a lot of our time and which is still underway, but soon will be released. So somebody should come up and say, oh, this is a test case that I've seen. And more importantly, when it, when we talk about security, it has to be thought about during the integration itself. It can never be enough thought specifically with AI as well. So for AppSec teams, it becomes even the bigger responsibility to come up with things.

44:45Chris RomeoSo Vandana, where can people go to review the OWASP Top 10 for MCP and how can they get involved in this process to help?

44:55The best way to go, go on the GitHub of omcp.top10. It's on the OWASP org. So you just go to owasp.org or github.com/owasp/project-mcp-top-10. You will just Google it. You will be able to figure out. Now there, if you make a pull request, I would definitely review within a week and approve it if it's really meaningful for the community. And you will be listed as a contributor because we want more people to contribute. It is not my list. It is not. one-person list or just group of people list. It's everyone's list. And I, we want more and more contributors to share their perspective. That's where I would lead it to.

45:40Chris RomeoExcellent. Well, Vandana, I want to give you a chance to offer us a key takeaway here that our audience can maybe put into action. Just one thing that you think the audience should do.

45:52Don't treat MCT server as like any other server. Think about when you are hiring a person in your organization, are you giving that person all the access in the world on the first day? No, even I did not have access. So why are we doing it with MCP server? Think before you give the access. It's like the zero trust paradigm that we talk about. Never trust, always verify. So never trust on the first day. Always check it out, even though you've given access and you think that it's safe, still reverify. That's very important.

46:27Chris RomeoAnd that's wise wisdom that you share, as you do always when you join us here on the Application Security Podcast. So, Vandana, thank you for, for being a repeat guest and for being out in the community fixing stuff, not just talking about it, but you're in the trenches fixing it. We appreciate that. Our community appreciates that as well. So, It was a joy to speak with you again, and we look forward to another conversation in the future here to, to check in on what you're up to.

46:55Thank you so much for inviting me. I'm really glad to be here. Thank you. Thanks to both of you.

47:01Chris RomeoThanks for listening to the Application Security Podcast. If you enjoyed this episode, subscribe, leave us a review, and share it with a friend or colleague who would enjoy the conversation. We'll see you next time.