Imagine asking an AI procurement agent to “handle this vendor renewal.”
It reads the vendor contract. Checks the supplier’s performance history. Reviews pricing. Determines whether the renewal falls within predefined parameters. Updates the procurement system. And sends an approval request.
The agent hasn’t simply answered a question.
It has interpreted a request, accessed enterprise information, selected tools, made decisions, and taken action.
That creates a question enterprises are only beginning to confront:
If an AI agent can act like an employee, who or what is it inside your enterprise?
For decades, enterprise identity and access management has been built around people, applications, and service accounts. Agentic AI introduces a different type of actor: software that can operate with increasing autonomy across enterprise systems and workflows.
And that changes the identity problem.
From Software to Enterprise Actor
Traditional applications generally execute predefined logic. Service accounts allow software to authenticate and access the resources required to perform that logic.
AI agents can behave differently.
An agent can interpret context, determine what information it needs, select which tools to use, and execute different sequences of actions depending on what it encounters.
The greater the autonomy, the less useful it becomes to think of an agent as simply another application with a credential.
Instead, enterprises need to establish a distinct identity model for these non-human actors.
That identity needs to answer more than:
“Who are you?”
It also needs to answer:
- Who created or authorized you?
- Who are you acting on behalf of?
- What task are you performing?
- What systems can you access?
- What actions are you allowed to take?
- Which actions require human approval?
- Can your actions be traced afterward?
These are not simply security questions. They are enterprise architecture questions.
Why a Service Account Isn’t Enough
A natural response is to give the agent a service account and assign the permissions it needs.
But that approach can hide a deeper problem.
Consider the procurement agent again. It may need access to contracts, vendor records, an ERP system, and payment-related workflows.
The question shouldn’t simply be:
“Does this agent need access to the ERP?”
It should be:
“What exact actions does this agent need to perform, under what conditions, and with what level of authority?”
An agent that can read a contract may not need permission to modify it.
An agent that can prepare a payment may not need permission to approve or execute that payment.
This is where least privilege becomes critical.
The objective isn’t just to authenticate an AI agent. It is to constrain what that identity is allowed to do.
The Agent Identity Stack
A practical identity architecture for AI agents needs several layers.
1. Identity
Every agent should have a distinct and attributable identity.
Shared credentials make it difficult to determine which agent performed an action and make access revocation more complicated.
2. Authorization
Authentication answers:
“Who is this?”
Authorization answers:
“What is this agent allowed to do?”
Agent permissions should be explicitly defined according to its business responsibility.
3. Least Privilege
Agents should receive only the access required for the task they are performing.
Higher-risk actions should have stronger controls and, where appropriate, require human approval.
4. Delegation
An enterprise needs to preserve the relationship between the person or business process initiating work and the agent executing it.
The architecture should make it possible to understand:
Human / Business Process → Agent → Authorized Action
The agent may be executing the work, but the organization still needs to understand where that authority came from.
5. Auditability
Every meaningful action should be attributable to the agent that performed it.
A useful audit chain is:
Request → Agent → Decision → Tool → Action → Result
Without this chain, an organization may know that something changed without knowing why, how, or which agent caused it.
6. Lifecycle Management
Agent identities need a lifecycle just like other enterprise identities.
Agents may be created for a specific workflow, modified as responsibilities change, temporarily suspended, or eventually retired.
Their permissions need to evolve with them.
The Accountability Problem
Identity ultimately becomes more than an access-control mechanism.
It becomes part of the accountability model for autonomous systems.
Imagine discovering six months later that an incorrect procurement record was created.
If the audit trail only identifies a generic service account, the organization may know which credential was used but not which agent, request, authorization, or decision led to the action.
A stronger architecture should allow the organization to reconstruct the chain:
Who requested it?
Which agent acted?
What was it authorized to do?
Which tools did it use?
What action did it take?
What was the outcome?
This becomes increasingly important as agents move from isolated experiments into real enterprise workflows.
Seven Questions Before Giving an Agent Production Access
Before an AI agent receives meaningful access to enterprise systems, leaders should be able to answer seven questions:
1. Who is the agent?
Does it have a unique, attributable identity?
2. Who authorized it?
Can its authority be traced to a human, role, or business process?
3. What can it access?
Are its permissions explicitly defined?
4. What can it do autonomously?
Which actions require human approval?
5. Under what conditions does its authority change?
Can access and permissions adapt to the task and risk?
6. Can its actions be reconstructed?
Can the organization trace its decisions and actions?
7. Can its access be revoked?
Can the agent be suspended or retired without leaving uncontrolled credentials behind?
The Future Enterprise Will Have Human and Non-Human Actors
Agentic AI is changing more than how software interacts with users.
It is changing who or rather what can act inside the enterprise.
The future enterprise won’t manage only employees and applications. It will increasingly manage a workforce of human and non-human actors.
That doesn’t mean AI agents should simply be treated like human employees.
It means they need an identity model appropriate to what they actually are: autonomous software actors with permissions, responsibilities, and the ability to take action.
The organizations that address identity early will be better positioned to scale agentic AI without allowing autonomy to become uncontrolled access.
Because the question is no longer simply whether your AI agents can act.
It’s whether your enterprise knows exactly who they are, what they are allowed to do, and who is accountable for what they do.