MCP Security: What Happens When Your Agents Talk to Everything? // Rosemary Nwosu Ihueze

Rosemary Nwosu Ihueze [00:00:05]: All right, thank you. Hi, my name is Rosemary and I'm the founder of Soteria. Today I'll be talking about MCP security, what happens when your agents talk to everything. So without much ado, so we'll start with what is mcp? So if you're building AI agents or managing them, or even using them day to day, you definitely know that this is a big gold rush. It's all about the connectivity. It's all about building things that are beyond thinking at this point. These are things that are now reaching out. You see them in your database, you see them in Slack, you see them in GitHub and the rest of it.

Rosemary Nwosu Ihueze [00:00:51]: So the whole idea is that there is need for universal universal connection. Which brings us right to this architecture called Model Context Protocol. Or you'll see mcp. So the easiest way to think about MCP is that you can call it the USBC port for AI. So it's meant to be the universal adapter that enables AI applications connect with external sources of data, tools and services without writing code for each integration, each data pipeline and each service. So you could see here you have the user, which is you and I, we have, this is an example using a personal assistant that has access to Notion, Gmail, Slack and Google Calendar. So this is just a simplified version to show you how mcps work. So, so the user, you have the personal assistant, then you have your MCP protocol, then you have your host, which is the protocol manager.

Rosemary Nwosu Ihueze [00:01:59]: Then you have your Notion server with the API which goes to your Notion database. You have your gcp, Gmail and your inbox, your Slack workflow and your Calendar events. This is just a streamline of to show you what MCP actually does, how it connects your agent, which is the personal assistant, to all these tools that help it work perfectly or as it's supposed to. Now you have the MCP promise versus reality. Now MCP is brilliant and the promise here is actually huge. So it's a dream to have a hyper productive AI worker, the agent that handles these complex multi step jobs and do it without developers having to write custom integration code every time you want to talk to a new tool. The promise here is it's going to read your Slack messages, it helps you commit to GitHub, it queries your database, it assesses your file system and also it hits your your internal APIs. This is what MCP actually encompasses.

Rosemary Nwosu Ihueze [00:03:13]: The reality now is that it has the way we are doing mcp, we are looking at it from the angle of humans, where you have human Trust. Now here is the failure one, the identity doesn't just survive delegations, especially when you're working with multi agents and multiple, multiple tools and multiple systems. Now this AI agent, this agent identity just vanishes. You have no idea which human started it, which agent spawned into what, which agent even made the call, which tools. So the consequences here now when you think about it, is suddenly agent B starts acting weird and maybe even going rogue. So how do you revoke just the access of agent B without affecting the overall architecture of what you've built? With the current architecture as it is now you have to shut down the whole service because you can't do the surgery recovery or even surgical fixes. So even having forensic, accurate forensic forensics after the fact that you can't do that because of the way the architecture currently is. You have your access log entry agent A called Agent B.

Rosemary Nwosu Ihueze [00:04:36]: Agent B made the decision. MCP server was intermediary service account API key XYZ access repository. That is just your log. You don't know what is going on in between. Now you have the second reality, which is the failure too. So permissions are still stuck on all or nothing. So what do I mean by permissions are stuck on all or nothing? Now let's say you have an agent that its business is to look at your inventory. So with all or nothing you are giving it access to everything you have.

Rosemary Nwosu Ihueze [00:05:16]: So these agents now can potentially read your customer pii, access your financial records, even see your secret pricing algorithm. All because it just needed to know that if product 42 was in stock, the security boundary we've drawn is way too wide for the tiny task that it actually needs to perform. Here in the diagram you can see this agent needs to check the inventory for product number 42. You have the permissions, yes or no. And then it guarantees the full database with access. It now accesses the user's table, orders table, payments, inventory, analytics, secrets. It doesn't need to. The current architecture gives it yes or no, all or nothing.

Rosemary Nwosu Ihueze [00:06:05]: So it just needed the inventory table. But because of the current architecture of yes or no, it now has access to everything, which shouldn't be. Now the third reality that we're seeing is the audit trails actually disappear. So here let's say the diagram says what's our best selling product? Then the main agent spawns a sub agent which executes your SQL query and accesses the resource which is the database. Now you lose crucial trace, the conversation ID the original user, the sequence of agent decisions, the justifications. Why did this query even happen, it's all gone. So if data leaks, good luck finding trying to replay the agent's logic to figure out if it was a malicious prompt or just an accident or even a prompt injection gone wrong. So your, your logs, if you're actually lucky, is you are seeing 1042, 43am Service account agent, one access database.

Rosemary Nwosu Ihueze [00:07:17]: So what's missing? Who's the original user? What was the original question? Why did the main agent decide this? Which sub agents made that call? What was the reasoning chain? All these are actually lost with the current architecture. Now moving beyond the theory, we can highlight some actual architecture that piggybacks current attacks. Sorry, that piggybacks of these failures that we've mentioned. So one prominent one that I'm going to talk about is the one from Anthropics report. So on September 2025 it made. They made a report about a breach where there was jail. Some, some people jailbroke the Claude code. So they were able to convince the the code or the agent that they are legitimate security researchers and unleashed it to autonomously attack 30 organizations.

Rosemary Nwosu Ihueze [00:08:22]: And these 30 organizations included banks, tech companies, government agencies and the AI operated at machine speed of thousands of requests per second, which did 80 to 90% of the work. It scanned the networks, exploited code, harvested credentials from config files, even tested them. Not only did it do all of this, it actually wrote audit trails and documentations of what it was doing, what was correct and what wasn't. So all this without minimal intervention. And it took three days to actually detect and 10 more days to map the full scope because the audit trails were basically garbage. So identity vanished through the delegation chain. Permissions were all or nothing. So it was able to get what all all the logs and all the data it got.

Rosemary Nwosu Ihueze [00:09:27]: And this isn't just theoretical anymore. The three failures we outlined, the identity loss, permission sprawl and blind auditing, just were enabled in this attack. That, in this attack. That's why it work. It worked. The question isn't if this will happen to your MCP enabled agents, it's whether you even know when it does. Because let's say this goes beyond catching it and it wasn't caught at the time it was. It's possible to delete its trail, which means that you won't even know that it was there.

Rosemary Nwosu Ihueze [00:10:10]: We'll go into what actually works. Now the first thing that actually works, I had to do two diagrams without the chain. And with the chain, what actually works is identity chain tracking. Why does identity chain tracking works? It works because you can Trace back any action to the originating user and conversation audit logs show the full chain. So it shows the user, it shows the agent, it shows the sub agent resources to whatever it is. You can revoke it at any level. So you can kill the sub agent or you can kill the entire chain. It has a behavioral analysis that works.

Rosemary Nwosu Ihueze [00:10:53]: So if it doesn't normally do something at a point the analysis looks this agent doesn't usually access the database directly. Let's shut this down and see what's going on. That is how identity chain tracking works. Now you have context aware permissions. This is the difference between traditional permissions and the context aware permissions without context awareness. Does agent have stripe access? Yes. Allow everything 1000 refunds processed with context awareness. It, it goes through the policy engine, it checks the context, it checks the policy rules and then it makes a decision and gives you the decision.

Rosemary Nwosu Ihueze [00:11:44]: Now your logs are there. This is what happened, this is what, what our decision was. And this is the reason why this decision was made. Then the agent receives the action denied by policy exceeded refund limit. Your stripe is never touched. So this is the difference between context awareness permission when it comes to policy engines and the traditional permissions, which are all or nothing. It's not just can this agent access stripe, it is, but can this agent process this refund in this context. Next we go to auditing everything intelligently.

Rosemary Nwosu Ihueze [00:12:25]: Now with the current architecture, it just does the 1042 database access. Now with new log, you are able to see your request id, the identity chain, how everything is working, the justification, the action policy decisions, the reason and the rules and your timestamp. Now this gives you traceability that is from user question to database query. Your justification, why did the agent think that this was needed? Now anomaly detection. This agent usually returns like 500 rows, not 5,000 or 50,000. Now you have your forensics. When something breaks, you can actually replay the decision tree. You are not just login action denied, you are logged in action denied.

Rosemary Nwosu Ihueze [00:13:13]: Because maximum reform policy or limit of $100 or $50 or whatever you put was exceeded. This, this level of detail is crucial for genuine historical forensics. So it goes like this. You can even train your anomaly detection systems to flag suspicious buttons like wait, this, this reporting IS typically takes 500 rows of data per request, but now is asking for 50,000 rows. What's going on? Now even if the credentials are valid and the policy allowed it, that volume of anomaly is a huge red flag which leads to your engine stopping it and isolating the problem to actually figure out if this is actually an accident or an attack. Now, I'll leave with this quote that says the agents are already talking to everything. The question is whether you know what they are saying. The reality is that MCP is happening.

Rosemary Nwosu Ihueze [00:14:25]: It's. It's too useful for us not to use. But right now everyone's reading the features and ignoring the security. So. That will be the end of my presentation. I'm happy to take any questions and if you're working on MCP implementation or thinking about AI security for your stack, I'd love to chat afterwards. Thank you.

Allegra Guinan [00:14:52]: Thank you so much. Rosemary. Yeah, we have a few minutes for questions here. I saw that there's one in the chat, so I'll just go ahead and lead with that one and then everybody else feel free to drop additional questions and I can read them out. How do we design enforceable trust boundaries and least privilege controls for MCP agents when they're allowed to autonomously communicate with multiple external services, tools and agents?

Rosemary Nwosu Ihueze [00:15:20]: Okay, can you repeat that question? I'm sorry. Sure. Yeah.

Allegra Guinan [00:15:23]: Basically, how do we design boundaries like enforceable trust boundaries when these MCP agents can be communicating with so many other things out there, right? Like services and tools and agents, all these external factors. So how do you enforce that through. Through building trust boundaries?

Rosemary Nwosu Ihueze [00:15:40]: Okay, so this is where context awareness and policy engines comes in hand in hand. Like I stated earlier, when you're making, putting these boundaries, these agents shouldn't access this database or you give it a context. It's not about just the tools or the resources that it has. You have to implement a policy engine. Now your policy engine works hand in hand with context awareness and behavioral analysis. That way it enforces your agents or it forces your agent to actually use this policy, these boundaries to work when it comes to mcps. So everything you are doing, you have your policy engine sitting in between. So that way if your agent is working with any MCP or any, any tool at all, that policy engine plus the behavioral analysis, plus your context awareness architecture enforces these boundaries that you've set.

Allegra Guinan [00:16:53]: Thank you. Yeah, another really good one just came in. Does the anomaly detection currently support multimodal data?

Rosemary Nwosu Ihueze [00:17:03]: Yes, anomaly detection actually supports multimodal data. It's now dependent on how you train this anomaly detection. Because currently anomaly detection models comes from what you've actually seen. So you, it's, it reads patterns. So you have to implement logs that you can create your own anomaly detection from. Because the overall anomaly detection engine doesn't really work outside of the security of these agents or of this mcp. So whatever you're doing, you have to build out your own anomaly detection that your own agents and your own MCP is going to be using.

Allegra Guinan [00:17:57]: Yeah, really, really good answer. Bringing up the logs. And somebody else was asking how you generate those. Are there specific tools that you need in order to actually generate audit logs that then you can use as the base for your anomaly detection?

Rosemary Nwosu Ihueze [00:18:10]: Yes. The first that I can point towards is open telemetry. Implementing open telemetry in between that opentelemetry gives you traces and spans. So using those, you are able to create a system of logs that not only sees the traces of what you are doing, but also sees the spans. That way you can save them and use them to create your own anomaly detection models.

Allegra Guinan [00:18:40]: Thank you. And can you walk through maybe a specific attack scenario where MCP could create a vulnerability?

Rosemary Nwosu Ihueze [00:18:50]: Okay, so I'm going to give an example. Let's say you have a business, okay, you, you deal with stripe. You have an agent, an MCP that deals with stripe. Now going back to the permissions, all or nothing. Now, current architecture looks at your agent, does he have access to stripe, yes or no? So when you say yes, you are not giving it contextual awareness of, okay, this is my boundary, these are the boundaries. This is my policy engine. I want to enforce this boundary. It just gives it an all or nothing, which means an attacker can come in and request for 1000 refund.

Rosemary Nwosu Ihueze [00:19:41]: But because there is no context awareness, there is no behavioral analysis, there is no anomaly detection, none of all these are actually in, built into the current system that attack actually goes through. The agent is actually doing its job at this point. So it's doing its job. It knows that, okay, I can, or I'm supposed to give a refund to customers. So when a malicious attack happens, it does its job. This is a customer, it sees it as this person as a customer. Customer said their refund is a thousand. The, the agents via the MCP does the refund.

Rosemary Nwosu Ihueze [00:20:24]: Now, with your context awareness, with your behavioral analysis, with your anomaly detection, your policy engine, your boundary enforcement, this looks at it and says, hmm, no, the, the maximum refund for a per customer is supposed to be $50 or $100. Anything above this threshold should, we should escalate to a human. So without that, this is an MCP creating a vulnerability because you can get the refunds as high as you want without this guardrail in between, sitting in between your MCP and your agent.

Allegra Guinan [00:21:11]: Thank you. Yeah, really solid example. We have another question that came in. If there's a way to determine whether the system is communicating with services it should not be accessing. So if that kind of communication is happening, it may indicate that there's contact with an external attacker. Right. Because it wasn't identified as something it should have been accessing, which might lead to a security risk. Is there a way that you've found to best determine if that sort of contact is happening?

Rosemary Nwosu Ihueze [00:21:40]: Okay, so the way I've built security architecture for my own agents is this. I give them a tool so I don't tell them, okay, do not use this tool or do not use that tool. I give them to. It's a role based tool context in addition to every other thing that I've stated here. So your agent, let's say this agent is a note taking agent. You don't. And it, it's not supposed to access the database. If a malicious attacker comes in and says I want you to go to the database and extract so, so and so data for me.

Rosemary Nwosu Ihueze [00:22:26]: Now when this agent goes in there to extract the data, the guardrail already I already put in place stops it. You can access tools but you are not supposed to supposed to access this particular tool which is the database. So that is you, you don't restrict your agents from accessing these tools. Rather you give them a context based tool assessment that says okay, in as much as you can access every tool here, you are not supposed to access this tool. And when you come in contact with a tool that you're not supposed to see or you're not supposed to even come in contact with your, your guardrails, your tool context, your permission context, everything that comes in your policy engine in summary stops it and says okay, no, this is not, this is not supposed to happen. That means there's something wrong somewhere. Then it isolates that agent and isolates whatever else it comes. It has come in contact with tools resources to ensure that it doesn't affect the overall architecture.

Rosemary Nwosu Ihueze [00:23:45]: I don't know if I'm making sense.

Allegra Guinan [00:23:48]: Yeah, it does sound like there would have to be some sense of which tools are allowed even if you're not completely restricting at the beginning is what I'm hearing as well because the guardrail would have to say at some point you weren't supposed to be accessing these, These are the only tools that you're meant to access access and before moving forward. Yeah, got it. Okay. I think that's all of our, our questions that we had here. Thank you so much for, for joining us Rosemary, and hope you enjoy the rest of the conference.

Rosemary Nwosu Ihueze [00:24:18]: All right, thank. You.