Agentic Operators for Web Application and API Protection

Host: Hi, Tim. This is, Shadow with ViB. Yep, just scroll down. The second poll was launched.

Tim Erlin: Perfect, there it is. Thank you.

Host: Definitely.

Tim Erlin: So the second poll is there, and We can see results coming in for it. The question here was, how much should an AI agent be allowed to do on its own in your security stack? And this is interesting, because I've just talked about how we're really pushing… how the threat landscape is really pushing us, to… Operate at a speed that humans can't keep up. And what we see here is that 29% have said, that, the agent should recommend only and humans act. And, that 41%, it should act only after human approval. 21% said it should act on routine changes, approval for the rest, so a little split.

And then only 3% said it should act fully on its own. So what this tells me is that we as an audience don't feel like we're quite ready for AI agents to run security truly autonomously. We're looking for, agents that can, can make recommendations or, you know, produce, actions, but, you know, only act after human approval. Maybe some of us are ready for routine changes to be made by an agent. That's a very interesting result, and we'll talk about what the equation looks like now from a labor perspective. So, there's some data here to share as well. So we talked about the amount of traffic, that is, you know, bots, or automated attacks.

But we haven't talked about the number of security alerts that are never investigated. So one of the sources, you know, the sources are listed at the bottom down there, says that 28-42% of security alerts are never investigated. So the example from that, the Mexican government agencies of 20 vulnerabilities that just hadn't been patched, you know, those are one example. The other example are not vulnerabilities, but alerts from a security control that says something happened.

And those are not necessarily being investigated. 60% of teams say that a skipped alert became a material incident. So it's not that we're just ignoring or unable to process alerts that don't matter, and that's okay. In a lot of cases, those alerts do turn into something material. And then, 45 minutes, median time to investigate one alert. So we'll take some of this data and turn it into a little bit more of a, conversation. So, let's just take a hypothetical, assume that you've got something like 1,800 false positives a week from your WAF, as an example. Based on that 45-minute figure, it's gonna take you 1,300… roughly 1,300 analyst hours to investigate all of those. That's about 34 full-time analysts.

I'm willing to bet that very few of you have 34 full-time analysts to investigate, to spend time on investigating false positives, that occur. But let's just say that you… you can investigate, you know, a third of them, one in three of them. That's still about 150 hours a week for four analysts, and that comes out to about $390K. So. even if you can't investigate all of them, you're still spending a significant amount of money investigating alerts. And this explains why we're seeing that 28-42% of alerts never get investigated, because there are just too many of them. You can also, of course, match that back, you know, with all the caveats about,

the cost of a breach data. We can all acknowledge that breaches are expensive, even if we can't agree on the dollar figure, and what should go into that dollar figure. you're talking about real cost, that's the point, is that it's not theoretical. When you don't invest… when you're unable to investigate alerts. When you spend time chasing false positives, that aren't real alerts, you're creating that potential cost of a breach, as… in addition to the analyst hours that have been spent.

So, all of that goes to say that the equation right now for managing alerts, from a WAF or from other security tools, it doesn't make sense. It's not feasible. It's not sustainable. And if we combine that with the, what we just talked about in the increase of, you know, as I said, AI speed attacks. It's not gonna get better, it's gonna get worse, and as long as we have… we're relying on human beings, as the primary means. To investigate these alerts, we're going to be falling behind.

Now, I also want to talk about the other side of this equation, which is where are companies investing? Where are organizations investing in cybersecurity? And specifically around AI and cybersecurity. So this is information from a Gartner press release, so public information that they shared about where spending is going. Drawing the distinction between, securing AI and AI for security. So, securing AI, I'm deploying agents and things in my environment and my applications, I need to make sure they're secure.

And AI for security. I'm sticking an agent in my security tools, or building security tools that have agents in them to actually automate my security process. So addressing the problem we just talked about on the previous slide, that is AI for security. And this was surprising to me, that the… there's such a difference Between securing AI and AI for cybersecurity. The red bars there are the spending on AI, or the market for AI, for cybersecurity, and the yellow, the 5.5% at the bottom, is what's being… the market for securing AI. So what this tells me is that organizations are actually spending more money, you know, on AI for cybersecurity than securing AI itself. And that makes sense when we think about the…

Well, it surprised me. It also makes sense when we think about the technology, doesn't evolve at aggregates point. All of those capabilities… all of those, technologies that were in the stack before are still there. When we look at the examples we had, often the ways that those technologies are being exploited are not new, but the speed at which they're being exploited is increasing, and then it makes sense that the spending would go towards AI for security, as opposed to securing AI. So, let's move on to the Agentic Operators themselves. So, what do I mean by Agentic Operators? I've used this term a couple of times. Because I want to draw a specific distinction between an AI agent, like a chatbot, that provides recommendations, or that

Infaces primarily with a human being, and, you know, provides, you know, generative output, as an example, with an agent that is designed to operate a tool, or to actually take actions in that tool. So that's why we chose the term Agentic operator here. So an Agentic operator in this case, for us, is about detecting, investigating, verifying, remediating, and then learning from what it's done in order to improve in the future. So, in the case of WallArm, and we'll get into the demo, that means looking at attacks, generating… investigating those attacks, generating findings that are verified, providing remediations, actions that it can actually take in the product.

And then learning from those remediation actions, in the future as well. So it runs the product, and, you know, takes actions for you. And that doesn't mean that you don't stay in control, so, you know, that poll at the beginning of this section around what agents should do on their own was very telling. You know, people would like human approval, human in the loop. And so that's built into this process with the Waller Magentic Operators as well. There are scoped permissions, so the agents themselves have

limited permissions to their jobs. There are approval gates, that you can enable or disable, so if you want an agent to run autonomously, you can have it do that, but it sounds like most people would like to have the approval step involved, and that exists. The agents provide evidence for everything that they do, and every finding, and that creates an audit trail. You can also override those agents, so if you think their judgment is wrong, you can override it and decline a recommendation or a remediation, and it will remember that moving forward. And that gives you that ability. As I mentioned, you have that ability to dial its autonomy to approval or not approval as well.

So let's talk about the specific Agentic Operators that WallArm is introducing. So, we've got four to talk about here, two of which are available in the product now, and two of which are coming soon. And then there are more coming soon beyond that. You know, once we've built the platform for Agentic Operators, we can come up with lots of ways to add agents to the platform. The first is, the attack anomaly Investigator. So, this agent is designed to, respond to traffic anomalies in the WallArm product. So, API traffic, web application traffic, MCP traffic, looking for those anomalies, and triggered on them.

It investigates each anomaly, and then determines if it's malicious or not, based on its investigation, and then it provides recommendations and actions. to take. So that can be things like adding an IP or IPs to a deny list, turning on or off blocking mode, you know, issuing a virtual patch or rate limiting, and that's the… its ability to respond, to those. And as I said, it will provide those recommendations, and then you approve them. As well. And then, the false positive fixer, is actually two agents that work together, which is why you've got this sort of, twins image here. There's an analyzer and a resolver.

The false positive analyzer, runs on a schedule, looks at the attacks that have been registered, and hunts for anything that might be a false positive in those attacks. It reports its findings to the resolver, and then the resolver confirms whether it's a false positive or not, and drafts rules, tuning rules, to eliminate those false positives, if they show up. This is an interesting one for us to demonstrate because, it requires that we manufacture false positives when our development team is, of course, always working to eliminate false positives, and so,

we have to sort of create situations that wouldn't ideally occur in a real environment. But we know that false positives are out there, and if you're spending your time on your web application firewall or your API security tool, manually tuning for false positives, this is the agent that is designed to eliminate that work for you and, you know. Take it over for you. We're also working on building another pair of agents that go together but operate independently. One is a red team agent, designed to essentially pen test your application environment, your APIs, and your web apps, and confirm that they are actually vulnerable, you know, as a pen tester would.

It can, of course, target your development environment or test environment instead of production, or production environment. And it will produce output, you know, of confirmed, exploited vulnerabilities, as you would expect from a red team agent. It gets paired. One thing on the Red Team Agent that I think is worth mentioning, actually, before I jump ahead. Which is that, because WallArm is built to process traffic and look for attacks, we have context already that other tools don't necessarily have. So the red team agent can actually leverage the context of what it's seeing in real traffic in order to craft exploits and validate whether or not applications and APIs are vulnerable.

Now, that red team agent pairs really well with the virtual patch agent. So, the virtual patch agent is designed to take input from either the red team agent or an external source, as long as that external source provides enough information to actually craft a virtual patch. In which case, it can, provide that virtual patch, which Wallerm can then deploy, you can approve and deploy. to block specific attack traffic to a specific application or API while you're waiting for development or developers or security to actually patch that vulnerability. So that's intended to close that gap between, we found a vulnerability and we patched it, the gap in which attackers might take advantage of that vulnerability.

So, if we, map these agents back to the incidents that we talked about. There are some interesting mappings here. I'll point out, first of all, that, you know, the false positive agents, which are really powerful for, you know, sort of lowering the operational burden of a WAF, don't map back to a specific incident, because they're operational agents as opposed to threat response agents. But, we can look at the other agents, the McKenzie-Lilly incident, incident that we talked about. The red team agent and the virtual patch agent would fit there.

The Mexican government incident, the attack anomaly Investigator agent fits there as well as the virtual patch agent. And that Anthropic Git MCP server incident, maps back to the red team agent and the virtual patch agent as well. So we're really excited to get those moving forward and delivered on top of the three agents, or two and a half, if you want to count the false positive as one, agents that we have in place today. So with that, we get to the end of the slides and to a live demo. So I'm gonna switch over to the product interface.

And I won't… I'll assume that most of you are not familiar with WallArm's product or interface, so I'll give you sort of the… I'll call it the nickel tour, not a full demo of what WallArm does, but enough to understand what the agents are doing, because the purpose here is to talk about the Agentic Operators. But of course, we're happy to do a full demo at any point in time. So the screen you're seeing here is the threat prevention dashboard, which is what you see when you first log in, and it shows you traffic that we've seen, as well as attacks that we've seen in this demo environment. This demo environment's relatively small. And, you can see… the discovered APIs in this environment here.

They're all in one application, and there are, you know, sort of 3 endpoints with a number of, supported methods on them. And all of that information about attacks flows into the attacks interface, so you can get a list of all the attacks that you've seen in the environment. You can drill into those attacks, so this is a remote code execution, get some summary data. You can drill into the individual requests that were part of this attack. So this specific attack contained about 3,000 individual requests. You can see, all the information about those requests here, what the attack payload was, and you can look at the request itself and see that that attack payload occurred in this,

In this header, actually, in this case. If there's a body for that request, you'd see the body as well. So, lots of detail about the attacks that you're seeing. As well. And then you can also see the session data, so if you're interested in what happened around the attack request, you know, what led up to it and what the attacker did afterwards, the session information will show that to you. You know, we've got a couple of sessions here that have attacks in them. We've also got a session that doesn't have any attacks, and you can see all of the requests in that session, and walk through what happened in that session, whether there's an attack or not.

And WallArm is designed to sit in line and block attacks. So we're not just about detection, we're also about blocking, attacks as well, and that's a key differentiator from some of the other tools in the market around API security. WallArm also supports API protocols, you know, across the board, and, what we call deep request inspection, which is that, decoding of encoded, requests, multiple encoded requests, or, nested encoding. as well as, having no limits on the, no size limit on how far into the request we will look for attacks as well. So, much more resistant to those WAF bypasses that I was talking about.

But we are here to talk about the Agentic Operators. And I'm going to start with the team of Agentic Operators that we have here. So, these should look familiar. We've got the attack anomaly Investigator here, we've got the false positive analyzer, and we've got the false positive resolver. In this environment. And for each of these, you can configure, as I said, whether you want to require approval before making changes, and you can see the permissions that each of these agents have as well. Now, the agents run on either a schedule or they run on a trigger. And they produce So there are the runs listed here, so you can see every run, that has happened for these agents.

And you can see that some of these were for this morning, from this morning, some from yesterday in this case. You can see what they, you know, findings and remediations. So these runs, they produce findings. And so from here, you can see the findings. In this case, we've got 3 findings, that are open. There are 7 that have been remediated already. And if you select one, this one that's marked not fixed has already been selected. You can see a lot of detail about what that finding is. This is a high-confidence false positive. If you want to mark it as wrong, as I said, you can. You can see an example request, a summary.

And then you can get into the evidence and history as well. So if you want to look at the evidence, this gives you the remediation analysis of why this was deem… deemed a false positive with high confidence. You can look at the history of exactly what happened here as well. So there's a lot to see, you know, and understand exactly what occurred here. And if we look at another example, let's take the… attack spike, this is a different one, because this is a malicious anomaly as opposed to a false positive. So this is from the,

Attack Anomaly Investigator, which saw 2,000 attacks in 5 minutes, which was 81.5 times the usual level, and so it investigated that, determined that it's a real attack, gives an explanation of that. The evidence, again, is here. Verdict is a real attack. And, tells you exactly what happened with that particular finding. Now, the findings are related to remediation, so I showed here, that you can see the remediations from here. But you can also see them on the remediations tab here. So these are all the recommended remediations. All of these agents currently are set for human approval, so none of this happens automatically unless you want it to. But these are the remediations that,

have been proposed. So, for example, you've got a tuning rule here. that says we should disable cross-site scripting detection, on the product description HTML field for catalog imports. So this is a very specific tuning rule designed for a specific false positive, that was detected in the environment. And I can approve that rule, and it will go create the rule, and it'll take me to the next one. You also have… the rest of these tuning rules are from the same false positive analyzer. You also have blocking IP addresses and adding a virtual patch. These come from the Attack Anomaly Investigator.

And in this case, it's recommending that you block requests from these IP addresses for 24 hours, and if I choose to approve that, it will create that. that rule for me. And I can go see where those show up, for example, I now have, I will have, as soon as it completes its finding, I'll have, those rules populated. into the mitigation controls and the IP and session lists, and the rules, if it's a, if it's a rule, in those, relevant sections. So that allows the, false positives to be addressed with the false positive analyzer, and the attack anomaly to be addressed by blocking specific IP addresses for a period of time, or in this case, creating a virtual patch for SQL injection on a specific endpoint as well.

So with that, it brings us to the end of the demo of the Agentic Operators and how they operate in the environment. I'll end on the overview screen. Which, if you were using the product, might be where you start, but it's helpful to have the explanation of how those operators work. To see the overview screen, you can see that we've got 10 findings, the different types of findings, the remediations that have been, Proposed, approved, declined, you know, and a number of other statistics, including the… how many candidates, or spikes were investigated, what was judged a false positive or judged malicious, and what was proposed as well.

So that overview gives you a dashboard view of exactly how the Agentic Operators are operating in the environment. And, with that, we can… Come back to the questions section. I think we've got time for questions here. Let's take a look. Shiloh, what have we got.

Host: I am going to relaunch those, the polls initially, just because some of our members were not able to respond, so you'll get a set of those. They're really active in the session, so awesome, thank you. I'm gonna go ahead and start with our first, question here. Will the red team agent cause damage in my environment?

Tim Erlin: That's a great question. So… anytime you're exploiting vulnerabilities, there's always the potential for some damage to occur. And the point of a red team agent… in fact, the distinction between penetration testing or red teaming and vulnerability scanning is that actual exploitation of a vulnerability. So a vulnerability scanner is designed, generally speaking, designed to find vulnerabilities without doing any damage. Or without actually exploiting them.

And that comes with a trade-off. You don't know for sure that those vulnerabilities are exploitable. A penetration tester, or a penetration testing agent, or a red team agent, is intended to specifically exploit vulnerabilities. So that's why it's important to be able to scope what it's doing. pointed at the right environment, and while many times those exploits won't cause damage or are designed not to cause damage, it's possible because you are actively exploiting a vulnerability. So, you have to understand what your objectives are between vulnerability scanning and, you know, penetration testing or red teaming.

Host: Awesome. Our next question here is, do the operators change anything without a human approving it?

Tim Erlin: So they can… I think I covered that in the presentation, but I want to make it explicit. The operators can operate autonomously, but you can also just set them for human approval, and then they operate with human approval, as we saw in the demo. You have to actually approve. The… the… the remediations before they get applied.

Host: Awesome. And then, where does my traffic data go when the AI analyzes it?

Tim Erlin: so there could be a couple of questions there, and I'll answer both of them. Actually, I'll answer a bunch of questions, so… the way that WallArm is architected, when it processes traffic, there are two parts. There's a… a management plane and a filtering node. Traffic flows through the filtering node. You have lots of options for how to deploy that filtering node. You can deploy it inside your environment so that the traffic never leaves your environment. You can use our managed filtering node, in which case you're routing your traffic through a wallarm managed filtering node. You can specifically redact information that goes from the filtering node to the management platform, so there's lots of ways for you to control that.

If you're using the… so that's one question. If you're asking about specifically the agents, in that case, we're using Amazon Bedrock Specifically for the AI component of that. So, the traffic has to be processed by that agent, but it doesn't leave the environment, and we chose Amazon Bedrock specifically for the controls that it offers in terms of managing where data goes.

Host: Okay, and then, why not build our own agents to do this?

Tim Erlin: That's a great question. You could. I mean, the reality is that you could build your own agents to do this. You would be missing a few components, which is sort of like the context that we have for all of the WallArm customer base. But the… the capabilities are there for people to build their own agents to do these kinds of things. You know, I think about it a little bit like,

you know, sort of any kind of expertise, you know, baking bread, for example. Like, anybody can bake their own bread, but we still buy bread from the bakery, because A, we got other stuff to do, there isn't time, you know, the baker has more experience and learned from all of their mistakes, and we don't really want to have the infrastructure and all the tools to bake our own bread. So. it's similar in that sense, you know, but if you want to build your own Agentic Operators for the platform, we're happy to have you do that.

Host: Awesome. And our last one here is, can I connect the operators to the AI tools my team already uses?

Tim Erlin: Yeah, absolutely. So… The operators that we've introduced now are built on top of our current platform, which does have APIs and an MCP server as well, so you can interact with the operators over those tools. We're also launching a new AI-native platform in the near future, which is intended to be even more accessible for external AI tools, as well. So, We're definitely interested in having customers interact with the operators programmatically over, you know, using their own agents, all that kind of stuff.

Host: Awesome. So that's going to conclude our session for today. So on behalf of Wallarm and ViB, thank you for joining us today. We appreciate you taking the time to be part of today's discussion. Before you go, be sure to visit the resource tab for additional materials shared by today's sponsor. You can also scan it here on your screen. A recording of today's webinar will be shared with all registrants shortly. If you've registered through ViB using your business email address and have any questions about today's webinar or your registration, please reach out to us at webinars at ViB.tech.

Thank you again for joining us, and we hope you found today's session valuable, and look forward to welcoming you to another ViB event soon. And that concludes our session today. Everyone have a wonderful day.