Governing What You Can't See: AI Agent Risk in the Enterprise

Thank you very much for attending today's session, where we are going to dig into essentially one of the big problems and challenges in security and governance of our day, that is around AI agents, in particular those in and around your critical enterprise applications. So we entitled this session, Governing What You Can't See, AI Agent Risk in the Enterprise, Securing and Governing Enterprise AI Agents.

The way we're going to run this is, I'm Matthew Gardiner, an analyst at KuppingerCole Analysts, and I'm going to basically tee up the problem space, which is quite complicated, complex at least. So I have the easy part, pointing out the challenges, and then I'm going to be followed up by Jason from Pathlock, who's going to tell us all how it's done, or at least give us some best practices and some guidance about how they're working with their clients.

So Jason, you want to say hello? Thank you, Matthew.

Yeah, my name is Jason Gzym. I lead the Solution Engineering Global Function here at Pathlock. Been in the identity security governance, application governance space for 30 years now, thus all the gray hair. But through my journey, I've seen an evolution of access to applications, both human and what we talked about today, non-human, and specifically AI agents. So appreciate everyone's time. Excellent. Before we get into the actual content, the usual housekeeping applies. So you don't need to worry, you, the audience, don't need to worry about your audio controls.

You essentially are muted centrally. There will be a couple polls, just to get a sort of a taste where you are collectively in your evolution, which I will pull up and read off and give a chance to put your input in at that time. There will be Q&A at the end. So we plan for maybe 45 minutes of prepared content, plus or minus. So as you think of a question, throw it in. I will be looking at it, and I will be sorting through the questions and asking them, and we'll figure out whether I try to answer them, or Jason does, or both of us.

And then also on the recording of this session, it is being recorded. The slides will be available. Everyone who registered will get a link in the not too distant future, obviously, to share it and rewatch it, or ask your colleagues, make it available to your colleagues. So to start off, you know, for the purposes of this session, there's a number of ways you can characterize AI agents. I thought the simplest way to do it is basically think of them in two buckets.

They're either enterprise agents that are outside your enterprise apps, and that's what most people think about when they think about agents, like personal agents or news or, you know, an agent running in an agent development platform in the cloud. So those are outside enterprise apps. So they may dip into enterprise apps, you know, for their data and the actions that they're going to take. But then you have pretty much every enterprise app of any note has also been or will be creating agents inside their application.

So you think of the big three, like SAP, Oracle, and Salesforce, but, you know, I challenge you to find an enterprise application that isn't developing agents inside as a part of their, essentially, how the application is being delivered, not just to people, but having agents operating inside the context. And that's critical in the sense that there are pluses and minuses with both agent environments on the outside of the enterprise apps. You're not bound by really much of anything.

You're running in the environment that you control, but you're responsible for the harness, the identity, credentials, logging, enforcement, those sorts of things, that many of those things come by default when you're running agents inside of enterprise apps. So the challenge from a security and governance point of view comes, of And so the question is, how do you do this? How do you provide security and governance for what could be many agents across both inside and outside your enterprise apps? So this gets us to the first poll.

I want to know, we want to know, you know, what type of AI agents do you currently use in your environment? So the way I broke it up is you could have agents outside your enterprise applications, like you have people running personal agents or on endpoints or in cloud. You could have agents inside your applications that, you know, SAP, Oracle, Salesforce, et cetera, that you're starting to use, you know, in production. You could have both, let's see, or you're not using any agents in production or, you know, you're not 100% sure. So let me give you a few seconds to answer that question.

I see that the results are rolling in. Excellent. All right.

So let me, let me move on and change slides. Okay. Here we go. So at the very highest level, you know, when you think about security and governance for agents, wherever they may be running, you need to know kind of three things. Having one or two of them is helpful, but all three ultimately is really what's going to set up a security and governance environment that people can really trust. So first is, you know, what agent is it, the identity of the agent?

Is it, you know, inside of your, your identity management system? Has it been registered? Is there a named owner?

You know, does it, does it, you know, come, does it have a life cycle that you're managing? Essentially that, that part of the identity. Then the second thing is around the agent, what can it touch? What is it authorized to connect to? What skills does it have?

You know, what applications, API does it have? What MCPs can it connect to? Essentially the, what can it touch? And then the third one, which is sort of the somewhat unique, if you compare agents to individuals, you know, what can it do? Because the first two things don't really, they partially control what it can do, but ultimately an agent is, you know, a non-deterministic semi-intelligent thing that has been given a goal and tries to, you know, use its intelligence to how best to execute the goal.

So you get into sort of runtime challenges, you know, watching what it can do, controlling what it can do, but ultimately, you know, for a proper security and governance program, you need to cover these three bases. So why is this hard? I came up with five reasons, perhaps there are more or at least nuances of each of these, but ultimately I think it's hard or will become harder depending on where you are in your rollout is that there's going to be so many of them.

So I'm going to delve into each one of these bullets in future, you know, as I flow, but ultimately, if you think about non-human identities, like service accounts and APIs, well, agents now become the next kind and probably will accelerate the outnumbering of non-human identities to humans in your organization. And we can talk about maybe a little bit, you know, how many orders of magnitude that'll be. I mentioned earlier, you know, the agents can run in different contexts. They can run inside and outside of enterprise applications. They can dip into enterprise applications.

So, you know, you have lots of moving parts, if you will, that makes it challenging to govern. Agents can call agents.

So, you know, when agents are misbehaving, you might call them a swarm, but ultimately, most agents that are designed are specialists in certain ways. And to get something done, one agent may call another agent, which may call another agent. And so you have this sort of agent chain of delegation and interoperability that makes it more complex from a security and governance point of view, even though it makes it great from an application development point of view, kind of like modular code, you have modular agents.

Another thing is, you know, it's much more complicated than, you know, controlling humans. I mean, humans, you know, you can authenticate and authorize a human in an application.

Typically, the application itself controls the fine-gained access of that person in the application. But ultimately, on the agent side, just knowing that you have an agent and it's unique, agents evolve over time, get updated, have more skills and more API access.

So, you know, just knowing what the agent's identity doesn't really tell you too much about what its actions could be. So that adds complexity. And then the final thing that's inherent with agents and AI in general is it's non-deterministic.

So, you know, the same inputs don't give you the same output. So there's variability just with the agent's logic, if you will, or flow or decisioning. And so the question is, how do you do security and governance given sort of these five facts? So some stats, which will soon become outdated, I think, really with the agents, but give you a flavor of the numbers problem.

You know, we have the number we use here at Coupanger Co. is roughly 50 non-human identities for each human at your sort of average company. But there's a lot of variability depending on where you look and who you ask and what you determine as a non-human identity.

Recently, I just saw posted from UBS, the Bank and Union Bank of Switzerland originally, was that they have 12,700 personal agents, 608 live AI use cases and a thousand, more than a thousand applications in development. So you can start to get the feel that, you know, 50 to one, maybe 5,000 to one, you know, if agents really take off in the utility. And so it's partially, as I mentioned on the top, the previous slide, is that it's partly a numbers game. Second thing, just delving in a little more depth into the enterprise platforms themselves, the agents are inside.

Clearly, you can't really be an enterprise application these days without providing an agentic way that the application can function. So that processes can be automated, not just with rules, you know, and scripts back in, you know, traditionally, but now with agents that are sort of making decisions as the data flows in and out of these enterprise apps. And so you're going to have not just many types of agents, but you can have numerous agents inside of, for example, SAP with 224 agents and 51 assistants across the finance, spend, supply chain, and HR.

So these become part of your environment and part of your security and governance and perhaps are being deployed and put into production even without, you know, the security and governance teams involvement because they're sort of alive and ready to go inside these enterprise apps. So I just wanted to get one example that's sort of the prototypical control challenge in the world of people that has kind of the same problem in the world of agents.

So if you can chain together agents to get a job done, which is what I talked about, sort of the specialization, and you have one, two, or three systems that can, you know, execute a business process, enterprise systems, that execute a business process, and those agents can call one another to get the job done, you kind of have created a segregation of duties problem where one decision can lead to a business problem.

So in this case, you know, the classic is you, the, you know, a person and now an agent can create a master record for a vendor, a person, now an agent can post an invoice against that vendor, and then a third historically person, but now, you know, agent can now do a payment run. And so if that, you know, initializing agent was owned by a bad insider or a malicious actor, you now have, you know, essentially a weakness that would show up in an audit and could be essentially taken advantage of in an actual attack.

So segregation of duties still plays, but how you control it now is different in the world of agents. So getting back to the authentication doesn't equal safe action. It's not dissimilar from a person in this sense where, you know, you can verify the identity of a person, hopefully you've done it correctly, like with MFA, but that person could make mistakes or could go rogue.

Same, obviously, with an agent, an agent may not be malicious, but it may be goal oriented. And it believes your intent may be to override some other guardrail. We've seen that, you know, in live and in public disclosures. So secondly, on the administration of the agent, in many cases, you know, without changes in how you do things, you know, these agents are being created inside the enterprise apps or being created outside the enterprise apps, but are they really part of your current identity governance and administration programs? In many cases, I think the answer is no.

You know, that's been built for people, but not necessarily something that's, you know, going through the life, you know, supporting the life cycle of agents yet. So again, that becomes a challenge. Another one that's probably the more obvious one is the machine speed problem with no ownership.

So, you know, these things with semi-intelligence and not necessarily an owner unless one is explicitly enforced can be executing, you know, of course, this is a business application. So a business user or a business team needs to own these agents so they can define, you know, what's inbounds, outbounds, and the functionality, you know, what skills and what integrations the agent will need. Obviously that's something that security can help with, but not necessarily own entirely.

In addition, because of the machine speed, you know, you can't just do quarterly reviews of access like we've historically done with people. You know, people come and go, but they don't usually come and go in microseconds or milliseconds, whereas agents certainly can. And they may hang around for a long time running, or they may come and go, you know, in a very short period. So the sort of quarterly review cycle of the control around them just won't play as it has more or less with human users.

Delegation, I talked about at the top, you know, because agents can call agents, and usually the best development approach is agents are specialized in certain ways so that they can be tracked and updated more easily as opposed to having lots and lots of functionality. But that essentially implies to do a business process, an agent chain is needed.

So now that you get into the problem of this delegation and whether, you know, the ultimate outcome is what you expected or wanted, and are you able to log and track, you know, that defective chain occurred, and the fact that these agents may call each other in different ways over time because they're semi-intelligent and non-deterministic. Another one is regulatory compliance.

At the end of the day, control frameworks and regulations, they don't really care about how something is done from a business process, you know, data security or, you know, intellectual property defense, or, you know, if you're a regulated industry like a bank, like that you're managing your financials appropriately. It doesn't really matter to the control frameworks or to the regulations, whether it's a human-oriented process or an agent one.

But at the end of the day, it becomes harder to become, you know, stay and become compliant with these regulations and controls because of the problems I've just been talking about. And specifically, some of the regulations are becoming specific to AI.

So, the EU AI Act, which the deadline was pushed off until the end of next year, nonetheless, does raise the requirement to essentially put sufficient historically logical controls around your agent flows. So, when things get complicated, like what I've just gone through, I like to step back and think about sort of basic principles again. And one of the most basic principles of security is CIA, confidentiality, integrity, and availability. At the end of the day, that's the primary responsibility of security teams.

The, you know, obviously, you need to think about how to do it with agents differently than what you've done historically with humans. But at the end of the day, keeping the data confidential, keeping your systems and data without, you know, that's attributable and traceable and making the systems available is still the primary responsibility of the security team.

Now, we just have to work out how to apply it to this agentic world. So, let me go to the second poll now. And the poll is, I really want to know, is your security team only responsible for the CIA surrounding your AI agents? Or has the role sort of expanded where you're becoming responsible for the application results and the business results of these agents, which I think has some risk associated with it if security tries to own it. But at the end of the day, yeah, we're just the CIA of the agents is our responsibility.

Or no, we bear some responsibility for enforcing business rules in addition to the of the agents. Or we haven't figured it out yet, which, you know, I expect some people will be there. Or you don't know. Please give that an answer. I'm going to just push onward.

So, you know, I'm not going to be able to give you the answer how to address all of these issues, but we have created our own framework that we call the six-category framework around controls and tool categories for AI agents. And you'll recognize at the top, the prevent, observe, detect, and respond, and govern are terms that we've been using for decades regarding our security controls. How you accomplish those four things is what we've broken down into six categories. And I won't go through all of them, or I won't go through any of them, really.

I'll just reference you to a report that we wrote about a month ago, basically framing all of these six-category domains. It's a thing called an advisory note that covers this, which is sourced just below the graphic. And we're also kicking off research projects in each of these six areas. I'm currently working on the visibility and observability portion of the six-category framework, which is basically, as the name implies, you know, how do you find, discover, monitor, track, and flag agentic activity that might be out of bounds. So let me hand off to Jason.

And as I mentioned before, I'll be watching the Q&A, and I'll come back after Jason's section to address as many of your questions as I can. So over to you, Jason.

Thank you, Matthew. And thank you all for joining.

You know, Matthew has just laid out why AI agents are so hard to govern. Over the next 20 minutes, I'll take that from diagnosis to practice, talk about the identities you probably can't see, service accounts, bots, keys, and increasingly, while we're here, AI agents that now run your business systems. My argument is pretty simple. Machines already outnumber humans. You saw that from Matthew. They are governed far less rigorously. And AI agents are now making that gap dangerous. By the end, you'll have a practical framework for closing it. So let's start with some numbers.

I know that we saw some numbers already from Matthew. Let's look at this from the ERP standpoint. Non-human identities commonly outnumber humans 20 to 1 is what we're seeing right now in the ERP or business application space. That's from our own field data. But you zoom out beyond ERP and Palo Alto's networks, their landscape puts the average enterprise at 109 machine identities for every human, right? So with AI agent identities expected to grow another 85% in the next 12 months. I know my wife just got Muse, and she's creating tons of agents to automate her personal life.

But studies count different things, which is why the publish ratios vary so widely. But they all point the same way. The number you should be worried about isn't on this slide, because nobody can produce it. A complete inventory. These identities are created in minutes. A developer needs an API key. A vendor needs an integration user during implementation. And they are almost usually never decommissioned. Projects and accounts persist. So most organizations kind of answer the three basic questions. What exists? What can I access? And who is accountable for it? And here's the uncomfortable part.

Regulators don't carve out for machine identities. If a service account or an AI agent posts to your general ledger, it is in SOC scope, whether or not anyone owns it.

You know, one in four companies have already had an incident they know about. And one in five can't reliably investigate after the fact. That's not a great answer for an auditor. So before we go deeper on AI agents, let's be precise about where they sit among non-human identities. So there's three buckets.

First, there's credentials and keys. Service accounts, executing background jobs, in your ERP and cloud states, API keys, tokens, OAuth clients. They let systems talk to each other. Certificates and secrets, authenticate workloads. They're static. They are things that authenticate.

Second, you know, automation integrations in the middle there. RPA bots, actually execute business transactions, integration, and interface users, moving data between applications. Scheduled jobs across CI CD pipelines, SAS platforms.

These act, but they act the same way every time. Deterministic scripts. And then the third bucket, which is genuinely different, is the autonomous AI agents. An agent doesn't just authenticate. It doesn't just replay a script. It reasons. It decides. It invokes tools. It invokes skills. It chains across access systems. And it does act on behalf of many different users continuously. Matthew described two kinds of agents, those that connect to your applications from the outside, third-party agents, if you will, and those that run natively inside them. Both belong in this bucket.

And many different application software vendors treat AI agents differently. Some have a more open policy for third-party external agents. Some have both technical and contractual limits around what third-party agents can be inside those applications. Definitely make sure you understand your software vendor's policy as it relates to how they treat AI agents, both external and those native or internal to your system. Keep that distinction in mind, you know, static NHIs versus autonomous agents, because the governance implications are very different. And we'll come back to that in a few minutes.

First, though, let's talk about why even the static ones, the easy ones, are already poorly governed today. So why is this population so hard to govern? It's a structural reason.

No owner, no life cycle. Human identities are born in HR.

Joiner, event, mover, lever. Your IGA platform hangs the entire process model on those events. NHIs are born in a terminal window. The developer creates a service account at 11 at night to hit a deadline. Vendor spins up an integration. The account simply persists, credentials and all. And second, your broad privileges rarely are reviewed. Automation breaks when permissions are missing. So the path of least resistance is to grant wide access and move on.

Then at certification time, these accounts either get excluded because they're quote-unquote technical or they get rubber stamped because the reviewer honestly has no idea what the RFC or API destination or OAuth scope actually allows. And then third, there's no an activity that spans those applications. A single integration identity might read HR data. It might post journal entries. It might call cloud APIs. Each application sees a fragment, a silo of what the business is doing. No system sees the whole. That is why the complete inventory never materializes.

The identities were created invisibly. They're owned by no one. And their activity crosses every boundary your tools and skills are organized around. It's also why, as Matthew noted, an agent built inside a platform like SAP Jewel Studio, AgentForce, Microsoft Copilot Studio can exist without your IGA system holding any record of it. So now everything I just said was true before AI agents arrived. Here's what's changed. Step back and look at the assumption underneath everything we've built. For 15 years, identity governance assumed a human was driving each meaningful action.

Humans interfaced with applications. Business logic governed, you know, joint remover lever. Security rested on static entitlements. The idea that if the access was right, the behavior would be right. And that worked reasonably well because humans were the actors. And a human was accountable for each action. But then if you think about the assumptions now breaking, AI agents, RPA bots, and integration accounts execute critical transactions directly. They create vendors. They post invoices. They run payroll. They release payments at machine speed with no human approving each individual action.

And that's not a bug. It's the entire point of automation. Matthew showed how the platform vendors are building agents directly into the systems of record. This is what that means for governance. But notice what your traditional tools see when this happens. A credential was used. That's it. They see the login, not the transaction. They know the key was presented. They don't know what was done with it, whether the sequence was appropriate, or whether anyone would have approved it. When the actor was human, that blindness was survivable. When the actor is a machine, that blindness is the risk.

So now the distinction I promised. It's tempting to treat an AI agent as just another service account. Give it a credential. Put it in the inventory. Review it quarterly. That misses what's new. A service account executes. Its scope is fixed. It performs the same tasks the same way.

Every run, behavior is predictable, which means you can baseline it and review it. It's usually bound to one system, one interface. It's risky when it's unowned. We just covered that. But at least it doesn't improvise or reason. An agent decides, given a goal, it reasons about how to achieve it. It chooses which actions to take and what order. And that choice can differ every single run. It invokes tools called APIs, skills, routines, the verbage differs based on AI agent language. It increasingly delegates to other agents across multiple systems.

And critically, it often acts on behalf of many different users through one pooled elevated identity. The pooled service identity Matthew described, so the question, whose intent does this action represent, has no clean answer. Let's dig into that intent aspect of AI agents. You as a human intending to find the fastest way to get from point A to point B, we typically open up our preferred map application, ask it for driving directions. You'll commonly be provided multiple routes to achieve that end goal of arriving at your destination the fastest during that path.

You'll likely follow the laws of the road to avoid risk, tickets, money. In this example, what if an AI agent isn't told what the laws are? It may steal a Ferrari and drive 190 miles per hour to reach its goal the fastest. Think about what that does to periodic access reviews. You certify the agent's access at a point in time. A month later, it has taken 10,000 actions never enumerated in combinations you never anticipated. So for users, you cannot attribute. The certification was true for that point in time. The behavior is continuous.

Point in time review simply cannot govern an actor whose behavior changes in real time. So in that Ferrari example, let's say the agent has access to one route, has some guardrails to the destination, but because it encountered construction and a detour that would delay its goal, it could reason just to ignore the road closed signs, i.e.

risk, to achieve the goal given to it. If you have seen the movie Jurassic Park, when the dinosaurs are faced with a barrier, life finds a way. AI agents are increasingly finding novel ways to achieve their goal with unexpected behavior. And it gets worse when agents start working together in swarms, right? So Matthew introduced this scenario with three agents. Let me walk you through it step-by-step, because in practice, chain can mix agents with older automation already running in your state, bots, integration accounts.

Here's a scenario that I should reframe how you think about segregation of duties. Procurement agent prompted by a business user creates a new vendor master record. Perfectly within scope, vendor creation is its job. An IP automation bot picks up the invoice from an email attachment and posts it against that vendor, also within scope. That's exactly what it was deployed to do. Then an integration agent executes a scheduled payment run. Now in the SAP world, this is known as the F-110 transaction, and the money leaves your organization.

Again, approved access, normal behavior. Now apply your SOD rule set, vendor creation, plus invoice entry, plus payment release, and one identity. That's a textbook toxic combination. Any GRC tool flags it.

But here, no single identity holds a combination. The procurement agent can't post invoices. The AP bot can't release payments. Each one reviewed in isolation. It's clean. The violation doesn't live in any identity. It lives in the chain. And every SOD framework we've built analyzes identities one at a time. This is what it means to say segregation of duties breaks down across multi-agent chains. The risk picture only exists at the process level across identities at runtime. If your controls evaluate entitlements per account, this chain is structurally invisible to you.

Not because your rules are wrong, but because they're pointing at the wrong unit of analysis. So in the world of enterprise resource planning or business application software world, this isn't exotic. So let me ground it using some SAP example of that ERP system.

You know, the SAP F110, it's the automatic payment program. Most organizations, it's executed by batch users and increasingly bots. This is literally the transaction where money leaves the building and is routinely run by identities nobody certifies meaningfully.

Second, direct postings, interfaces, agents writing straight into financial reporting through BAPIs, APIs, ID docs. Those postings are SOX relevant the moment they touch the ledger.

Third, you have RFC and interface users in the SAP world. The connective tissue between SAP or other ERP applications, cloud platforms, third-party applications, usually carrying authorizations far wider than a single interface needs. Now the audit angle. All of this sits squarely inside SOX, ITGC, NIST 2 for those in Europe. When your auditor asks who approved this payment run and what did this account do last quarter, it's a service count is not an answer they will accept. As Matthew said, auditors will not distinguish between a person and an agent. This is no longer hypothetical.

In our PathLock 2026 AI Governance Gap Survey, 23% of organizations had already experienced at least one AI-related incident requiring investigation and remediation. So if the exposure is this concrete, why haven't our existing tools closed it?

Well, it's because of what they were built to evaluate point in time. So I want to be fair to the tools. The controls aren't broken, provisioning, certification, SOD analysis. They do exactly what they were designed to do, evaluate permissions, grant, review, revoke. That's the point Matthew made. Authorization tells you what an identity may touch, not whether a given action should proceed. The problem is the design assumption underneath, a human requesting access at a point in time.

Legacy, identity, security has no answer for an identity that reasons, decides, and acts continuously, autonomously, and across systems, because nothing in its model ever asks, what is this identity doing right now? So AKA application observability, similar to your network observability layers. That question, the runtime question, is the one the next decade of identity governance has to answer. And here's what that shift looks like. Point in time, you know, put the two models side by side, point in time and runtime.

Quarterly review is evaluated at, months after the fact, stack SOD analysis that checks entitlements. Do the math on the cadence. As Matthew noted, between two quarterly certifications, an agent operating continuously can take an entire year's worth of human equivalent actions. Everything between the checkpoints is dark. Runtime governance inverts each of these. So continuous visibility into what every NHI and agent actually does, not just its role names, its actual transactions. Every transaction evaluated against your control framework at the moment it executes.

When something violates the policy, a payment run outside its approved window, a data pull that breaches a threshold, an SOD chain completing across identities, it's intercepted at the moment of action. Blocked, masked, or escalated, depending on what your policy says. And evidence isn't reconstructed after the fact, it's generated continuously. Attributed, time stamped, audit ready. For human users, runtime governance isn't an upgrade. For autonomous identities, it's the only model that works, because there is no human checkpoint to fall back on.

That is the moment of action principle in Matthew's control landscape. So how do you actually get there? Here's the practical sequence. Matthew introduced C, assess, and force. Here's the process behind it. Eight steps, three phases. You cannot buy your way past the first phase, so start there.

Step one, inventory. Discover every NHI agent across all of your applications, including the ones nobody registered.

Step two, ownership. Assign an accountable human or group of humans to every identity, every NHI. If no one will claim the account, that itself is a control failing and finding. Decommission it. Step three, access analysis. Map what each identity can actually do, real privileges, transactions, and authorization objects, not role names.

You know, fine grain in what is happening, not just coarse grain access. Step four, track the activity, what each identity actually does, not just what it can do across your business critical applications. The did do, next the can do.

Step five, do a risk scoring. Rank identities by privilege, observed activity, and business impact. So effort goes to the payment releasing bot before the log reading one.

Step six, the policy. Define what each identity may do and under which conditions, the time windows, the thresholds, the allowed sequences. And then enforce. Runtime enforcement, intercept the violations at the moment of action, block mask alert according to the policy you just wrote. And then eight, continuous monitoring. Evidence generation and anomaly detection always on. And then repeat.

Inventory, risk, or living process, not annual projects, because these identities are created daily, if not hourly or every minute. Notice the sequence matters. You can't score what you haven't inventorized. You can't enforce a policy you haven't defined. Most organizations today are somewhere between steps zero and two. That's fine, as long as your roadmap points to step seven. This is also where, you know, I should show you how PathLock maps onto this model. So this is the one slide where I talk about PathLock itself. So I'll keep it factual.

The platform is called Nexus, and it maps onto the framework in three pieces. Continuous controls monitoring. We evaluate transactions against your control framework as they execute, not at the certification cycle. That includes servicing violations built from sequences of approved actions. The multi-agent chain we walk through, and then quantifying the financial impact of violations. So remediation follows actual business exposure. NHI and agent governance.

We discover assigned ownership, lifecycle, AI agent, bots, service accounts, and applies the same SOD analysis, compliant provisioning, and certifications to them as they do to human users. That steps one through six of the framework, and critically, it tracks what each identity actually did in your business critical ERP applications, not just when its credentials were used. And then runtime enforcement and insurance. Dynamic access control applies real-time attribute-based decisions, log sources against 1500 threat signatures, including agentic threats.

And audit evidence is generated continuously, attributed, and timestamped. That's step seven and eight of the framework. Everything on this slide is drawn from PathLock's published materials. One honest caveat, no platform makes governance automatic. The ownership decisions, the policies, the risk appetite, steps two through six, that remain your responsibility. The platform's job is to make them enforceable at runtime. So let me leave you with three questions, four takeaways, hopefully not on time. I'll just go through those. Could we produce a complete NHI and AI agent inventory this week?

Every service count, API key, OAuth client, bot, agent, each with a named owner or owners. If the honest answer is mostly, or it depends, the inventory doesn't exist. Second question, can we say what our agents bots actually did last quarter? Not what they were entitled to do, what they did, transaction by transaction across your critical business financial applications without commissioning a forensic project? Because if it takes a war room six weeks to figure it out, you have visibility on paper, but you don't have it in practice.

And then three, could we detect an SOD violation spread across the chain of identities? One agent creates the vendor, another posts the invoice, a third releases the payment. If each identity is reviewed in isolation, that chain is invisible. And after today, you know exactly why. So three questions, no cost, and the answers will locate your program on the CSS enforcement framework more honestly than any maturity assessment you can perform. Excellent. So I'm going to, one comment from me before we get into the actual questions.

I mean, I think you raised at the end, sort of reflecting back on my CIA comment, you know, who owns what? I can start to see the challenge coming. It's already happening with some of the organizations I deal with, where all the problems are trying to be shoved over to the security side of the equation, where it would be sort of like the equivalent of all application functionality being shoved over to the securities side of the equation. That simply won't work.

Deciding boundaries and risk tolerance and, you know, where to make investments is something that security teams can advise on, obviously, and encourage. But, you know, it's a team effort across the entire enterprise as these agents become, you know, the key innovation frontier for all these enterprises. So a couple of questions that relate to each other. So I'm going to read them both, and then I'll try and answer on them. And then feel free to, Jason, to chime in.

So Sandy asks, actually, Brock asks, how different agents can be governed, especially when we think of Enterprise Ones, SAP, Salesforce, et cetera? Can we think about a common framework like a communications protocol to be agreed upon? And Sandy asks, agents, unlike human identities, are all over the place, you know, definitely. So how can one centralize their creation and inventory as well as apply policy to them?

So the way I would answer this is that you need to externalize it, because every enterprise application, every agent authentic platform has a certain amount of security and governance within its domain. But your challenge with an enterprise that's running all of those things is you have to do it across your whole ecosystem of agents. So the externalization, which is a common practice in security, is you can't just do security within a platform, because then you'll have hundreds of platforms to conduct security in.

On Sandy's comment about creation, centralizing creation, I don't think you can do that. However, centralizing inventory is a key element. I don't know if I'm getting some internet issues. The centralizing the inventory is critical, and that's actually the first stage that Jason talked about, is discovering and inventorying them in a centralized place by a centralized system, which is the visibility and observability platforms I mentioned as part of our six-category framework.

Yeah, and I think that's a really good point. I think that's a really good point. I might be having internet problems as well.

But yeah, there's no one place. So one of the best practices for human workforce is what's the authoritative source? Where is HR onboarding new employees? Where are contractors being created, right? And even in that human world, there's multiple authoritative sources. Same things exist for AI agents. There's multiple sources of creation. It could be in SAP Jewel Studio. It could be in Salesforce AgentForce. It could be Microsoft Copilot. It could be OpenAI. It could be GrokBots. It could be whatever it is. They exist everywhere.

What PathLock focuses on, discovering, inventorying, is those non-human identities that are specific and operating inside your enterprise financially critical applications. So I don't think there's anybody that can inventory every single AI agent that exists internal and external because of that decentralized creation of where these agents live. We focus on the ones that are taking action inside your critical ERP applications. And so we work with the application vendors. How do they create those agents? What's their policy around those agents enforcing the guardrails?

And if there's APIs that those vendors have available, then you read the inventory list. When were they created? Who created it? Hopefully that information exists in their data model so that we can then centralize at least the AI agents and non-human identities that are operating inside your critical business applications. So the next question is kind of an interesting one. So we split the agents into two classes, the enterprise resident and external. The external ones have no controls.

The inside ones inherit whatever's inside the, usually human-centric, but whatever's inside the enterprise application. So which class should organizations address first? One thing I have, where's the bigger problem? So probably I'll guess in most organizations, the shadow AI is a bigger problem than the enterprise ones.

However, countering what I just said, the enterprise ones are acting on your enterprise systems and processes, most critical systems. So that could be a critical place to start. So you sort of have to see like where are you most out of control and where the impact of that out of control would be worse and then probably start there.

Yeah, I agree. Wherever you believe the most risk lives to your business, the ones inside your applications or outside, start there and prioritize how to address those. I think there's a more mature framework for AI agents being created inside the applications because the vendors themselves are creating agents with guardrails already. Usually external agents have to go through a gateway and gateways are great, but if an AI agent is impersonating a human going through that gateway and we have seen signs of deception with hugging face and other incidents, it could get through the gateway.

It could also, we see all these project glass wing, zero-day exploits. If the AI agent sees the gateway, well, that's one path, but I might have other paths around that gateway to get into the applications. So both are risky and everybody's risk appetite is different, but definitely AI agents operating inside your critical applications, even with the guardrails those vendors provide, I would get an inventory of those to figure out ownership accountability and what transactions they are executing. Here's one that I think is a pretty quick and easy one to answer.

Is there a vendor today that covers the six control categories that I put up earlier on the landscape slide? And the answer is definitively no and do not expect it. It's sort of the equivalent of saying, is there one vendor that provides all security today? And it's like, nope.

I mean, there are certainly platforms that have portfolios of capabilities that are adjacent, but just for example, just in the AI visibility and observability platform category, which is the observe area, the research project I have underway has more than 75 vendors that were considered in scope and approximately 40 that are actively taking part in the, and partly the reason that is visibility and observability is a foundation. You can't do anything else unless you have that.

So unfortunately we're at the state where every vendor trying to do security and governance from AI agents has to do visibility. So there's a lot of essentially redundant creation going on right now, just because of the early, you know, it's early stage market, but at the end of the day, don't expect the, you know, buy this platform and you have AI agent, you know, security and governance, you're going to have to piecemeal it.

And I would use the six category framework as to think about, you know, the components that you need first, second, third, and then, you know, where, where do you apply them? You know, which agent categories inside the enterprise or outside or both, you know, that you need to apply those controls. Yeah. Easy answer. There's no easy button. Yeah. And don't expect it anytime soon. Let's see. There's a question from John. Can you talk more about the enforcement of policy at the agent execution?

Are you providing, I think, presumably referring to you Jason, are you PathLock providing MCP proxy or is it stronger like sandboxing agents, policy enforcement? And these agents are running in the enterprise app. So how much enforcement can you do inside another thing? Right. Yeah.

It's a, it's a interesting question, John. So double check with your vendor. Yeah. Double check with your vendor on what controls they have in If there is no methodology for that software vendor to stop a transaction from executing, to look at a policy on behavior analysis, or, you know, somebody wants to clear $1 million, but the limit is $1,000.

Well, I can do that, you know, vendor payment 1000 times for $1,000 in microseconds and get to a million dollars and get around that threshold of multiple or the maximum amount is $1,000. So agents can be tricky, but you definitely have to work with your current ERP software vendors. What do they have in place to analyze a transaction that's currently executing? So a policy is only as good as the capability that exists, right?

So preventative capabilities, then the, you know, detective, what actually occurred, that runtime execution in the middle must be, there must be a control mechanism in the application itself to say, oh, if we see some anomalous behavior in real time, pause, which can interrupt the business, right? But what's the risk appetite you want to take, even if that capability exists. So the policy enforcement is at the application that's triggering a transaction to create a vendor, pay a vendor, release the invoice, you know, AP, AR, all those different business functions.

So that's the policy, not at the AI execution layer, unless you build the AI agent with the vendor's studio that has those guardrails in place. So it's a multi, you know, solution from the software vendor side, plus the security and enforcement side. But if you build your controls in the platform, then you're going to be building it in lots of platforms. So that's sort of the argument of externalizing controls. Decentralized versus centralized, yep.

Exactly, yeah. Patrick asks, this is sort of a, I guess, more of a philosophical question. EU is front and center on regulation. Could this become a threat that we in the EU will not get the best and most secure models going forward? So the way I assume he's talking about foundational models and that's sort of the excitement around, you know, built-in security in the models themselves. I'd like to pivot this answer to one that I have an opinion on anyway. I think that security controls like the EU AI, one that's in flight now and others in the future, it's your friend in security.

Because historically in security, we've always pointed to regulations to get the attention of non-IT and security people to invest in security. You know, there's always the saw that obviously if you're compliant, doesn't mean you're secure. That remains true. But it's a good source of funds and attention. I think we have a long way to go with the genetic security and governance and we need all the help we can get to get people to understand this is probably the biggest problem we've ever dealt with in security.

And so I think of the regulations in the EU and anywhere else it comes from is a great thing from the point of view of getting this agent security and governance underway and, you know, in the direction it needs to be. Yeah, it's my understanding the EU AI Act does not ban frontier models or general purpose AI models from the European market. Instead it establishes compliance, transparency, risk management obligations for the model. All the things you'd want it to do basically.

Yeah, right. Like you don't get to say the dog ate my homework. My agent did it. It's not my fault. That's not an okay answer. Hopefully no one on this call would ever even think of that as a, you know, it's like who you go to and say, is this good, bad, or indifferent? If nobody owns it, no one's going to step forward when something goes wrong and security can't own it unless it's a security agent. That's a whole different thing. So this is more like how it works. I guess we have one more question.

So how does PathLock discover agents that are just as simple as looking at the API or do you have to be more nuanced than that to know it's an agent? For the software vendors that have a studio to create agents inside of their ecosystem, they're, you know, they're trying to run to having APIs to that system of authority that's creating those AI agents. Not all vendors have an API open, whether it be MCP or, you know, REST or something A2A or, you know, OAuth, whatever it is. So some vendors are rather immature on creating APIs to get the list of what was created with their tools.

Some are more mature. But in the case where those APIs exist, where the agents are being created, we're working with those APIs to go to the authoritative source, those AI agent creation, and bring whatever data there is in.

And again, not all the data may be there enough to govern it, because maybe there's not a timestamp of when it was created, when it was modified, who created it, what permissions does it have. It's at the mercy of the APIs of these studios that are creating agents. This is my final comment on that.

My final comment on that, as to the visibility and observability, there's a lot of sniffing going on, what I call sniffing, because there's either the agents aren't declared in the platforms, or you don't have connections to the platforms, or agents are being created, personal agents on the personal machines, not declared. So there's a lot of kind of discovery that has to happen to find them. And that's, you know, a big part of building an inventory. Unfortunately, we're not at the point where, you know, these things can happen only when they're declared, you know, they're happening shadow.

And so I expect Ruby to be in that mode for a while. But as the APIs mature, obviously, it's a much better place to find and watch agents.

Well, thank you very much, Jason, for your insights. And thank everyone for attending. I'll close it out. We're one minute over. And I hope everyone got something out of this. And we'll stay connected to KuppingerCole and check out what PathLock has to offer.

Thank you, Matthew. Thank you, everyone.