Detection is not Enough

Noah Labhart: [00:00:00] Hello listeners. Today we are dropping another episode in our series, 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 speeds. In his follow-up appearance on the Code Story podcast, Tim Ebbers, Field CTO at Wallarm, discusses why detection alone is insufficient for AI-driven systems, what real enforcement looks like at the runtime level, and what accountability becomes possible once all four stages are in place [00:01:00] Tim, welcome back to the show.

Excited to have you back on a follow-up episode on Code Story. Thanks again for being on the show.

Tim Ebbers: Oh, I appreciate being here. It was fun last time and looking for more fun this time.

Noah Labhart: Absolutely. We're gonna have a ball. So today's episode is entitled Detection Is Not Enough, and we're gonna talk about how detection alone is insufficient for AI-driven systems.

And jumping right into it, security teams are used to detecting incidents and responding after the fact. Why is that model insufficient for AI-driven systems?

Tim Ebbers: I think as you look at how fast AI is developing, not only on the bad actor side, but also on the code side, we're putting out a whole lot more code, and AI can, on the bad actor side, can go through that, those endpoints so much faster than they can today when it was all human done.

Sure, we had automation before, and they could have lots of, lots of IPs hitting an endpoint, but really when you look at the detection then response [00:02:00] model, it was designed for human speed incidents, and with AI, it's just so different. People exfiltrating data used to take hours, and now it's seconds And when you look at the way that we used to do enforcement, it was fire alert, send off some logs, and then go look to see what's going on, and by that time, the data's already gone.

So detection tells you what happened, but it doesn't really change what happened. For AI systems, that's not a tolerable gap.

Noah Labhart: Yeah, that makes sense, and I think it feels familiar with the speed that AI is moving, and you describe the older process of responding for security teams. What does their enforcement usually mean today, and why can actions like restarting pods or rotating credentials, things like that, come too late?

Tim Ebbers: So there's a lot of enforcement that's done at the perimeter, and that's really where we spent a lot of time is defense in depth at the perimeter, really block at the firewall, rotate keys, [00:03:00] maybe kill a pod. Those responses are usually for things that have already occurred. So a pod restart takes time, but that data may already be gone.

That, that credential rotation requires propagation. In the meantime, the AI agent is still being compromised or is misbehaving and can invoke a production workflow. So exfiltrating session context and violating compliance boundaries happen in real time or in runtime versus after the fact, and you have to be able to enforce that at the point that it happens, not after the fact.

Because then you're just doing cleanup and not enforcement.

Noah Labhart: So that seems clear, and answer for your first two questions really create this picture of a gap between incident and then response in the traditional way, and I could probably cherry-pick or kinda hypothesize from what you've said so far, but why does AI behavior require controls that operate closer to that runtime?[00:04:00]

Tim Ebbers: Because they don't operate the same. So traditional software runs very differently than an AI agent who's making decisions in real time, whereas the old APIs and the old traditional software, there wasn't really decisions being made and tools going and being used based on inferences that are coming in.

It's really more deterministic. And really, in an AI agent, they're dynamic, and then the tools that they call and the data that they pass and the services that it invokes are all done at runtime and all done based on model outputs. So you can't really enumerate that behavior In a static policy written before the deployment.

It has to be watching in runtime and changing with the behavior of the agent and understanding the guardrails that need to be put there.

Noah Labhart: That makes total sense. It has to be as, I don't know, as adaptable or as flexible as the agent themselves. It has to be learning from what is happening. Is that... Am I hearing you correctly?

Tim Ebbers: Yeah. It has to be really flexible and really be able to watch [00:05:00] the behaviors and/or put guardrails around that runtime so that you won't let it go and do things that aren't what you want them to do. And that's really the big thing, is understanding the behavior of those agents and only giving them the permissions that they, that they should have.

Noah Labhart: 100%. Okay. When enforcement changes at the different levels, right? What's different about it happening at the kernel level rather than maybe, say, network, identity, or application layer?

Tim Ebbers: Three things change. First, you enforce without the application's cooperation, right? The application doesn't need to be patched or updated, so you're doing this in real time as the transaction is happening.

Second, you can act on the identity that's visible at the workload level, the specific session, the specific user, the specific trace, not just the IP or the certificate. So you can see all of it when you're looking at the kernel versus what you were able to see before, which might just be a log. And then we can inject different ways of [00:06:00] enforcement in the kernel that can immediately block those transactions or that transaction while the pod keeps running.

We don't have to take the application down to do enforcement. Other sessions are unaffected, and you haven't deployed anything, so you don't have to change your application necessarily if you're doing it at the kernel level. So your developers are just developing how they normally do it, and we become a really a layer beneath that, watching everything.

Noah Labhart: I'm tracking with that. And to stick with the session there and then not changing sort of the application, and maybe this applies to it a-as well, what does it mean to revoke or contain a compromised AI session without having to touch the broader deployment?

Tim Ebbers: They really go hand in hand. When you're able to, to really get in the middle of that transaction and terminate that active connection mid-flight, you have the ability to protect the downstream data that would've been compromised that through that transaction.

And that's the thing that is hard to see and [00:07:00] hard to understand is what that AI agent is going to do at that particular time based on that particular context or those particular prompts with the data that it was given.

Noah Labhart: For sure. Okay, so then how does real-time blocking change the risk side of things, the risk equation for AI agents that access sensitive data, external services, or production workflows?

How does it change the risk side of the world?

Tim Ebbers: It actually changes the question from how quickly can we respond to can we stop this before it completes? It's fundamentally a different risk posture. If an agent in mid-flight on a request that would exfiltrate PII or invoke a payment API it shouldn't touch, real-time enforcement lets you terminate that in progress.

You're not doing incident response anymore, you're actually preventing the incident.

Noah Labhart: Which is fantastic. You're not doing cleanup, it's stopping it from happening. So i-if organizations are hearing this right now and they're ready to jump in and get going, what should [00:08:00] they be able to stop immediately? What kind of AI behaviors should they be able to stop immediately?

Tim Ebbers: I think there's two things that you need to think about, and it's not a long list, and I think people think it's-- there's always a journey, but it's not, it's not 300 things that you have to think about. It's really a few categories, which is access to data, right? Does that agent and should that agent have access to that tool which has that data?

Calls to external services outside of the approved scope. So should this agent be able to go external or to this other location with this PII data? And understanding the violations of compliance boundaries. I think compliance boundaries are gonna get very interesting with HIPAA and PCI and, and whatever else applies in your industry to understand if those agents are being manipulated and sending or receiving data from where they shouldn't.

Things like prompt injection patterns and unusual tool sequences in those sessions while those things are happening are really important to understand and to be able to stop immediately, and [00:09:00] th-the policy needs to surface and manage those things for you. But the problem is today, most organizations really don't have a mechanism to enforce it at the moment it happens.

Noah Labhart: That makes sense there. When you think about compliance and security, I think some folks can respond to that feeling like it's a clampdown on innovation and speed, right? How do teams balance strong enforcement, which is really important, with the need to avoid slowing down AI dev and deployment?

Tim Ebbers: The key architectural decision is to separate enforcement from deployment If policy changes require a deployment, you've now coupled enforcement to a release cycle, and teams will avoid touching it, right?

So you don't wanna do that. So enforcement rules have to be pushed at runtime, updated without having anything restarted, so that you can iterate on your policies independently of application changes, and then you'll get strong enforcement without becoming a bottleneck. Because that's the thing that [00:10:00] security folks and infrastructure folks are always...

They don't wanna be the bottleneck, right? They don't wanna be the blocker. And so if you separate those two things, I think that it-- you, you cease to become the bottleneck, but you still get strong enforcement. I think the other big piece is observability. Teams adopting enforcement faster when they can see what would have been blocked before they turn it on, right?

Understanding the blast radius of what would have happened or what will happen, I think is really important before you go and turn things on.

Noah Labhart: Certainly. Okay, one, one more question, Tim. Once organizations can discover, observe, and enforce AI behavior and security and enforcement, what does accountability look like at the enterprise level?

Tim Ebbers: Yeah, and I think the big thing here is accountability requires evidence, not just logs. I think gone are the days of, "Hey, show me the log when this happened," because it doesn't help you understand what the agent did. The question that auditors and regulators will ask isn't, "Did you have a policy?" It's, "Did the policy work, and how can you prove it?"

And I think [00:11:00] the, "And how can you prove it?" is the really important part, right? If enforcement is tied to specific sessions, specific users, specific tool calls with timestamps and outcomes, it means being able to answer that question of, this is what the agent had access to based on this policy, and if it was off the rails, we would have fired an enforcement block or terminated the connection either which way.

But that's really important is being able to show that trace all the way through so that you can produce that evidence. And then you've got the closed loop from discovery through governance that organizations can not only show what was observed, but it-- also what was stopped, so that in the wave of the new AI compliance requirements, because they're coming, they will be ready before they hit, hit the different avenues.

Noah Labhart: Yeah, absolutely. Tim, all this makes too much sense in my eyes. Moving the enforcement to runtime. AI runs at system speed incidents, not human level incident [00:12:00] speed, and so security teams need a new model. You gotta enforce security fast and at runtime. And I hear you saying that companies re need-- really need to change their risk posture from thinking about cleaning up incidents to preventing issues from happening altogether.

And moving enforcement to that runtime is the real answer to changing this posture and ensuring that companies remain secure, but still can move fast in their deployment. So Tim, I really appreciate you walking us through this today and appreciate you returning to the show today.

Tim Ebbers: Yeah, great to be here.

Thanks for having me

Noah Labhart: As Tim points out, security teams need to change the way they think about incidents. AI is changing the game and the speed around models and programs that will require enforcement to be moved to runtime 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 [00:13:00] listening.