B (3:56)

So we're basically viewing it as another random cloud app, right?

A (4:01)

Yeah. So we use EBPF and other sort of ingestion formats to understand even as far as like there's a workload that's reaching out to OpenAI and it's using a certain model. Right. That is very useful when it's customer data on the line, pii, PCI data, HIPAA data that customers don't want sent to those models per se. So we're still leveraging the tools we have in the platform today as a CDR cloud detection response platform, but you know, really doubling down on the AI aspect.

B (4:38)

You obviously see the rise of rogue and insecure AI, as you call them, as an emerging threat for enterprises. Do you think this will be a hard problem to mitigate or are we just at a phase where most people don't understand these tools, but securing them should be easier than the other stuff they're running?

A (4:56)

I think this is going to be, this is going to present unique challenges beyond traditional cloud based workloads and cloud infrastructure. One of the big ones that we're seeing today is it's this just emergence of other AI tools that connect to systems that aren't necessarily AI. So for example, there's a ton of freemium and kind of credit card style AI tools out there that will connect to things like a looker database or to a jupyter notebook or things that seem benign that any employee could sign up for with a credit card. And all of a sudden data is being used as part of that third party service and that's really hard to track. And you know, I don't think it's something we can't solve and can't figure out. It's just going to take a bit of governance and really be able to track the data lineage to those locations in a different way than we would with traditional cloud infrastructure, which is more tightly bound.

B (6:01)

So do you think this is a people training problem or are there specific technical aspects involved that require specialized tools or just both?

A (6:09)

I think you can, you can train people. That's gonna get you a little bit of the way, but I still think we need a technical guardrails. People are going to sign up for tools that make their lives easier, whether it's the chat GPTs, the cursors, the whatever it may be. I don't think we're going to be able to stop that through training. And I've talked to a lot of security engineers lately who are, their companies have strict AI policies to not use these tools. So they just sign up with a personal account and a personal credit card because they're that useful. So, you know, even the training kind of falls short. So we're going to need to figure out how to track these data flows, really put those technical controls into place along with some training. But I don't know if training is going to get us all the way there this time.

B (7:02)

So you've been obviously looking into this for a while. Can you share some of your findings? Are there specific types of AI tools and large language models that seem to cause more problems than the others?

A (7:13)

Obviously the hot topic of country of origin models like Deep SEQ and things coming down through open source are. That's, that's a very hot topic right now. Open source is a good thing in general, but it is, is it part of your, your governance policy to allow those tools, those models to run in your infrastructure, not knowing everything that they do? So we're keeping an eye out on where models originate, right? Hugging face type models that are built by the public and you know, published for anybody to download and use. Most of them are okay, but some of them are not. Right. They have packages, they have libraries that are vulnerable, they have elements that make them, you know, more or less insecure compared to others. And then I think what we're going to see an emergence of is kind of this rag database vector database explosion. People are going to start using third party. They already have started using third party vector databases with LLMs and workflow builders that all of a sudden you're transporting and storing custom, potentially really sensitive data in somebody else's infrastructure. You don't know how they're isolating that data, we don't know how they're using it to train their own models. And once that's out of the bag, it's really hard to rewind. So I think we're starting to see a lot of that as well.

B (8:40)

You mentioned some of the particular techniques you use to find vulnerable AI. What, what about all the regulation? Do you find any of that useful? Of all the guidance that we recently have dumped on us by all these open source organizations and governments, is this useful for you to test an AI system and see if it's compliant from a regulatory point of view?

A (9:00)

We have that capability in our product today. As we discover AI assets, we can map them back to things like the EU AI act or the NIST AI Risk Management framework depending on, on, you know, locale. Each of those are kind of broad stroke attempts to, to regulate AI in some way, shape or form. So I think they're, they're useful. From what we're finding right now, most of the companies who are trying to comply with things like that, especially NIST AI Risk Management framework, are, you know, it's a good marketing kind of tactic, right? To be in compliance is a good thing, but it doesn't necessarily mean your AI stack is secure. So we expect to see much more technical regulation when it comes to these frameworks and we're staying on top of that pretty much every day in the right circles and trying to be involved in that. Because if you overregulate then innovation kind of grinds to a halt. If you don't have any frameworks at all, then it's the wild west. So we have to fall somewhere in between.

B (10:10)

So what about. You're obviously a defensive company that helps companies protect networks from your data. Do you see threat actors abuse AI?

A (10:18)

We're starting to see that as we talk about. I've been discussing AI from a defensive point of view, data sprawl, governance standpoint. But if we look at the attacker's perspective, the usage of AI has really enabled just speed, right? And, and, and you know, being able to really target and hone in on different payloads, try different things, exploits much faster phishing campaigns become amazingly intelligent, right? Everything from the phone call being automated through voice and AI prompts to emails that you get to LinkedIn messages, all of this is like entry points into a broader sort of compromise is really amplified with AI. So it really for us means we have to stick with our man of real time detection and high detection efficacy, right? Like you cannot necessarily predict what an AI centric or AI created attack will, will look like through like a signature or some legacy way. You have to actually be defending the AI attacks with AI, which is crazy to think about in the world we're living in, but that that is really what you need to do, because these things move so fast. So we're going to see more and more of this, and we'll report back as, as we have more findings.

B (11:39)

Do you think the broad adoption of AI by threat actors will effectively act as a filter for the infosec market? Like companies that don't have good products will be basically left in the dust by threat actors that now move faster than usual?

A (11:51)

Absolutely. Yeah. If you're still relying on your good old list of top 30 things to look for, whether that's misconfigurations or signatures or endpoint detections, I don't think you stand a chance. So you're going to need to fight fire with fire here.

B (12:09)

Okay. So on that gloomy note, thank you very much, Jimmy.

A (12:13)

Absolutely.