Latest / Code Story | Startup Podcast for CTOs, CEOs and Technical Founders / The AI Control Loop: Detection is not Enough - with Tim Ebbers of Wallarm

Transcript

The AI Control Loop: Detection is not Enough - with Tim Ebbers of Wallarm · Code Story | Startup Podcast for CTOs, CEOs and Technical Founders

• 0:01
  [SPEAKER_00]: Hello listeners!
• 0:03
  [SPEAKER_00]: Today we are dropping another episode in our series, The AI Control Loop.
• 0:07
  [SPEAKER_00]: How Enterprise is governed the AI they've already deployed.
• 0:10
  [SPEAKER_00]: Sponsored by our friends at Wallarm.
• 0:14
  [SPEAKER_00]: Wallarm is the AI Control Platform for Enterprise AI, protecting every AI workload, API, and application in production.
• 0:22
  [SPEAKER_00]: Giving CSOs the governance they need, and CIOs the speed they demand.
• 0:27
  [SPEAKER_00]: Organizations choose Wallarm for a complete inventory of APIs, AI agents, and AI apps using patented AI ML-based threat detection, and blocking the operates at production speeds.
• 0:40
  [SPEAKER_00]: In his follow-up appearance on the code story podcast, Tim Ebers, field CTO at Wallarm, discusses why detection alone is insufficient for AI-driven systems.
• 0:50
  [SPEAKER_00]: What real enforcement looks like at the runtime level and what accountability becomes possible once all four stages are in place.
• 1:00
  [SPEAKER_00]: Tim, welcome back to the show excited to have you back on a follow-up episode on code story.
• 1:05
  [SPEAKER_00]: Thanks again for being on the show.
• 1:06
  [SPEAKER_01]: Now I appreciate being here.
• 1:08
  [SPEAKER_01]: It was fun
• 1:10
  [SPEAKER_00]: Absolutely, we're going to have a ball.
• 1:12
  [SPEAKER_00]: So today's episode is entitled Detection is not enough.
• 1:16
  [SPEAKER_00]: When we're going to talk about how Detection alone is insufficient for AI-driven systems and jumping around into it, security teams are used to detecting incidents and responding after the fact.
• 1:27
  [SPEAKER_00]: Why is that model insufficient for AI-driven systems?
• 1:30
  [SPEAKER_01]: 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.
• 1:50
  [SPEAKER_01]: Sure, we had automation before, and they could have lots of IPs hitting an endpoint, but really when you look at the detection,
• 2:00
  [SPEAKER_01]: It was designed for human speed incidents, and with AI, it's just so different.
• 2:05
  [SPEAKER_01]: People exfiltrating data used to take hours and now it's seconds.
• 2:10
  [SPEAKER_01]: And when you look at the way that we used to do enforcement, it was viralirt, send us some logs, and then go look to see what's going on.
• 2:19
  [SPEAKER_01]: And by that time the data's already gone.
• 2:21
  [SPEAKER_01]: So the detection tells you what happened, but it doesn't really change what happened.
• 2:26
  [SPEAKER_01]: For AI systems, that's not a tolerable gap.
• 2:28
  [SPEAKER_00]: Yeah, that makes sense.
• 2:29
  [SPEAKER_00]: And I think that feels familiar with the speed that AI is moving and you describe the older process of responding for security teams.
• 2:39
  [SPEAKER_00]: What does their enforcement usually mean today?
• 2:42
  [SPEAKER_00]: And why can actions like restarting pods or rotating credentials?
• 2:46
  [SPEAKER_00]: Things like that come to late.
• 2:48
  [SPEAKER_01]: So there's a lot of enforcement that's done at the perimeter.
• 2:51
  [SPEAKER_01]: And that's really where we spent a lot of time is defense and depth at the perimeter, really block at the firewall, rotate keys, maybe kilopod.
• 3:01
  [SPEAKER_01]: Those responses are usually for things that have already occurred.
• 3:07
  [SPEAKER_01]: So a pod restart takes time, but that data may already be gone.
• 3:12
  [SPEAKER_01]: That credential rotation.
• 3:14
  [SPEAKER_01]: requires propagation.
• 3:15
  [SPEAKER_01]: In the meantime, the AI agent is still being compromised or is misbehaving and can invoke a production workflow.
• 3:21
  [SPEAKER_01]: So, extra trading session context and violating compliance boundaries happen in real time or in runtime versus after the fact.
• 3:32
  [SPEAKER_01]: 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
• 3:40
  [SPEAKER_00]: 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.
• 3:51
  [SPEAKER_00]: And I could probably cherry-pick or kind of hypothesize from what you've said so far, but why does AI behavior require controls that operate closer to that runtime?
• 4:00
  [SPEAKER_01]: because they don't operate the same.
• 4:03
  [SPEAKER_01]: So, traditional software runs very differently than an AI agent who's making decisions in real time.
• 4:09
  [SPEAKER_01]: 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.
• 4:19
  [SPEAKER_01]: It's really more deterministic and really in an AI agent, they're dynamic.
• 4:24
  [SPEAKER_01]: 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.
• 4:33
  [SPEAKER_01]: So you can't really enumerate that behavior in a static policy written before the deployment.
• 4:39
  [SPEAKER_01]: It has to be watching and runtime and changing with the behavior of the agent and understanding the guardrails that need to be put there.
• 4:47
  [SPEAKER_00]: that makes total sense is to be as, I don't know, as adaptable or flexible as the agent themselves.
• 4:52
  [SPEAKER_00]: So that's to be learning from what is happening.
• 4:54
  [SPEAKER_00]: Is it, am I hearing you correctly?
• 4:56
  [SPEAKER_01]: Yeah, it has to be really flexible and really be able to watch the behaviors and or put guard rails around that runtime to that you won't let it go and do things that aren't what you want them to do.
• 5:09
  [SPEAKER_01]: And that's really the big thing is understanding the behavior of those agents and only giving them the permissions that they should have.
• 5:15
  [SPEAKER_00]: 100%.
• 5:16
  [SPEAKER_00]: Okay, when enforcement changes at the different levels, right?
• 5:20
  [SPEAKER_00]: What's different about it happening at the kernel level, rather than maybe say network identity or application layer?
• 5:27
  [SPEAKER_01]: Three things change.
• 5:29
  [SPEAKER_01]: First you enforce without the application's cooperation.
• 5:32
  [SPEAKER_01]: All right, the application doesn't need to be patched or updated.
• 5:35
  [SPEAKER_01]: So you're doing this in real time as the transaction is happening.
• 5:40
  [SPEAKER_01]: 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.
• 5:50
  [SPEAKER_01]: 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.
• 5:57
  [SPEAKER_01]: Then we can inject different ways of enforcement in the kernel that can immediately block those transactions or that transaction while the pod keeps running.
• 6:08
  [SPEAKER_01]: We don't have to take the application down to do enforcement.
• 6:11
  [SPEAKER_01]: Other sessions are unaffected and you haven't deployed anything.
• 6:14
  [SPEAKER_01]: So you don't have to change your application necessarily if you're doing it at the kernel level.
• 6:19
  [SPEAKER_01]: your developers are just developing how they normally do it and we become really a layer beneath that watching everything.
• 6:27
  [SPEAKER_00]: I'm tracking with that and to stick with the session there and then not changing sort of the application, maybe the supply is as well, what does it mean to revoke or contain a compromised AI session without having to touch the broader deployment?
• 6:41
  [SPEAKER_01]: They really go hand-in-hand when you're able to really get in the middle of that transaction and terminate that active connection mid-flight.
• 6:49
  [SPEAKER_01]: You have the ability to protect the downstream data that would have been compromised that through that transaction.
• 6:56
  [SPEAKER_01]: And that's the thing that was hard to see and 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.
• 7:10
  [SPEAKER_00]: for sure.
• 7:10
  [SPEAKER_00]: Okay.
• 7:10
  [SPEAKER_00]: So then how does real time blocking change the risk side of things?
• 7:15
  [SPEAKER_00]: The risk equation for AI agents that access sensitive data external services or production workflows.
• 7:21
  [SPEAKER_00]: How does it change the risk side of the world?
• 7:23
  [SPEAKER_01]: It actually changes the question.
• 7:26
  [SPEAKER_01]: from how quickly can we respond to, can we stop this before it completes?
• 7:32
  [SPEAKER_01]: It's fundamentally a different risk posture.
• 7:34
  [SPEAKER_01]: If an agent in mid-flight on a request that would exfiltrate PII or invoke a payment API, it shouldn't touch.
• 7:42
  [SPEAKER_01]: Real-time enforcement lets you terminate that in progress.
• 7:45
  [SPEAKER_01]: You're not doing incident response anymore.
• 7:48
  [SPEAKER_01]: You're actually preventing the incident.
• 7:49
  [SPEAKER_00]: which is fantastic.
• 7:51
  [SPEAKER_00]: You're not doing clean up.
• 7:51
  [SPEAKER_00]: It's stopping it from happening.
• 7:53
  [SPEAKER_00]: So if the organizations are hearing this right now and they're ready to jump in and get going, what should they be able to stop immediately?
• 8:01
  [SPEAKER_00]: What kind of AI behaviors should they be able to stop immediately?
• 8:04
  [SPEAKER_01]: 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.
• 8:23
  [SPEAKER_01]: calls to external services outside of the approved scope.
• 8:25
  [SPEAKER_01]: So should this agent be able to go external or to this other location with this PI data and understanding the violations of compliance boundaries?
• 8:35
  [SPEAKER_01]: I think compliance boundaries are going to get very interesting with HIPAA and PCI and whatever else applies in your industry to understand if those agents are being manipulated
• 8:49
  [SPEAKER_01]: Things like prompt injection patterns and unusual tools sequences in those sessions while those things are happening are really important to understand and to be able to stop immediately and the policy needs to surface and manage those things for you.
• 9:04
  [SPEAKER_01]: But the problem is today most organizations really don't have a mechanism to enforce it at the moment it happens.
• 9:11
  [SPEAKER_00]: That makes sense there.
• 9:12
  [SPEAKER_00]: When you think about compliance and security, I think some folks can respond to that feeling like it's a clamp down on innovation and speed, right?
• 9:22
  [SPEAKER_00]: How do teams balance strong enforcement, which is really important, with the need to avoid slowing down AI dev and deployment?
• 9:31
  [SPEAKER_01]: The key architectural decision is to separate enforcement from deployment.
• 9:35
  [SPEAKER_01]: If policy changes,
• 9:37
  [SPEAKER_01]: require a deployment, you've now coupled enforcement to a really cycle, and teams will avoid touching it, all right?
• 9:43
  [SPEAKER_01]: So you don't want to do that.
• 9:45
  [SPEAKER_01]: So enforcement rules have to be pushed at runtime, updated, without having anything restarted, so that you could iterate on your policies independently of application changes.
• 9:55
  [SPEAKER_01]: And then you'll get strong enforcement without becoming a bottleneck.
• 9:58
  [SPEAKER_01]: Because that's the thing that security folks and infrastructure folks are always, they don't want to be the bottleneck, right?
• 10:03
  [SPEAKER_01]: They don't want to be the blocker.
• 10:05
  [SPEAKER_01]: And so if you separate those two things, I think that you cease to become the bottleneck, but you still get strong enforcement.
• 10:12
  [SPEAKER_01]: Think the other big pieces of observability, teams adopting enforcement faster when they can see what would have been blocked before they turn it on.
• 10:19
  [SPEAKER_01]: All 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.
• 10:28
  [SPEAKER_00]: Certainly.
• 10:28
  [SPEAKER_00]: Okay.
• 10:29
  [SPEAKER_00]: One more question, Tim.
• 10:31
  [SPEAKER_00]: Once organizations can discover, observe, and enforce AI behavior and security and enforcement, what does accountability look like at the enterprise level?
• 10:40
  [SPEAKER_01]: Yeah, and I think the big thing here is accountability requires evidence, not just logs.
• 10:44
  [SPEAKER_01]: I think gong are the days of, hey, show me the log when this happened, because it doesn't help you understand what the agent did.
• 10:52
  [SPEAKER_01]: The question that auditors and regulators will ask isn't, did you have a policy, it did the policy work, and how can you prove it?
• 10:59
  [SPEAKER_01]: And I think the, and how can you prove it is the really important part, right?
• 11:03
  [SPEAKER_01]: 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.
• 11:18
  [SPEAKER_01]: And if it was off the rails, we would have fired an enforcement block and were terminated the connection either which way.
• 11:25
  [SPEAKER_01]: But that's really important is be able to show that trace all the way through so that you can produce that evidence.
• 11:32
  [SPEAKER_01]: 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.
• 11:41
  [SPEAKER_01]: So that in the wave of the new AI compliance requirements, because they're
• 11:48
  [SPEAKER_00]: Yeah, absolutely.
• 11:50
  [SPEAKER_00]: Tim, all this makes too much sense in my eyes moving the enforcement to run time.
• 11:55
  [SPEAKER_00]: AI runs at system speed incidents, not human level incidents speed.
• 12:00
  [SPEAKER_00]: So security teams need a new model.
• 12:02
  [SPEAKER_00]: You got to enforce security fast and at run time.
• 12:04
  [SPEAKER_00]: And I hear you saying that companies really need to change their risk posture from thinking about cleaning up incidents to preventing issues from happening all the other.
• 12:13
  [SPEAKER_00]: 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.
• 12:22
  [SPEAKER_00]: So Tim, I really appreciate you walking us through this today and appreciate you returning this year today.
• 12:26
  [SPEAKER_01]: Yeah, great to be here.
• 12:27
  [SPEAKER_01]: Thanks for having me.
• 12:30
  [SPEAKER_00]: As Tim points out, security teams need to change the way they think about incidents.
• 12:34
  [SPEAKER_00]: AI is changing the game and the speed around models and programs that will require enforcement to be moved to runtime.
• 12:45
  [SPEAKER_00]: If you'd like to learn more about Walarm, you can visit Walarm.com, that's W-A-L-L-A-R-M.com.
• 12:54
  [SPEAKER_00]: And thanks again for listening.