AI Agents Need Identities Too: The New IAM Risks Security Teams Need to Manage

We’ve spent years moving security decisions away from network location and toward identity. AI agents make that identity problem harder because the software is no longer simply waiting for a user to click a button.

An agent may search internal data, call APIs, write code, interact with SaaS applications, trigger workflows, and make changes without a person approving every individual action. From an IAM perspective, that makes the agent more than another application. It becomes another actor in the environment.

Once software can act, familiar identity questions become urgent. Who is making this request? What authority does it have? Where did that authority come from? How long should it keep that access? Who is responsible for it? And if something goes wrong, can we reconstruct what happened?

In my recent discussion of IAM as a core cybersecurity skill, I described identity as the connective tissue between security, cloud, networking, applications, and incident response. Agentic AI adds another kind of identity to that environment.

The First Risk Is Letting the Agent Become the User

The fastest way to make an agent useful is often to let it operate with a user’s existing credentials or permissions.

That’s also where I would start asking questions.

An employee may legitimately have access to customer records, financial systems, source code, messaging tools, and cloud resources because that person performs several responsibilities throughout the day. An AI agent completing one task probably does not need all of them.

NIST has specifically highlighted credential sharing between people and agents as an identity problem because it weakens accountability. If the same identity represents both the employee and the software acting for that employee, it becomes much harder to determine which one actually performed an action.

My preference is straightforward: give the agent an identity that is distinguishable from the person it represents and delegate only the authority it needs.

But we also have to be realistic about how these systems will be deployed. Users will connect agents to accounts they already have. Developers will take shortcuts. Some applications will not support a clean agent identity model yet. That makes least privilege even more important.

Least privilege is not a substitute for giving the agent its own identity. I would not want an organization to interpret it that way. But if an agent is allowed to operate through a human identity, intentionally or otherwise, the amount of access attached to that identity determines how serious the mistake can become.

A user with tightly scoped access gives an agent a much smaller blast radius than a user carrying permissions accumulated over ten years of role changes.

Agents need separate identities where the architecture supports them. Human identities still need least privilege whether agents are involved or not. Agentic systems simply make the consequences of getting either one wrong much easier to see.

Agent Permissions Can Outlive the Task That Required Them

IAM teams already understand privilege creep. A person changes roles but keeps old group membership. A service account remains active after the application disappears. Temporary access quietly becomes permanent. An agent can accumulate the same leftover access, potentially much faster.

Maybe an agent receives access to a repository for one project. Maybe it is allowed to call an administrative API during a particular workflow. Maybe it is granted access to sensitive data for one analysis.

What happens when that work is finished?

If nobody removes the authority, the organization has created another standing identity with permissions that may no longer have a business purpose.

Now repeat that across dozens or hundreds of agents.

This is why I think the IAM lifecycle has to extend beyond employees and traditional service accounts. Security teams need to know when an agent was created, who owns it, what it is supposed to do, what access it currently holds, and when that access should disappear. The technology is new, but orphaned identities are not.

Access Control Has Always Included What You Can Do

One thing agents do not change is the definition of access control. Access control has never been only about whether an identity can reach a system. It also determines what that identity is authorized to do once it gets there.

If I can view payroll data, that does not mean I should be able to change payroll records. If a service account needs to read from a database, that does not mean it should have administrative authority over the database.

The same applies to agents. What is different is that we now have to apply those controls to software that may choose its own next action.

An IT support agent might need to read device inventory, check account status, search documentation, and create a ticket. None of that means it should be able to create administrators, disable security controls, erase logs, or modify production systems.

I would look at agent access in terms of a few fairly ordinary IAM questions:

• What resources can it reach?
• What actions can it perform against those resources?
• How long does it need that authority?
• Which actions are important enough that another approval should be required?

There is nothing especially exotic about those questions, the harder part is applying them consistently to an actor that can work at machine speed and may make decisions without a human choosing each individual action. To be fair, many organizations already struggle to implement access control properly for people. Agents do not invent that problem, they magnify it.

The Trust Chain Is Getting Longer

An agent rarely works alone. It may interact with a model, query a database, call an API, invoke a tool, hand work to another agent, and then send the result into a system that performs the final action.

From an identity perspective, I care about the whole chain.

Which user or system initiated the task? Which agent received the authority? Did that agent delegate work to another agent? Which tool did it call? Which credential or token did the tool use? Which system ultimately accepted the request?

If I can only see the last identity in that chain, I may know that something was authenticated without knowing whether the resulting action was actually authorized in the way I intended. That is where agent identity gets more complicated than a new service account.

The challenge is not just identifying the agent. It is preserving enough information about delegated authority that the organization can still explain why an action was allowed several steps later.

The IAM Industry Is Starting to Treat Agents as Identities

The encouraging part is that the IAM industry is no longer treating agent identity as a theoretical problem.

Microsoft Entra Agent ID is now generally available and gives organizations a way to manage agents as distinct identities, including ownership, lifecycle, permissions, governance, and agent-aware access controls. Microsoft’s guidance also makes the separation between the person and the agent explicit: an agent should not simply inherit everything its human sponsor can do.

Okta is approaching the problem somewhat differently. Its Agent SSO work places the identity provider in the middle of agent-to-application access so enterprise policy can determine which applications an agent is allowed to use on behalf of a person.

Auth0 is also implementing the emerging Cross App Access model, although parts of its implementation were still in early access during 2026.

I would not read too much into which vendor currently has the longest feature list. The more important point is that agent identity is becoming a normal IAM architecture problem.

That’s a meaningful shift. A year or two ago, many agent security discussions started with the model. IAM platforms are now starting with the identity.

The Standards Are Moving, but Delegation Is Still Messy

There is also some convergence in how agent-to-application access might work.

Cross App Access is one of the more interesting developments. Instead of every agent maintaining long-lived API credentials or asking users to approve every connection independently, the enterprise identity provider can participate in the decision about which applications the agent is allowed to access.

The Identity Assertion JWT Authorization Grant, or ID-JAG, is part of the IETF work behind that approach.

For a relatively simple scenario—one agent acting for one user against a known application—that model makes sense.

The harder question is what happens when one agent hands work to another. That’s where I think the current standards still have a lot of work to do.

Existing token exchange can record information about prior actors, but recording the chain is not the same thing as restricting what every actor in the chain is allowed to do. If Agent A delegates to Agent B, and Agent B delegates to Agent C, I want more than a history of who touched the token. I want to know that each step received only the authority it actually needed.

Some newer IETF proposals are trying to address that with attenuated delegation, where authority can become narrower as it moves downstream. That could mean limiting which tools an agent can call, what arguments it can pass, how long a token remains valid, or whether the agent can delegate again. Those proposals are still developing.

So I would be careful about saying IAM has “solved” agent identity. We are getting better at the relatively simple case of one agent acting for one person against known applications. Autonomous agents, agent-to-agent chains, cross-organization delegation, and fine-grained tool permissions are much less settled. Security architecture needs to account for that gap.

An Authorized Agent Can Still Do the Wrong Thing

Authentication and authorization do not guarantee good judgment. An agent can have a perfectly valid identity, exactly the permissions it was supposed to receive, and still be manipulated into doing something nobody intended.

Prompt injection is the obvious example. Suppose an agent is authorized to read documents and send information to an external system. It encounters malicious instructions hidden inside one of those documents. The attacker may not need to steal a password or bypass authentication. The attacker only needs to influence how the agent uses access it already has.

That changes the question I would ask. Instead of only asking whether the agent is authorized, ask:

If this agent follows a bad instruction, how far can its legitimate permissions take it?

That is where IAM controls start working together with AI security controls.

Least privilege limits the amount of damage available to the agent. Short-lived access limits how long that authority exists. Human approval can interrupt higher-risk actions. Runtime controls can restrict tool use. Monitoring can flag behavior that no longer looks like the task the agent was originally assigned.

Microsoft makes a similar point in its guidance on securing AI agents: the agent should not be able to disable the controls watching it. 

I think that distinction is important. The agent cannot be the final authority on whether the agent is behaving safely.

Every Agent Needs an Owner, an Identity, and an Off Switch

Before I allowed an agent to operate in production, I would want a security team to answer six questions:

1. Who owns it?
2. What identity does it use?
3. What can it access?
4. What can it do with that access?
5. Which actions require additional approval?
6. Can the organization quickly see its activity and revoke its access?

If those answers are unclear, the organization has an identity governance problem before it has an AI problem. That’s why I don’t see AI security and identity security developing as separate disciplines.

Practitioners still need to understand authentication, authorization, privileged access, service identities, federation, lifecycle management, monitoring, governance, and Zero Trust. Then they need to understand what happens when those controls are applied to software that can interpret context, choose tools, delegate work, and take action.

That overlap is also why these skill areas belong together.

INE’s Certified Identity & Access Management Associate (eIAMA) builds the vendor-neutral IAM foundation across authentication, federation, authorization, privileged access, service identities, lifecycle, monitoring, and governance.

The AI Systems Security Specialist (eAIS) applies many of those same control ideas to AI systems, including prompt injection, tool misuse, secure design, and AI security testing.

The technologies are different, but increasingly, the security problems are connected.

The Actor Is New. The IAM Problem Is Familiar.

As agents take on more meaningful work, identity management has to keep pace with what we allow them to do.

I would start with an inventory. Know which agents exist. Give each one an owner and a purpose. Make its access visible. Scope that access to the work it needs to perform and remove it when the work changes or ends.

Where the architecture allows it, give the agent its own identity.

Where that is not yet happening, be even more disciplined about the privileges attached to the human or service identity the agent is using. That is not the end state I would recommend, but it is a practical way to reduce the consequences of a suboptimal design while organizations catch up.

Higher-risk actions should receive stronger controls. Some may still need human approval. Enough telemetry should exist to reconstruct what happened after the fact. And when the agent no longer needs access, there should be a reliable way to take it away.

None of that requires a completely new security philosophy. IAM has always been about deciding who or what deserves authority, under which conditions, and for how long. AI agents make that discipline harder to fake.

FAQ

What is an AI agent identity?

An AI agent identity is a distinct digital identity used to authenticate, authorize, monitor, and govern an AI agent as it accesses data, applications, APIs, tools, or other systems.

Why shouldn't an AI agent simply use its user's credentials?

A user's identity often carries more access than an agent needs for a particular task. Sharing that identity also makes it harder to determine whether an action came from the person or from the agent. A distinct identity makes least privilege, auditing, lifecycle management, and revocation easier to enforce.

Does least privilege replace the need for a separate agent identity?

No. They address different problems. I would still prefer the agent to have its own identity. Least privilege limits the impact when an agent is over-permissioned, manipulated, or allowed to operate through another identity.

How does IAM change for AI agents?

The fundamental IAM principles do not change. Organizations still need authentication, authorization, ownership, lifecycle management, monitoring, and revocation. The difference is that those controls now need to work for autonomous or semi-autonomous software actors that may choose and execute actions without a human approving each one.

What is delegated authority for an AI agent?

Delegated authority is permission given to an agent to perform specific actions on behalf of a person, application, or another agent. Good delegation should preserve accountability and limit the agent to the resources, actions, duration, and conditions required for the task.

Are there standards for AI agent identity?

Existing identity standards such as OAuth provide much of the foundation. Newer work around Cross App Access and ID-JAG is addressing agent-to-application access, while multi-agent delegation and tighter control over authority passed between agents are still developing.

How does Zero Trust apply to AI agents?

The same way it applies elsewhere: verify identity and context, grant only the authority required, assume the actor can still be compromised or manipulated, monitor its activity, and keep critical controls outside the actor's control.