Welcome to the KuppingerCole Analysts chat. I'm your host. My name is Matthias Reinwarth. I'm analyst and advisor with KuppingerCole Analysts. My guest today is Alexei Balaganski. He is a lead analyst for cybersecurity and much more at KuppingerCole, and he has many more roles. But today we are here to talk about MCP security. But first of all, hi Alexei. Good to have you. Hello Matthias, and thanks for having me again. Great to have you. And we have a lot to cover today. And we're starting with a research that has been published a few weeks ago.
A research that published the analysis of an attack from earlier this year, mid-August, and someone found self-hosted AI servers on the internet without authentication. And as you can expect, the attackers had root access and within minutes to a lot of servers, 23 of them. And this comes through a feature that comes with the MCP support, of course. But this really does not sound too new to me. So no authentication on the internet sounds like they are out there for exposure and for attack, right? Right.
Well, yes, Matthias, I guess we have to probably walk our listeners first through the reason why we are talking about this topic today. So yes, the actual attack happened earlier this year. The research was published just two weeks ago. This is why I think it was a good opportunity to hook and start the discussion.
But yes, basically local AI is a very popular open source platform to run your LLMs locally, a popular alternative to commercial systems. And it comes with all the bells and whistles of a real enterprise-led solution, including different interfaces. And of course, MCP is the most popular one. MCP stands for Model Context Protocol, and that has emerged as a de facto standard for, let's call them, agentic AI tools. Answer your questions, but if it's connected to a set of MCP servers, it now has tools to actually change the world around it.
It can query data, it can execute system commands, it can do basically whatever the MCP server offers. And this is why this is such an underappreciated new, not really new, subfield of cybersecurity. Because in this scenario, an attacker just found a random unprotected instance of that local AI installation, and then they tried to probe different ways to get in. And the easiest one was to let the platform itself start a local MCP server, which basically gave them the same access as a root console on a Linux machine.
Because through the nature of the MCP implementation in the platform, you can basically run any command and treat it as an MCP tool. And apparently, according to the research in the OASIS security, one of the affected persons was someone from Thai military, and his exploitation basically exposed some sensitive data relevant for military and whatnot. So luckily, it was identified, it was prevented, the scale was not large, but it opens up very interesting and lucrative opportunities for future similar attacks. This is why we have to talk about it. Right. But let me take a step back.
So it is an unauthenticated protocol exposed on the internet. This is not much different from a SQL server being online and available and admin as username and password. So isn't that just a misconfigured local AI platform? Why is this an MCP story?
Well, you are, of course, right. We're saying this is nothing new. And this is what we have been saying for years as well in all our research. Nothing in this world is new. It's all based on an interesting combination and interference, if you will, between existing features. And this is exactly one of those scenarios.
Yes, there was an admin API, which was unauthenticated. Not a new topic. We have covered issues like this and solutions to solve these issues for a decade now.
Hint, hint, read our leadership compass on API security. But again, there are other topics involved here. Probably the biggest one is software supply chain risks. Because again, MCP is just another artifact, which you do not control. You just get from a vendor or even you just get a possibility to deploy an MCP server from a vendor, which is an exploited. And if you are not monitoring those artifacts, if you only think your software security analysis is limited to like open source libraries or your own code, well, this is no longer the reality. You have to think bigger.
You have to monitor new opportunities for attackers. So yes, and by the way, there was a similar attack or somewhat similar attack earlier this year, which someone called dead bugs for whatever reason. And they're basically someone, nobody knows until now who it was, has injected malicious MCP tools into existing projects.
Basically, if your project had an MCP server, it would work fine for some time. And then suddenly the descriptions of the tools would change. And those descriptions are read by agents and they affect their behavior. So basically they will do the usual thing, working with the same tried and tested MCP server and suddenly to give them malicious instructions.
So yes, this thing is much more flexible than traditional APIs. And this is why it's, there are so many opportunities to exploit them. Right. If I remember back correctly, there was an episode together with Martin, our colleague, and he said the S in MCP stands for security. And so that is this usual saying that we hear. On another point, if I remember correctly, you said it's a de facto standard, but it's still coined and created by a vendor, by Anthropic, if I remember correctly.
So if there are that many issues, challenges just right now, and it's so heavily used, shouldn't that just be fixed by the owner, by Anthropic? Well, again, this is a philosophical dispute on its own. We won't probably touch it in detail, but basically, yes, Anthropic has come up with the standard, and they created a reference implementation. So if you are building an MCP server with Python or JavaScript or whatnot, you're probably using their SDK. And the implementation in that SDK basically has, we would call it a vulnerability, they of course call it a design decision.
So they say, yes, we are not doing this on purpose, securing your interface is your job anyway. So we can spend hours or weeks discussing and kind of shifting the blame, but the more practical approach would be to actually fix it ourselves. Especially if you consider this is basically a de facto standard, it's not owned by a single company anymore.
Right, so fair point. So as you said, if we think of MCP, just another tool that gives access to resources, to anything that can be behind such an MCP server. So is it not an MCP vulnerability in air quotes, but something where we see that it's just the focus point, the crystallization point for security problems that come from MCP or do not? So is MCP a new kind of security problem, or is it just a new focal point where they happen?
Well, again, Matthias, you are hitting kind of the nail on the head, and you are scratching a huge itch. We discussed it earlier as well. People love inventing new labels for all things, because labels sell. So of course, if you can say, hey, we have just launched an MCP security product, you have to buy to protect yourself from all this fascinating new problems.
Sure, people would fall for it. But if you are following Kubernetes' year-long advice and say, stop looking at labels, look at functionalities and capabilities behind, then yes, MCP is just a new standard, a new protocol, if you will. But it's essentially a wrapper for existing things. It's either an API or just a plain direct execution of a system command. And that STDIO interface, for example, for MCP, is basically a possibility to run a local command and treat its output as your result. This is it. There is nothing new. It's just a different way to wrap existing things.
The only probably major difference is that it's not targeted at humans or traditional software. It was designed specifically to be easier to be discovered and consumed by agents, which means it contains a lot of semantically vague natural language explanations of what those tools are actually supposed to do. The standard REST APIs come with a very strict specification, which outlines precisely what each endpoint or tool, if you will, can or cannot do, what kind of inputs it's supposed to accept, what kind of outputs it's supposed to deliver.
And you can always relatively easily and deterministically validate whether it's doing fine or even doing something malicious. With MCP, it just became a lot more difficult. Because again, those descriptions are written in English or any other natural language, which is much more difficult to analyze. So it only means that this is now an additional way to somehow work around your existing security tools. Does it mean that you now need to scrape all of those existing tools and replace them with new ones?
No, of course not. There are much easier, much better ways to solve it. And obviously, the most reasonable way is just to treat MCP as a thin wrapper, a protocol conversion layer, if you will, around existing security controls. Unfortunately, a lot of developers don't understand it because, well, this is not how you wipe code MCP, right?
You say, hey, I want to talk directly to your database without any existing security controls. And this is precisely the wrong way of using MCP. And this is what we've been trying to explain and correct in our publications for a couple of years at least. And I totally recommend going back and reading and listening to our existing publications and episodes like this.
Yeah, you mentioned, for example, Martin's analyst chat back in July about the lack of MCP. Yeah, this is a very catchy phrase, but it really should make you stop and think, am I doing MCP right or not? Right. So if we think of MCP as a tunnel that provides a tunnel between system A and system B, the security should not be in the tunnel or around the tunnel, but within the tunnel. So it should be baked into the way how you use the load that you transport through the tunnel. So it's really the other way around. But you've mentioned that before.
So why are there so many MCP security products when it's actually just around about proper usage of MCP? Well, again, this is not as simple as just hey, add another thin layer on your existing security stack. Because first of all, and again, this is a topic that deserves its own episode, this whole cybersecurity fabric notion. Because again, you probably already have individual capabilities. You probably have a PAM solution, which would stop an execution of a malicious command on a Linux machine, for example, the same machine that runs your MCP server. You already have it.
You probably have an API gateway, which already protects your legitimate existing APIs you know about. You probably have some endpoint security solutions, which would stop a malware, regardless how it has infiltrated onto your infrastructure. The problem is that all those capabilities, they do not work together. They do not exchange signals. They do not know about each other's existence. And this is what you are supposed to be solving when you are designing your security or identity for that fabric, instead of a suite or even a platform.
Because again, when you are thinking about a platform, it's presumably coming from a single vendor and you have to rip and replace. A fabric is something you design, you weave, if you will, from your existing capabilities.
So yes, an MCP is just another thread in that weave. The question is, where should it land? Should it be a new capability in your API gateway? Should it be an AI gateway? Should it be something else? Depends. The only answer I can give you, it depends on your risk appetite, your needs, your existing capabilities. But it has to be there. It has to be weaved into existing security stack. You cannot just buy a new box called MCP security tool and expect it to solve your problems.
But if I understand that correctly, so the API layer, those are the MCP access entrance point, is something to secure to do it properly. On the other hand, within the things that you do inside of what is transported through MCP, the security is important. You've mentioned the signals, the interaction between different systems. But if you go back to the API layer, what is missing there? What can you not do? And you've mentioned that we are talking about an ecosystem. We are talking about MCP service that we consume from the outside, from our vendors, from partners, from I don't know where.
How can we protect that? Is this an API layer thing? Or where do we start with protecting this? Or are we lost anyways?
Well, again, kind of to put it probably a little bit oversimplified, but still to put it the API layer, the traditional one, is your perimeter layer. It knows who is allowed to connect to your backend service and what they are allowed to do. So they are doing authentication and authorization. This is kind of the primary things. And then of course, they usually come with an additional capabilities like analyzing the payloads, looking for malicious threats, doing some DDoS protection and bot protection and whatnot. They are protecting the entrance, if you will.
API gateway knows nothing about what happened behind the gate. It kind of assumes that it's job is done. A bit of the proper safe payload is delivered. But what would happen then and how it would be processed further, it doesn't care. It's a little bit oversimplifying things, but this is how it's usually deployed. Presumably, what's running behind the gate is either your code and you have a separate stack of security tools to kind of secure your own code, or it can be someone else's code.
And then you probably have a separate stack of tools, which we usually call software supply chain security tools. Unfortunately, some people still have this really outdated notion of what software supply chain security should cover. Most people think, yeah, it's just software composition analysis. I know that my code uses log4j as a library. So I know that there was this huge vulnerability in log4j called log4shell. So I have to deploy a tool, which would basically secure me from that vulnerability. Good job. You hopefully have been doing this for years.
Well, now it's just no longer enough. Because MCP is a new kind of the same software supply chain security artifact. It's not a library, but it's kind of also not your own code. There is another way to get into your code, your infrastructure, and it's a thing designed by somebody else. So now you at the bottom just have to analyze what's going on. You have to know what's happening with your quote unquote MCP inventory. You have to have that inventory in the first place.
So if we really treat that as a supply chain risk, and I think this episode is slightly moving away from MCP security to proper third-party risk management, software supply chain risk management, because I think that's really what it is. MCP is just the entrance door. It's a protocol that can be used properly or not. It can be integrated properly or not. But in the end, we're really talking about something else. But how does that look in practice? You've mentioned the product category. There is software supply chain risk management tools around.
But what would be something that a developer, an application owner, a system provider, a system owner would have to do? How does that look in practice?
Well, again, you just mentioned the thing which is the biggest challenge here, because we are trying to assess it from the kind of pre-existing notions and viewpoints. Is it an API security problem? Is it a software analysis problem? Is it an infrastructure problem? Is it something else?
Well, it's all of those things. That's the biggest challenge. And there are also different ways to fix it on different levels.
And again, if somebody is trying to sell you a solution called MCP security tool, you should stop immediately and ask the biggest question, what exactly does it really do? Because it can be doing multiple things, or it can be doing just one thing, and this is just not the one you actually need. It may be kind of tackling this on a specific API gateway layer, or on the network layer, or on the code analysis layer. Only you can actually know, do you need all of those, and where your primary risks are coming from, and so on.
So again, stop looking at labels and start thinking in what you are actually solving. But is a new kind of a dependency. So you have to have a registry, if you will. You have to have some kind of a discovery and classification solution, which would look for shadow MCP servers within your environment. You have to be able to validate where they are coming from, whether they are changing silently.
Again, you remember the deadbox issue, because somebody has deployed an MCP server, which was tested and found okay, but then it just silently changed the next day into introducing malicious tool descriptions. You have to be able to identify those changes. You should be able to pin specific versions, for example, just like you are doing, hopefully, for open source libraries. So when the library, or like an external JavaScript package, or something changes, it does not silently go into your next build.
It has to be vetted and validated, and only then you can say, yeah, it's safe for your future versions. And of course, you have to review the configuration of all those servers, because again, not just servers themselves, but your AI platforms, your API platforms, your other tools, they come with configurations, prompts. Now you have skills, you have specific description files aimed at agents, and various different configurations. You also have some kind of agent management platforms you're probably using from the cloud, or locally.
They all come with their own configurations, which means they all come with their misconfigurations. This is all you have to, for all of this, you have to at least be able to know what's going on, to say nothing about actually fixing those misconfigurations. Because obviously, again and again, you cannot fix what you don't know, even in this. So there is a lot of things to account for, but is it really that new? You probably, again, you already have a software composition analysis tool, you already have a pen tool, you already have, hopefully, an API security tool.
The question is, can they all be extended to solve these additional issues, or do you really need a specialized tool? And can that specialized tool replace all those existing ones, or should it be able to work together with them? So do you need a fabric extension? Do you need a replacement? Do you need something else? This is the biggest question to be asking.
Right, it's very close to what I do when it comes to identity and access management, really understanding what is required. There is this huge overarching term IAM, but what's in there is difficult. And I think it's the same here, if you say MCP security, this means everything and nothing. You just described some of the capabilities that are needed, but I guess there is no single tool, even no single tool category, which will provide these capabilities to the end-users.
And end-users, of course, they like to have a solution that's prefabricated, that they can just install and use, but that won't work there anyway, as it does not work for IAM. So do we need that fabric approach? And do we need, or do security architects need to weave that fabric for MCP security as a whole?
Well, again, what are the alternatives? I can think of two completely real alternatives. The first one is the obvious one. You delegate it to a third party, to a managed service provider.
Awesome, but then again, you probably already have an existing managed security service provider doing something else. Then you should be asking them the same questions. Can they do it for you?
Again, great way to shift the burden to somebody else's shoulders, but you still have to actually validate their claims. Another option would be, again, to go and shop around for a quote-unquote MCP security platform or whatever. But then again, how do you know what exactly does it do? Is it really next generation software composition analysis? Sounds sensible enough, but again, what exactly does it do? And what exactly does it do that another tool you already have for years doesn't do?
So again, kind of stop looking at labels, start asking precise questions. I have these challenges. Does your tool solve those challenges? How? What are the limitations? What are the scalability limits? Can I do the same across different clouds, for example? Can I do the same on an air-gapped environment? So on and so forth. In the end, even if you are not building your own fabric on a technical level, you should at least kind of design one in your head.
Because even if it's something which your approved third-party provider is doing for you, you still need to understand, at least on the conceptual level, what is it that they're actually offering and what are the gaps. Because in the end, it's still your responsibility if your customer data is lost or your infrastructure is destroyed and you have to recover. Nobody will take the legal and reputational blame for you.
Right, so I'm not a developer and the world is better off if I don't write code. But if I remember correctly, that software composition analysis looks at a build time. This is when you create software in the first place. If I watch my friend, the LLM, working on stuff for me and using our own MCP server, etc.,
it says, I'm creating a tool, I'm using a tool, I'm changing a tool, I'm trying to discover new tools and I use them afterwards. This all happens after build time or compile and linking time.
So, are these tools missing at least half of what they should be looking at? So, the runtime behavior, because they change over time, as LLMs do all the time?
Again, this is an absolutely valid question and a very right question to ask. The problem is, again, different people would probably have very different ideas how to address it.
And again, this is about challenging definitions. Because the quote-unquote traditional software security is also now dealing with a lot of code and deployments which are ephemeral. For example, containers and all those JavaScript third-party packages.
I mean, they all change all the time. And sometimes, the way applications are designed, they can even change in runtime. Question is, do you allow this? And then you have to build additional runtime controls for monitoring and securing those changes? Or do you make a decision and limit those changes and say, no, when I'm building my container image, of course, it should not be changed in runtime. That defeats the whole purpose of having a container image.
So, if we want to change our applications on the fly, we have to design an automated build process for that. There are different approaches. They all have their pros and cons, if you will. There is no single right solution for everything. Maybe you have to just kind of stop and step back and re-align your architecture.
Yeah, this will be difficult, but it will be solving your entire technical debt and future proofing it for whatever future challenges. I cannot decide for you. You have to do it yourself.
And again, if you're looking for specific technical and architectural and implementation guidance, we might help or other experts might help. But nobody knows your needs. Nobody knows your risks. And of course, nobody knows your future ideas, because that's your intellectual property, if you will.
So, you have to look for somebody to have a productive discussion with. There are no fixed answers for everything. Right.
So, we need to boil it down to capabilities that we should expect everybody needs. So, if we shift gears back to capabilities that you've mentioned, I think, and you've mentioned that already, you can only, and this is this truism that everybody says all the time, you can only protect what you know of.
So, finding the MCP servers in the first place is a key capability. So, inventory, but how do you do that with MCPs when these servers are fired up and retired within minutes or hours and no longer available? How does inventory work for MCP?
Well, again, the problem is that there is more than one kind of MCP. The most obvious distinction is there are some servers which run on a network layer. You just connect to them like you would connect to a normal REST API, because it's HTTPS, the same network transport.
So, you can absolutely scan for and analyze those network layer MCP servers using your existing API tools. API discovery can and should absolutely be extended to cover those. But MCP servers can also be run directly on the server, on the machine, using this STDIO interface. And those are like SSH keys. They can be everywhere. They can be on your developer laptop. They can be on your Linux infrastructure machine. Maybe they even end up on a container image or whatnot. And they can be ephemeral and they can be decentralized.
So, they need a different approach. How do you govern your entire developer stack? Should you probably have repository analysis? Should you probably have plugins for your IDEs, developer environments? Do you need some agentic governance to intercept an agent's request to such a shadow STDIO server, if you will? The gaps are multiple.
And again, there is no single tool which would cover all those gaps. But on the other hand, you probably already have tools that can cover three quarters of those gaps individually. The question is, how do you unify all those findings and make sure that they're all normalized and cross-correlated and give you a single picture? And how do you ensure that the picture is updated all the time? Right.
So, we are back to weaving that fabric. Inventory and discovery is part of the game.
So, it's not just a simple capability that you can easily describe. It's part of a bigger game. I'm afraid that we have the same thing for my next question, so that it will be a more complex answer than the question is. But if we use an MCP server and we consume data from there, this data goes back to the LLM, to the AI in general terms. And something that is often presented as a new challenge is prompt injection.
So, if I get a malicious or an unwanted prompt back from such an MCP source, how do I protect myself from that? But I think getting info back and just using it plainly as it is delivered is something that we had before. Or do you see that differently?
Again, prompt injection is often misunderstood as some kind of a new dark art worthy of studying at Hogwarts, if you will. It's something like, well, really smart hackers. You remember all those old movies where hackers used to type in stuff into terminals and hack FBI and the military and whatnot. Prompt injection is seen as the next generation of that kind of activity.
Well, it's not. Again, score is just input validation. It's like the oldest security problem which existed as long as we had programs running inputs. The biggest difference is what the prompt injection can actually achieve. If you just say, hey, copilot, tell me my boss's salary, and somehow it ignores all the previous tell me my boss's salary, and it does. This is prompt injection. Did it ruin everything?
No, but it still gave you access to sensitive data you should not have been accessing. Whose problem is it? Why had the copilot itself access to the data before? Should we blame the identity team? Should we blame the data security team, the HR team, somebody else who have to be fixing this? But imagine now you have MCP. Now you have agentic tools which can actually do things in the real world. What if you use prompt injection and your agent drops your production database? That's a completely different level of risk.
But again, is this the prompt injection problem or is it the problem of your DBA allowing an untrusted identity to execute system commands on your database? Because again, I've said that many times, nobody in your company, human or not, should be allowed to drop production databases. Period. If it's allowed, then it's not the AI problem. It's a DBA problem. It's an infrastructure problem, if you will.
So yes, it all highlights the same problem. Everything is now untrusted, especially the inputs and outputs of AI for different reasons. But they should never be trusted because they are non-deterministic. They always can be malicious and they're very difficult to reliably sanitize.
So yes, API security does not solve that major problem, but it does its job on a very specific subset on those issues. And of course, it has to be complemented with all other controls. Endpoint controls, database-level controls, network-level controls, only working together as a defense-in-depth multi-layered security stack, security fabric, if you will. It would give you a reliable enough protection.
And again, this will never be 100% reliable. So you still need your backups, obviously. You still need your business continuity scenarios. And you still need your risk assessment. What is more expensive? Deploying another 10 security tools or losing some of your sensitive data? Nobody but yourself can decide. Right. So what we can do, if I understand that correctly, we can control or at least try to control the downstream effects of such a prompt injection to say, OK, let's protect us from this. And you've mentioned all the parts of the mechanisms that are in place.
API security, proper least privilege in the end as a concept, downstreams for what an AI can actually do. And as you said, the example of dropping the production database makes pretty clear that just for doing a lookup in a database does not need to have full admin access to a database. But is it right or is it too simplistic to say, OK, if everything is authenticated, if everything is properly authorized following least privilege downstream, when these tools call something via MCP, via any API, are we safe then?
Again, you are asking very right questions. We can argue separately whether it's still relevant for specifically MCP as an attack vector or is it a much bigger question?
Because, yeah, I think it's a much bigger issue. Again, what you are talking about here, I believe that we can reliably or somewhat reliably secure a single individual API call. But does it automatically mean that the entire sequence of these transactions, even if going through the same API gateway or maybe going through a different set of gateways and combined with some other, what if it still breaks the original intent?
Again, an API gateway only checks a single API call, whether it's valid or not. And it can very well happen that several calls completely valid on their own combine into a malicious or at least to an unexpected result. This has happened before in very expertly crafted state-sponsored attacks. But now the same can happen with the help of AI on a scale which you just cannot reliably predict. So you have to be looking for that as well.
But again, this kind of only shows that you have to monitor on a higher level. You have to establish the logical sequencing of those calls. You have to identify patterns in those sequences. You have to monitor not just every individual table or record or file on the backend. You have to understand what's happening across them. Because again, the other end, the malicious actor on the other side can do cross-correlation and analysis across different vectors and can identify things which normally would require, again, kind of too much of computational and manual effort.
Now it can be done in real time. We know kind of somewhat less malicious examples from, for example, the advertising industry, which would monitor your individual activities in your browser or on an online shop or somewhere else. They would buy additional information about you from less reputable sources and then they combine those data and they know everything about you.
Well, the same approach kind of works on an industrial security level now. What if somebody is just doing the same level of monitoring of your legitimate interfaces and somehow kind of preparing for an attack? You have to think about that. This is a real risk. The question is, how do you do? How do you prepare for that? And who should be doing that in your company, by the way? That's a very real question as well.
Well, that means we are back at a question that we see in our daily advisory work in IAM all the time. And I think it returns with more force here again. So if we think of identity and access such a system or the right owners, and if you have plural, that always means collaboration, cooperation. So if you have an employee IAM, if you have consumer IAM, if you have B2B, if you have NHI, these are different owners, these are different teams, different responsibilities. And if we translate that over to MCP security, if there is such a thing, who owns MCP security in a typical company?
Well, that is exactly the problem. To put it bluntly, nobody does. Because MCP security, again, kind of, for the lack of a better term, let's continue calling it like that. It sits on an intersection of at least three major existing disciplines. One is obviously API security. And at least large companies have dedicated teams for that. Also AI defense, if you will, this newly emerging kind of AI security discipline. And a lot of companies do have special teams for that. And the last one is, well, it's still about non-human identity governance.
So it's probably some existing IAM team or a subset of an IAM department. Those three teams usually don't like each other very much. They probably sit in different buildings. They don't talk. And of course, they have different owners, tools, processes, and they never share their telemetry with each other. And this is exactly the problem. Because again, even while they're doing a good job at their own parts of the defense, there are gaps between and nobody owns those gaps. And attacks are successfully exploiting those gaps. It breaks the seams, if you will, the whole defense system.
So if you have an AI agent kind of having a delegated authority of a human with too much privilege, and it's using an unmanaged endpoint to exploit even if properly secured application but it is able to inject, for example, that poisoned tool definition into an MCP server, well, that's already enough to compromise the entire security stack. So yes, the threat model isn't new. And the org chart responsible for defending against them is definitely not new. If anything, it's too old. The problem is how do you synchronize those?
Again, this is not a technology issue. This is a business and process issue and ownership. Right. So we're back at the target operating models, at responsibility, at budgets, at people talking to people within the organization, and most probably also from the inside of the organization to the outside of the organization because of all these supply chains issues that you've just mentioned. So there should be properly executed communication even across organizational borders.
When we do, when you and I, when we do panels and moderations, the final question often is, and I like it and sometimes I don't like it, but this time I do like it. What are your recommendations? Because this is such an open field and not yet well tackled. What should an organization, what should a responsible person do on Monday morning? What should our listeners do for protecting themselves from at least parts of the challenges that we've just talked about?
Well, the most obvious and probably the most trivial response would be, well, you have to monitor an inventory and secure your MCPs. But that would not be very helpful because the next question would be, well, how do I do that? And the problem is, again, there is no single way to do it with one tool or within one team. You have to tackle it from multiple directions. So obviously, if you have already an API security stack that deals with gateways and server meshes and cloud native environments, well, somehow you have to expand that stack to also analyze MCP, at least on the network level.
Because again, they share the same protocols. They usually hopefully kind of work through existing known platforms like agentic platforms, for example, especially in the cloud. So existing tools probably already support that capability, at least partially. On the other end, you have to ensure that you also cover the endpoint footprint, if you will, because many of those MCP servers run directly locally on a developer machine, for example, and no network level tool can identify them reliably.
And finally, probably the best future looking advice as well, when you are designing your next MCP server, don't try to build it from scratch. Instead, try to implement it as a thin translation layer on top of existing APIs, hopefully reusing all those existing API security controls. And of course, you have to implement some kind of a policy, like acceptable usage policy for MCP, if you will, to explicitly disable, to explicitly prohibit the developers run those ungoverned local MCPs and instead enforce some kind of a central MCP server catalog, if you will.
And again, you can already do it with existing tools. Like for example, if you have a team or an enterprise subscription for a cloud with some existing monitoring and governance controls, you can probably do it even better with a proper enterprise-grade solution, which we will not advertise in this chat, but we can definitely talk about that in specific customer projects. And of course, again, you have to fix your processes.
If you are a CSO and you have three different security teams which never talk to each other, which only talk to you, well, you have to teach them to work differently because this kind of military-style chain of command just doesn't work anymore. You have to make sure that different teams share their threat signals. Wow. That seems to be a challenge that we cannot solve within one episode, of course. And I would love to continue that conversation. At some point on such a podcast, we just need to come to an end.
So the question is, if the audience wants to continue that conversation, and especially wants to continue learning more about that, if we look at Küpping & Kohl research, and I know you are very active in providing that research when it comes to MCP, to API security and cybersecurity in general, what would be the recommended reads that you would like to hand over to our audience as the next step? Well, we definitely have quite a few publications in our research library. You can just go to our website and search for MCP or something like that, and it will give you a list of recommendations.
I mean, I know that I wrote it myself, but I really like this kind of quote, models reason, APIs act, and identity grants the authority to act. This is kind of a one-line summary from one of my recent publications on this specific topic. And basically, it gives you all those recommendations, how to consolidate those three disciplines into a single working fabric, if you will. Because you cannot just do it once per MCP incident. If your existing process involves rallying up the troops to address the next published vulnerability, it will never scale. You have to get ready in advance.
You have to share the risk findings, the threat signals, and of course, the security controls. Only then, it would work as a proper fabric.
So again, kind of look up, keeping a close eye on the security fabric and identity fabrics. I think it's worth your time in the reading and understanding the approach. Great final words, and we will continue that conversation. I'm pretty sure that we will come back to MCP security if there is such a thing, but more to get to an overall fabric approach to protect modern architectures and modern organizations. I think that's the more adequate way. And MCP is a symptom. It's not a disease, I think. So thank you very much, Alexei, for being my guest today. We will continue that conversation.
Always great to have you in that podcast because it's always something where I can learn a lot. So thank you again, and I hope the audience also liked it. And I've mentioned, of course, panels and moderations and events. There are upcoming events which I would really like to highlight for the audience as well. So there will be two more impact days per today. We are looking at the AI and NHI security impact day, which will be in just a few weeks. There will be one around consumer identity, and there will be an event around identity-centric security together with Heidel.
And all of this will take place in Germany later this year. So if you are already on our website looking for MCP research, also look at the events page as well. There is a lot of interesting stuff to come and where you can meet us for personal discussions as well.
So again, thank you very much, Alexei, for being my guest today. See you at events and see you in an upcoming episode very soon. Thank you. Thank you very much, Matthias, for having me.
And yes, thank you. Have a nice day. See you. Bye-bye.
