Why AI Agents Challenge Identity Governance

That model remains fundamental to enterprise security. But autonomous AI agents are exposing a gap that traditional IAM was never designed to close.

An AI agent can have a legitimate identity, valid credentials and perfectly legitimate permissions, and still take an action that makes little sense in the context in which it is operating.

Consider a sales agent with permission to read CRM records and send emails. Those permissions may be entirely appropriate. But if the agent decides that emailing 50,000 customers will improve pipeline, should it be allowed to do so?

The identity is legitimate.

The permissions are legitimate.

The action may still be wrong.

That distinction is becoming one of the more important questions in identity security.

We have spent decades making sure users are authenticated and authorised. With autonomous AI, the harder question is whether the action itself is justified.

That is the next IAM problem.

Identity tells us who. It does not necessarily tell us why.

The industry is understandably focused on giving AI agents identities, credentials and permissions.

It should be.

An agent that can access enterprise systems without a distinct, attributable identity is difficult to govern, audit or revoke. NIST's work on software and AI agent identity explicitly examines identification, authentication, authorisation, auditing and non-repudiation, reflecting the fact that agents are becoming capable of taking actions across enterprise environments.

But establishing an agent's identity is only the beginning.

The harder problem emerges at the point of action.

Imagine an AI agent responsible for managing customer support. It has permission to access customer records, create tickets and issue refunds up to a defined threshold.

A customer contacts the organisation.

The agent retrieves the customer's information, assesses the case and issues a refund.

Nothing unusual.

Now imagine the same agent suddenly begins processing hundreds of refunds because it has inferred a broader pattern from a set of conversations.

The credentials have not changed.

The permissions have not changed.

The agent is still the same agent.

But the context, scale and potential consequence have changed dramatically.

This is where a traditional access decision begins to look insufficient.

The move from access control to action control H2

The distinction is subtle but important.

Traditional IAM largely asks:

Who are you?

What are you allowed to access?

With autonomous agents, security teams increasingly need to ask:

What are you trying to do?

Why are you doing it?

Is that action consistent with the original instruction?

Is it appropriate in the current context?

What is the risk if it proceeds?

Who authorised it?

This does not make authentication or authorisation obsolete.

It makes them part of a larger control model.

NIST's current work on AI agent identity and authorisation specifically raises questions around dynamic policy, least privilege, an agent's ability to prove authority for a specific action, how an agent can convey intent, delegation and binding agent actions back to human authorisation.

That is a significant signal.

The standards conversation itself is beginning to recognise that agent authority cannot be treated as a static property of an identity.

AI agents change the meaning of a “permission”

For a conventional application or service account, permissions are often relatively predictable.

A payroll application may need to read employee records.

A backup service may need access to specific storage.

A deployment pipeline may need permission to update infrastructure.

The application executes predefined logic within those boundaries.

AI agents introduce a different variable: interpretation.

An agent receives an objective and determines how to accomplish it.

That might involve:

• Selecting which systems to query
• Choosing which tools to invoke
• Retrieving additional information
• Calling APIs ‍
• Delegating tasks
• Creating or modifying records
• Sending communications
• Executing workflows

The agent may therefore turn one broad instruction into a chain of actions that no administrator explicitly anticipated.

This is where permission becomes more than a binary question of allowed or denied.

It becomes a question of scope.

An agent may be allowed to access a system without being allowed to perform every conceivable action within it.

And it may be allowed to perform an action without being allowed to perform it at any scale, at any time, or under every circumstance.

A legitimate identity can still behave illegitimately

This is perhaps the most uncomfortable part of the discussion.

Security teams have traditionally been trained to look for unauthorised identities.

But autonomous systems create a different failure mode: an authorised identity behaving outside its intended purpose.

That distinction is already familiar in other areas of cybersecurity.

A legitimate user account can be compromised.

A legitimate administrator can misuse privileges.

A legitimate API token can be stolen.

The identity remains valid.

What changes is the behaviour.

AI agents make this problem more complicated because unexpected behaviour does not necessarily require compromise.

The agent itself may have reached an unexpected conclusion.

It may have misunderstood the task.

It may have been influenced by untrusted information.

It may have followed a chain of instructions that was technically permissible but operationally inappropriate.

Or it may simply have interpreted an objective more broadly than its human operator intended.

That means behaviour becomes part of the identity governance problem.

Least privilege is necessary. It is not sufficient.

Least privilege remains one of the most important principles for securing AI agents.

An agent should not have access simply because it might need that access someday.

But agentic environments expose an additional challenge.

With traditional applications, it is often possible to define required permissions relatively precisely.

With autonomous agents, the precise sequence of actions may not always be known in advance.

NIST's agent identity and authorisation work explicitly asks how least privilege can be applied when an agent's required actions are not fully predictable at deployment time.

This suggests a more dynamic model.

Instead of asking:

What permissions does this agent have?

security teams may increasingly need to ask:

What permissions does this agent need for this task, at this moment, under these conditions?

That is a fundamentally different authorisation problem.

Context has to become part of the access decision H2

Consider two actions performed by the same AI agent.

The first is a request to update a single customer record during normal business operations.

The second is a request to export 200,000 customer records at 3am to an unfamiliar destination.

The identity is identical.

The underlying permission may even be identical.

The risk is not.

A mature AI security model therefore needs to consider context alongside identity and entitlement.

Context can include:

• The human or system that initiated the task
• The original instruction
• The business process involved
• The application and environment
• The sensitivity of the data
• The volume and frequency of activity
• The destination of the action
• Whether the action is reversible
• The potential financial or operational impact
• Previous agent behaviour
• Whether another agent delegated the task

This is where identity governance begins to overlap with runtime security and behavioural analytics.

Intent is emerging as the next authorisation boundary

The industry is only beginning to formalise this idea.

Recent IETF work includes proposals exploring dynamic, intent-based authorisation for AI agents and mechanisms for binding agent operations to verifiable authorisation. These are Internet-Drafts and therefore work in progress, not established standards.

Another 2026 IETF proposal explores "Intent Admission Assertions", where an intent can be authenticated, checked against policy and passed to a downstream execution point for verification before an action is taken.

The technical mechanisms will evolve.

The underlying question is more durable:

Can we establish that the action an agent is about to take is within the authority it was actually given?

That is a much richer question than simply validating a credential.

The agent's authority should not grow with its ambition

There is an important principle here for enterprise security architects.

Intent should constrain authority, not expand it.

If an agent has permission to access CRM data but has been instructed to produce a sales forecast, the instruction should not implicitly grant permission to export the underlying customer database.

If an agent can create infrastructure changes but has been asked to identify a configuration problem, it should not automatically gain deployment authority.

If an agent can access financial systems but has been tasked with preparing a report, that does not mean it should be able to execute transactions.

The technical capability may exist.

The authorisation does not necessarily follow.

This is an important distinction because autonomous systems can turn broad objectives into increasingly broad action chains.

The permission boundary must remain stronger than the agent's interpretation of the objective.

Delegation makes governance even harder

The challenge becomes more complex when agents begin working with other agents.

A future enterprise workflow could look something like:

Employee → AI agent → specialist AI agent → application → API → data

Each step potentially introduces another identity and another authorisation relationship.

The original human may have authorised the first agent to perform a task.

But can that agent delegate the same authority to another agent?

Can the second agent delegate further?

Does the authority survive each transition?

And can the organisation reconstruct the entire chain afterwards?

These are not theoretical governance questions.

NIST's work specifically considers delegation, "on behalf of" scenarios, binding agent identity to human identity and non-repudiation.

The answer will ultimately need to be more precise than simply knowing which credential was used.

Enterprises need to understand who authorised the action, which agent executed it, what authority was delegated and whether the final action remained within the original scope.

Behaviour becomes evidence

There is another shift worth watching.

Identity governance has traditionally been periodic.

Access is granted.

Access is reviewed.

Access is recertified.

Access is revoked.

That cycle works reasonably well for relatively stable identities and permissions.

It becomes harder to apply when an agent can take thousands of actions in minutes.

For AI agents, governance increasingly needs a runtime dimension.

Security teams should be able to identify patterns such as:

• A sudden increase in transaction volume
• Access to resources outside an agent's normal workflow
• New tool or API usage
• Unexpected delegation
• Attempts to access increasingly sensitive information
• Changes in behaviour following new instructions
• Actions outside expected business hours
• A sequence of individually legitimate actions that creates an unusual outcome

This is where identity governance, Identity Threat Detection and Response (ITDR), privileged access management and AI security begin to converge.

The question becomes:

Is this still the behaviour we expect from this identity?

Human oversight needs to become risk-based

The obvious response to autonomous AI is to put a human in the loop.

But that approach does not scale.

If an organisation requires human approval for every decision an AI agent makes, it has effectively recreated manual processing.

The better model is human authority at the points where risk warrants it.

An agent might be allowed to:

• Retrieve information automatically
• Draft communications
• Create low-risk tickets
• Make recommendations

But actions involving:

• High-value transactions
• Sensitive data exports
• Irreversible changes
• Privileged configuration
• Regulatory decisions
• External publication

may require stronger controls or explicit human approval.

The goal is not to remove autonomy.

It is to make autonomy bounded, observable and interruptible.

What CISOs should be doing now

The technology is moving quickly. Governance programmes need not wait for the standards landscape to settle before taking practical steps.

1. Discover every agent

Start with visibility.

Identify agents across SaaS platforms, cloud environments, development tools, business applications and internally developed workflows.

Shadow AI is becoming a governance problem when agents acquire the ability to act.

2. Give every agent an accountable owner

Every production agent should have a clear business owner and technical owner.

There should be no anonymous autonomous actors.

3. Map authority, not just access

Document the applications, APIs, data and workflows an agent can reach.

Then understand how those permissions were granted.

4. Separate capability from authority

An agent may technically be capable of performing an action without being authorised to perform it in every context.

That distinction should be reflected in policy.

5. Establish risk-based action controls

Not every agent action needs the same level of scrutiny.

Define thresholds for automated execution, additional verification and human approval.

6. Capture the chain of authority

Where an agent acts on behalf of a human or delegates to another agent, preserve that relationship for audit and accountability.

7. Monitor behaviour continuously

Identity governance should not end when credentials are issued.

Watch how agents actually behave.

8. Make revocation real

When an agent's authority needs to be withdrawn, the organisation should be able to stop its access quickly and reliably.

From Identity Governance to Decision Governance

This may be the more profound change.

For years, IAM has been primarily concerned with identity and access.

Agentic AI pushes it towards identity and decision authority.

The emerging control model could be thought of as seven questions:

Identity

Who is acting?

Authority

What can it technically do?

Intent

What task was it authorised to perform?

Context

Under what circumstances is it acting?

Risk

What could happen if the action proceeds?

Behaviour

Is its activity consistent with its expected purpose?

Accountability

Can we prove who authorised the action and reconstruct what happened?

None of these replaces traditional IAM.

Together, they extend it.

And that extension may become essential as AI agents move deeper into enterprise operations.

The Trevonix Perspective

At Trevonix, we see AI identity as an important foundation, but not the end state.

Giving an agent an identity, credentials and permissions answers a necessary question:

Who is this system, and what can it access?

The harder question is:

Should this specific action be allowed now?

That is where the next evolution of identity governance is likely to happen.

We believe enterprises will increasingly need an approach that brings together identity, intent, context, risk and behaviour at the point where an agent takes action.

The objective is not to constrain AI until it becomes useless.

Nor is it to give autonomous systems unrestricted freedom.

It is to establish boundaries within which autonomy can operate safely.

That means moving beyond static permissions towards more adaptive authorisation, stronger least-privilege models, traceable delegation, behavioural monitoring and risk-based controls.

For organisations in the UK, Europe, North America and other regulated markets, this will also become an accountability question.

When an autonomous system changes a record, approves a transaction, sends sensitive information or modifies infrastructure, the organisation needs to be able to answer:

Who was acting?

On whose authority?

For what purpose?

Under what conditions?

And why was that action allowed?

That is the level of governance required if agentic AI is to move from experimentation into trusted enterprise infrastructure.

The Next IAM Question Is “Why?”

The identity industry has spent decades answering:

Who are you?

Then:

What are you allowed to do?

Agentic AI adds a harder question:

Why should you be allowed to do this now?

That question does not diminish the importance of identity.

It changes what identity governance has to accomplish.

The future of IAM will not simply be about knowing every identity in the environment.

It will be about understanding the relationship between identity, authority, intent, context and action.

Because the most difficult security event may not involve an unknown identity or stolen credential.

It may involve a perfectly legitimate identity doing exactly what it was technically allowed to do.

Just not what it was actually meant to do.

And that is why the next generation of identity governance must move beyond proving who can act to establishing why an action should be allowed.

Key Takeaways

• AI agents challenge traditional IAM because legitimate permissions do not necessarily guarantee legitimate actions.
• Authentication establishes identity; authorisation establishes capability; context and intent can determine whether an action is justified.
• Least privilege remains essential, but static permissions may not be enough for autonomous systems.
• Agent delegation creates new requirements for traceability, accountability and non-repudiation.
• Behaviour and risk increasingly need to become part of runtime identity governance.
• Human oversight should be applied according to risk rather than to every autonomous decision.
• Emerging standards work is exploring intent-aware and operation-level authorisation, but these approaches are still developing.
• The strategic direction is clear: IAM is moving from access governance towards decision and action governance.

Frequently Asked Questions

1. What is AI agent identity governance?

AI agent identity governance is the practice of identifying, authenticating, authorising, monitoring and managing autonomous AI agents and their access throughout their lifecycle. It extends established IAM principles to software capable of independently taking actions across enterprise systems. NIST is actively exploring standards-based approaches to AI agent identity and authorisation.

2. Why do AI agents challenge traditional IAM?

Traditional IAM largely determines whether an identity has permission to perform an action. AI agents can dynamically interpret objectives, select tools and chain together actions. This creates situations where an agent may have legitimate access but still perform an action that is inappropriate for the task or context.

3. What is intent-aware authorisation?

Intent-aware authorisation considers the purpose or task associated with an agent's requested action when determining whether that action should proceed. Several emerging IETF proposals are exploring intent-based and operation-level authorisation for agentic systems. These remain works in progress rather than established standards.

4. How should enterprises secure AI agents?

Organisations should begin with agent discovery, distinct identities, accountable ownership, least privilege, clear authority boundaries, risk-based action controls, delegation tracking, continuous monitoring and rapid revocation.

5. Are AI agents non-human identities?

Yes, AI agents can be treated as a category of non-human or software identity. However, their ability to interpret goals, make decisions and dynamically select actions creates governance requirements beyond those associated with many conventional service accounts and machine identities.

6. Does Zero Trust apply to AI agents?

Yes. NIST's work specifically considers how Zero Trust principles can be applied to agent authorisation, including dynamic policy and changing agent context.

‍