API Platforms: The New Security Perimeter for the Age of GenAI and Agentic Systems

Well, hello and welcome to another KuppingerCole webinar. My name is Alexei Balaganski, I am the lead analyst at KuppingerCole and our topic for today is API Platforms, the new security perimeter for the age of generative AI and agentic systems. This is KuppingerCole's research webinar where we are presenting the current challenges we observe in our research and of course show the findings of our recently published leadership conferences and other papers. So today we are going to discuss our recently published leadership conference on API security and management solutions.

Before we dive into the topic however, a few words about the housekeeping rules. Everybody is muted centrally, you don't have to worry about the microphones. We are in fact not planning any polls today, even though we could. The Q&A session will be as usual in the end of the webinar, but you are very welcome to submit your questions at any time using the questions tab. And I might even pick them up during my presentation if they are relevant to a specific slide or topic. We are recording this session and it will be published on our website along with a slide deck.

Probably tomorrow and everybody who has registered will receive a link to it. And also since this kind of webinars are usually available for anyone without registration, I would be glad if you could share this recording with your colleagues or any other people who you think might be interested in the subject. There is not really a very formal agenda for today. I will start kind of explaining the current state of the universe, IT and security markets. I will try to show how generative AI and the genetic systems will further complicate all the things around them.

I will give you some hopefully practical recommendations and then we will be talking about specific findings of our leadership compass. Again, feel free to submit your questions at any time. And without further ado, let's dive in. So as I like to start almost every my presentation, what a time to be alive. So much interesting stuff happening around it, like in the notorious Chinese curse.

But yeah, some of those interesting things happening include multi-cloud environments and hybrid architectures, mobile workforces, especially after the COVID pandemic, everybody's working from home. We have so many managed and cloud-based collaboration and business tools where we do not have enough control over the security and protection of the data. And of course, we have the elephant in the room, the generative AI, the next industrial revolution happening around us as we speak.

And finally, even if you do not even believe or worry much about all those developments, there's always compliance you have to think about. So yes, we are living in a very interesting, very complicated and profoundly insecure world. And APIs actually play an increasingly large part in that complexity. A lot of times you would hear that business data, sensitive data is the crown jewels of every business. Or you would hear people saying something like data is the new oil or anything like that. I would argue no, data is not actually oil. Data is the new air.

Because having access to your data is exactly the same as being able to breathe. As soon as you are gasping for air when you don't have enough of it, if there is something wrong with your plumbing delivering your air, just like on the picture, well you are in big trouble. And you have to remember that modern IT is no longer in the era of mainframes or even public cloud services. It's highly dynamic, it's highly distributed, heterogeneous and ephemeral.

You have instead of one or two or a dozen of business applications, you have thousands if not tens of thousands cloud-native workloads, containers, AI agents and other things. And APIs basically act as connectors. They transport data between those things, they orchestrate business processes, they integrate devices, clouds, IoT, fleets and again AI agents as well. They allow them to work together, mostly hopefully. And basically every business and enterprise function nowadays, from a retail transaction to a massive AI powered business decision, they are all mediated by APIs.

They are the channels for business logic flows. And whether you like it or not, APIs are critical infrastructure. You have to consider them as such, because if you do not, there is enough malicious actors outside who would think otherwise and exploit the opportunity.

Of course, APIs started over a decade ago with that Cambrian explosion of REST APIs, but nowadays the tempo and the scale of that complexity is absolutely mind-boggling. We know that there are so many different types of APIs for different use cases and purposes.

REST, of course, is still dominating the market, but we have GraphQL, we have RPC, we have streaming protocols like Kafka, and of course we have MCP, about which a minute later. More importantly, we have highly fragmented environments, multi-cloud service meshes, edge deployments, all of those things communicate over APIs, and there are just too many of those APIs. Some are nowadays called shadow APIs, because nobody actually knows that they exist, or because they're undocumented.

They might be third-party, they might be created by rogue developers, they might be something forgotten, but while they are out there and they are a huge risk, there are also zombie APIs, which used to be important, but have been long duplicated, but still live somehow in a half-dead state. You have to deal with all this complexity and a growing risk pool, because with great power comes great exploitability, if you will. And of course, generative AI and agentic AI introduce an additional layer of complexity, simply because there are so many things happening in this field nowadays.

But one thing we have to emphasize again and again is that AI models do not exist in vacuum. AI agents, as well, always speak the language of API. AI systems interact with anything via APIs, different kinds of APIs, depending on whether you are talking to a model as a human, or if you utilize a fleet of AI agents, or if you are building a complicated AI-powered tool chain with multiple MCP servers and other sources involved, you are using APIs, you are using a multitude of different APIs. And of course, if something breaks, the results will be fatal.

Most attacks on AI systems nowadays are actually attacking not the models themselves, or training data, for example, because their exposure to the internet, to the outer world, is very limited. But they are attacking data sources and they are attacking API interfaces. This is how you perform prompt injection, this is how you organize data leaks, token abuse, and other types of attacks.

And when you have like a real, or when you are going to have like a real complicated system of autonomous agents working for you, maybe tomorrow, maybe in five years, but sooner or later this will happen, those risks will be amplified by many, many times, if not orders of magnitude. And to deal with those risks, you have to be able to understand what's going on. You have to understand the business context of every such transaction, you have to understand the intent, like why a certain AI agent is doing what it's trying to do. Is it a part of a bigger task or objective?

Does it actually align with your stated policies? And is it still following some instruction from somebody and who is responsible? You have to understand the context behind every agentic action at runtime, in real time, and again all those activities basically happen through APIs. So obviously you cannot secure AI without securing APIs. Because just like with the early age of the cloud, and then kind of the early age of RESTful APIs, security is unfortunately an afterthought, an all-time.

I think many companies would ignore knowing that their priority is bringing their products to market first or beating competitors in accessing some data or grabbing as much data as possible from the world. Security is always seen as something which hinders, that stands in the way. And of course, when we are talking about MCP, the scope of this API security extends to the entire world, because everything now speaks MCP. For those who don't know, MCP stands for Model Context Protocol.

It's a standardized interface protocol designed to facilitate exchanges between AI agents and the rest of the world. Databases, websites, applications, clouds, and so on. MPP is just another API protocol. It's based on existing standards, but it's expanded. It has been designed to accommodate the way AI agents think. There are no certain rules, there are no certain policies. The agents are able to look up and discover what tools a certain MCP server is offering, and then figure out how to use those tools for different implementations. It's very easy and quick.

You just expose an existing set of functions, capabilities, maybe a database or an application through an API, and magically every agent in the world can now tap into it. The ecosystem is massive and rapidly growing. The workflows become structured, composable, and explainable, and agents can collaborate between different clouds, systems, and heterogeneous systems. But the risk, again, is obvious. There has never been much thought given to security and data protection. There are some rudimentary access controls built into MCP, but not really the full scope of API security capabilities.

And again, we will discuss those capabilities in this webinar as well. The biggest challenge I see here is that everybody is basically trying to build their own MCP server for any existing tool, product, or service. But implementations and threat mitigation strategies vary dramatically. Some vendors will just build a direct interface to their existing database, with minimal access controls and zero security controls, and call it a day. This is like building a huge open gate in your castle wall, without any guards, without any kind of security. Some are strategically more sensible.

They first create a proper quote-unquote old-school set of APIs, then apply a full set of API security controls, and only after everything is tested and works as expected, they would build a thin MCP wrapper around that architecture. This is a much better way to do MCP, but unfortunately, it has not been standardized yet.

So, when we are talking about agentic systems, besides all those kind of low-level existing security threats and risks we already know, like data leaks, and account takeovers, and denial-of-service attacks, and whatnot, you have to often think a lot about much higher-level specific issues. And first of all, you have to think about the scale of it. Don't forget containers and Kubernetes. Forget NHIs, where supposedly machine identities outnumber humans like 100 to 1.

If we actually follow the plans of current AI vendors, we will probably have millions, if not billions, of autonomous agents running errands on our behalf. And the scale of this, and the entire world becomes our attack centers, if you will. And a lot of those issues we have to now deal with are not that deterministic by their nature.

Like, AI itself is not deterministic. The AI risks cannot be boiled down to rules. You have to think about prompt injection manipulation, which is somewhat half-understood already as a kind of science of its own. But you also have to think about goal management, and how to prevent unintended autonomy of those AI agents. When you describe a task to an agent, how can you make sure that it interprets it correctly, and that it stays aligned with your human goals at all times? How do you monitor this alignment in real time, and how do you prevent potential abuse if an agent goes wrong, if you will?

What happens if it develops its own emergent behavior and starts working in a way you never anticipated? How do you prevent it? How do you stop it in time? How do you ensure that you never lose control over those agent fleets? And of course, how do you make sure that those agents do not abuse your existing tools like MCP servers, and do not end up destroying your data, your code, your customer data, or your entire physical infrastructure? Because nowadays everything is API controllable, including power stations, and satellites, and whatnot.

So the risks are massive, and unfortunately they are still kind of poorly understood, not just in terms of dealing with them, but just to understanding the actual scope of those risks. And unfortunately, what we have now is this emergent idea that AI security has to be its own standalone discipline, specifically designed and developed from scratch to secure AI systems.

I've heard more than enough vendors trying to sell their solutions using this moniker, and saying, yes, only AI can understand another AI, and only AI can prevent another AI from acting maliciously, because, well, it has to outsmart an AI, and obviously a human cannot, because it's too slow. Well, that's a very wrong assumption.

So our, if there's like one, there's one takeaway you would have from this webinar today, it should be that there is no AI security as a standalone discipline. Stop preventing the will. You have to understand that most of the things happening inside and outside of AI systems works over the same infrastructure protocols, data tool formats, and as the rest of IT. And the goal is always to protect the data, not the AI itself. Sometimes you don't have to protect the data from the AI, if you will, both at the source and in the workflows.

So AI security is ultimately, it can boil down to a very simple formula. So behold, AI security is in essence just API security plus data protection. There is nothing magic in it. You can of course discuss the scopes and the relative priorities. Do you have to invest more in API security or data protection or both? Who has to own the entirety of your AI security and solutions and like AI security fabrics? But ultimately, there is nothing new to invent. There is no magical AI security will.

You just have to reuse your existing tools, but perhaps adapt them for the new level of scale and real-time decision making. And of course, whenever you try to talk to the non-technical people and explain that yes, while you do not need to rip and replace your existing security or architecture, you need to invest in additional tools and capabilities. It always helps to talk to them in a language they understand, the language of business.

So API security can be seen as a business enabler if you just stop thinking in terms of okay, how do I prevent a data breach or how do I save the number of tokens burned and think about how do I protect the dollar spent, if you will? How do I improve my compliance posture? How do I ensure that my AI-powered business products and services remain accessible and can be delivered to a customer, hopefully a happy customer, anywhere around the world?

And yes, of course, you still need to think in terms of edge deployments and Kubernetes and GPU clusters and whatnot, but it's not the goal. It's just a means to achieve a business enabling goal, how to make your business work smoother, faster, and in a way more profitable. And with that regard, if you do not have any questions, and I think we even have a very fitting question in that regard, so how do we need to build this bridge between APIs and revenue and business context?

We would probably need another hour or another separate webinar to just talk about this subject in detail, but again, you should always start with understanding that you do not need to burn a lot of money. You don't need to invest a lot in new tools, in kind of new kind of tools that some sneaky peddlers out there are offering. You have to, first of all, start by understanding what you already have, how well your data is covered, how well your APIs are protected, and how all those existing investments fit into the whole security fabric, the whole AI security fabric, if you will.

But you have to be able to explain all those investments and potential improvements in the language that talk about money in the end and profits. Yes, you are not burning tokens, you are saving dollars, you are not blocking bots, you are helping legitimate customers to get better level of you are not kind of introducing another level of complexity for your business line units, but you are actually improving the productivity by taking away the burden of compliance from their shoulders, for example.

And the solution is, well, there is definitely more than one solution, and we will be talking about the specific API focused ones in a second. But yes, you're right, protecting the identity is a big part of it. To be honest, I would say there is no cyber security without identity nowadays, period. And let's see how it actually becomes a part of the overall API security fabric, if you will. So just recently, we have published a leadership compass on API security management solutions. And just for those who are not yet familiar with our methodology, a quick recap.

So what we have found while doing our research is that, well, some of those things I have already talked about. Yes, APIs are the backbone of AI. Shadow APIs are perhaps the largest cyber security risks around APIs, especially when those APIs have something to do with business logic. Shifting lead is a great term where people would say, yes, let's actually make our developers thinking about security and building the code secure by design, which is great in theory. But unfortunately, developers have their own job to do.

And it's still our job as security experts, if you will, and security teams to find out how to combine shifting left and right and up and down all the other directions. My point here being that API security must cover the entire life cycle.

And yes, the complexity is growing, multiple gateways, hybrid API fabrics, agilative enforcement, new things happening, new technologies emerging, trying to tackle this complexity. Let's dive into details. We have identified some eight major ranking axes, if you will. This is how we measure the primary required capabilities of an API management or security solution. It has to cover the entire life cycle. It has to deploy and integrate into a broad range of existing infrastructures and ecosystems. It has to support developers.

It has to offer very strong identity and access controls and monitoring. Back to your question, if you will. It has to deal with proactive vulnerability management, identifying those weaknesses and problems in advance. But at the same time, it has to be able to provide real-time analytics and visibility and observability to detect zero-day attacks and kind of anticipate future problems, not necessarily security-related ones, but stuff like proactive maintenance, for example.

It has to be able to actually offer active protection against threats, be it something simple like DDoS and bots to some targeted business-level attacks. And finally, it has not to be in the way. It has to be able to scale and offer a reliable performance level for every deployment. We have analyzed 26 vendors in our latest report, and I've just listed a few logos here. You can see that the API security and management market is still very much diverse and turbulent.

Just a week before the report was published, for example, we have found out that Merzif, one of the very capable API monetization solutions, has been acquired by WSO2, who was, by the way, one of our overall leaders. The market is quickly evolving, and this is why it's really important to stay on top of all the recent developments. Some vendors are large, like Akamai and Cloudflare. Some are very, what kind of, boutique and niche solutions, like Nevatek, for example. Some have been with us for over 20 years, offering API security for over 20 years, like forum systems.

Some have just started offering it very recently through acquisitions or just kind of organic understanding that API security should be a huge part of services offered by a company like Akamai or Cloudflare. Just by looking at the vendor logos, you should, I believe, feel the urge to read more about each of those solutions, because this is a fascinating subject of its own to observe how the market evolves. We also have listed a few logos of vendors to watch.

Those are companies we also know, we have talked to them, we understand their capabilities, but for whatever reason, they decided or could not participate in our rating. Yet, some very interesting companies are on there, some truly revolutionary and innovative, some kind of old school and existing a very long time. Some very focused on things like solving just the access management and identity problem for APIs, and so on. Some are specifically focused on solving European markets.

Again, a lot of things to discover if you want to know more. And here, straight to the overall leaders.

So, we have ranked all those 26 vendors according to our methodology, and we have identified the following companies as the leaders. You can see them on the right. WSO2 as the overall leader and a bunch of companies following, all offering a combination of very sophisticated product capabilities and a strong global market presence, partner networks, and of course, large customer bases.

And again, it's really interesting to see both large companies like Google and really small and almost like startup sized companies like 42Crunch competing almost head-to-head simply because we believe that our methodology kind of represents a very interesting mix of the capabilities, the size, and innovation. So, if there is a company which only solves one problem, but does it extremely well, we will recognize them as leaders as well.

Product leaders are, again, those who offer the biggest, the broadest API management and security capabilities, and I wish we had another hour planned for us and I could go through every of those vendors. But again, just to give you a couple of examples, 42Crunch is only focusing, or primarily focusing, on the shifting left part, the early stages of API development, where they would offer you a set of tools to ensure that even the API contract on its own, before you actually have written any code, is already secure and resilient by design.

On the other hand, you have companies like Forum Systems, which have been serving very demanding and highly regulated customers for over 20 years, only offering them hardened API security appliances. Or we have Akamai, again, a very well-known cloud service provider, which integrates API security as a necessary part of their much broader portfolio, or Cloudflare, which basically just started doing the same very recently. We have companies like Gravity, which are trying to build the same level of API security for, quote-unquote, non-traditional protocols, like Kafka, and so on and so forth.

But there's a lot of stuff to analyze, to dig into, I can only recommend you reading the report and asking questions specifically about each vendor. And yes, the same we have for innovation leaders. You don't have to be huge to offer something which nobody else can, and you can see, again, how we have vendors like WSO2 and Akamai on one hand, and Salt and 42Crunch on the other. There are many different ways to achieve innovation leadership. And finally, we recognize market leadership as well, and of course, probably no big surprises for you.

You can see that the largest vendors have, of course, the largest market presence. What we also provide for each company is a detailed explanation of product capabilities, strength, and challenges, as well as a spider chart which demonstrates how well it can address each of those eight axes of required capabilities we have identified beforehand. And if you go and check our website, you will be able to play with it interactively and see how well those solutions actually address different types of use cases.

If you have ever read our buyers' compasses, for example, you would know that those are the companion reports for leadership compasses where we explain not just why you should choose a specific product over the competitors, but how do you approach that process, like which questions you should ask a vendor, or which capabilities are required to address a specific use case.

And here I have just listed a few primary use cases for an API security solution, ranging from protecting AI models and agentic workflows, to security posture management, to monetization ecosystem buildup, to compliance, or designing a unified and optimized API security framework. And of course, for each of those use cases, we help you to understand which capabilities are more important and how those capabilities translate to the use case fulfillment. Do we have any further questions?

Yes, we do. So, are we treating MCP2 inventory and least privilege as stable stakes?

Oh, we do, definitely. This is what I've been talking about earlier in the presentation. But the question continues. Why do teams still dodge this when tools drive 99% of exposure?

Well, I think I even mentioned that as well. Security for many teams, especially if it's not a security team, it's only an afterthought. Or even worse, it's a hindrance. It stops you from bringing your product to the market as quickly as possible, and prevents you from starting earning dollars from the product.

And again, MCP is a wrapper, this is true, but there is more than one way to create a trapper. And there is the right way, which is basically designing a proper API security gateway first, and then adding a thin additional layer of MCP-ness on top. There is probably a much more complicated, but more realistic way is to create an MCP server first, and then build a set of additional controls around it. It would be slightly easier, but much more chaotic in real implementation. But of course, the worst part is just creating an MCP wrapper without any security controls at all.

Yes, a lot of companies do that, but sooner or later they will be beaten, and they will understand that they were wrong all the time. The only difference is, can they survive that kind of be catastrophic. Before we jump to the Q&A session proper, I just have a few key takeaways for you. So first of all, again, to reiterate, APIs are not just developer tools, they're not the plumbing, they are channels through which digital life flows. If we fail to secure them, we are not just risking applications, we are putting the entire enterprise nervous system at stake.

You cannot secure AI without securing APIs. Every agent, every model, every workflow is only as safe as the interfaces it touches or it's working through. And finally, the API is now the perimeter, treated like critical infrastructure or someone else will. And with that, we come to the end of my presentation, and let's tackle the rest of the questions we have. Microsoft is also providing API gateways to protect them. I presume you mean MCP servers, right? So obviously Microsoft is also a player in the API security management market.

I will not pretend that we know and cover every existing API vendor in our research. In fact, if you've ever seen the API landscape diagram created by one of the group out there, sorry, I can't remember their name now, it includes hundreds and hundreds of vendors. We can definitely talk more about specific details, but again, if you have to security as a primary kind of service they offer, and there are companies which only do it because they build the rest of the IT architecture around it, so to say. And of course, even Microsoft does not do it alone, they collaborate.

For example, they just recently collaborated with Positive Branch, and this is why it's one of their market leaders as well nowadays, because they can get a lot of Microsoft customers from that partnership. Can you discuss the market dynamics between API security, AI security, and WAP, WAP stands for Web Application and API Protection.

WAP, Worlds of API Security, it's actually kind of a pet peeve of mine. There is a lot of different acronyms with a various degree of overlapping, and of course, every vendor has a different understanding how exactly their solution aligns with a specific acronym. This is why my personal response is always forget labels, forget the alphabet soup, think in terms of capabilities. In our leadership compasses, we list specific capabilities we believe are crucial for securing and application protection tools.

Some necessarily cannot be overlapping because they are designed specifically to address business logic of APIs. And of course, AI security has an additional layer of complexity because they are much more non-deterministic, and you have to deal with a very free form of prompts and responses as opposed to like API schemas, for example. So there is a certain degree of overlap. I personally believe that WAP is a dying market, if you will.

It either has to kind of modernize itself and grow up to be a real API security vendor, or it will just kind of die out just like traditional antiviruses died out in favor of more modern endpoint security solutions. Okay, do we have any further questions? We have. Do you think that OAuth is enough to sustain the strong delegation mechanism that you need to have agents acting on behalf of existing humans all across very distributed API infrastructures? Do we need another authentication authorization protocol here?

Wow, again, this is a question that deserves probably like another webinar, but probably another conference like our own EIC. And I believe if you attend next May, this will be one of the subjects discussed over there and very hotly debated. I believe I do not have a simple like one paragraph response. The reality is always like we have to deal with what we have, but be ready to expand as soon as a new protocol standard emerges and gets traction. Agility is should be like the key word for you, not just in like crypto agility or quantum agility or even AI agility, but in authentication as well.

This is something where you have to be able to be as flexible as possible. And again, you have to know your requirements, you have to know your risks, and you have to understand how to map those to existing solutions. That's probably the best answer I can give you in a minute.

Okay, we have one more question. From what I understand. Sorry.

Yeah, from what I understand, 42Crunch is a leader in API security testing, but don't see traditional DUST or SAST vendors offering this API-centric capabilities. Well, of course, the quote unquote traditional DUST or SAST dynamic and static application security testing vendors, we would rather cover in a separate leadership conference, because this is a huge market, established market on its own. API-centric capabilities are, well, by nature, by the matter of fact, that you have to design APIs first with a contract.

And at this stage already, you can make an API contract secure by design if you will harden it, because you are dealing with a contract before you write the code. There is nothing to quote unquote traditionally test yet. So this is why I guess there is not much overlap in that regard. But of course, nobody stops you from using both.

When you start with a hardened contract, you design the contract with the help of a specialized solution like the one we just discussed, and then you hand it over to a traditional application security testing solution, which hopefully will be able to get all the signals and parameters from the contract and adjust, for example, the testing suite for your runtime dynamic testing or look for specific vulnerabilities aesthetically. So there is a lot of collaboration and sort of competition here, just like in the rest of the cyber security industry.

Okay, I think we are reaching 45 minutes, which is already a little bit further than originally anticipated. It was great seeing people asking interesting questions. Thank you very much for being with us.

Of course, have a look at both the leadership compass and the buyer's compass for API security and management. If you want to know more about each vendor and tool, read my blog post where I try to summarize those findings and kind of apply them to the future of security as well. Attend some of our upcoming events. There will be a cyber security and identity centric cyber security one in November in Frankfurt. Hope to see some of you there and, well, let's talk, let's collaborate. That's what our job is nowadays. Thank you very much again.

If you have any additional questions, do not hesitate to reach out to us and have a nice day.