Why AI Agents Challenge Identity Governance

Agentic AI
,
Artificial Intelligence & Machine Learning
,
Identity & Access Management

CIOs Need New Controls for Discovery, Intent and Token Costs

Jennifer Lawinski •
August 4, 2026    

See Also: Scattered Spider Exposed: Critical Takeaways for Cyber Defenders

For CIOs, the challenge begins with visibility and control, said Vibhuti Sinha, chief product officer at Saviynt. Technology leaders need new ways to identify agents operating across cloud platforms, applications, employee devices and custom code. Then they must determine whether those agents are behaving as intended when they interact with enterprise technology stacks.

The challenge extends beyond cybersecurity. Organizations are also struggling to identify duplicate agents, attribute token consumption to individual business units and calculate whether their AI investments are producing sufficient business value.

Sinha joined Saviynt when it was founded in 2014, previously holding roles as chief cloud officer and vice president of cloud products. In this conversation with ISMG in New York City, Sinha discussed the governance, identity-data and cost-management issues CIOs face as agent adoption expands.

Edited Excerpts Follow:

Why do autonomous agents create identity risks that conventional identity controls were not designed to handle?

Before the agent era, when you looked at identities, they were very deterministic in nature. You could define a scope and a boundary for human identities or deterministic non-human identities, and they would operate within that boundary.

That’s not the case with agents because agents are autonomous. That autonomy means agents can do more than what you intended. If they can deviate or do something more, how are you going to ensure that they are not doing that? You have to look at what the agent is doing during every transaction.

Before governing agents, how can technology leaders build an accurate inventory across approved platforms, SaaS applications, employee devices and custom code?

The first thing we do, which is relatively easy, is look at the known, sanctioned and managed agent-building platforms. If you are, let’s say, a Microsoft or Amazon shop, you may have agents in platforms such as Amazon AgentCore or Bedrock.

Second, we look at devices, including laptops, developers’ workstations and servers where people might be running code that the organization does not know about.

The third thing we look for is traffic patterns. If we cannot identify something directly, we can look at network traffic to determine whether there is a call being sent to an external AI service, which indicates that an agent is communicating with that platform.

Then we can do what we call a reverse lookup. An agent can only get access to a downstream application by using a non-human identity. It may use a user ID and password, API key or secret. We look at those non-human identities to see whether they are connected to an agent. Finally, we look at developers’ code repositories.

Why can an agent remain within its assigned permissions and still create a serious security or operational risk?

Intent and appropriateness are two very different things. With agents, the biggest problem is intent deviation.

Let’s say you write a prompt that says, “Go ahead and find the best possible report or sales opportunity.” You might be a North American employee who should only have access to North American data. But because you used the word “best,” the large language model may determine that it should look at reports from every geography. An agent could then ask another agent for data it cannot access directly.

The agent deviated. It did something it was never supposed to do. A runtime control should recognize that the original intent was to look at North American data and prevent the agent from accessing Australian records.

What should enterprises evaluate in real time while an agent is executing a task?

There are three things to evaluate when an agentic transaction is happening. The first is intent deviation. When you create an agent, the creator defines a goal or objective. You need to determine whether the agent’s actions remain aligned with that goal.

The second is a policy enforcement check. An organization might have a policy stating that its agents are never allowed to interact with certain models because of geopolitical or security concerns. The organization needs to determine whether that policy is being enforced.

The third is behavioral anomalies. If an agent is deleting 1,000 files, deleting 1,000 records or downloading 1,000 files in a way that creates a data-exfiltration risk, the organization should flag the activity and take action to stop, block or monitor it, depending on its policies.

Why can’t organizations govern AI agents using the same access-review and approval processes they use for employees?

When a human employee joins an organization, you have a well-defined blueprint covering which systems that person can access, how the person will be onboarded, and who will provide the badge and laptop. You don’t have that defined structure for agents.

Developers are building agents. Business users are building agents. Who is ensuring that they are all following the same mandate and the same policies?

Human identity governance requires a lot of human involvement. Somebody approves a request, and somebody reviews the access. You can’t do that with agents because of the sheer volume and velocity. Organizations will have to use automation for agent governance and involve humans only when necessary because people will not be able to keep up.

What underlying data and organizational problems are preventing companies from realizing value from their agents?

The majority of organizations face three deterrents. The first is data quality. It is garbage in, garbage out.

The second is security. AI centers of excellence moved quickly with experimentation and demonstrations, but identity teams were often brought into the process late. They are now getting caught off guard and are not prepared for what is coming.

The third challenge is determining how to attribute the investment to business value. Organizations need to understand what they are spending and what value or return they are receiving.

Why are token consumption, duplicate agents and cost attribution becoming CIO-level governance issues?

The number one issue today from a CIO standpoint is token management. Cost is the most important boardroom conversation right now. The majority of our customers are telling us that, as we surface security risk, they also want us to surface cost risk. When organizations discover their agents, they want to know whether they have agents performing similar work.

If HR and marketing are both running agents, and two of those agents are doing the same job, the organization is burning tokens twice for that work. How do you reconcile that?

The discovery process should evaluate the similarity of agents and their token consumption and then roll that information up to the CIO or another executive. It might show that a percentage of the organization’s agents are doing largely the same work and driving significantly higher token consumption.

The second major problem is connecting token consumption to individual business units. CIOs are struggling to determine which business unit is contributing to consumption, how the costs should be distributed and what value or return the organization is receiving. Right now, token consumption is hitting the roof, but the business value is not being delivered.