Welcome to the KuppingerCole Analysts Chat. I'm your host. My name is Matthias Reinwarth. I want to welcome my guest for today. It's an elite analyst in cybersecurity and our Welcome, Alexei Balaganski. Thanks for having me, Matthias.
Hello, and it's good to be back. Great to have you. And we want to talk about a topic that you have been looking at and covering for quite a while. We just before this episode, we just were thinking how many times you covered that topic over the years. We came up with four or five times. But the good thing about topics in cybersecurity is that they just don't stay the same. So for today, we want to talk about API management and security. And don't go away, this will be a ride.
Because Alexei, how much is left from the original version of API management and security that you did six, seven years ago? Well, it's actually been 10 years ago when we started digging into this topic.
Yeah, almost exactly 10 years ago, it was a very different world. There was no AI, there was much less cloud available. And of course, we had iPhones, of course, but they were not as widespread as today.
So yeah, APIs were a technical thing. It was a developer thing, a universal format for basically developing distributed applications. This is where we started. This is how we started looking at them 10 years ago. And unfortunately, this is how a lot of people still perceive APIs nowadays. A lot has changed, including on this whole AI elephant. Right. And if I think of API security, and I know I'm not the expert in that area, I think of API gateways, about protecting APIs, registering them, understanding them, describing them, this has changed, right?
Well, again, since we now are all implementing AIs everywhere, and of course, we have to keep in mind that the AIs of today are not even the same as AIs of two years ago. No, things have developed on their own. And the more sophisticated, the more distributed, the more interconnected those AI systems become.
Of course, the more APIs have to be involved, because every action you are performing through an AI-enabled system essentially starts a cascade of API calls between all those agents and endpoint systems and databases and cloud services and mobile devices. Basically, everything which is now connected over the internet is connected over an API. So it's mind-bogglingly complicated. And of course, it's just as insecure, unfortunately, as it was 20 years ago or 10 years ago, right?
But when the infrastructure, when the platforms, when the systems have changed, that obviously also means that the threat landscape has changed, has expanded, and has mutated over time. So if I ask you if you are still protecting systems against prompt injection or data exfiltration, is this still a thing or is this just a small part of the equation?
Well, if you continue talking about AIs, you have to understand that an AI system today is no longer just an LLM, not just a language model where you would ask a question and it would think a little bit and give you a response. So yes, you have to feed it with more information. It was valid before and it's still valid now.
And yes, prompt injection is an important risk, a threat. But I think that now you probably are, tomorrow you will be interacting not with a single LLM, but with thousands or even hundreds of those.
And they will be talking to each other directly behind your back, because whenever you basically give your favorite AI agent a task for today, write me a report, find me the best candidate for our open position, or run this specific mathematical experiment somewhere on the cloud, whatever your job is, those AI agents will be communicating on your behalf, but they will be talking to each other without your approval or oversight. And all of those interactions have to be protected, because if your favorite agent can book a call with someone on your behalf, somebody can exploit that API interface.
If your AI agent can start a manufacturing machine somewhere in your plant or whatever, it's an even higher risk. And all of those will be, and they are already actually being implemented, all those interactions, they have to be secured, they have to be monitored somehow. And essentially this is the job of an API security expert. So when I understand you correctly, so agentic AI, the communication originating from AI agents, and then also coming back to AI agents as consumers of APIs, is increasingly important when it comes to using API management and security platforms.
And that means combining management and security is essential. And I've talked about that topic in various cases, because all these AI agents that you just mentioned, they also need to have an identity, they need to have a proper profile, they need to have attributes to understand what they do, what they're allowed to do, and what they're not expected to do. But in the end, these are agents, and agents is closely related to the term agency. So they do something autonomously, they do it on their own within their expected realm of behavior.
So also access management and security has changed to this different type of behavior. Well, this is like a separate whole new kind of warms, if you will, probably was a separate analyst chat episode or two or five.
But yes, you're absolutely right. What people seem to forget is that even though there is a lot of things emerging nowadays that will be done by non-human systems, agents, or just a traditional server, if you will, or a client, or an API host, or whatnot, all those activities are still done on someone's behalf.
Someone, a human, hopefully, is still responsible for all those activities. And this is why it's in our, as humans, greatest interest to make sure that all those interactions, all those agencies, if you will, are aligned with our human goals. As soon as you are allowing an AI agent, an automated system, run freely and do whatever it seems worth doing at this moment, well, you are basically enabling a future Terminator scenario. You are building a Skynet, and we don't want that.
And as soon as you want to actually make sure that your AI assistant won't go rogue on you and actually always do exactly as you want, you have to have a lot of controls in place. Not just monitoring, actual guardrails, audit trails, prevention, if you will, and runtime security.
Basically, it's, again, the whole entirety of existing security as we know it, from the low-level hardware and networking access to the highest level of business logic analysis and policy-based access management. Everything has to be expanded onto these, as they call it nowadays, non-human identities. But the problem here is not that identities are different. The problem here is that the scale increases a hundredfold, if not a thousandfold, overnight. So it's very difficult to make sure that it all works in a predictable and foreseeable and observable way on that scale.
I look at this more from the identity perspective. You are looking at it from this API security and management perspective. But I think the technology that at least I realized as being more or less one of the silver bullets for curing these issues is MCP, the Model Context Protocol, that is often mentioned when it comes to being the loophole where every API access needs to go through. Is this something that you can confirm from the product landscape, from the overall design of these fabrics that you're creating?
First of all, let's just take a step back and have a 10,000 feet look down upon this whole API thing. So it all started back when applications needed to talk over network. Every time you have a client running on one computer and the server running on another one, you would have to connect them somehow. And that would be called an API, an Application Programming Interface.
And it evolved in an almost mainframe-like model where you would have an API gateway, a massive piece of network infrastructure which would expose, centralize, and manage multiple API endpoints for different servers and, of course, for different clients. And this was like, and it still is for a lot of people, the way how they understand API management. It was like a massive mainframe which centralizes all your APIs for different things and purposes. Not how it works anymore. This view is outdated for at least 10 years or something.
Nowadays, API interactions are all decentralized. First of all, we had these microservices and cloud-native applications where basically every small part of your app would talk to another small part of your app over an API. So we had this need to evolve API service meshes as a decentralized, small-scale hub for enabling all those interactions between different parts of your application.
Now we have the same decentralized thing at a global level because, again, everything, every system, every database, every cloud, every application, maybe in the near future, every car and every coffee maker and whatnot, they will be, at least in theory, controllable through an AI. And to enable that, we need a standard. And as I mentioned, this standard de facto at the moment is MCP, Model Context Protocol.
This is a standard which allows an AI agent, an application powered by an LLM, to control physical world or digital world, whatever, to pull data from a database, to start a car, to tell your coffee maker to brew fresh coffee and stuff like that. And, of course, MCP is just another kind of API. And if you want to make sure that only you or your family members can actually start your coffee maker and you don't want your car to suddenly drive away from you, you have to make sure that all those APIs are properly secured.
And unfortunately, just like 20 years ago with the rest of APIs, MCP isn't really well prepared for fine-grained authorization and security controls and whatnot. It was never the priority. The priority has always been bring your product to the market first.
Otherwise, there will be a competitor offering a different product. So, yes, MCP won the first round. Now they have to grow up and mature to become properly, strongly, manageable, observable, and secureable solution for this entire API world. Now that we've talked about MCP, are there other competitors, other technologies that you have encountered during your research around API management and security that fill some gaps or are just competitors?
Well, again, there is a lot of different standards and solutions and frameworks emerging because, again, this is a very hot topic. But I would really prefer not to talk about them today because these are all things of the near future and we don't know yet who will emerge as a winner. What I wanted to mention is absolutely a couple of other things which are not directly related to API management or even AI security but are nevertheless going to influence this whole evolution a lot. First of all, it's this whole notion of edge computing.
You know, we have the on-prem, our local computing devices, laptops and other devices. We have the cloud somewhere far away, a virtual mainframe, if you will. But we now have this third layer, the silver lining behind the cloud, the edge.
This is extremely important for various scenarios, for occasionally connected things like vehicles and ships and spaceships, if you will, for manufacturing environments or for just highly distributed applications like, well, how would you run a database which has to be present and close to every consumer regardless whether they are based in the US or Brazil or India. You have to spread your application logic to be as close to those consumers as possible. This is where this whole edge thing lives. A distributed platform for running a computation as close to consumers as possible.
We've seen solutions from large providers like Cloudflare, for example, or other CDNs. Now we have even more interesting emerging technologies like WebAssembly, where you would run your computations directly on the endpoint device like my phone or your browser, for example. This is what Java promised us 30 years ago, but never actually delivered fully.
Well, this is like the second and presumably most successful attempt. So basically, nowadays you can run an API service anywhere. It can be on a gateway, it can be on a service mesh in the cloud app, or it can be directly on my phone or on your browser, or maybe even in the webcam. And how do you secure that? How do you make sure that there is no malicious actor hiding in my webcam right now trying to do something with my local AI model or your local AI model?
The level of decentricity, decentralization of the upcoming new world is so mind-boggling that everything becomes determined by the level of API security again, because you have to protect, you have to monitor, secure, and audit huge amounts of decentralized traffic. There is no gateway anywhere, there is no tap port you would look into, because there are millions of those ports. Somehow we have to figure out how to enable this on a massive scale, which is much bigger than anything we had, say, five years ago. And it all boils down to APIs, because APIs are the connective tissue.
They're the logistics behind all those activities, whether business-related or something else. Whether it's about your money or your products or your life events, it's all basically now running through APIs.
Right, and first of all, really interesting. One thing that just came to my mind when you said we are losing this centralized aspect, because there is no centralization anymore because APIs are distributed. One key aspect that I remember of API management and security was the detection of shadow APIs, not well-protected, forgotten APIs that were somewhere around used by a developer or two, and not actually well-secured, not well- managed, maybe even insecure in themselves with the functionality, the remote procedure calls that they provided.
Are these solutions that you just looked into also A, detecting them and protecting them and managing them as well? Yeah, absolutely. If you go out nowadays and start shopping around for any kind of security product, you would instantly hear about posture management, whether it's a cloud security posture management or data security posture management, or now we have API security posture management, which is basically understanding what you have. Before you start protecting something, you have to know what you have to protect in the first place.
And yes, shadow APIs are those which are presumably not managed by you by design. It might be forgotten APIs, it might be third-party APIs, maybe some built-in embedded management things, interfaces and whatnot. And the biggest challenge for a company is to just account for them all to make an inventory. The problem is when you start talking to different vendors, everyone has a very different understanding of what a shadow API actually means. Some vendors, as well as a lot of customers, are very much developer-centric.
They would say, our company is a provider of, let's say, we are a digital bank, so we have like 10 primary financial APIs we have to care about, we invest in tons of resources into securing them because they're highly regulated, and we don't care about all the third-party stuff because it's not our responsibility. I would say it's a very short-sighted approach and you never know how you can be compromised. You probably know the famous scenario of hacking a casino through a fish tank pump API.
And even if you don't have a fish tank in your office, you probably have a printer with a network interface or a webcam or Amazon Alexa device or something like that. And they all have APIs which are unaccounted for and unprotected. So absolutely, you have to know them all. You have to at least be able to assess their risk and say, yeah, this is within my risk appetite. I am not going to do anything about my printer, but I would rather invest in securing my primary APIs more. Or you would say, no, we want to have an entire posture and secure it as best as possible.
So there is a lot of tools out there. There are so many different ways you have to scan your environment for those APIs. You cannot just connect to a known gateway to, hey, tell me which APIs we publish. That's not enough. You have to be able to sniff network traffic, to look through your source code, maybe to connect to your GitHub account, for example, and go through all of your repositories. You have to monitor endpoint devices.
Basically, you have to integrate with all your existing security tools to look for specific fingerprints of API traffic. And as soon as you identify those, you can start doing your inventory and classification and risk management. Fascinating. So we have AI everywhere. We have APIs everywhere. And those two together lay a foundation of new types of architectures. You looked into that from the perspective of creating a new leadership compass, API management and security. Can you tell us a bit more about that? What is the focus? What are the main results, new vendors, market consolidation?
And when will it come out? Well, I just finished writing it yesterday, actually. So it will be published probably sometime in July after it will go through all the reviewing and fact-checking rounds as usual.
Again, we started doing API security market coverage 10 years ago. We've updated this report at least five times. I even lost count myself. And every time, the results are different. First of all, because the actual domain of this area is growing and evolving so rapidly. And the second, of course, the market itself is very turbulent. Some of the companies which I hailed as amazing leaders two years ago, well, some of those, of course, still remain, but others were acquired and integrated into some bigger vendors. Some have maybe kind of changed their focus and so on.
The results will be interesting even to those who have read the previous one because, again, this market changes at a rapid pace. But basically, the whole point of this updated version is the scope of API management and security continues to grow. There is no such thing as two separate API management and API security industries. They are merging together more and more, and it's up to us to decide whether it's more management-related or security-related.
I would argue it's both, and also observability, and also everything, including even sustainability, because cost is now a major factor as well. And if you want to be green and sustainable and reduce your operating costs, there are some solutions out there available already. But the most important thing is basically that it's now even more important to take care of your shadow APIs, to shift left, right, up, down, and in all directions to make sure that you cover the entire API lifecycle, ideally even before you start writing any code.
But if you design your API properly with security by design in mind, it would save you a lot of effort later. And, of course, that, again, API management has now become hybrid in the same way cloud applications became hybrid and identities became hybrid earlier. There is no centralized gateway you can manage. You have to deal with all those sophisticated and decentralized and very, very different environments where you have APIs. Right. This is really an interesting topic, and I would love to continue doing that because we have not talked about regulations, GDPR, for example.
We have not talked about the AI Act, and we talked about AI a lot. But we have not talked about resilience. So APIs are now the key capabilities or business capabilities of an organization. And if they are not available, the company is not available. The business services are not available. We have not talked about that. So there's a lot more to cover. I think a lot of this is in your leadership compass. So I highly recommend when you're listening to that to go to coopericole.com and find the leadership compass API management and security.
Once this episode is published, it should be close to being available as well. And before I thank you, Alexei, I just want to make sure that everybody out there who thinks, hey, they missed that topic, leave your questions below this video on YouTube. Drop us a mail. Drop a mail to Alexei, to me. And we will follow up on these questions because this API topic is getting more and more important, as you just described. It's the glue between components, and it's really tying services together in this hybrid world that we're doing that. I do that for the identity fabric.
You do that for a type of API fabric, I assume, and as part of an overall cybersecurity fabric. So this is really amazing developments that we're just witnessing. And that's just great. Having said that, thank you very much, Alexei, for being my guest today and for shedding a light on this interesting topic. And when you hear API security, you just don't see the full picture initially, and you described it very well. It's really so important. Thanks again.
We have to think about it in the same way people probably thought about telegraph in the 19th century, and then radio and television and internet. Those were all, in a way, revolutions that have profoundly changed the way we consume and produce and exchange information. API ecosystem, economy, along with management and security, is just another revolution in the historical scale of development. So absolutely watch this space because we will be covering it more in publications and probably in future episodes of this podcast.
There is a lot to watch, and you are right, finally, in the regulations catching up. So regulating your AI systems and API systems will become much more pressing and relevant.
Again, watch this space. Absolutely. Great final words.
Thank you, Alexei. I don't add anything. Looking forward to seeing you again for another episode, maybe on APIs.
Thank you, Alexei. Thank you, and bye.
