AI Security is API Security

Noah Labhart: [00:00:00] Hello listeners. Today we are kicking off a new series entitled The AI Control Loop: How Enterprises Govern the AI They've Already Deployed, sponsored by our friends at Wallarm. Wallarm is the AI control platform for enterprise AI, protecting every AI workload, API, and application in production, giving CISOs the governance they need and CIOs the speed they demand.

Organizations choose Wallarm for a complete inventory of APIs, AI agents, and AI apps using patented AI ML-based threat detection and blocking that operates at production traffic speeds. Today's episode is entitled AI Security is API Security, and joining us is Tim Erlin, VP of Product Marketing at Wallarm.

We discuss the foundational link between AI security and API security, digging into the role that APIs play in the dev, deployment, and operations of AI. We explore how they contribute to the risk profile of [00:01:00] AI transformation projects, and how securing APIs is critical for successful AI transformation.

Tim, thank you for being on the show today. Thanks for being on Code Story.

Tim Erlin: My pleasure. I'm happy to be here.

Noah Labhart: Really excited to dive into Wallarm and all the things there, and our topic for today, which today's episode is en- entitled AI Security is API Security. Really excited to dive into all things there.

Before we do, tell me and my audience a little bit about you.

Tim Erlin: Sure. So my name's Tim Erlin. I'm the VP of Product and Security Strategist at Wallarm. I've been at Wallarm about three years. I've been in cybersecurity for 20-plus years, and really joined Wallarm because I saw this gap in the market around API security, and it was a gap that I had tried to get into in the past or tried to solve in the past, and I felt like Wallarm really was well positioned to address something that just seemed like it was missing in the space.

So that's why I dove into API security.

Noah Labhart: Amazing. That's very cool. What do you do for fun?

Tim Erlin: Fun? I play soccer and I mountain bike as much as I can.

Noah Labhart: [00:02:00] Nice. Very cool. So you're obviously in good shape. Both of those are very grueling- ... grueling sports.

Tim Erlin: I do both of those things much more slowly than I would like to, so...

Noah Labhart: Okay, cool. Let's dive into the meat of it then. My first question is around AI security, and when p- people hear AI security, they often think first about models, prompts, or training data. Why do you argue that AI security starts with APIs?

Tim Erlin: So I think to answer that question, you just have to start thinking about how AI works, not from a, a model standpoint, but from an interaction standpoint.

So when you connect to an AI tool, you're connecting over an API. That web interface that you might be using, ultimately, that's a web interface backed by APIs that connect to those models. When you interact with an AI-enabled tool where AI is embedded in the application, behind the scenes, those are all APIs.

And then the AI tools themselves, the agents, the applications, when they connect to the [00:03:00] things they need to get the job done, that might be just another API, or it might be an MCP server, which is frankly just another API, or a tool which is usually over an API. The conclusion you inevitably come to is that all of the AI interactions are underpinned by API interactions, and that's why I argue that AI security starts with APIs.

Noah Labhart: That makes a lot of sense. And like you said, when you think about the components and how they fit together, they are communicating through e- exactly what you said, through APIs. Where do you see organizations underestimating API risk? And as they move AI projects from pilot to production, where are they falling short in how they estimate the risk here?

Tim Erlin: So over the last few years, a lot of organizations have come to realize that the APIs they expose out to the world present risk, exhibit risk. They've started addressing that risk through API security tools. What's missing, where organizations underestimate that API risk, is on all of the internal tools and APIs [00:04:00] that their AI capabilities or their AI applications connect to.

So you might think, "Hey, this API is internal to my organization. It's less of a risk. It's presenting a lower r- risk profile than my external APIs." But if you've got AI tools that are using those APIs, there is actually a route to them from an external standpoint, and I think that's where that underestimation occurs.

It's really not understanding all of the connections between the AI applications, AI agents, and the tools and APIs that they're using internally.

Noah Labhart: Mm. Yeah, that's clear there. How does the rise of AI agents change the stakes for API security compared with traditional application architectures?

Tim Erlin: We all understand that the difference between a, an LLM and an agent is that the agent is designed to take actions on the user's behalf to actually do something rather than just generate text or images and pass those back.

And so as you have these agents taking more actions, whether it's booking a flight or issuing a refund, or I have a, an agent that I [00:05:00] use to help manage my day-to-day tasks, so it connects to a, a third-party task management system and manages tasks in there for me. All of those interactions that agents make, that's what increases the stakes.

That's what changes the stakes for API security because those API connections now are part of your AI infrastructure, and they weren't before necessarily.

Noah Labhart: Yeah, that, that makes sense. You essentially have agents representing any sort of interactions you'd have with these other systems, with these APIs.

Yeah, totally.

Tim Erlin: And you have to keep in mind the authentication and authorization there. So they're acting on your behalf. Understanding what they're allowed to do or not allowed to do, a context, the user, uh, context in which they're acting is a, a big part of that challenge as well.

Noah Labhart: Absolutely, and I would imagine that what you just said is wrapped into an answer for this next questions.

What are the most common API security assumptions that break down once you have this sort of setup where AI systems are taking action autonomously?

Tim Erlin: It's a tough question to answer because people's assumptions are varied and very [00:06:00] different, but a lot of those assumptions are around a- authentication and authorization.

So the assumption i- is often that if an agent can do something, it's allowed to do that thing. And what I've seen from a lot of organizations in this sort of period of AI transformation is giving up on or making exceptions for core security principles that have always been applied to new technology.

But for some reason, with AI, we throw them out the window and say, "You know what? I'm not gonna worry about least privilege. I'm not gonna worry about strong authentication and authorization 'cause I just really have to adopt and use these AI tools." And I expect we're going to see a series of breaches and incidents that are the result of those assumptions or misassumptions, however you wanna phrase it.

AI systems become more integrated and act more autonomously moving forward.

Noah Labhart: Yeah, I think we are gonna see some things that go down there. Okay, let's flip into threat stats, right? That's Wallarm's research, right? Wallarm's threat stats research points to APIs as a major overlap [00:07:00] point for AI vulnerabilities.

As we're discussing this, it really comes to light. Uh, a- again, AI vulnerabilities and exploited vulnerabilities, so the areas they're gonna actually take advantage of. What does that tell us about where attackers are likely to focus?

Tim Erlin: So the threat stats research is a research that we do on an annual basis.

So at the end of the year we look back at the previous year and collect and analyze a bunch of different data from public sources and from our own platform. What we've seen over the last few years is this growing trend around AI and API overlap. The first question you asked about why is API, AI security API security, it's not just opinion, there's data behind it that, that sort of has pushed us in this direction.

As an example, we've seen that from 2024 to 2025, there was a 390% increase year over year in AI vulnerabilities. So the number of... And we're talking about CVE IDs really, not just CVE IDs, published vulnerabilities, but published vulnerabilities is the key there. So 439 [00:08:00] published AI related vulnerabilities in 2024, 2,185 in 2025.

So massive increase. But AI doesn't necessarily mean API, so what's that overlap look like? And this is where it gets interesting. In 2024, the overlap was essentially 100%. I think there were 438 API vulnerabilities that were also... Or AI vulnerabilities that were also API vulnerabilities. So it was nearly a perfect overlap.

In 2025, that overlap changed dramatically. There were only 786 overlapping vulnerabilities in 2025, but you've still got massive growth of 80% from 439 to 786. So what we saw was the trajectory for the overlap continued to grow at a high rate, but the trajectory for AI vulnerabilities overall took off massively.

So it shifted from 100% overlap to 36% overlap, if I remember correctly. Just very clearly there's a, a strong relationship between the AI vulnerabilities and the API vulnerabilities that drive [00:09:00] this conclusion that AI security is API security.

Noah Labhart: That just makes so much sense. I mean, you think about the architecture of agents, you think about the architecture of AI, which you've already stated, there are API connections between those things.

But now you look at the data, right? And there is a rise in those vulnerabilities based on the fact that it's AI. How should security leaders think differently moving into authentication, authorization, and API abuse when the user, quote unquote, "may be an AI agent rather than a human"?

Tim Erlin: Well, so I think it's a fair question to, to ask whether they should think differently or they should think the same.

And the reason I say that is that, that when there's a new technology that sort of takes off, there's often a tendency to think that we have to build new tools for security controls, that we have to think fundamentally in a different way. The reality is that the security controls themselves on concept don't change that dramatically.

The implementations might, the need to implement them for that particular [00:10:00] technology might change, but the controls themselves don't necessarily change that much. So if you take, for example, authentication and authorization. So authentication, you need strong authentication. That is not unique to AI. You need to be able to authenticate agents in a robust way, the way we authenticate human beings in a robust way.

And if you don't, you're gonna run into the same kinds of problems where an agent can interact with tools and APIs that it shouldn't because authentication isn't present or isn't strong enough. Authorization, you want to apply the principle of least privilege. The principle of least privilege is not new.

It's been around for a long time, but that control isn't well applied to agents. We tend to think these AI agents can go do whatever it is they need to do. They have a degree of freedom right now in, in being creative about how they solve problems, but they really shouldn't. Had some interesting conversations about applying zero trust to agents, which is a good way to think about it.

Zero trust as a principle, not as a, a tool, is really a strong way to approach agent authorization. But the reality is that there, there aren't that many tools out there, if any, that really [00:11:00] give organizations the ability to implement some of those security controls effectively for AI. So when you say how thinking differently, it's not necessarily about thinking differently, it's about thinking creatively about how to implement the controls you know need to be present, those critical controls in an environment where AI is deployed or when you're-- while you're undergoing an AI transformation.

Noah Labhart: It's interesting to think about this. Some of this is best practices here, the things that we're talking about, right? And in securing APIs and how people may or may not take that seriously, but with the advent of AI, it's really propagating this sort of problem here. To get started, what is one practical step teams can take today to strengthen API security before AI adoption es- expands further?

'Cause it's happening fast.

Tim Erlin: So be- before we talk about that practical step, I wanna expand on something you touched on there because you, you almost said it. It's not just that APIs underpin the AI interactions. It's also the growth in AI is driving a massive growth [00:12:00] in the number of APIs, an almost exponential growth in the number of APIs that are out there.

Because the more AI agents and AI applications need to interact with other tools via APIs, the more organizations are building and deploying APIs to support that need, the more APIs there are out there, and the more of an attack surface is available for attackers. Not an AI attack surface necessarily, but an API attack surface.

And a good example of that actually is, uh, as a protocol. So MCP is a protocol that allows an agent to access tools and resources and prompts in a programmatic way to interact with another tool. It, it is another type of API, and it runs over an API protocol most of the time. So MCP is really, as a growth area, is really an expansion of the API attack surface.

So I don't wanna leave that unsaid that it's not just that AI is growing, but that it's driving a massive growth in API threat landscape as well. So what was the question that I completely ignored and decided to answer a different one?

Noah Labhart: No, I'm glad you touched on that one. My question was around [00:13:00] practical steps, right?

Getting started, what is one practical step teams can do today to strengthen API security before AI adoption expands further, because it's happening really fast.

Tim Erlin: So if it's not clear, I'm a fan of looking at the patterns that have occurred in the past and applying them to the future. So anytime we have a new technology, whether it's virtualization or cloud or now AI, there is a pattern that occurs from a security standpoint that's worth following.

It's not a bad pattern at all So the first thing, the first practical step is inventory. It's discovery. It's understanding what you have in your environment. So if you wanna do something immediately, start by creating an inventory of what AI tools, AI workloads you have in your environment. Expand that inventory to the resources that those AI workloads use.

So that would be the MCP servers, the, the APIs, the data sources that they access. And that inventory is your starting point so that you can then move on to the second step in that pattern, which is now I have an inventory, but I don't know what those things are doing. So [00:14:00] understanding the behavior, the interconnections, the connections between those assets and objects, that's the second step.

So I think those are first two steps, and then you move on to blocking bad actions, and then ultimately, you end up with governance and compliance because the regulatory environment will eventually catch up.

Noah Labhart: Okay, last question, Tim. So once you accept that AI security depends on APIs, what do organizations actually need to discover before they can protect it?

And knowing a little bit about Wallarm, I kinda know where you're gonna go with that, and I'm excited for you to say it.

Tim Erlin: Yeah. I kinda hinted at it before, which is that your AI inventory isn't just AI. So if you're looking at creating that inventory, and you're cataloging the agents you're running, maybe the LLMs that you, you have running or that you're accessing, that's only part of the puzzle.

You have to also discover the things they connect to, the APIs they use, the MCP servers they use, the data they access, and that data has a... It brings in a, a whole conversation of [00:15:00] sensitive data and PII because that's part of discovery too, understanding what data your AI agents and LLMs have access to and how it moves about in your environment.

Those are key components for discovery in order to deliver protection because you can't protect what you don't know about, and so you have to start by finding out about all of those elements in your environment related to your AI workloads.

Noah Labhart: No, that just makes so much sense, and the way you said that too, you can't protect what you don't know about.

You have to discover these APIs. You have to have a portfolio of them, and you have to know what you have to secure out there. Tim, I really appreciate you being on the show today. It's very clear from our conversation that AI security is in fact API security, not only because that's what the architecture actually points to, but the data actually points to it as well.

As you mentioned in Wallarm's research, there's a rise in vulnerabilities related to AI alongside the increase in agentic representation of people's actions. So it's critical that businesses take this seriously and take a hard look at how they are securing [00:16:00] their APIs in order to best secure their AI infrastructure and their agents.

So Tim, thank you very much for being on the show today.

Tim Erlin: My pleasure. Thank you for having me.

Noah Labhart: If it wasn't clear to you before, AI security is API security, and platforms like Wallarm are your go-to solution in order to discover your entire portfolio of APIs and secure them before your AI and agents take more action than you're ready for.

If you'd like to learn more about Wallarm, you can visit wallarm.com. That's W-A-L-L-A-R-M.com. And thanks again for listening.