Governing AI Agents Within the Enterprise

So, hi everyone. I'm Heiko. There was a change in the agenda, so Malha is ill and so I jumped in on short notice and was a bit busy in kind of finalizing my slides, because they haven't been there yet. But I think it's quite good and for the next 20 minutes it might be a bit of a different topic, but feel always free to put your questions on later on.

So, today it's about Governing AI Agents Within the Enterprise. And who am I?

I'm Heiko, basically an identity guy by heart, and more than 20 years in the identity and access management space, CEO of Nexis, the leading identity, visibility and intelligence platform, advisor to Yamones and to Asterix, recently acquired by Cisco. And, yeah, basically working a very, very long time in the identity space. Last year I spoke here at EIC about non-human identities and gave a kind of foundational introduction what these kind of NHIs are.

And one of the key things was last year and still today, non-human identities, NHIs or agentic agents will outnumber humans within the enterprise by 50 to 140-ish, so different numbers by different analysts. And basically we will see some of this year or next year or whenever. But one thing is for sure true, it will be far more than you have, that you have employees in your enterprise. And basically majority of you is aware about what it means with IGA, kind of keeping your workforce, your external partners, your consultants, your suppliers kind of managed and governed.

And one thing is clear, it won't be easier in the future. And with agents, a couple of things are changing. So we are not longer securing tools, we are governing in parts digital employees. When I'm speaking today about agents, I am referring to the longer living one, not to the short-term ephemeral one, cloud code is spawning up, working for a couple of seconds, a couple of minutes and disappearing. Because this kind of thing is a different animal. So you need very, very fast reactions, you have a different scope, it runs on a different environment.

When you see agents replacing kind of certain parts within your enterprise, being it augmentation to your own employees, being it working like a digital employee in your Slack or in your Teams clients, you can delegate tasks to, then it's probably not Michelle anymore, the marketing lady that was writing content, it's probably Michelle the agent who is kind of asked in creating some things and giving some output. Or it's a service account that's a long-living account ensuring kind of some system to system communication.

Or think about services replacing, agents replacing kind of a classical service that's normally kind of implemented somewhere in a web client application doing something like that, where it's now an agent adapting and has to be managed. And all these examples do not really fit well in a classical identity and access management setup. So majority of tools was built for humans and it will break by agents. So let's assume it's a factor 50 or a factor 100, and most likely the majority of you has some IGA software out there. Now imagine it's a factor 50 or a factor 100 more identities there.

What it means when you are doing cleanup jobs, when you're doing kind of reorganizations or something like that. So many customers and users are still struggling today when there is an org change on January 1st.

It means, depending on the maturity of your product, that it could be a couple of hours or a couple of days, for some even weeks, to recalculate. And what's obvious, kind of static roles and static permission assignments that won't work anymore. It can't follow dynamic intent and permission might be gripped because there is not a clear job description for an agent anymore. So independent on how much you're mature as an enterprise and your organizational units, a couple of things are clear. So every one of your human employees has normally a manager.

Whether it's documented in HR systems and org charts, sometimes it's not, I know, but basically normally every employee has a manager. Sometimes employees don't know, but that might be an organizational failure. But there is someone who's deciding on pay raise, salary raise, who's approving vacation and this kind of stuff. Every employee is bound to kind of an organizational unit, a team, a department, something like that. Employees are normally managed in a kind of HR system and someone is paying salary at the end of the month. And following money is always a wise rule.

So you have some processes there. When the employee is leaving, you are quite sure that you stop paying. That's a very established process. Despite so many processes are not probably working well, this is one. And when someone is starting and doesn't get salary, the person will raise their hand, where's my first salary, and it will be fixed. This is completely different with agents. Has an agent a manager? By default. It's part of an IT system, most likely by default, not directly assigned, not naturally.

You don't bring the agent in the room and saying, hey, this is your new manager, I'm making you an onboarding tour. Agents are not directly bound to organizational units. Just because we as human beings are structured that I'm working in a sales department, in an engineering department, in a marketing department, and have my kind of workspace inside marketing, inside finance, that's likely probably not the case for agents anymore. When you run data analytics agent for kind of some special analytical purposes, you can work across business units.

So those of you who are working in a metrics organization and are heavily involved in project work, have probably the challenge already that you are kind of working in a kind of different organizational units, and that you are kind of having an accumulation of different authorizations in a big mix. With agents, it will become more harder. And agents don't have job descriptions. So whilst the majority of you is basically knowing what's your responsibilities, what are your tasks, and hopefully your manager knows it as well, it's not that clear for agents.

So there was some developer sitting in an engineering department and building an agent. There was the young finance consultant in your finance department who was very into IT and into all the new technologies, building an agent. But likely there is not a job description made up up front. And the manager isn't even aware that this young finance consultant has deployed in his own ecosystem a couple of agents. And then it gets more and more complicated because a lot of those things are missing. And last but not least, orphaned agents survive their creators.

So if an agent is there and there is not a manager, the agent doesn't care. If there is not a human owner assigned, the agent is running and running and running and running and working and working and working probably. But there must be or should be kind of a human owner side and a key responsibility structure, whether it's a technical owner and a business owner, whether it's called an intra-ID for agents, a sponsor and a technical owner. There are kind of some ownership relations where you assign them or clusters of agents to human beings.

And all those agentic actions have to tie back to somehow human principles, especially when you're a regulated company, when you're a bank or finance institution or an insurance company out there, you have a couple of obligations. You have to be compliant to the law out there, whether it's DORA, whether it's ISO 2701, when you're in CRITIS, it's NIS2. And most likely every large enterprise has at least the basic regulations that are fulfilled. And if not, you are probably not officially audited.

But what's requested in ISO 2701, for example, to do a regular recertification on who's allowed to do what, makes sense from an IT security perspective. So whether you are or whether you're not, it does make sense. Some of you have probably heard already about intent. So it's inside the agentic AI and we do agents and we do AI. A lot of people up there and on the vendor side are talking about intent. We have to describe the intent. We have to describe somehow or analyze behavior, match behavior to intent. But the maturity is probably not aware what intent is.

There is a very, very good paper out there from Microsoft. A couple of researchers have broken it down. So basically that's a quick, a short summary. In the final version of the slides, not in the one that I uploaded, I can include the kind of the reference back to Microsoft. It's really worth a read to get a couple of ideas. So basically the Microsoft researchers are breaking down the overall intent in four dimensions. Number one is an organizational intent.

Policies, kind of things that are normally stored in an ISMS, an information security management system. Regulations. And those policies are not the fine grained IT policies like OPA or OSEN. These are the very, very high level policy. In German it would be Sicherheitsrichtlinie or Richtlinie within the ISMS where you describe on a high level what your kind of guidelines you are following as a company. Then you might have some role-based intent according to the Microsoft researchers. That's the kind of the agents or the NHI's digital job description.

So where you kind of bring in some boundaries to make it precise, to make it clear what is the agent intended for. Other you might have this kind of deviation and that agents are slipping away and doing out of a sudden something different at a certain point in time. Whilst when you're building software like you have been used to do in the past, you have to make changes. So basically your CRM system doesn't evolve out of a sudden to be an ERP or an HR system. There are kind of identities in there, customers and it could be a smart idea.

Okay, let's put in our employees as well. Let's do a bit of tricks and making, reusing the CRM as an HR system and this kind of stuff. This doesn't happen because you have processes in place. You have a clear understanding what's the system for, how's the system working. You have changed control boards and this helped you to mature your company, your IT operations, your compliance to standards. So with role-based intents, you kind of define what an agent should actually do.

And there's the developer intent, according to Microsoft guys, kind of defining what the developer originally had thought that those things are allowed to do. So kind of which services are those agents really needing and acquiring and using to grabbing data. An MCP connection to an HR system, a direct REST-based connection to a finance system, whatsoever, it won't be the case that everything is open.

Now, when you're playing around in Cloud Code, it feels sometimes when you do it privately or on a kind of very open company, notebook, MacBook, it feels that it's super easy and you can connect to everywhere. But in fact, what you're doing as of today, you're probably using Cloud Code, opening PowerPoint on your local machine when you are in the cowork or a code mode. You basically might connect with the Chromebook in your Chrome browser, being able to use LinkedIn. You might connect via MCP, a task management software.

But a lot of those things you're probably connecting today are either not fully integrated into enterprise systems or they are your private pilots or POCs. But very likely within your company, on your company's computer, you can't directly access your CRM system, your finance system, and your ERP system. Most likely nobody, except you have some kind of high-privileged admin rights. Last but not least, the user intent is important. So basically, what's intended the user to do? I can skip this slide. So basically, this slide recaps all I have said.

But for later on, it might be a good read from you. And what are we doing now to govern agents? And how can we govern the question, what's an agent allowed to access? What's an agent allowed to do? So a key of that would be dynamic access policies. I likely don't tell you something new about this. But what does it mean? So the world is a world of very, very mixed access control on different things. There is role-based, static and dynamic ones. There is policy-based. There was rule-based. There is relationship-based. There is attribute-based and policy-based. So a lot of variants.

A key point is, and this is where we are, what we are believing is a kind of, it will be at the end, always a mix. You will be mixing attributes from the identity, so from the agent, and attributes that are describing the agent. You might have some static roles describing the agent's job function, because it's a recruiting agent. It's a loan calculation agent. It's not a multi-purpose agent, so it's not a Swiss army knife. It should have a dedicated purpose, a dedicated intent, and then it could have some kind of key roles as well. And then a couple of rules where you help your enterprise.

Remember, agents outnumbering human beings by 50 to 100 to 140, so a big bunch of identities. Then you can't do manual assignment, probably even not a rule-based assignment. You will generate policies that build a guardrail in order to kind of deny certain actions for certain kind of identities, and allow certain actions for certain identities. Segregation of duties is a big topic when agents are working. So many companies out there, and I don't ask who, so in other words, I won't blame you. So many companies have not implemented segregation of duties company-wide very, very well.

You have probably SOD defined in your save point, or in your one identity, or in your savient, but have you done it cross IAM silo? Have you implemented SOD across your save point instance and your PAM instance, across IGA and PAM, and probably across your legacy IGA, your new IGA, your PAM and your Enter ID? I bet not.

The majority of customers haven't done that, and so basically you have gaps open that are kind of managed in a manual way, that might be managed with Nexus, which is my recommendation, or that are just ignored by doing the bad, oh, nothing will happen, and probably the auditor won't find it, but when you regulate it and get a finding, then it's not that funny for you. And one thing where I might have to disappoint you, recertification and access review is not that. This is a task you won't get rid of at all.

So I'm completely with what people are saying in the industry, the time of manual access reviews for identities will become solved the sooner or later. But what we have always to do when there is a policy, you have to review the policy. You have to review as a business owner the policy, whether the policy is still matching your intent, your task, what you're really trying to do. Then you are not reviewing anymore, is HYCO allowed to do it? Is the agent allowed to do it? But on a meta layer, you have to review basically whether the policy still is expressing what you're expecting to do.

And that's why we see a strong convergence of identity and access management and GRC. That's the so-called FAN, as I call it, where we have the visibility layer across several systems, where we have an intelligence and observability layer. So when something deviates from what is good, what does good look like, you can do the remediation. And there are a couple of typical GRC elements, third-party risk management and ISMS where you can grab data from. When you do vendor onboarding in your company, you collect a lot of data. Are you certified? Are you following these standards?

Are you hosting in the US or in Europe? But it's barely used. Normally it's ending up by procurement being stored in some SharePoint folders. So imagine you have this data available into an identity and access management-backed ecosystem and you can evaluate it. You can say this Workday recruiting agent, Workday is an HR company in the US, is hosted in the European Union. There is the certification that it's not biased. It has not to be biased according to the European Union's AI Act. It doesn't use model data for model training. And it's only allowed to access HR systems for European citizens.

And the same vice versa, the opposite way for US customers. Then you can build the guardrails and having a policy-based approach to seek your agents together with GRC data. And an important step to be compliant, to DORA, to analyze, to the European Union's AI Act, using this and leveraging your ISMS data. You should have anyway kind of which application owns PI data, which application owns HR data and this kind of stuff. And identity, visibility, intelligence could be a first step to solve these issues. So basically coming to an end, think about ownership and clustering of agents.

Think about connecting lifecycle to human lifecycles, that you have the kind of owner assignment that you are able to govern and manage the owner assignment. Think about policy-based authorization and don't forget segregation of duties. It's a different level. It gets even more complex when you think about that. And you won't get rid of recertification of policies. Skip this one before I'm cut off. And one last thing, don't wait for standards. Build adaptability into governance now.

So there are so many standards in progress and standards will be super important and standards will be the enabler for a working agentic AI cybersecurity ecosystem. But if you wait too long until the standards are published or mature or implemented, you are falling behind. So start taking care about your non-human identities and agents as of today. You can think about how to do ownership assignment, how to do kind of recertification and the more sophisticated stuff who's allowed to delegate what. What parts have to be impersonated or delegated? What are the kind of corresponding standards?

That's an important thing, but it can be the next step. So if you go step by step, there is enough to do today. Thank you very much. Thank you very much.