AI Agents Just Changed the NHI Conversation

A traditional service account is given credentials and executes a defined process.

An AI agent can be given an objective, determine steps, select tools, retrieve information and take actions across multiple systems.

Both require identity.

But the governance question is no longer only:

Can this non-human actor authenticate?

It becomes:

What authority did we delegate to it, on whose behalf is it acting, and can we reconstruct what it actually did?

That changes the NHI conversation.

Consider a Procurement Agent

Imagine an enterprise agent designed to help a purchasing team.

It can:

• read an email request;
• retrieve supplier information;
• access ERP;
• query inventory;
• review a contract;
• call a supplier API;
• create a purchase requisition;
• route an approval;
• update a CRM record.

From the business perspective, that is productivity.

From an identity perspective, it is a chain of delegated authority across multiple trust boundaries.

Which identity accesses ERP?

Does the agent use its own identity or the employee's?

Does it inherit the user's permissions?

Can it invoke another agent?

Can it access every supplier or only the suppliers relevant to the task?

Can it create a PO or only a requisition?

Can we distinguish what the employee requested from what the agent decided?

Can we revoke the agent without disabling the employee?

Can an auditor reconstruct the transaction?

Those are identity questions.

Agent Identity Is Not Just Service-Account Governance With a New Label

Many controls from NHI security remain essential.

Discovery.

Ownership.

Least privilege.

Credential security.

Lifecycle.

Monitoring.

But agents introduce additional context.

They may act:

• autonomously;
• on behalf of a human;
• on behalf of an application;
• through another agent;
• through tools such as MCP servers;
• across several systems during one objective.

The identity system therefore needs to understand more than the credential presented at the final API call.

AVIKORE Agentic Authority Model

Evaluate every material agent through five lenses.

1. Identity — Who is acting?

The agent should be distinguishable from the user, application or platform that created it.

Shared identities destroy attribution.

2. Authority — What may it do?

Define permissions at the level required by the business task.

“Access Salesforce” is not an authorization model.

3. Delegation — On whose behalf?

An agent may have its own identity while operating under delegated user or application authority.

Preserving that context matters.

4. Intent — What was it authorized to accomplish?

This is where agent governance begins to differ from conventional service access.

An identity may technically be allowed to call an API while the particular action falls outside the intended task.

5. Accountability — Who owns the consequence?

Every enterprise agent needs accountable ownership.

Not merely a developer.

Someone must own the business use, permitted authority and risk.

Identity → Authority → Delegation → Intent → Accountability

That is the agentic identity problem in executive terms.

Authentication Is Necessary. It Is Not Sufficient.

Security teams naturally begin with authentication.

That is appropriate.

Agents should not depend on unmanaged shared credentials or hard-coded API keys. Strong workload identity, short-lived credentials and precise authorization are important patterns.

But successful authentication only answers:

“Was this actor allowed to authenticate?”

It does not fully answer:

“Was this action appropriate for the delegated business objective?”

Agentic systems therefore push identity closer to behavioral and transactional governance.

The New Separation of Duties Problem

Traditional IAM asks whether a person has incompatible access.

Agentic systems create another question:

Can an agent combine individually legitimate capabilities into an outcome no human user would have been permitted to perform directly?

For example:

Read supplier master.

Modify bank details.

Create payment.

Approve transaction.

Each tool call may be authorized.

The combined authority may be unacceptable.

That is why agent architecture must consider chains of action, not just isolated permissions.

What CISOs Should Require Before Agents Reach Production

Distinct identity

Know the agent separately from the human or workload behind it.

Explicit ownership

Establish both technical and business accountability.

Scoped authority

Give the agent only the tools and actions required.

Delegation context

Preserve who or what authorized the activity.

Short-lived access

Reduce dependence on persistent credentials where architecture permits.

Observable actions

Make the agent's activity attributable and reconstructable.

Lifecycle controls

Creation, approval, change, suspension and retirement should be governed.

Kill capability

Security and business owners need a reliable way to revoke the agent's authority.

The Market Is Already Moving

The Black Hat USA 2026 sponsor landscape shows identity vendors explicitly converging on agent governance.

Established identity platforms are extending governance across humans, NHIs and AI access.

NHI vendors are adding agent discovery, identity, ownership, behavior and lifecycle.

New vendors are appearing with agent-specific identity, authorization and control-plane approaches.

This is not evidence that every enterprise needs another product.

It is evidence that agent identity is becoming an architectural domain that CISOs need to address now.

What Not to Do

Do not create one shared “AI service account.”

Do not automatically give agents the permissions of their creators.

Do not assume an API gateway is an identity-governance strategy.

Do not store broad static credentials simply because an agent needs convenient access.

Do not allow the AI team to invent an independent identity architecture.

And do not wait until hundreds of agents are deployed before defining ownership.

AVIKORE Executive Takeaway

Agentic identity is not primarily an authentication problem.

It is a delegated-authority problem.

The enterprise needs to know:

Who is acting?

What authority do they have?

Who delegated it?

What were they authorized to accomplish?

Who is accountable for the outcome?

Organizations that answer those questions early can adopt agents faster because security architecture becomes an enabler rather than an emergency control added later.

What to understand next

• The underlying definition — what agentic identity is, and why an agent is technically a non-human identity but a distinct governance class: What Is Agentic Identity?
• Where agentic sits in the wider shift from identity to authority: Human → Non-Human → Agentic

Leadership Discussion Questions

• Do we know which AI agents currently access enterprise systems?
• Does every production agent have a distinct identity?
• Can we preserve delegated user/application context?
• Can we reconstruct an agent's actions across systems?
• Can we revoke one agent without disrupting unrelated users or services?
• Who owns agent authorization policy: IAM, AI governance, application teams—or all three?