AI Agent Identity: How Enterprises Authenticate and Authorize Non-Human Actors

Every agent deployment eventually hits the same wall: the identity stack was built for humans and for service accounts, and an agent is neither. A human authenticates interactively, proves a second factor, and holds a session that expires. A service account holds a long-lived credential, does one narrow job, and answers to no particular person. An agent inherits the weaknesses of both. It acts on behalf of a specific human, so its permissions should never exceed that person's, yet it runs unattended and cannot answer a second-factor challenge. It touches many systems across a single task, so a narrow static credential does not fit, yet it is the actor most dangerous to over-permission. The first production incident in most agent programs is not a bad model output. It is an agent doing something entirely permitted by its credential and entirely outside what anyone intended to authorize. This guide covers why the existing primitives break, the delegation patterns replacing them, how to scope authorization so blast radius is bounded by design, what an audit trail has to capture, and the rollout sequence.

Key Takeaways

• API keys and OAuth service accounts fail for agents on four properties: over-scoped for any single task, long-lived rather than task-bound, unattributable to the human who triggered the work, and slow to revoke. Each is tolerable for a background job and compounding for an actor that decides its own next step.
• An agent credential has to carry three facts at once: which agent is acting, which human delegated the authority, and which task it belongs to. Traditional credentials carry the first inconsistently and the others not at all, which is why attribution collapses the moment an agent surprises someone.
• The authorization rule that holds up is an intersection: only what the human principal may do, only what the agent is provisioned for, and only what the current task requires. Most incidents trace to implementations enforcing one bound and skipping the other two.
• Budget and blast-radius limits belong in the authorization layer, not the prompt. Spend caps, rate limits, row-count ceilings, and hard stops on irreversible actions hold only outside the model, because anything inside the context window is subject to the model's judgment and to prompt injection.
• Roll this out before scale. Non-human identities already outnumber human ones in most enterprises, and agents accelerate that curve. Retrofitting delegation and attribution onto a sprawling estate of static keys is far harder than establishing the pattern while the agent count is still countable.

Why the Existing Identity Stack Does Not Fit

The identity infrastructure most enterprises run was designed around two actor types, and agents match neither.

Human identity assumes interactivity. The person is present, can be challenged for a second factor, and holds a session renewed by the same interactive path. Every strong control in the human stack, step-up authentication, device posture, risk-based challenges, depends on somebody being there to respond. An agent running a scheduled task at three in the morning cannot answer a push notification.

Service account identity assumes narrowness and permanence. A batch job holds a credential, does one predictable thing on a schedule, and its permissions can be tightened until they exactly fit, because the job does not change. The credential lives for years, acceptable precisely because the scope is tiny and the behavior deterministic.

An agent breaks both models at once. It is non-interactive like a service account but acts with the authority of a specific human like a session. Its scope is broad because it decides what to do next rather than executing a fixed script, and broad scope is what makes a long-lived credential dangerous. The properties that make agents useful, described in what agentic AI actually is, are the properties that make the old credential models unsafe. Four failure modes follow, each with a different fix.

Over-scoping. An agent that might need to read a warehouse, file a ticket, and send an email gets one credential covering all three permanently, because per-task provisioning was never a supported workflow. A prompt injection or a reasoning error then operates against everything the agent might ever do.

Long lifetime. A static key rotated rarely is a standing invitation, and its value to an attacker scales with how long it stays valid and how much it reaches. It also ends up in more places than intended: a config store, an environment variable, a log line.

Unattributability. The most consequential failure and the least discussed. When an agent acting under a shared service credential performs an action, the audit log records the service account, not which human asked, which task it belonged to, or which agent instance was running. The investigation opens with no way to answer who authorized this.

Slow revocation. Cutting off a compromised static key means finding every system that trusts it, rotating it, and redeploying whatever holds it: hours of work during an incident, while the credential stays live and a looping agent keeps going.

What an Agent Credential Has to Carry

The fix begins with a modeling decision, not a tool selection. An agent action has three participants, and the credential must make all three explicit.

The agent identity. Which agent, and which running instance, is acting. Not the application, not the deployment, the specific actor. This is what allows revoking one misbehaving agent without disabling the fleet.

The delegating principal. Which human, or which system acting for a human, granted the authority. This field makes the intersection rule enforceable and the audit trail meaningful. An agent with no principal is a service account in costume, and deserves service-account narrowness.

The task context. Which unit of work the action belongs to, with enough identity to correlate every downstream call back to one originating request. This lets an investigator reconstruct a sequence rather than read disconnected log lines, and lets a budget cap bind a task rather than a month.

Traditional credentials carry the first inconsistently and the others not at all. Every pattern below is a way of closing that gap.

The Credential Patterns Replacing Static Keys

Four patterns dominate, and they combine rather than compete: workload identity establishes what the agent is, delegation tokens establish whom it acts for, per-task scoping bounds the current unit of work.

Workload identity federation. The agent's runtime proves its identity to a trusted issuer using a platform-attested signal rather than a stored secret, receiving a short-lived token in exchange. The open standard is SPIFFE, which defines a workload identity document and an issuance framework; every major cloud provider ships an equivalent for its own compute. What matters is eliminating the static secret: there is no key to leak, because the credential is minted on demand from an attestation the platform vouches for and expires in minutes.

Scoped delegation tokens. The agent exchanges a token representing the human's authority for a narrower token representing what it may do on that human's behalf. OAuth 2.0 Token Exchange, specified in RFC 8693, is the standardized mechanism, and the on-behalf-of flows in major identity platforms implement the same shape. The resulting token names both agent and principal, preserving attribution downstream, and scope is reduced at exchange time rather than inherited wholesale.

On-behalf-of chains. When an agent calls another agent or a downstream service that must act with the same authority, each hop performs another exchange rather than forwarding the original token, so the delegation path is preserved in the token. This prevents the confused deputy problem, where a downstream service performs a privileged action because it trusts the caller without knowing on whose authority the request was ultimately made. Interoperability across these hops is what the agent protocol standards are competing to define, as covered in the agent protocol land grab.

Per-task credentials. Minted for one unit of work, scoped to the resources that task requires, expiring when the task ends. Strongest posture, most work, because it requires knowing in advance what a task needs, which is uncomfortable when the point of an agent is deciding dynamically. The practical compromise is a task credential scoped to a declared resource set, with escalation requiring a fresh authorization decision.

The column most organizations underweight is attribution. Lifetime and revocation get attention because they map onto familiar security instincts. Attribution determines whether an incident is investigable at all, and it is the one property that cannot be retrofitted, because the information was never captured in the first place.

Authorization: The Intersection Rule

Authentication establishes who is acting. Authorization is harder, and for agents it has a shape that differs from both human and service-account authorization.

The rule that holds up is an intersection of three bounds. An agent may do only what its delegating principal may do, so an agent acting for a support representative cannot reach data that representative could not open directly. Only what the agent itself is provisioned for, so a ticket-triage agent cannot issue refunds even when acting for someone who can. And only what the current task requires, so an agent summarizing one account cannot enumerate every account.

Most incidents trace to implementations that enforce one bound and skip the others. Enforcing only the principal bound produces an agent that can do everything a senior administrator can, which is a catastrophic amount. Enforcing only the agent bound severs the connection to the human and lets a low-privilege user trigger high-privilege work. Enforcing only the task bound is the shortcut where scope lives in the prompt rather than the token, which is not enforcement at all.

That last point is the most frequent architectural error in early deployments. Constraints written into a system prompt are guidance, not controls. The model may follow them, and may also be argued out of them by content in a document, a web page, a ticket, or a tool response. Prompt injection is not exotic, it is the expected condition for any agent reading untrusted input. An instruction never to delete records is a preference. A credential lacking delete permission is a control.

Two categories of limit belong in the authorization layer precisely because they cannot be trusted to the model.

Budget caps. Token spend, tool invocations, and downstream API calls, bounded per task and per principal, enforced by whatever mints and validates the credential. An agent in a reasoning loop otherwise consumes until something stops it, and that something should be a policy, not a monthly invoice.

Blast-radius caps. Row counts on bulk writes, rate limits on outbound communication, hard denials on irreversible operations, required human confirmation above a consequence threshold. The design question is not whether an agent will act wrongly, it is what the worst single sequence accomplishes before something external halts it. That number is a design output, not an aspiration.

Where an organization sits on this progression, from prompt-level guidance toward enforced policy, is among the clearest signals of genuine agent readiness, and maps onto the stages in the agent readiness maturity model.

Audit and Attribution

An agent audit trail has a higher bar than a human one: volume is higher, actions are faster, and the reasoning behind an action is not observable from the action alone.

Four things have to be captured per action. The first three are the identity triple already described. The fourth is the authorization decision itself: which policy permitted this, and what scope the credential carried at the call. Recording that an action happened without recording why it was allowed leaves an investigator unable to distinguish a policy gap from a policy bypass, which are different problems with different fixes.

Two further practices separate trails that support investigation from trails that merely accumulate.

Correlate across systems. The task identifier has to survive every hop, including calls into third-party services and between agents. A trail confined to one application boundary answers almost nothing, because the interesting agent failures are cross-system by nature.

Retain tool inputs and outputs, not only the calls. Knowing an agent called a search tool is nearly useless. Knowing what it searched for and what came back is what reveals a prompt injection delivered through a document, and it is the difference between a trail that explains an incident and one that timestamps it.

Governance matters as much as plumbing. An agent with no registered owner and no recorded purpose is the non-human equivalent of the unsanctioned usage covered in shadow AI governance, and it arrives the same way: a team builds something useful, it works, and nobody outside that team knows it exists until it does something surprising. The register tracking sanctioned AI usage and the register tracking agent identities should be the same register.

Where the Vendors Are

Three groups are converging from different directions, and the decision depends more on where an organization already sits than on features.

Identity incumbents. Established identity platforms extending into non-human identity: agent-specific token exchange, lifecycle management for machine credentials, and governance surfaces treating non-human identities as first-class objects rather than directory afterthoughts. The advantage is integration with the policy engine, directory, and audit pipeline already in place. The limitation is pace, since agent requirements move faster than enterprise identity roadmaps.

Non-human identity specialists. Newer vendors focused on discovering, inventorying, and governing machine credentials: finding static keys already scattered across an environment, mapping what they reach, driving them toward short-lived alternatives. Discovery is the genuinely valuable function, because most organizations cannot say how many non-human identities they have or what those identities can access.

Agent platform native. Frameworks building identity into the runtime, so credentials are minted per task by the layer that runs the agent. Integration is tightest and developer experience best; the trade-off is identity coupled to a platform choice that may not survive the next architectural decision.

The pattern from every previous identity wave applies: specialists win early because they solve the acute problem faster, incumbents absorb the capability over the following cycle. Use specialist discovery to find what exists now, while standardizing new agent work on what the incumbent platform supports, so the estate does not fragment.

A Rollout Sequence

The ordering inverts the instinct deliberately. Attribution comes first because it is cheap, requires no architectural change, and immediately makes the estate investigable. Credential replacement is expensive and slow, and doing it first spends the budget while still unable to answer who did what. Blast-radius bounds sit third because they limit damage during the long stretch when most credentials are still wrong.

Where These Programs Break

Scope in the prompt rather than the token. The most common error. If the only thing preventing an agent from deleting production data is a sentence asking it not to, there is no control.

One shared identity for a fleet. Convenient, and it destroys both attribution and selective revocation. When one agent misbehaves, the only response is disabling every agent sharing the identity.

Principal identity dropped at the first hop. The agent authenticates the human correctly, then calls downstream services with its own service credential. Attribution survives exactly one hop, usually the one before the action that matters.

Human-in-the-loop that is really a notification. An approval arriving as a message the reviewer cannot practically evaluate, at a volume guaranteeing reflexive approval, is logging in the costume of a control. If approvals exceed the rate a human can genuinely assess, the threshold is wrong.

Revocation never tested. The ability to kill one agent's authority in seconds is assumed rather than exercised. An incident is the wrong moment to learn that revoking a credential requires a redeploy.

Frequently Asked Questions

Why can an AI agent not just use an API key?

Because an API key fails on four properties that matter more for agents than for scripts. It is scoped to everything the agent might ever need rather than what the task requires, it outlives any single task, it records no connection to the human who triggered the work, and it is slow to revoke. A deterministic batch job tolerates all four. An actor that decides its own next step does not.

What is non-human identity management?

It is the discipline of treating machine actors, service accounts, workloads, and now AI agents, as first-class identities with owners, lifecycles, scoped permissions, and audit trails rather than configuration details. It matters now because non-human identities already outnumber human ones in most enterprises and agents accelerate that growth, while the governance applied to them stays far weaker than any employee account receives.

How should an agent's permissions relate to the user's?

Through an intersection rather than inheritance: only what the delegating human can do, only what the agent itself is provisioned for, and only what the current task requires. Inheriting the human's full permissions is the common shortcut, and the one that turns a single prompt injection into an incident scoped to everything that person could reach.

Can prompt instructions be used to limit what an agent does?

They guide behavior and cannot enforce it. Any instruction inside the context window is subject to the model's judgment and to injection through documents, web pages, tool responses, and tickets the agent reads. Limits that must hold, spend caps, write ceilings, denial of irreversible operations, belong in the credential and the authorization layer, where the model cannot reason its way past them.

What should an agent audit log capture?

Four things per action: which agent instance acted, which human delegated the authority, which task it belongs to, and which policy permitted it at what scope. Retain tool inputs and outputs alongside the calls, since that is where evidence of prompt injection appears. The task identifier must survive every hop, including agent-to-agent calls, or the trail reconstructs only a fragment.

The Bottom Line

Agent identity is not a new category of security problem. It is the delegation problem, which distributed systems have worked on for decades, arriving at a scale and speed enterprise tooling was not built for. The mechanisms exist: token exchange is standardized, workload identity is mature, short-lived credentials are well understood. What is missing is the modeling decision to treat an agent as an actor with a principal rather than an application with a key.

The sequencing is the practical part. Attribution first, because it is cheap and makes everything else investigable. Blast-radius bounds second, because they limit damage while most credentials are still wrong. Credential replacement third, spent on the highest-reach identities rather than uniformly.

The alternative is the path most enterprises are on: agents shipped with static keys because that was the fastest way to make the demo work, accumulating into an estate nobody has inventoried, until an incident arrives and the investigation opens with the discovery that the audit log says a service account did it.