The Foundational AI Governance Gap: Your Asset Inventory

Okay, thank you for attending this session. We entitled it the Foundational AI Governance Gap, Your Asset Inventory. I'll give you the key takeaway right up front before we get into the details.

Basically, the arrival of AI agents require a strong asset intelligence, a strong asset inventory and hopefully you'll take that away and we'll explain why that's the case. I am joined here by Kamden Schewitz from Axonius. Why don't you introduce yourself and then I'll introduce myself.

Yeah, absolutely. Thank you, Matthew.

Hi, everybody. Thank you all again for joining. My name is Kamden. As Matthew had mentioned, I am representing Axonius. For anybody not familiar, Axonius is the asset intelligence platform for cybersecurity teams and we'll get more into that later, but I look forward to this one. We have a lot of great topics and yeah, let's get to it. So before we get into the details, I am a senior analyst here at KuppingerCole and so we're collaborating on this session in a somewhat different model. It's not just straight presentation.

We have basically 10 questions or statements that we're going to dig into and basically a fireside chat mode. So hopefully this dialogue will help explain why we think asset intelligence is so foundational and even more so now with the arrival of AI agents. But before I get into the details that we get into the details, just some housekeeping items. First of all, you don't need to worry about audio control. It's all centrally done and questions you can ask at any time in the questions tab. We'll probably address them more towards the end.

In this case, we're not doing polls, but in most webinars we do, but given this is sort of a dialogue, we figure the, you know, polls don't really make much sense. And the recording of this webinar and the slides, because some of the slides in the back end we're not going to get to, but they're good reference material, will all be available and you'll get a notice when they're available. So the first, you know, before we get into the details of why asset intelligence is important, we probably need to define what it is.

So I pulled from a white paper that we're going to refer to at the end that goes into all this in more depth, the definition that I thought made sense to state here, and we can discuss it a little bit. So asset intelligence is a continuously reconciled, ownership-attributed, and confidence-scored view of what exists and what each asset can reach, reliable enough for humans and autonomous systems, AI agents, to act on directly. Another short way to say that is, you know, you need to know what exists, who owns it, and what it can reach.

And if you don't do those things reasonably well, you'll have gaps in your asset intelligence. So Camden, any further thoughts? I think you hit the nail on the head there. Assets being a very broad range of things. I think traditionally when people think of assets, they think of, you know, devices or SaaS applications, and we're extending it into identities for a while now, but also a new type of asset being AI assets.

So all the agents and MCP servers, different types of models or knowledge bases you and your employees are accessing every day is growing the attack surface, and we're folding that into the umbrella and trying to basically take the idea of asset inventory, move it into more of a modern framework built for, as you're saying, the continuous reconciliation of everything that comprises your attack surface. Yeah, it takes me back to my early days in software engineering and working in an IT department where it was all servers and, you know, we didn't even have laptops back in those way back days.

But at the end of the day, it was like the asset tags on your machine, and that was what, you know, they were trying to keep track of. But obviously the world has dramatically expanded with SaaS applications and non-human identities and AI agents, and so hopefully you'll understand given the role of AI agents and how dependent they are on all those things being known and tracked. Asset intelligence is more than just the CMDB, but I'm getting ahead of myself. So the first question that I'm going to ask is, you know, why did this decade-old asset inventory problem become urgent this year?

And it's sort of like the graduate movie in one word, or actually it's two words, an acronym. In one word, it's AI.

If you think about, you know, an AI system that you're probably already using, whether it's chat mode or whether you're building and deploying agents, those things, you know, they come in generic into your enterprise, you know, from the LLM perhaps, but to make it really useful for your organization to leverage, you know, to give your AI agents hands, if you will, you know, ability to do things and the ability to customize its intelligence to your data, you have to give it access to your data.

So really what's happening is, you know, the gap that has existed in your asset, you know, for a long time is now a very important dependency for the success of your AI program. And it's sort of part of a larger theme of moving from sort of periodic check-ins, you know, like the, you know, checking on your assets every quarter to see if, you know, the laptops are still owned by the right people, which is, you know, 15, 20 years ago, to be more of a continuous process, because of course, the agents that are running are running continuously.

So they need, you know, updated information about what you have and, you know, what it can reach and who owns it. It's definitely been something for a while that people have been focused on.

I mean, it's fundamental to any security program, right? If you look at... It's hard.

Yeah, it's... It's very hard. It's historically not easy.

Yes, but it is the foundation, right? If you look at, you know, take the NIST frameworks, all of them start with understand what you have and understand how it's secured. And I think right now, there are two major forcing functions that are making people revisit something that they've likely been doing for a very long time. And when you hit the nail on the head, the attack surface is growing rapidly because of AI, right? Everybody's a builder now, people who has had no business in the past, building applications or integrations, or these micro SAS tools are now capable of doing that.

And then on top of that, right, like you have these top down mandates from executives basically pushing teams to adopt AI as fast as possible. And that's bringing in a lot of new tools, new technology into the network. And then on top of that, the second forcing function into, you know, why are we talking about this today? The time to exploit has dropped dramatically, right? So in the same way that businesses are using all these AI tools, the people trying to attack those businesses are as well.

And we see that with the drop of time to exploit, and all these new, you know, headline breaking changes, like the PHP to shell debacle that hit this past week. So that's primarily, you know, the two reasons. And I think for the longest time, asset intelligence or asset inventory was something that was done point in time.

So you would maintain, you know, your spreadsheets, your CMDBs, periodically, maybe on a monthly or quarterly basis, run the drill of exporting all the different data from your various domains, making sense of them into one place, and then looking at how coverage applied across all that. And as cloud started to grow, and SAS became popular, we started seeing a lot of these affirmal assets, right, or things that were here one day and gone the next, whether that be a container that was spent up, spun up, or, you know, a code library that only existed for a short amount of time.

And that started forcing people to, you know, rethink how they go about building a view of their attack surface. And I think that's been taken further now with AI, right? Yeah. I also think of like, you know, you can kind of think of agents like people, but there's, you know, an agent is sort of like a naive person, not that some people aren't naive. But at the end of the day, a human can kind of fill the gaps, if you will.

Like, knowing, you know, a system has changed, or, you know, a data set is reliable or unreliable, based on their, you know, expertise, where an agent, unless it's well, you know, well guardrailed and prompted, doesn't really know. So, if you feed it, you know, it's garbage in, garbage out problem.

And so, you know, as you're automating a relatively naive, but intelligent, you know, autonomous system, the system, what you're feeding it becomes even more critical. I'm not that it wasn't critical with people, but it becomes more hypercritical.

Yeah, 100%. I mean, there's a funny kind of cliche that you hear, and it's that AI is like the worst person you work with, where they will be wrong, and they'll be wrong confidently, and they won't tell you that they're wrong.

So, just in context framing, like when we talk about AI agents, yes, we're talking about agents that all the employees in the business are using, but also agents in the sense of, as security operations is moving to be more gigantic and more autonomous, the agents running within all the tools that you use from your EDR, your identity provider, cloud security, the context that they're operating on, sometimes might not be all the way up to date. And that's where asset inventory comes in, right? I like to think of it, a hyper psyched intern.

Yeah, all those things like, they don't know what they know, don't know what they don't know, but they're very enthusiastic and glad to help. And so, like a human intern, they can get into trouble if you give them too much responsibility. Right. And as we'll talk about with the hugging face incident, they're very resourceful, and they are what I would call mission oriented. Like if you give it a task, it'll find a way, and sometimes that way it goes off the rails.

Yeah, I didn't know it was, we're going to the agents didn't know they were doing the wrong thing, or they kind of knew, but they thought the goal was more important. Whereas a human has some intuition about what is right and wrong. Right. So now this one's for you, but to start off on, so the concept of, there's lots of ways to aggregate data. Traditionally, you would jam it into something, your CMDB, but there's a how would you characterize the difference? Yeah.

I mean, I think coming off what we were just talking about, right, this is a very timely topic because we're looking at the state of security today. You have all of these new tools available to teams, whether you're an anthropic shop, or you're using Copilot or Gemini or any of these new tools available. I think it's very natural to start wondering like, what can this do for us? How can we put this to use to solve problems that we have been dealing with for a very long time?

And on the topic of today's webinar, the attack surface and asset inventory, I think as it pertains to artificial intelligence, like AI is going to be very good at aggregation, right? It can connect via MCP to all of the tools that you have today. It can pull in all the data that you have. It can build a pretty decent understanding of your attack surface, right? I think this applies more specifically to smaller environments. I think you can get away with that if you have five or six tools that you're working within daily. I don't see a reason why you couldn't just pull those in.

But at scale, I think it starts to break. And as we were talking about the growth of all these new types of assets on the network, whether it be over the past five years with the boom of cloud and SaaS or with what we're dealing with right now with AI, I think aggregation breaks down kind of at scale, right? So you can get in all this different data, you can visualize it, but you can't necessarily see how it works or, you know, reliably understand how you came to the conclusion of what you're looking at.

And the other side of that is the process is whether you're doing it manually or through a software like Exonius. And it's understanding what do we do and how do we handle sources that disagree? How do we fill in the gaps on duplicates? Like if we're pulling in data from the EDR and a couple of endpoint devices are missing, but we see in the mobile device manager that, you know, these MAC addresses don't have EDR applied to them. Like it's the full cycle process of what happens after you collect the data. I think it is a lot harder.

So for anybody out there looking at, you know, can we use AI or can we use these different tools to help with reconciliation and removing some of the manual work that we've done for a long time of looking through spreadsheets? I would encourage people to try it, but I would also say be mindful that AI is what we call probabilistic, right? You don't know, you're not going to get the same result every single time.

Whereas, you know, software or even a manual method might be a little bit more deterministic where you can do the same thing repeatedly. The example I grew up with in security is that I had various security systems that I was product managing and when they were rolled out at customers, they would have visibility into different hosts. And there was almost never a complete list, an accurate list of the hosts that were alive.

You know, they would go away and we didn't know whether they were coming back or not from our system's perspective. And so, you know, that's what, you know, laptops and servers, which come and go at more human scale, but now imagine, you know, it's agents coming and going.

You know, you'll essentially always be, there'll always be a gap between, you know, the reality and what you're seeing. And so that's where reconciliation really hits home for me is that we sort of survived in the old world of, you know, gaps in servers, knowing about servers existing, but now in the world of AI agents that this gap becomes too painful.

Yeah, absolutely. So maybe some people are thinking, hey, I have a CMDB, doesn't the CMDB provide an asset inventory?

Yeah, I mean, it does. Absolutely. Right. Like CMDBs, whether they're from ServiceNow or BMC, or any of these big companies have been around for a very long time. They're very good at what they do. But I think kind of going back to what you were talking about, about the days of the asset tag, like, I think they tend to be a little bit more of an IT centric tool that are good for things like change management, or service mapping, or troubleshooting. But for security, I think a lot of times teams demand something a little bit more dynamic.

So the ability to view something in real time or near real time, like what it looks like today, without relying on somebody going in updating it or manually managing that set of data, but then also being able to visualize like how an asset could be chained together, or what the different assets and the relationships look like, right? So you have this device, but who are the users accessing it? What security controls are applied on it? What did that look like 30 days ago? And then what does that look like today? So CMDB definitely does a good job at asset inventory.

But I think in the age of, you know, a lot of these digital assets, a lot of people are questioning the applicable use of it for attack surface management. I mean, ultimately, something needs to feed it.

Like, you know, it might have a process historically to feed it. It's sort of like having a active directory or entry ID of your people.

Yeah, it's a really good directory. If it's, you know, if there's an identity governance process, provisioning process, etc, feeding it, updating it, deleting people that, you know, the movers, adders and levers in a process. So basically, what I'm taking away is that asset intelligence, you know, incorporates CMDB as a essentially a reservoir or as an authority, but it has to, you have to have a process around it to keep it up to date. Is that a fair statement?

Yeah, I mean, I would say that's super fair, right? That Exonius, one of the key use cases that we enable is what we call enhancing CMDB fidelity. And earlier this week, I was on a call with one of our American manufacturing companies, and they were looking to start rolling this out, right?

Like, how do we understand what is in the CMDB and what's not? And then how do we go about feeding data into it to make it more accurate and up to date? So it still, you know, has a very important place. And I think the success of CMDB can be measured in things like how many unmanaged assets are you discovering? And then are those reflected in the CMDB?

Or, you know, what, how long is reconciliation taking us right now? And how can we get that number lower? And having something like Exonius in place that's pulling from all these different sources and doing a lot of the data cleanup and reconciliation automatically helps make the CMDB stronger, both for security, but then also the IT teams that rely on it.

And so I, back into my earlier days in IT, you know, it used to be, kind of, you'd go into a meeting and say, how accurate is your CMDB? And everyone would kind of chuckle, you know.

And again, that was well, you know, a decade ago. So again, we obviously survived that, those days, but because of, you know, the AI dependency on your assets being accurate and, you know, having good knowledge about them, you know, that dependency becomes much more intense. So this is one, kind of, obviously very much related, trusting AI as a consumer of data.

So I, at the top, I talked about, you know, what this, essentially the purpose of the webinar, this is a key part. You know, as you bring AI systems into your organization, you know, it's not just generic, you know, chat engines talking to a generic LLM.

You know, you either connect those up into your internal data sources and or you're building AI agents that are even more autonomous and making multiple step decisions. You make them extremely useful using your own data and systems. And so at the end of the day, you know, it's the garbage in, garbage out problem, where if you have this autonomous, you know, a semi-intelligent system making decisions in part based on your data and how you prompted it with a goal, you know, the data is important.

And it's important both, like, for training, like if you're going to train your own models, say you're doing an open source LLM and you want to train it to have, you know, different weights, you know, based on your use cases or and or on the inferencing when you're actually, you know, when it's actually making decisions, you know, the data has got to be good and you've got to be pointing it at the right sets. And of course, data is a living, breathing thing.

And so, you know, to trust your AI system, it's dependent on your data. You have to know where your data is and believe you're pointing it at the best data that you have. Yeah.

I mean, I think that goes back to the idea of the term we're hearing more and more of, which is the idea of a context harness, right? Like the value of the LLM is very clear to anybody who's ever used one. Like it's doing a lot of great things, but the context that it's operating on, I think teams have the ability to tweak and modify and make sure it is accurate and up-to-date to their environment. So the underlying kind of context layer that AI is running on is becoming more and more important. And it's like a crawl, walk, run kind of progression.

Like you understand what these tools can do, and then you start putting guardrails in place. And then to get fully optimized and avoid what we call like automating guesswork faster, you want to make sure that it is firing on all cylinders and making decisions based on the most accurate understanding of, you know, whatever the problem at hand is. And security, a lot of times that accurate understanding comes down to having a full and complete picture of the attack surface. So that's a big piece of it. The AI system doesn't know what it doesn't know.

You know, it's like any person. So if you don't have it wired in to data that would be relevant, it will give you the best answer it can based on the data that you've allowed it to get to. So there's this whole background process basically to make sure, you know, it's wired into the right systems, and it's wired into the right data. It evolves and as the data is evolving underneath it, you know, you got to keep it keep active.

Yeah, absolutely. Before we get off of this topic, there's okay, I think.

Oh, sorry. Sorry, I think I cut out for a second.

My bad, Matthew. Yeah, no problem. Go for it. Okay.

Yeah, when we look at trusting AI as a consumer of data, right, I look at it, we have the accuracy piece, but I also think there is the trust piece as well, because we're talking about AI can be a very relentless problem solver, and you want to avoid having what I'm calling these little insider threats running in your environment. So ensuring that you have proper guardrails in place is important. Otherwise known as a mistake machine, basically. Mistake machine.

Yeah, that's right. When we were going through the topics for this, I saw number four pop up is trusting AI as a consumer of data, and I thought back, I saw something on Twitter a couple of weeks ago, it was about a guy who was outside of, you know, the corporate world, but he had built a series of these AI agents to handle a bunch of different tasks on his behalf in his day to day life. And one of the things he had to do is look at the gym that he went to, and find open workout classes that he wanted to get into.

There was one like Saturday morning, he said it was full, he was like, Oh, come on, please find a way like I got to get into that one. And that AI agent found a weakness in the the API's on the gyms like application, and was able to go in, remove another guy's reservation who had booked by himself in advance, and then replace the owners, or replace that guy with the owner. So he was able to get in. And I think that is kind of emblematic of the idea of trusting AI, both as a consumer of data, but also to take action on a mini hugging face.

Yeah, it took action slightly inappropriate, but nonetheless, you told it you wanted to work out on Saturday morning. Yeah. So I think we hit that one. So this is the one of the key takeaways that hopefully people take away. And it's been talked about a lot in the market and also from Kubernetico is we need you need to think about agencies as first class identities. What does that mean? Meaning it's not hiding behind a person, even though that's a common use case, where they get your attention, get your privileges and act like you, but they isn't you.

But you know, in the in the short run, it's you know, it's the way life is right now, or it gets a service account. And, you know, point of view of the environment, it has no idea what it is. It doesn't know that it's an agent. It just knows it's some, you know, software service, you know, running there.

You know, that's okay, I guess, in the short run, very short run to get the ball rolling. But at the end of the day, agents are different beasts. And so they need to have, you know, their own identity. And this becomes like a lot of things. It's a it's a it's a little problem right now, in many cases, because you only have maybe 40 or 50 non human identities per every person.

You know, and that's been building up with service accounts and API's over the over the years. But I think we're, you know, we probably all generally agree that the probability of having 1000 agents for every person is plausible.

You know, maybe more who knows, but you know, as this, this really takes off, you can't really have 1000 of things, you don't know what they are specifically. So at the end of the day, the whole like human oriented, join, move, leave, kind of identity governance provisioning process, you know, doesn't really apply, it's a whole new animal. And so we need to rethink even just the identity management side of the equation to apply, you know, appropriately to agents, thus making them their, their own thing, you know, distinct from people and those other types of accounts.

Yeah, you and I had spoken about the idea that a lot of these agents are just inheriting the identity and permissions of the users using and personal agent. Yeah, yeah. I think it is. I don't want to go on unsolved problem, but it's something that from our data, at least we're seeing a lot of difficulties arise, we ran a study that I think we're going to publish here in the next couple of weeks, where we looked at what non human identities, actually, we mapped them out across a lot of our different customers environments.

And we found I think it was 40% of all non human and machine identities were able to be flagged as non human. So that's good, you know, 40%, you're able to identify as this is not a human taking action within x, y, or z. But the other 60% looked exactly like any other account. So there wasn't a service account attached to them. And you can, you can go in, you can look at Xeroth or API keys and different things like that. And I think make better sense of it.

We're seeing companies, Asterix, I think was one of them that's been popping up recently, that are specifically solving the the idea of non human identity. But it is, it's a large gray area, in my opinion, I don't know if you're seeing anything different, but still definitely, yeah, definitely the same.

I mean, obviously, you got to, in the short run, you got to work with what you got. And you got to, you know, the reality is service accounts and personal accounts are, you know, the most common way or inside a SaaS application, an agent running there, it's going to run probably as the context of user as well.

You know, and that, you know, what are you going to do in the short run, but in the longer run, because these, you know, the agent is not equal to the person, or the agent is the service account is too generic for what an agent can do, historically based on what service accounts are used for. Security and governance just won't work effectively, if it doesn't even know there's an agent. And so like you're implying, there are tools and techniques out there to try to discern based on telemetry, whether that thing operating is an agent or a person. And so you're sort of backing your way into it.

Of course, what we'd rather have is, you know, have every agent be registered, and obviously be distinctly registered as a as an agent versus some generic identity. Right. So let me go to the next one. So this this concept of shadow AI, which we were kind of just implying to like unregistered AI systems and agents, you know, is a rerun of shadow SaaS, which is itself a rerun of shadow IT.

That, you know, we thought, you know, 1015 years ago, shadow IT was a big problem, because, you know, you know, systems were being deployed, and data was being manipulated and moved around without security and governance around it. But in retrospect, that was the easy times, because, you know, in most cases, to get a server, and to load software, you couldn't bypass the IT team at all, because there was no other way to do it, with exceptions, of course, with some exceptions.

But with the rise of SaaS applications 10 years ago, and up till current day, you know, it's very simple for a business unit or an individual to sign up for a SaaS app and use it for business purposes. So that started building the shadow SaaS problem that, you know, we've been dealing with for four or five years with the new tooling.

But now it's a shadow AI, which is kind of very similar to shadow SaaS, like anybody can turn on or, you know, roll out a personal muse agent or something to do something for a business purpose or on a business machine, if you will, or turn on an agent inside of a, you know, an app development platform or SaaS application. So one of the good things I'll point out, actually, one data point that is worth pointing out is the Cloud Security Alliance released a report in April of this year, that said 82% of organizations have discovered shadow AI.

So not surprisingly, it's pretty ubiquitous, unfortunately. But any organization that's been doing shadow SaaS application discovery and management governance has a foot in the door, basically, of doing the same thing for shadow AI. So for those listening to this, if you've been doing shadow SaaS application discovery, and improving your monitoring and governance of your SaaS apps, in many cases, those same platforms have the ability to do equivalent things for shadow AI and AI agents.

Yeah, I think the scale of it has grown a little bit, like just as a personal observation, it feels like every week, I'm seeing more and more people on my team sharing tools on, have you heard about this text to speech tool that we could be using, or this new video editing software that's using AI, and then you have the Muse and the Grokbots of the world, which personally scare me. I used Muse a couple weeks ago, and I was just testing it out, and I was shocked with what I saw, seeing it open up the virtual desktop and log into my, I immediately shut it down after.

But yeah, on the topic of shadow AI, I mean, I think it is really a two-pronged problem where you have AI being brought in through the applications you've already approved, which is a very difficult thing to work through, right? Like, give you a quick antidote on this, and I'll share it with the audience today. In the past few months, I went through procurement for a new tool for my role. We're looking to, you know, find a way to build these interactive elements for our website, and I found a tool that served exactly what we needed.

It was very specific, kind of small user base, but it did what we needed to do. I brought it in through IT and security. They did their reviews. I filled out all the forms. They went through the integration documentation and compliance, and it was set up in SSO, and then two weeks later, I log into the app, and I see a banner at the top. We have new AI features. Would you like to use some? We know that that in and of itself was the opt-in.

It wasn't, you know, a formal opt-in process or acknowledgement of data handling. They just showed up one day, and that by itself is one thing, but the integrations that we had into that platform touched sensitive customer data, and I haven't used any of the AI features, but I was just looking into it, and I found the model provider was DeepSeek, which is explicitly prohibited in our organization and excluded from the list of tools that we're able to use, so you have this tool that in security's eyes is checked off the box. It's secure and safe. They're monitoring it.

If exposure or vulnerability comes out, they'll restrict access. It's within the guardrails, but one day, AI shows up and could be sending sensitive data outside of our domain into a model provider that we're not able to use, and that is, I mean, we are able to use it, but you shouldn't.

Yeah, you've just described drift, basically, and that's like, I didn't hit on it, but SaaS apps obviously have, you know, you're talking AI. In that case, it's just inside a SaaS app, and it's a feature, and it's a feature that arrives one day, and it wasn't there yesterday, and in that case, you're opting in, but the opt-in person may not be as judicious as you.

You might just say, yes, not thinking through all those things you just thought through, and so you have this concept of drift, like what was okay yesterday may not be okay today, and so that's why this sort of continuous monitoring, like once, yeah, I don't know if you put it into your, you know, API, but if, you know, once you have a security and governance system plugged into that app's API, it could, in theory, see the fact that there's a new feature that's been deployed or that's been proposed, and then you could then decide to block it or not based on, you know, the rationality you just gave, you can't use Deep C.

Yeah, that is something we're working on at Axonius.

In the past few weeks, we rolled out a tool called Shadow AI Discovery, and it looks at 200 of the top SaaS applications, and it's able to show you what is the AI being used, what level of autonomy does it have within the SaaS application, is RBAC enabled, is RAG enabled, what's the opt-in policy look like, what model are they using, and where does that model host it, and then the next step of that will being able to solve for the drift problem of actually looking at the application settings themselves and seeing, all right, we have this tool that's approved, AI is not enabled, and then you can look back in a week and say, okay, it is, let's flag this, we have the owner attached to it, we'll send them a message and say, hey, turn this feature on.

That actually, you know, just exposes the other issue with this Shadow is that the administrator is often not in IT and security, it's in marketing or, you know, whoever owns that app you're going to deploy, maybe it's you, so at the end of the day, you know, security is responsible, trying to be responsible, but it's not the administrator, so you have to have taps into the app to see, you know, what's changed on a daily basis, thus you can advise the administrator to accept or not accept the AI feature, but they may not even know that there's a security risk of it, so you have to have sort of that oversight.

Yeah.

So, we alluded to the Hugging Face and OpenAI incident, you know, this is not a case where asset intelligence is the answer to, you know, making this not happen, and just to remind people what happened is, in a very short version, is OpenAI was testing their agents, and it gave it a, and actually a vulnerability exploit problem, which was apparently very hard, and it's a common test, and the agent realized that it was hard, and decided it was able to find access to the internet, so that's one thing that existed that, you know, OpenAI didn't know, and then find that Hugging Face had the answer, so it then found basically unowned credentials in Hugging Face, again, something that, you know, is an asset that was an intelligence gap on the Hugging Face side, and basically spawned a bunch of agents, and effectively, they say hacked, but logged in is another way to say log in, and found the answer eventually, you know, without permission, so in that case, both OpenID and Hugging Face had an asset intelligence gap that these agents basically took advantage of, and so both sides, you know, could have done a better job with their asset intelligence, not necessarily to stop the agent from trying to do the wrong thing, but at least making it much harder to do the wrong thing by not having, you know, credentials, you know, that exposed credentials that are unowned and unmonitored, and not having, you know, access to the internet that they didn't know about on the OpenID side.

Right, I think this one was interesting.

I listened to a very long podcast on this, and it was crazy to hear the details on it, but when we talk to customers about this, one of the things, I was at Blackhat this past year, and I spoke kind of on this general topic, I think when it comes to AI and these types of incidents, right, the attack here was a novel attack, but the attack path was not necessarily novel, so if you take away the headline, any human would have done that, you know, right, it gets the foothold, or harvests the credentials, and move laterally, like it's textbook stuff, but it's just being done at a faster scale, and then autonomously by things that, in this case, we had put to use for a positive problem, but all of that to say, you know, we're not necessarily seeing novel attacks, just a higher rate of traditional ones, and going back to the asset intelligence baseline, I think I'm not going to sit here and say, like, that'll prevent these things from happening, but at least gives you the fundamental visibility into what are the different relationships between all these different things in our network, and then what can we do to put either compensating controls or reducing the types of coverage gaps we have now in place, so that hopefully things like this don't happen in the future.

Find the exposures, fix them if you can, monitor them if you can, but at least, you know, you're aware, you're not unaware, which is essentially the problem of this attack is it lasted over multiple days, because they were unaware, both sides were unaware. Yeah, then, you know, yeah, the speed in which this happens, I think, largely removes kind of the margin of error, so having the foundational visibility, it should come first in a lot of ways.

Exactly, so this one's for you to start off with, so the whole ownership, you know, I'm an AI agent, but nobody owns me, that seems like a big problem. Yeah, how do you address that?

It is, I look at it in two ways, right, so first is the asset ownership problem, so not necessarily ownership of an AI agent, but how it comes down to using AI agents across the tools that you use today for scoping issues or remediation, so you have all these new tools, like every security vendor is rolling out autonomous agents or genetic features to help with, you know, whatever they're best at, right, we'll take the example of exposure management, I think a lot of times when you're using these AI tools, the bottleneck isn't necessarily finding issues, but rather routing them, so tying it back to asset intelligence, you have tickets assigned to the wrong team, they might sit there, they bounce, they age, or they die out, and as you lean more into automation, one of the things that we're seeing is that using agents for tasks like triaging or instant response, without understanding the proper ownership context, you hit the same wall, so that goes back to automating guesswork a little bit faster than I was talking about, but then the second part of that, I think more of what we're here is ownership of AI as a whole, and I know we'll get into this in the next few topics, but when you look at a lot of the emerging frameworks and regulations, EU, AI Act, or AIRMF, they all, you know, start with and assume accountability, so who owns these AI systems, are they risky owners, what does ownership look like, and I think that just compounds with all the traditional identity access management risks that we see today, right, so we have the off-boarding risk, like when an employee leaves, what happens to the agents and tokens and different SaaS integrations they've created, and going back to like the earlier point on, in the age of everybody being a builder, I think we're seeing more and more issues of, we're heavily relying on these AI workflows, the person responsible for them leaves, what happens to that workflow or that set of tools in the event that somebody, I guess, joins, leaves, and moves?

Yeah, I mean, you, I mean, obviously, I think from an IT and security point of view, any agent that has no owner should be, you know, should be stopped, because at the end of the day, like if something starts to go wrong, what do you do about it, so just like a, just like a, you know, a server system, there has to be a chain of responsibility, like if it crashes, like who's going to fix it, you know, that kind of thing, and I also think of sort of like agents are like dogs, like a dog has an owner, and if the dog misbehaves, bite somebody, for example, you know, the police don't come to the dog and arrest it, or whatever, you know, start their investigation with the dog, if dog is an asset, and in that case, maybe a liability, but you know, it's the responsibility of the owner to keep the dog on the leash, or, you know, train the dog not to bite people, or whatever the bad behavior it's doing, so the same idea plays here, and I think one of the actually measures of a good asset system, whether agents or more generalized IT systems is, you know, what percent of your assets have an owner, at any point in time, it's probably not 100%, but the goal should be 100%, and so if you're at 20%, that's bad, and if you're at 99%, you're pretty good, you know, is that a metric that you see people using?

It is, right, asset ownership is one of the key kind of records that we have taught apply to the assets that we bring in at Axonius, so when you spin up a table or dashboard, you see what's the name, what are the host name, you know, the MAC address, key identifiers, but then asset owner is right there next to it.

Thinking back to that report I was talking about, we're putting out a report in the next week or so, or next few weeks, on our analysis of non-human identities, and one of the things we found from our analysis was that two-thirds of non-human identities within our customers' environments have no group membership data, so they can't be risked, and I imagine that would be the case across a lot of these large enterprises that have gone heavy down the agentic route. It's like, you know they're there, but assigning ownership to them has become increasingly difficult.

And I guess you sort of have to decide based on this, you know, the security's relative control and importance in the organization, do you kill the agent, do you report the agent, do you live with it and monitor it, you're going to have to figure out what you're going to do with these unowned agents. Yeah.

Go ahead, and then we'll go into this topic. Oh, I was saying, that reminded me of, there are a couple of companies, I think in the past year, Amazon was one of them, I think J.P. Morgan was another, and then maybe Samsung. They ran into issues, not necessarily major incidents, but issues where they were looking at the NHIs and their environment at large, the general usage of AI, and they had put temporary blanket bans on the usage of AI.

So running into these problems, and ownership is just one pillar of this large spectrum of issues, but it gets in the way of some of the top-down pressure that I was talking about of, we want to innovate, we want our business to be as efficient as possible, but security teams are coming back at times and saying, we just need to pause on this and figure out what's going on before we allow this to continue.

Well, I mean, that was sort of getting at, I mean, highly-regulated businesses like banks might be able to say no, but that's a pretty small portion of the world of IT and security, for the most part, no is not the right answer. You need to discover them, and then you need to build a process for having, in the case of agents, have them registered and owned. But probably blocking them, most people can't do, but so we're in this sort of weird period where we know what's happening, we know there's a better way, we know there's a process that should be followed, but it isn't.

So we got to be part of the team, essentially, to help expose the problem and suggest solutions, starting with ownership. And that actually leads into this topic, the regulatory pressure.

I mean, not surprisingly, you don't get to say the AI agent did it, it's not my fault, meaning the company, the regulators, presumably, is going to be like, well, I don't care, it's your software, and you can't necessarily say, well, it's the LLM that did it, it's not, but no, the agent's running in your domain. So there's really no free lunch.

In fact, all regulatory controls apply to AI agents, there's no exceptions, like if AI agent, then the compliance doesn't matter, but they're also, the regulators are responding with more explicit regulations like the EU AI Act that you mentioned. And that's quite explicit that it asks for classification, documentation, human oversight, logging, and monitoring for AI systems. The deadline itself is pushed off until the end of next year, but the principle of control doesn't really change with AI agents, it becomes harder.

And so, as I've been around in security for a while, what you do, ideally, is you leverage the compliance requirement to provide better security systems and processes, because the compliance is something that every executive understands or can be made to understand. But you can, in a sense, leverage the need for compliance into improved security programs. So there's no free lunch, the regulators have arrived, and no doubt will be arriving even more as AI has problems and as things evolve.

Yeah, absolutely. I saw a funny meme the other day, it was a guy holding a checklist, looking at the checklist, smiling, and on the checklist was written AI governance policy. And all the boxes were checked. Nice. And he looked up and the whole building's on fire. That's emblematic of what a lot of people are working through right now. It's like you get the policy written, but actually enforcing it and coming up to spec is a whole different beast.

Yeah, I mean, obviously, the saw of compliance doesn't equal security remains true. But I always view it as a source of investment. And it's been used by security professionals over the years. We got to comply. And here's our recommendation for the operational processes and systems necessary to do it. And by the way, by doing that, you get improved security. Yeah. All right. So this one's for you, I think. But it sort of raises the question, we're talking about this sort of AI agents and AI systems are rolling out massively, no secret there.

But a lot of the AI, a lot of the asset intelligence is kind of behind. So how do you know the card is sort of before the horse? How do you sequence these things? How do you get your asset intelligence to at least speed up and catch up to your AI deployment?

Yeah, I think this is a good one to end on, right? I saw the deputy CISO from Anthropic put out a tweet the other day. And it was in response to the PHP to shell incident. He was saying, basically, this is going to continue to happen. Before you guys go push your leadership for new AI tools, return to the basics. And I think that's exactly the case for sequencing asset intelligence ahead of AI governance, right? I think it's natural for people to always rush to the shiny new thing. And I do believe AI governance is incredibly important.

But at the same time, I also believe it is very difficult to do it right without having a strong fundamental of asset intelligence in place, right? It's a good thing. It's something everybody should be striving for to understand how AI is being used across their environment. But to get most out of it, I think you need all of the surrounding context within that kind of in the same place, right? So understanding the endpoints that AI touches, what security controls are applied to those endpoints, the identity profiles, people using it, the access and applications that live within those.

And I believe to accomplish that asset intelligence is kind of the prerequisite, right? I don't believe AI necessarily replaces the fundamentals here. But going back to topic one of why is this decade-old thing becoming popular again? And teams are just understanding the value in building a truly accurate view of their environment, and then all of the downstream possibilities of that, one being which is AI governance.

Well, it sounds like the approach is if you have the AI, a lot of energy and investments going in there, attach your asset intelligence program to it. And maybe, yes, you're not going to do the complete enterprise across all assets, but you're at least going to focus on the ones that the AI systems would like to use or are going to use. And then you can build, use that investment to build a platform that can do those other things that are more traditional, servers and laptops and SaaS applications and all those other things that may be not as sexy right now, but can come along for the ride.

And then if you continually improve that system through regular updates and using it like your system, you can end up with a pretty comprehensive asset. Yeah, exactly.

I mean, two things can be true at once, right? Like you should be doing both. And I think in a perfect world, you get to choose one or the other and knock that project out. But the reality is you'll likely have multiple priorities all at once and they're all competing. My view is that asset intelligence should be one of those four we've talked about in the past.

Yeah, and try not to build it just for the AI environment. Build it on a platform that can do that plus everything else so that you're at least building towards a better future. A hundred percent. So that actually brings us to some closing recs before we get to some of the questions that Yeah, absolutely.

I mean, you're doing this sort of asset intelligence for your AI program because that's hot. But don't forget the traditional IT SaaS cloud side of your equation and build out that in an integrated solution. We'll pay benefits as you go down the road. Require a named human owner for every AI agent, actually every non-human identity, service accounts and API keys. So you have to know who's responsible and who to go to if there's a problem or something needs to change.

The thing I implied when I was talking about shadow, shadow IT, shadow SaaS, is that you're probably doing, there's a good chance you're doing, you have a shadow SaaS application program underway at some level. Those can be extended relatively straightforward.

The same, similar discovery and similar inventory for AI can really mold well into your SaaS discovery, SaaS application discovery. Minimize your SaaS, shadow SaaS, and you can minimize your at the same time.

You know, be the department of yes. Very rarely can security teams say no to something critically important like AI and AI agents.

So, you know, provide a short list of best practices and systems that people should be using and so encourage them to, instead of going rogue, you know, give them a path where they can stay with the program. And then, you know, leverage compliance, regulatory compliance, whether you're following the EU AI Act or some of the more general purpose regulations and impact IT to invest in your security side of your AI program. And there's also a white paper which I'll flash up while I get to the questions.

If you have any questions, please throw them in and I will basically pick off some of the ones that are in the system. So, this is one, I think, more for you, Camden. Where do you draw the line between having a CMDB and a tax service management tool?

You know, how are they different? How do they work together?

Yeah, they absolutely work together, right? I think the CMDB is great at being a system of record for what you intend to have, right? Your configuration items, your owner's relationships, all of that.

Whereas, asset intelligence or tax service management is going to be very good at showing you what you actually have and then, more importantly, how is that exposed? And it can do so a little bit more continuously.

So, I think the CMDB is going to be great at answering, you know, what is this? And a tool like Axonius or another asset intelligence tool is going to be better at answering what's out there, what's actually out there, and then what's at risk. I do think with that they fill each other's gaps, right?

So, we know CMDBs are only as good as the data being fed into them and they can often end up stale or missing some of the shadow IT or shadow SaaS or shadow AI that we talked about. Where an asset intelligence tool is going to find those gaps and then being able to pull from the CMDB for all the business contexts around it.

So, they complement each other well. One of the examples I heard, actually somebody else on my team gave, is that the CMDB is kind of the map in some way where a tool like Axonius is a satellite view and you need both, right? You need the satellite to keep the map honest, but on top of that, you also need the map to understand whose house is on fire. Final question from Alfred, how do LLMs, large language models, play into asset intelligence and to help understand the attack surface? There's definitely strong usage there, right? I'll speak from the Axonius lens because that's what I know best.

We have an LLM within our platform that allows you just to ask in natural language, you know, what does this asset look like? What's at risk? Show me internet facing assets with old operating system or old firmware on them that don't have CrowdStrike involved.

So, that use is great, but then also having an asset intelligence tool, being able to take the MCP server from that tool and plug it into your own LLM, I think helps a lot too, right? So, that is providing the clean enriched context layer into whatever workflows you want to run through your LLM of choice connected to all the different tools that you have.

Yeah, well on that, we'll close it out. I appreciate everyone attending and Camden, thanks very much for your insights. As mentioned, the white paper that's on your screen is posted on the Cooper-Nichol website.

So, feel free to grab it and I presume you guys maybe have posted it as well. It basically goes into much greater depth into everything we were just talking about.

So, thank you very much and have a good rest of your day. Awesome.