Transcript
I'm the VP of Product at Wallarm and I'm thrilled to be joined today by Craig Riddell who's our Field CISO. We're going to talk about the results of our 2026 API Threat Stats Report. Before I dive in, just a couple of housekeeping items. This webinar is being streamed on both Zoom and LinkedIn Live, so you could be joining on either platform. If you have questions or comments, feel free to put them into the chat. The comment section on LinkedIn or into the Q&A in Zoom and we'll do our best to try and address those either as we talk or at the end, so feel free to do that. Someone always asks if slides and a recording will be provided. They can be for sure, but also the session will be available on LinkedIn and on YouTube, so you can always come back and watch the recording there as well. I think those cover the housekeeping items. Craig, welcome. Thank you for joining us. Happy to have you here. Thanks, Tim. I'm really excited for this. I know. Craig and I have been talking about this deck and the presentation and having a few repertory conversations, and I can tell you Craig is definitely excited to have the conversation. I think it's worthwhile for us to get started and dive in. I'm going to start just by explaining a little bit about what the report is for those of you who might not be familiar. Wallarm does an annual API Threat Stats Report. Actually, we do a quarterly report that we then do an annual roll-up, and I think this is something like the 15th report that we've done. We've been doing this for a number of years, and obviously, the report itself has evolved over time. The content has changed, but this is an ongoing report that we continue to do, and we're pretty excited about it. In terms of the methodology, for the annual report, we combine a couple of different sets of data. We look at public vulnerability advisories, published vulnerabilities. We look at CISA's known exploited vulnerabilities catalog. We look at breaches that have occurred in the timeframe that we're analyzing. We also pull in data from our own Wallarm platform in order to understand attack patterns and attack trends as well. Obviously, there's a lot of filtering and normalization because what we're looking for in this dataset are really API attacks, and increasingly, actually, AI attacks as well and vulnerabilities. We're looking to exclude things that don't fit into those categories. We classify and analyze them increasingly using AI, but also manual methods and validating what AI does. The reason we do this, the reason we started doing this report, wasn't originally to publish it as a resource, but to feed the Wallarm platform, to feed our own threat intelligence in order to build a valid API and AI security product. We need to know what attacks are occurring, what the vulnerability trends look like, what the exploit trends look like. As we built out that corpus of information, we found that it was something valuable that we could publish as a report as well. We started publishing that, and over time, it's become more valuable as a report as well, in its own right, in addition to helping us build a better product. That's the genesis of the API Threat Stats Report and the methodology behind it a little bit. With that, we can move forward to some of the content. We're going to start with what we call the API Threat Stats Top 10. This is the analysis of our own collected exploit data from the Wallarm platform. We're going to look at it in two dimensions. The classification here is a little bit different. Let me just pull up this year-over-year change chart and talk about classification for a second. We call this the Wallarm API Threat Stats Top 10 because it's our top 10 breakdown of API attack classes or categories. You may be familiar with the OWASP API Top 10, which is also a classification, generally more classification of vulnerabilities, classification system for API conditions. There are some places where they overlap, not surprisingly, and there's some places where they differ. We can talk a little bit about those as well. What you're seeing on the screen here is the top 10 from 2024 ranked attacks that we've seen. Then on the right-hand side, the top 10 from 2025, looking at the 2025 data. Of course, some arrows to show how things have changed over the course of time. I think, Craig, I'd like to bring you into the conversation at this point. If you're looking at this year-over-year change, what strikes you as the most important takeaway or the most surprising conclusion from the year-over-year change? Yeah. I think just going through and looking at the report in its entirety and then this visual here puts it on right front and center. It's just really where these would-be bad actors are really optimizing their approach. It seems to me like access controls remain pretty fragile. I was interested to see the insecure resource consumption jump up as far as it did. But for me, this is really an optimization path here on how we're going to see these things unfold at scale as more companies go through this AI transformation. Yeah. We haven't talked about it yet in this session, but we've talked about it in lots of other venues. The connection between API and AI, AI runs on top of APIs. I think, Craig, you and I were just having this conversation about how if your focus is API security and someone tells you that AI security is really API security, you're not going to be surprised by that because you understand the API side of it. But if you're someone who spends a lot of time with AI, that might seem like a surprising conclusion to you because a big part of the job of AI is to abstract away the interaction with those APIs. It might not be a conclusion that you come to naturally. But the reality is that there is this very tight connection between AI and APIs. When you talk to an AI interface, whether it's a chat interface or whether you've created an agent, what it's doing is operating over APIs. I think you're right to point out that some of the shifts that we see here in the API attacks may be related to AI adoption in the market as a whole. Yeah, it's really interesting, that directional realization. Like you said, if you come from one side, it's very apparent. But from the other side, like you said, it's obfuscated. So it's an interesting conversation just depending on where it starts. Yeah. The two that jump out at me, you pointed out the insecure resource consumption, which I think very well, that increase could have a tie to more AI-related APIs being deployed and being exploited or attempting to exploit them. The other is the cross-site issues, which may also have a similar relation. That's fundamentally about crossing trust boundaries. We know that the deployment of more AI-centric tools, especially ones that interact with each other, increases the number of trust boundaries that are out there. Attackers tend to follow the attack surface. A bigger attack surface means more attacks. Yeah, 100 percent. Wow. Anything else here jump out at you that you thought was interesting? It's a lot of changes year over year, but nothing here that really jumped out is like, oh, wow, that was unsurprised or caught me off guard, I guess. I think you did point out that, I can't remember if you have phrased it exactly, but access control authentication flaws, they remain near the top. The authentication flaws went down a little bit, access control went down a little bit, but they're definitely in that top half, top 50 percent consistently. I think maybe we can flip to the next slide and see what that looked like from a quarter by quarter basis. This is the quarterly change, which just gives you a slightly different view. You can see that broken access control actually just stayed in that number three spot, and then in Q4 jumped up to the number one spot. And although it had the third spot result for the year as a whole, it's very consistently a significant problem overall. When you look at these year over year, or especially quarter over quarter, it almost jumps out that attackers in this day and age are prioritizing abuse over bugs. They're being able to go in and beat up some configurations versus down through memory and all of that type of stuff. That's another one of the things that jumped out at me, especially as you break it apart for quarter over quarter. Like you said, the injections remain pretty consistent. Broken access control is pretty common here too. But I think all of this points to the shift in evolution in our security strategy to be the demand for more of a runtime type of approach versus staking time. Yeah, yeah. And I think a couple of things to point out there. So first of all, injections you pointed out, that is one of the key areas where the wall arm top 10 differs from the OWASP top 10. The OWASP top 10 in their last update, which was 2023, I think, they took what was a separate category for injections and they moved it into another category, which I think was unsafe consumption of API, something like that. So they sort of buried it a little bit. But when we look at the attack data, we see injections consistently near the top and feel like that sort of merits its own category. Yeah, and that's the unsafe consumption of APIs to me is a bit of a too wide of an aperture. Like you can put a lot of things in that category, right? Yeah, yeah. Yeah, that's true, that's true. And it's interesting to consider. I mean, we can always talk about limitations of the dataset and the analysis, right? When you talk about business logic attacks, there are some types of business logic attacks that can be detected. But of course, one of the big challenges for organizations is that business logic attacks are difficult to detect because they're multi-step. They often exploit business logic as opposed to a vulnerability. And so they look like a series of requests that are within specification. And so it's interesting to consider how discrete sort of stateless attacks like injections or broken access control can be part of a business logic sequence. And I think that's an interesting place to put some thought as well. All right, well, I think we can move on from the API threat stats top 10. Obviously, there's analysis in the report itself, but we can jump out a little bit to a different topic and talk about MCP. So in the threat stats report, we decided to, we usually have like a threat stats spotlight. We've called it the last couple of reports. And MCP and MCP security was really the topic that we chose to spotlight in this report. And I think I haven't had anybody tell me that that might not be appropriate or that it's not super important. And I think it's worthwhile because this market, this technology is shifting and changing so fast and being adopted so quickly. It's worthwhile to just have a little bit of a conversation about what MCP is and what role it plays. And then we can talk about why it presents risks, right? So I didn't, I realized I left one label off of this slide. The tools, resources and prompts are what you would call primitives. And the idea here for MCP is that it is a control plane or a mediation layer for AI. So you have a client, the MCP server advertises or tells those clients what it can provide in terms of primitives, tools, resources and prompts. And then it mediates access to those things. So in this made up example here, I imagine some kind of a financial services organization where you might have tools like creating an invoice or issuing a refund. Those could be APIs or likely APIs that carry out that function. You have resources like getting a list of trades or getting stock prices. You have prompts that feed into another AI tool to do some kind of analysis or summary. And that's kind of the idea of an MCP server and what it provides sort of in the context of AI and AI interactions. And the MCP client would likely be or certainly could be an AI agent who can discover those tools, resources and prompts and then do things with them as well. So Craig, I don't know if there's anything you wanted to add to that or anything that I got wrong there. You're welcome to correct me. That's totally fine. No, no, no. I think you nailed it. And the way that you laid it out explains it really clearly. It's a control plane, right? MCP servers, I think of them as a control plane for AI. And the unfortunate or fortunate thing about it, depending on how you think about it, is that it's autonomous. So there's no more risk-based authentication or step up for an MFA prompt to make sure you're not doing something that's potentially hazardous or dangerous to the business, right? What really stands out to me about MCP in general is it's delegated authority with the ability to act autonomously and actually go execute. So it's an amazingly powerful tool, but deployed improperly, it can be incredibly damaging. And I think understanding how it works and the way you laid it out is a great first step to going about deploying it securely. And I think, you know, I've had a couple of interesting conversations in the past with folks around zero trust and API security. And the consensus I got from those conversations was that like in concept, APIs are a great application for zero trust, right? We should absolutely be authenticating and authorizing every call. We should absolutely. In reality, the organizations that are most mature adopting zero trust are still really adopting it for human identities and struggling to adopt it for non-human identities. And now we're talking about AI and MCP servers, and it's another case where it seems like this is a great application of zero trust principles, but we're not there yet. Like it's just missing. Does that make sense to you, Greg? Yeah, it totally does. And I wonder if it goes back to kind of the initial comment that you made about the directional understanding of the underlying how it works. So again, coming from the API side of things, that's probably a really clear conversation. But coming from the AI side of things where it's a bit obfuscated, I wonder if that's lost on some people. But it is a perfect opportunity to validate and call these things out. Unfortunately, and I guess as we'll see as we get further into the data, it hasn't been the case so far. Well, and I think, yeah, no, I think you're absolutely right. It is interesting, of course, to consider how the security controls that we've talked about in the past that are sort of known as best practices still apply even when you have new technology in place. So yes, it's MCP. It's a new technology. Yes, it's AI. It's a new technology. But you still have the challenges of who should be able to access what tools and what data and how do you validate them on a continuous basis? That problem is not new. No, it's funny because we were kind of talking about this earlier today on a different topic. It's the same security trends with new acronyms, right? So I almost wonder if we should demystify this a little bit. If you look at this as a control plane, in any other control plane, we drive towards these privilege. And that's the same thing that we're doing here while enabling automation, autonomous action, and improving how we can work effectively and efficiently with these modern tools. It's just a matter of tuning and tightening. Yeah, yeah, yeah. Well, so let's talk a little bit about the data here around MCP as well. So the reason that we pulled it in as a spotlight was because we looked at the number of AI vulnerabilities that were discovered. And there was a huge, or published in 2025, there was a huge increase in the number of AI vulnerabilities, something like, I think it was 398%, if I remember correctly, overall. But 14% of those were MCP related. And in contrast, last year, we had obviously a smaller number of AI vulnerabilities, but there weren't enough MCP vulnerabilities for us to really break it down along those lines. And so MCP has, in terms of its vulnerability profile, has really just skyrocketed in 2025. It's trajectory is up and to the right, like a hockey stick. And that kind of a growth, it matches the growth in the market and in usage, but that's what sort of pushes it to this sort of spotlight status. And then, we should talk a little bit about, we touched on it, but why MCP presents a particular risk. And I think, Craig, you started to talk about this, but maybe you want to sort of expand on that a little bit. Yeah. I mean, it's over permission tools, right? And it's direct API exposure. So let's pause on that for a second, because over permission tools is a great phrase. But in a practical sense, what does that mean? If I'm a security practitioner, what am I worrying about when I worry about MCP having over permission tools? Yeah, it's being able to operate outside of what your intended function was. So if I can take a tool that can tie into data that's supposed to generate a report, and it's maybe only supposed to read, but it was set up improperly, and I can read and write, or it's unauthenticated, and I can pivot from one tool to another, or take a token from something and pivot through the environment that way. And given that all of these tools are now integrated into this one control plane that I think is maybe not as well understood as some of the other gateways and things like that that we've come out with recently, you start to see this type of stuff. Weak authentication, tool sprawl, chaining, overly broad scope of things. And I think that has to do with, again, the problem set not being clearly defined by an ownership committee or one team. So you have an MCP server where maybe your direction from leadership was just, hey, we're looking to enable AI to do this function, and then we're going to see what we can do with it. Well, an open-ended problem statement like that tends to lead to over-permissioning, which tends to lead to access to data or data leakage that maybe you weren't supposed to have access to, or that wasn't supposed to be in scope for the tool, because you're still trying to figure out what you want to do with these new tools and these new automation capabilities as a business. Like I said, it's kind of the same security story repeating itself over again, but unfortunately, the way that AI has changed things is that, we talked about a little bit earlier, is these things look normal. They're authenticated, they follow all the specs, but they're bypassing all of your existing security tools because most of them are out of band and not in line. So everything looks normal and above board until you realize there was something wrong. Well, so I think you're touching on that lack of runtime enforcement in the third box on the slide here, which is that there aren't today best practices or good standards for runtime enforcement for MCP. It's a challenge for organizations. Is that accurate? Yeah, 100%. And I mean, you could even bubble it a layer higher. MCP is certainly there, but any AI enablement or transformation, I mean, even API traffic in general, you could make that argument. But yes, MCP definitely shines a spotlight on it because of now it's giving these agents the ability to actually go execute on behalf of you. And that can be a scary thing when it's not understood how it's actually being used. It's the difference between a snapshot and actual understanding of how it's operating in production, right? Yeah, yeah. I want to touch on the challenge of direct API exposure as well, because I think it's a little underrepresented. When people talk about MCP functionality, they're often thinking about AI interactions, but they're not thinking about the increased use and exposure of APIs in order for those actions to take place. So when I put in an MCP server, I'm doing that in order to facilitate an AI interaction to a bunch of APIs usually. And I might end up developing more and deploying more APIs in order to facilitate the function of that MCP server, all of which creates more exposure for those APIs. Maybe those APIs existed before, but people didn't know they were there or they weren't used very frequently. But now you've got agents or other tools that are directly accessing them, mediated by that MCP server. And there's a follow-on consequence of a massive explosion of APIs as well. Yeah, I'm really glad you brought that up, because I mean, I guess the one point to really hammer home on this for me is that AI risk is API risk. You cannot have one without the other. It's the underlying, like we keep saying. And this is only assuming this is a known entity. We're not even talking about shadow MCP servers and the risk that that presents and all of that, right? So it's very interesting. And I made this point the other day that was kind of, we saw companies that had a really robust identity strategy pivot well into COVID. I think it's going to be similar here, where you see companies who have a really good understanding of how their APIs are being used and have a really robust API strategy are going to pivot well into this AI transformation era. And then companies that maybe don't understand their API landscape need to do some homework before going out and enabling autonomous action to go run through their environment. Yeah, yeah. We've got a comment, not a question in the Zoom. Beyond authentication authorization, data level security is very important and requires custom slash separate enforcement. It's all about bringing the context of the user, their roles and permissions and applying it consistently down to all the tools. I think that's a great comment. Ultimately, it really is about data security almost all the time. And I think that authentication authorization does need to flow to the data and who's accessing it. I think that's a key point. I don't know if you wanted to add anything to that, Craig. No, for me, that's always been two halves of a problem, right? Like if you have a really strong data security model, but you have a poor identity strategy and over-permissioned users, it's kind of irrelevant and vice versa. You have to solve both sides of that equation in order for it to be effective. And I think that's spot on. Well, and then the question becomes, what's the point of evaluation? Not what's the point is and what's the objective, but what is the logical point of the evaluation and enforcement? Because you have to be able to enforce whatever policy you have at some point. APIs present a really attractive target for being that point of enforcement because they mediate access so effectively and they often have capabilities to enforce authentication authorization, that kind of thing too. So another reason that API security is really AI security or vice versa. All right, let's jump out a little bit and talk about some of the breaches that occurred in 2026. So in the threat stats report, we look at all of the breaches that API related breaches that we could find for the year. And then we evaluate them, come up with a top 10 so that we can talk about trends. We're not going to talk about each of the top 10. You can read them in the report itself if you want all the details. We're going to start by talking about the breach trends though. So for each of those, we look at what those root causes are for the breaches. And then we've got them mapped here just for visual fun, a table and then a bar chart. The table is the OWASP categories and the bar chart are the wall arm threat stats categories. So, I mean, Craig, what's your first conclusion that you see out of this set of root causes? That most of the breaches really weren't sophisticated. They were scalable. That seemed to be the thing that jumped out to me really quick here. I mean, 65% mapped authentication failures. We talk about tokens and secrets, but then really automation here is going to massively amplify impact. But this seems to me going through this report in its entirety, it's back to kind of quick scalable wins as an adversary, not necessarily deep, long running, sophisticated attacks. It's scalable because it can be right now. So that's kind of the first thing that jumped out to me. Yeah. A couple of notes about the data to keep in mind. So when we looked at the API threat stats top 10, we're looking at attack trends, the year over year changes. Those are attack trends, not necessarily successful attack trends. When we're looking at root causes of breaches, these are, of course, the breaches that were published, that people found out about, that were discovered. I always worry about the ones that aren't discovered and what those trends might look like, but the unknown is hard to analyze. So if we think about this in terms of breaches that were successful, obviously there's a clear alignment between the OWASP broken authentication and the wall arm threat stats authentication flaws, 65%, 52%. Almost, I mean, clearly the majority of successful breaches that we saw that were published started with or involved some kind of broken authentication. And I think that's really, it's almost, it's really important to understand, but it's also the kind of conclusion that I think security folks tend to have a hard time knowing what to do with. You know what I mean? Like, it's tough to take an action on. It's tough to make action. It really is because we, as a security practitioner, we're constantly fighting the symptom and it's hard to go attack the problem itself, right? My advice there is as a security practitioner, go get really, really interested in what your business colleagues are doing and see how you can get involved as early as possible. A lot of these types of issues around identity are usually because there's a mismatch somewhere. Somebody's not communicating effectively or brought, security isn't brought in early enough and it's always a catch up. And when you're trying to catch up as fast as the world's moving today, it's an impossible task. Yeah. Yeah. And then on the threat stat side, we, the number two rank was API leaks, which is effectively which is effectively some kind of stolen credentials. some kind of stolen credit. And I wanna pair those two together because they're both effectively, while we separate them as categories, they're both effectively the same problem, which is that your mechanism for enforcing who can use this API was broken in some way, either through a stolen credential or through an actual broken authentication mechanism. And that's a huge chunk of the issues in breaches. There's some kind of authentication issue and it's challenging, yeah. I think your point about finding those mismatches and misalignments is key as well. Anything else from the trends here? I mean, we had unsafe consumption of APIs as number two and number three for wall arm. That's where, or insecure resource consumption. That is an abuse situation for the most part, some kind of abuse, right? Yeah, yeah. I wonder how much of this goes back to kind of that delegated authority kind of a metric and how we'll see these stats, this being the first year that we've got all of this MCP data and all of that. I wonder how, as we monitor this quarter over quarter and then roll it up into this next year, how we'll see these things trend and if they'll continue to trend up because of the delegated authority that AI introduces as companies are going through this transformation. Yeah, yeah. Totally possible. Interesting. All right, well, let's talk a little bit about some of the specific incidents, breaches that we saw. So 700 credit is an interesting one. We've got one, two, and three here, right? 700 credit, Qantas, Sales Loft. I'll start with 700 credit. I think it ended up at the top because of the number of victims, 5.6 million is a sizable number. And it was sort of a supply chain, third-party API access issue with insufficient enforcement of lease privilege controls. Of course, not surprisingly, it fits well into the pattern that we've just talked about there. And it impacted a large number of folks. I don't know, Craig, if there was something that jumped out at you about that one, or you could pick any of these that you thought were worth highlighting. Yeah, I guess maybe just speaking on all of these three, the interesting thing here for me was that it wasn't like AI didn't introduce some new exotic attack. It just amplified failures that were likely already present. And the other side of this is that now as security practitioners, it's not enough to just be aware of what's in our environment with this now very connected world that we live in. We have to worry about what our supply chain security looks like, what our vendors are looking like, how they access our systems, when, why. It's very important to not only understand the security side, but also how it's intended to be used and how it's actually being used so that we can put the proper controls in place to make sure that it's not just exploits, right? It's business logic abuse. And we need to have patterns and playbooks in place for all of those types of things. And now that requires an understanding of what the business is trying to go do. Yeah, yeah. I mean, I think you're right about that for sure, definitely. It's interesting because the next slide, we're gonna talk about the AI related breaches that occurred because that was a trend as well. But these three specifically, none of them were specifically AI related, but it is, I think, important to keep in mind that these types of AI vulnerabilities when exploited can be tied to, these types of API vulnerabilities when exploited can be tied to AI. They can impact AI if these are environments where there are AI tools deployed, broken authentication to an API, to an MCP server, like it's all tied together is what it comes down to. Yeah, and I mean, like this is something that we have to change just our mentality around. Our business now runs on APIs. So our risk model needs to as well. We have to start adjusting the way that we think about all of this type of stuff. It's a lot like what you said, abuse at scale, right? Token issues, we're starting to see that type of stuff, but third-party integration and trust failures, that's really key. And then like you said, in the MCP side, the control plane exposure, there's a lot of problems that if any one of those chains in the link or any one of those links in the chain is weak, then you potentially have an issue on your hand. So it's really important to know how all of these pieces fit together to paint the bigger picture. Well, I think you mentioned token issues. That's the Sales Loft incident here, which is worth calling out. Sales Loft, and Sales Loft actually, I guess it was AI related if you wanna think about it this way. Sales Loft has a product called Drift, which is a chat bot that gives you the ability to access your Salesforce data via this AI chat. And what happened was that either one token or multiple tokens, it's a little unclear whether it was an over-permission token or a bunch of tokens were compromised, giving the attackers access to this Salesforce data of multiple companies. It was 12 or 13 organizations, maybe more have been disclosed since. And so it was a big impact for what was effectively a credential theft. And certainly relevant and important. It's interesting, right? Like we said earlier, it's half of the equation is the identity side, right? So valid credential, over-permissioned credential data leak, right? But now it's not just at human speed, it's at machine speed. So it takes fractions of time to go make a massive impact. Yeah. So then if we move on to numbers five, six and seven, we see a trend in these being specifically AI related API breaches. So just to run through them briefly, the first one is with a company actually called smithy.ai, which is a software, an AI tool for managing MCP servers. And the issue here was a path traversal exploit that allowed an attacker to have access to 3000 plus MCP servers, essentially. We had an incident with Claude as well, another API access control weakness that gave an attacker access to functionality they shouldn't have access to. And then with Langsmith, which is a API development tool or API tool, sorry, AI tool. This was just internal APIs being exposed without sufficient authentication. So in all three of these cases, we have an AI organization being impacted by an API flaw that wasn't really directly related to AI, but the impact is there as well. And that's a trend worth calling out in the breach data from last year. Yeah, I think you completely nailed this one. Again, going back to that directional understanding, this makes a lot of sense coming from where we are. But I suspect MCP incidents will probably continue to climb for a while. And then prompt injection and tool abuse is really starting to show operationalized risk. It's one of those things that without solid understanding, just having these new ways to interact with tools at speed and scale can introduce a new risk element in and of itself. Yeah, yeah, absolutely. And so, as we pay attention to the breaches that occur in 2026, I think we're gonna continue seeing some of these trends unless something significant and material changes, but I don't think the security controls change that fast. So let's talk a little bit about the key takeaways from the report. We've covered some of the data and some of the sections. Obviously, there's more detail in the report itself. So I would encourage you to take a look at that. But I wanna bring us to sort of the summary of what folks should know. And let's start with this one. API risk is business risk. What does that mean to you, Craig? Why do you think that's a key takeaway? Oh, because like I said earlier, our businesses now run on APIs. They sit in the middle of our revenue flows, our customer data, and now our automation and autonomy, our autonomous action, right? It's the underlying network of everything that our modern businesses will operate and continue to operate on. APIs dominate vulnerabilities, exploits, and breaches now. It's really as simple as API for how your business makes money. API security should be very closely tied to revenue protection. Do you think that most, I'll ask two questions on this. Do you think that most security practitioners understand the connection between APIs and the revenue their businesses generate? I bet it's a mixed, it's probably a pretty mixed bag there. I talked to a lot of CISOs and it is kind of companies that have maybe been on the front end of this transformation, financial services, to just kind of pick a vertical. Likely, yes, because they've already learned that they have to go partner with the business in order to have an effective security strategy. Where maybe companies that are a little bit behind the adoption curve haven't quite come to that realization yet. They're probably feeling the pressure of not knowing what they don't know, but it will be a requirement, in my opinion, to have a strong relationship with the business in order to be effective at security. So the second question there, the corollary question is, do you think that the business owners understand the connection between the revenue they generate and the APIs? I think it's, I mean, maybe some, but I think it's probably more just a by-product of a bigger project that they're working on. And I think it goes back to kind of that directional understanding of what's happening. A lot of the business owners or people who are going out and creating all of these multi-tool or multi-API chained AI initiatives are likely coming at it from the AI side of things where there's that layer of obfuscation. But security practitioners have been, we have this unique challenge of we have to secure all the legacy stuff, but then we also have to be familiar and prepared for where the business is going, right? So we kind of have the history there, but yeah, I think it's probably a little bit better understand on the security side. You've given me a chance to say one of my favorite phrases, which is that technology doesn't evolve, it aggregates. Oh, that's great. I haven't heard that before. You adopt all this new, in this case, new AI stuff. Maybe it was new cloud stuff before, but it doesn't mean that you're getting rid of that HPUC server that has that one key function. It's still there. Somebody still has to deal with it. Oh, and we all have one of those things that nobody breathes too heavy around because we need it to stay up, right? Like, yeah, it's absolutely that. Yeah. Well, so you started to bridge, I think, to the second key takeaway, which is that AI security is API security. And I think we touched on this a little bit, but it's worth emphasizing why this is a key takeaway from this report and why it's important for CISOs and security practitioners to really understand that this is true. Yeah, and it is. It's not, I don't think this is a, like a unique to wall arm statement. This is just a fact. And the data here really backs it up, right? I think it was like 36% of AI vulnerabilities overlap with APIs, and then 36% of AI exploded vulnerabilities also overlap, right? That being in parallel is like, it should be a very clear message. You cannot secure AI without securing APIs. And I think that understanding will determine how well you pivot. And I think it's important to connect these two things together, these two key takeaways. So if AI security is API security and API risk is business risk, then AI risk is business risk, right? You're back to that connection of sort of a triple, if you will, connecting those three things together. Yes. Yeah. So the last key takeaway, behavior is the risk boundary. We actually, obviously we didn't script this entire conversation because it's much less interesting if you do that. I thought we would talk more about behavior and business logic abuse than we did, but it is a theme in the report. And it is part of what I think is most challenging in the API threat landscape and the AI threat landscape today. So why do you think that this is one of the key takeaways? We're back to, you know, things working at scale here, right? How fast can I ramp things up? The data in our report showed 97% of API vulnerabilities were single request, relatively trivial to exploit, and detection after the fact is irrelevant. It's always an N plus one, as we've seen from pick a data breach that related to APIs. It's always an N plus one, as we've seen from pick a data breach that related to. It happens so fast, and the amount of data and information you can get out of an organization is staggering in such a short amount of time. I think this is just a shift from... You had to throw a data point in there. We did, last year, we did an API honeypot report. We built an API honeypot, and we did a report on it. If I remember correctly, the calculation that we came up with was that using modern APIs, so batch queries, GraphQL or batch queries, you can steal 10 million records in under 10 seconds, basically, which is just incredibly fast, right? Insane. I mean, that kind of goes to the point that I was driving at is it's no longer just, hey, we need to protect against these known vulnerabilities, or we need to make sure that we've got these big walls. Yes, all of that is still incredibly relevant, but it becomes more around behavioral enforcement in line, and being able to protect against business logic abuse, being able to see where there's drift from expected behavior, and that becomes incredibly relevant. As we've seen throughout this report, a lot of this abuse or would-be bad actors, it flies under the radar because it looks like a totally normal call. It's following all the guidelines, it's authenticated. When that happens, and everything looks normal, you have to have that in-line, real-time kind of behavioral enforcement engine that can look at things in context. There's another connection to make between these takeaways. If behavior is the risk boundary, and AI, if you think about AI as a more behavior-driven application, it's more interactive, right? You can abuse AI using logic as opposed to technical exploits. I like to play with the idea that the increase in generative AI makes it possible for philosophy majors to get into cybersecurity, because all the exploits are logic-based. That means that API security and AI security become more behavior-based because of the use of AI to exploit it. On the attacker side, it's behavior-oriented as opposed to technical exploits, which is something to consider as well. Yeah. I love that you made that point, because it's interesting. We've all taken our corporate anti-phishing training, where it's like, oh, you create a sense of urgency, you don't want to look at that, or maybe look at it twice if there's somebody trying to force you to do something in a hurry. It's interesting now that we've got these AI models that we can create the same type of event, where we can say, oh, no, no, no, don't think too hard on this, because you'll eventually figure out I'm trying to get data I'm not supposed to. You can create almost this sense of urgency, this fake sense of urgency, this race condition for these tools that were designed to ultimately give us what we ask for, and you can make it perform in ways that it's not supposed to. You could still call that a hack, but without exploiting any sort of vulnerability, you can make it, beat it up on the logic side of things, which is interesting that you can do to a machine, but that's the era we live in. That's true. That's true. There's one other angle on the behaviors, the risk boundary that I think people may not consider that's important to consider, which is that it's not just the behavior of the attackers, that's what we tend to think about, it's also the behavior of people adopting AI that creates risk. I know, Craig, there's an example of someone deploying OpenClaw, or the desire to adopt AI tools by high-powered executives that creates risk. That's a behavior-based risk boundary that we're not really thinking that much about. That's a really fascinating point, and it's 100% true. What are you trying to accomplish by bringing in these AI-powered tools, and have you even defined that internally? Because that will certainly determine a lot of behavioral-based risk. That's a really, really good point. Yeah, yeah. I suppose it also applies to developers adopting AI tools to increase their own velocity. If you can make the leap that increased development velocity drives the speed of development, drives risk in some way, then adoption of AI tools by developers also drives risk in some way. Sure. We were talking about this in another session earlier today, where we were saying, okay, well, now you've got so much AI-generated code that the only way to do a QA on that AI-generated code is also with AI. And as any good security practitioner knows, it's a great idea to have dev and QA as the same thing, right? Exactly. Until the agent writing the code is using logic-based abuse to get the agent QA-ing the code to pass the bug on. I mean, it goes back to the point I keep making. It's the same patterns, just new acronyms, new ways to talk about it. Yeah, it's true. That's fascinating. All right. Well, cool. I think that's really great. It's been a super interesting conversation. I'm going to wrap us up with a little bit of how Wallarm can help. It's one slide. And while I'd love for people to listen to that slide, it's also an opportunity for you to get your questions in. So if you have questions, feel free to put them into the Q&A or in the comments in LinkedIn, and I'll come back and take a look after this one slide. So as I started to say at the beginning, we started this API Threat Stats Report as a way to improve our product. If you're not familiar with what Wallarm does, we are an enterprise API security company. We protect API and AI applications in your environment. We do that by providing these four capabilities. Starting with discovery, you can't protect what you don't know about. So we want to tell you what's in your environment. Comprehensively, we want to find all those APIs, tell you what they are, what they're doing, find all those AI agents and AI applications and MCP servers, help you find and manage the shadow and legacy endpoints that you might have. And then we go on to protect them. So we were built and architected to do real-time inline protection to actually block attacks and to block them either as individual requests, as whole IP addresses, or to block individual API sessions as well. So there are lots of capabilities there. We also provide API security testing so that you can adopt that shift left mentality and eliminate risk before it's pushed into production. And then we provide capabilities around governance for your API and AI exposure. So that's all about enforcing consistent security policies, monitoring risks over time so that you can manage them and providing that sort of board level or executive visibility into those risks so that they can be managed at a strategic level as well as a technical level from the other capabilities as well. Obviously, if you're interested in Wallarm, we're happy to follow up and talk more about it, but I'll take a look and see if we've got any questions added. I think we had one from LinkedIn. I would love to hear more on the cross-site or trust boundary issues, what led to the risk as well as the mitigation strategies. Interesting. So there's some limitations in terms of how far we can dive into that analysis of attack trends because it's essentially trend data, right? We don't have all of the details of all of those attacks, sort of down to the individual requests to see exactly what was happening over the course of the year. We can make some reasonable assumptions that we're... So if the attack trends are an indicator of what attackers are spending their time on, then what that indicates to us is that the attackers are seeing increased value in exploiting cross-site issues, crossing trust boundaries within APIs. The conclusion as to why comes to, well, either there's a substantial change in the software that's being deployed and it being vulnerable, which I don't think is the case, or a change in what those targets look like or how applicable those targets are. I think that's what leads me to the conclusion that the increase in development and deployment of AI and AI-related APIs drives that change in the target surface that drives the increase in cross-site issues. I don't know, Craig, if you had a different conclusion, but that was kind of the thought process I went through. You nailed it. I mean, the uncomfortable truth from a CISO's lens for me is really that we designed our APIs for connectivity and scale. We didn't really design these trust models for autonomous action and this high degree of automation. Our trust boundaries right now are very, very static, but our systems are dynamic. And then that mismatch is where the risk is. And I think the way you summed it up is perfect. Yeah, awesome. All right. Well, good. I don't see, I think, I don't see any more questions in Zoom or in LinkedIn. Let me give it one more refresh and just see if, make sure I'm caught up before we go. I have put up the slide to get the whole report. So if you want to read the report, there is a QR code and a URL there. You can obviously find it on the Wallarm website and hopefully it's interesting and useful to you. And I thought, Craig, this was a great conversation, super interesting for me and a lot of fun as well. And hopefully everyone else enjoyed it too.
