September 9, 2026
Giving an AI agent unrestricted use of an employee account might look like the pragmatic choice. The account is already authenticated, it already carries the right permissions, and the project can move without another lengthy security review. The problem surfaces the moment the agent starts to act, and the line between the person and the software disappears. The audit log records that an employee opened a file, amended a record, or approved a transaction, when in fact an agent did the work. Accountability becomes guesswork, and the agent quietly holds far more access than its task requires.
Giving each agent its own identity is the right correction, and it is the first of two. A distinct identity establishes which agent acted. It does not establish that an accountable human approved what the agent did. That second problem survives a well-run identity program, and it is the one that carries legal and financial consequence.
The 2026 Gartner® Hype Cycle™ for Digital Identity defines the category this way: “AI agent identity is the unique digital representation of AI agents within an organization. Establishing and governing identity for AI agents, including assistants and chatbots, enables identity and access management (IAM) systems to assign unique identifiers, issue targeted credentials for access to resources (e.g., APIs, data, and services), and establish clear human accountability and audit trails across enterprise systems.”
Unique identifiers, scoped credentials, and an audit trail that attributes actions to the right actor are all attribution properties. They establish which agent acted and under whose authority, which is a different question from whether a named person approved the action it took.
Borrowed Credentials and Service Account Security Create a Blind Spot
Early AI projects tend to run on whatever access is already to hand:
- An internal assistant may inherit excessive permissions unless its delegated access is explicitly restricted.
- A workflow routes through a shared service account.
- A developer wires an agent to an API with a long-lived key.
These arrangements create different risks: excessive access, ambiguous attribution, or persistent credentials. The agent may receive more permissions than its task requires. Human and agent activity may blur together where credentials are shared. Security teams may have no reliable way to know when an agent is running or which transactions it has completed.
This is why service account security has become an urgent problem rather than a housekeeping one. A shared service account was never designed to represent an autonomous actor making its own decisions at machine speed, and a static API key carries no information about who authorized the work or why.
Borrowed credentials also erode non-repudiation – a security feature that proves a specific person sent a message or made a transaction, and cannot later deny doing so. When a person and an agent share one identity, the organization cannot prove which of them performed a given action. According to the report: “The hazardous practice of deploying AI agents as proxies operating with human access credentials breaks auditing, traceability, and nonrepudiation requirements, significantly elevating the risk of overpermissioning, and the impact of credential compromise and account takeover.“
These are attribution failures, and a distinct identity is the right remedy for them.
What Does A Separate Identity Change?
A dedicated identity gives the agent its own record in the IAM environment, with a named owner, a defined purpose, and a deliberately narrow set of permissions approved on its behalf by that owner. It can be switched off without disrupting the employee or team behind it. AI agent authentication becomes a distinct event you can see and reason about, rather than something hidden inside a human session. The agent can be issued short-lived credentials rather than a standing password or API key. Its access can be confined to a specific application, task, or transaction. Its activity can be reviewed on its own terms, separate from any human’s.
Rebinding deserves particular care. Reassigning an agent to a different owner or principal is a change of identity rather than an update to a field, so it should require renewed verification of the human now taking responsibility. An ownership record that can be edited without re-establishing who agreed to carry the risk leaves the relationship open to dispute.
This is closer to how Zero Trust is meant to operate, where an earlier authentication is not treated as standing proof of anything. The agentic case extends that logic one step further. An earlier authentication is not proof that a person approved what happens next, either
Do AI Agents Need Standing Access?
Often, yes. Human access usually follows a job role, because responsibilities persist. Some agents work the same way. A reconciliation agent that runs every night, or a service agent working a continuous queue, needs continuing authority to be useful at all. Others need far less: pull one invoice, match it against a purchase order, return the result. Handing either kind an employee’s full permission set would be indefensible. Short-lived credentials help in both cases, though they reduce the window for misuse rather than closing it, and expiry does not in itself negate the underlying permission.
The report describes an adjacent innovation profile as follows: “Workload access management, which is a part of an overall machine IAM program, secures the exploding universe of workloads, which includes AI agents, applications, containers and microservices, by enforcing least-privilege access at runtime, replacing static credentials with dynamic, context-aware controls. Workload access management eliminates standing permissions, reduces machine-to-machine attack surfaces, and closes the critical blind spot undermining most zero trust strategies.”
We keep persistent permissions, and ask a different question of them. Not how long an agent holds authority, but who granted it. Each permission set should be approved by a named human, using evidence the agent could not have produced. An agent that can produce, replay, or satisfy that evidence can effectively approve itself.
Identity Alone Doesn’t Explain Intent
A separate identity establishes which agent is acting. It says nothing about what that agent is trying to achieve. The distinction matters as soon as an agent receives a broad instruction such as “organize my business travel” or “resolve this customer’s account issue.” The agent may interpret the request in ways the user never intended, and it can be steered off course through prompt injection or poisoned data.
Authentication and authorization pull apart here. AI agent authorization has to answer a question that a sign-in cannot: is this specific action within the bounds of what the person actually asked for?
The report describes a further innovation profile addressing exactly this: “Intent-based access control is an emerging authorization framework that replaces broad, standing permissions and is currently targeted at agentic AI, but offers broad applicability. Intent-based access control grants access to back-end resources based on the captured or inferred intent of users interacting with an agent and evaluates the agent’s intended actions against that intent.”
Inferred intent is a useful input to an access decision. It is not an approval. Intent captured from a conversation is still a description assembled inside the agent’s own context, so a misaligned or prompt-injected agent can shape it. Intent evaluation can narrow what an agent does within an authority somebody granted. Establishing that the authority was granted is a separate step. Three controls are each doing real work by this point, and each has the same limit:
- Verifying the human establishes who the person is. It does not establish what they agreed to.
- Inferring intent establishes what the request appeared to be. It does not establish that the person saw the action that resulted.
- Scoping access narrowly establishes what the agent may reach. It does not establish that this particular action was wanted.
What the highest-consequence actions need is a binding between three things: a verified person, the agent acting for them, and the specific action or permission that person approved. So the action should be held before it takes effect. The control layer, rather than the agent, should present what the action does and within what limits, and the decision should return out-of-band, directly to that control layer, through a channel the proposing agent does not mediate. We call the evidence released against that decision agent-resistant: the agent cannot generate it, replay it, or obtain it by recruiting a second agent on another device. iProov Dynamic Liveness supplies it, establishing a genuine human present at the point of approval and bound to the exact action. We have set out how that delegation should work in a separate piece on verified human authorization in agentic AI.
Start by Separating People From Agents, Then Prove the Approval
Agents should not be invisible extensions of an employee’s account. Give each one its own identity, assign an accountable owner, keep its permissions tight, track what it does, and remove its access when the work is finished. Treated properly, this is AI agent lifecycle management rather than a one-time configuration: agents get provisioned, reviewed, reassigned, and retired, and AI agent governance is what keeps that cycle honest as the number of agents grows.
Then decide which actions cannot proceed on delegated authority alone, because this is where stronger proof pays for itself. Organizations commonly confine agents to low-consequence work, not because the agent cannot do more, but because they cannot evidence human approval for anything higher. A proof of approval that no agent can satisfy lifts that ceiling. Payment initiation, payee changes, privileged role elevation, and changes to an agent’s own permissions can each be automated right up to the approval point and held there for ready for step-up authentication, then released against a receipt naming the approver, the action, the parameters they were shown, and a single-use validity period. The friction attaches to a handful of consequential moments, and the routine work in between runs uninterrupted.
Approval evidence cannot be reconstructed after the fact, so the link between a human decision and the action it authorizes has to be designed before agents are deployed. These steps ask for effort at the start of a project, and they head off a far larger problem later: thousands of autonomous agents operating through shared or inadequately governed credentials, taking consequential decisions that no identifiable person can be shown to have made.
Gartner, Hype Cycle for Digital Identity, 2026, Zachary Smith, Nayara Sangiorgio, 6 July 2026.
Gartner and Hype Cycle are a trademark of Gartner, Inc., and/or its affiliates.
Gartner does not endorse any company, vendor, product, or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.
Next in the series: why identity visibility matters so much once humans, machines, and AI agents are all reaching into the same environment.
