AI Agent Identity: Who Is Actually Making the API Call?
An agent acting for a user isn't the same as the user. A real architectural look at agent identity, delegation, OAuth, least privilege, and zero trust.
A user types one sentence to their AI agent: "Send this report to the customer." Five words. But underneath that sentence, a real question has to get answered before anything happens: when the API call actually fires, who is the caller?
Is it the user, because the agent is just carrying out their instruction? Is it the agent, because the agent is the thing that actually authenticated to the API, built the request, and called it? The honest answer is that most production systems today never decided this on purpose. They defaulted to "the agent runs as the user" because it was the fastest way to ship, and that default is exactly why an over-broad, prompt-injected, or simply buggy agent can do far more damage than the same mistake made by a human ever could.
The one sentence to remember
An agent acting on behalf of a user is not the same thing as the agent acting as the user. Collapsing that distinction is the single most common mistake in agentic system design, and almost every failure mode in this article traces back to it.
This is an architectural investigation of agent identity: what changes when the caller behind an API request stops being a human at a keyboard, how authentication, authorization, delegation, and audit have to be rebuilt for a principal that can act autonomously, and the practical model that keeps an agent's permissions from quietly becoming a blank check.
Traditional vs Agentic: Where the Model Actually Changes
The application used to be a passive pipe. Now it's a second principal
A traditional application doesn't decide anything on its own; it's a conduit for a human's own choices, one click at a time. An AI agent decides things, chooses which API to call, and does it without a human confirming each step. That makes the agent a real actor in the system, with its own identity, not an invisible extension of the user's. Skipping that step is what makes the rest of this article necessary.
Who Is the Caller? A Concrete Example
Walk the "send this report to the customer" request through the architecture properly, and the branch point becomes obvious.
Why this can't collapse to a single identity
If the system only checks the user's permissions, a compromised or manipulated agent inherits everything that user is allowed to do, including actions the user never actually asked for in this session. If the system only checks the agent's permissions, a shared, powerful service credential lets the agent act far beyond what any individual user should be able to trigger through it. The correct answer checks both, deliberately, every time.
User Identity vs Agent Identity
This is the actual key question underneath everything else in this article: should an agent act as the user, or as its own, distinct security principal that happens to be acting for the user?
OAuth 2.0 Token Exchange, RFC 8693, already answers this precisely, because delegation was a solved problem in enterprise identity long before agents existed. It defines two different patterns, and they are not interchangeable:
| Impersonation | Delegation | |
|---|---|---|
| What the token says | The bearer is given all of the user's rights and is indistinguishable from the user within that context | The user remains the subject (sub); the agent appears separately as the actor (act) |
| Can you tell who really acted? | No. An impersonation token carries no marker that it resulted from impersonation at all | Yes. Every downstream system sees both the user and the specific agent that acted for them |
| Blast radius if the agent is compromised | Full: the agent can do anything the user could do, with no way to distinguish agent actions from the user's own | Bounded: limited to whatever authority was actually delegated, and clearly attributable to the agent |
Impersonation quietly destroys the rest of this article
Every later section, least privilege, auditability, non-repudiation, zero trust, depends on the system being able to tell the difference between "the user did this" and "the agent did this on the user's behalf." An impersonation-style token where the agent simply becomes the user makes that distinction technically impossible to recover after the fact, no matter how good your logging is.
The correct architectural answer: an agent should hold its own identity, connected to the user through an explicit delegation, not disappear into the user's.
Authentication: How Does an Agent Prove Who It Is?
A human authenticates with something they know, have, or are. An agent has none of those in the traditional sense, so agent authentication has converged on a different set of mechanisms:
A stable, first-class agent identity object
Microsoft's Entra Agent ID, generally available in 2026, gives each agent its own object ID and application ID in the identity directory, the same way a human employee or a service has one, rather than treating the agent as an anonymous extension of whoever built it.
Federated identity, not a stored password
Modern agent authentication increasingly avoids long-lived secrets entirely. Entra Agent ID authenticates agents via Federated Identity Credentials, no password to leak in the first place.
Workload identity federation for API access
Anthropic's own API supports exactly this pattern: an agent's runtime environment presents a JWT identity token, the SDK exchanges it for a short-lived access token at a dedicated endpoint, and that access token auto-refreshes. There's no static API key sitting in an environment variable waiting to be exfiltrated.
The common thread
Every credible approach to agent authentication in 2026 is converging on the same idea: give the agent a real, first-class identity, and prove that identity through federation and short-lived tokens rather than a static secret it has to hold and protect indefinitely.
Authorization: What Is the Agent Actually Allowed to Do?
Authentication answers "who is this." Authorization answers a completely separate question: "what is this specific identity allowed to do, right now, for this specific action." Conflating the two is how an agent that's correctly authenticated ends up doing something it was never actually supposed to be able to do.
An agent's authorization should be expressed as its own scoped permission set, not simply inherited wholesale from whichever user happens to be talking to it in a given session. A support agent authenticated to read tickets shouldn't automatically be authorized to close them, refund a customer, or export the whole database, even if the logged-in user could technically do all three themselves through the regular UI.
Delegated Authority and OAuth for AI Agents
Delegation is what actually connects the two identities from earlier without collapsing them into one. RFC 8693's token exchange mechanism provides the concrete plumbing:
The may_act claim authorizes the delegation itself
A token can carry a may_act claim that explicitly states which other party is allowed to act on the subject's behalf. The authorization server checks this before ever issuing a delegated token, so delegation isn't just assumed, it's granted.
The act claim records who actually did the acting
Once delegation is authorized, the resulting token keeps the user as the subject and adds the agent as the actor, so every downstream system can see both without ambiguity.
Delegation chains are now a standards-track problem, not an improvisation
The IETF OAuth working group's identity chaining draft extends token exchange specifically for multi-hop agentic delegation, one agent calling another, each hop recorded rather than flattened into a single anonymous "the system did it."
A critical rule for anyone consuming these tokens
Per RFC 8693, a consumer of a token should only make access-control decisions based on the top-level claims and the current actor. Earlier actors in a nested delegation chain are informational, useful for audit, not something to grant additional access based on. Don't accidentally build a system where being three hops deep in a delegation chain quietly grants more trust, not less.
This is what "OAuth for AI agents" actually means in practice: not a special new protocol, but token exchange, actor claims, and now standardized delegation chaining, applied deliberately to a principal that happens to be an agent instead of a human.
Service Accounts, Short-Lived Credentials, and Least Privilege
Why a Permanent, High-Privilege Service Account Is Dangerous
The fastest way to get an agent working is to hand it one powerful, permanent credential and let it do everything through that. It's also the architecture behind some of the worst agent security incidents on record. In 2026, researcher Aonan Guan's "Comment and Control" disclosure showed exactly this failure mode: AI coding agents connected to CI/CD pipelines with standing access to secrets were tricked, through nothing more than a malicious pull request title or issue comment, into leaking those very credentials. The credential didn't need to be stolen through some separate exploit. It was simply sitting there, permanently available to an agent that could be talked into misusing it.
Short-Lived Credentials Done Right
The fix isn't a smarter agent. It's a credential that expires before a compromise can do much with it. The same workload identity federation pattern from the authentication section applies directly here: exchange a short-lived identity token for an even shorter-lived access token, on every use, rather than issuing one credential the agent holds indefinitely. A leaked token that expires in minutes bounds the damage in a way a permanent service account never can.
Least Privilege in Practice
Scope to the task, not the role
Don't ask "what permissions does an agent like this generally need." Ask "what does this specific task actually require." An agent drafting a report needs read access to the data behind it. It doesn't need write access to the customer database just because some other task it occasionally performs happens to need that. Separate credentials, or separately scoped delegated tokens, per task category, not one broad grant covering everything the agent might ever do.
User Impersonation vs Delegation, Revisited
It's worth stating the practical consequence of the earlier distinction directly: if your agent architecture lets an agent simply act as the logged-in user with no separate identity of its own, you have already lost the ability to answer "did the user do this, or did the agent do this while the user wasn't even looking." That's not a hypothetical gap. It's the exact condition prompt injection and agent hijacking attacks rely on, an agent taking an action that looks, to every downstream system, exactly like the user chose to take it. For the mechanics of how an attacker actually gets an agent to that point, see Prompt Injection and Agent Hijacking.
Agent-to-Agent Identity
Once one agent can delegate a sub-task to another, covered architecturally in AI Agents Are Not Chatbots, the identity question just multiplies. Agent A isn't a user, so what does it mean for Agent A to authenticate Agent B?
The same delegation chaining mechanism applies recursively. Agent A holds a delegated token identifying the original user as subject and itself as actor. When Agent A calls Agent B, the chain extends: Agent B receives a token identifying the original user as subject, with an actor chain now showing both Agent A and Agent B, not a token that's quietly been laundered back down to looking like the plain user again.
Don't let sub-agent delegation become impersonation by accident
A sub-agent that receives a fresh, unscoped credential from its parent agent, rather than a properly chained, narrowed delegation, recreates the exact impersonation problem from earlier, just one level deeper and harder to trace.
MCP Authorization and Tool-Level Permissions
MCP's own authorization model, covered in depth in MCP Explained, is built on OAuth 2.1: a remote server acts as a resource server validating tokens issued by a separate authorization server. Identity industry players are now converging on this same surface directly. Okta's Cross App Access, generally available in August 2026, is a vendor-neutral extension for letting identity follow an agent across applications, and its adoption into the MCP authorization specification means agent identity for tool access is becoming a shared pattern, not a one-off integration per vendor.
Authenticated to the server does not mean authorized for every tool on it
A connected, authenticated client can typically see every tool an MCP server advertises. That is not the same as that client being authorized to actually invoke every one of them. An agent authenticated to a finance server for the purpose of reading invoice status should not automatically be able to call that same server's issue_refund tool just because both tools live behind the same connection. Authorization needs to be enforced per tool, not once at the connection level and assumed from then on.
Context-Based Authorization
A yes/no answer based on identity alone is often not enough. A more complete authorization decision considers the whole context together: who the user is, which agent is acting, what resource is being touched, what action is being requested, and the surrounding circumstances, time of day, transaction size, whether this exact action was performed moments ago.
| Factor | Example question it answers |
|---|---|
| User | Does this user have the underlying right to have this happen at all? |
| Agent | Is this specific agent identity authorized to perform this category of action? |
| Resource | Is this particular record, account, or system within scope for this request? |
| Action | Is this a read, a write, or something irreversible, and does that change the answer? |
| Context | Does the amount, frequency, or timing of this request look like the normal pattern, or an anomaly worth stopping for? |
A policy engine that evaluates all five together catches cases a simple role check never would, an agent with the right role technically, requesting something that's individually plausible but collectively suspicious.
Human Approval
Identity and authorization decide whether an action is permitted. Human approval is a deliberate, additional gate on top of that for actions where being permitted still isn't sufficient on its own, covered in detail in AI Agents Are Not Chatbots. From an identity standpoint, the important detail is that approval itself should be logged as its own event, tied to the specific human who granted it, feeding directly into the audit trail below rather than existing as an invisible UI click nobody can reconstruct later.
Auditability and Non-Repudiation
The question every audit log needs to answer, completely
Who requested this. Who, or what policy, authorized it. Which specific agent identity actually performed it. What API or tool was called, with what parameters. If any one of those four is missing, you don't actually have an audit trail, you have a log line.
This is precisely why the delegation model from earlier matters so much in practice. A token carrying both a sub (the requesting user) and an act (the specific agent that acted) gives every downstream system enough information to answer all four questions without guessing. Non-repudiation, the ability to prove which identity actually performed a given action, is a direct consequence of maintaining that distinction consistently, from the first delegation all the way through to the resource that finally got touched.
Credential Delegation and the Agent Identity Lifecycle
Delegating authority safely is only half the problem; the other half is managing the agent identity itself over time, the same way any enterprise identity gets managed.
Creation
An agent identity should be explicitly provisioned, with a defined owner and a defined scope of intended use, the same rigor applied to provisioning a new service account, not spun up implicitly the first time some code happens to call an API.
Rotation
Credentials tied to that identity should rotate on a schedule, or better, be short-lived enough that rotation is continuous rather than a periodic manual task someone has to remember to do.
Suspension
It should be possible to immediately suspend an agent identity's ability to act, independent of revoking the underlying user's own access, the moment something looks wrong with that specific agent.
Revocation
When an agent is retired, its identity and every credential tied to it should be revoked outright, not simply left dormant with standing permissions nobody remembers to clean up.
Compromised Agent: Blast Radius and Response
When an agent's credentials or its context gets compromised, whether through leaked secrets, prompt injection, or a poisoned tool description as covered in Prompt Injection and Agent Hijacking, the entire identity model from this article determines how bad that gets.
This is where every earlier section either pays off or doesn't
With a scoped, short-lived, properly delegated agent identity, a compromise is contained: limited permissions, a short window before the credential expires, a clear audit trail showing exactly which agent identity was affected and what it touched during that window. With a shared, permanent, high-privilege service account and no meaningful distinction between user and agent identity, a compromise is total, indistinguishable from a legitimate user action, and nearly impossible to fully scope after the fact.
The immediate response to a suspected compromise should be the suspension step from the lifecycle above, cutting off that specific agent identity's ability to act, without needing to lock out the human user it was acting for.
Zero-Trust Agents
The last principle ties every preceding one together: never grant an agent trust simply because it's already running inside your infrastructure. An agent that sits on an internal network, or holds a valid session, is not automatically safe to trust with the next action it requests.
Verify per call, not per connection
Authorization should be evaluated for each individual action an agent requests, not granted once at connection time and assumed valid for everything that follows in that session.
Network location proves nothing about intent
An agent running inside your VPC that's been hijacked through a poisoned document is still inside your VPC. Location-based trust doesn't detect that, and shouldn't be the thing standing between an attacker and a real action.
Assume any given request could be the compromised one
Zero trust for agents means the context-based authorization, least privilege, and human approval mechanisms from earlier apply to every request, not just the ones that happen to look unusual.
The Architectural Transition
Put the whole model together, and the shift from a traditional application to a properly identity-aware agentic one looks like this:
The traditional pipeline, user, login, application, API, only ever had to answer one identity question, once, at the start. The agentic pipeline has to answer it continuously, at every single action, because the thing making the call can now decide to make a call the user never explicitly reviewed.
A Practical Secure Agent Identity Model
The test to run against your own system
Pick any action your agent can currently take. Ask: is this attributable to a specific agent identity distinct from the user, scoped to only what this task needs, time-bounded by a short-lived credential, and logged clearly enough to answer who requested it, who authorized it, and what was actually called? If the honest answer is no on any point, that's not a future hardening task. That's the actual security model of your system today.
The Bottom Line
An AI agent acting on behalf of a user is not the same thing as that agent inheriting everything the user is allowed to do, and every architecture in this article that gets agent identity right treats that as the starting assumption, not an edge case to handle later. Delegation, not impersonation. An agent identity distinct from the user's, short-lived and narrowly scoped, not a permanent, powerful service account inherited by default. Authorization evaluated on user, agent, resource, action, and context together, at every call, not granted once and trusted forever because the request came from somewhere inside the network.
The question that opened this article, who is actually making the API call, should have an answer your system can produce automatically, for any action, at any time. If it can't, that's the identity problem worth fixing before the agent gets any more capable than it already is.
For the hands-on version of turning "scope to the task, not the role" into an actual tool layer, one function per capability, tiered by blast radius, against a real API, see How to Give AI Agents Access to APIs Without Giving Them Too Much Power.
Written by
Chetan Yamger
Cloud Engineer · AI Automation Architect · Modern Workplace Consultant
Cloud Engineer, AI Automation Architect, and Modern Workplace Consultant based in Amsterdam, Netherlands. Specializing in scalable, secure enterprise solutions with Microsoft Azure, Intune, PowerShell, and AI-driven automation using ChatGPT, Gemini, and modern LLM technologies.
Stay in the loop.
New articles, straight to you.
Deep-dive technical articles on Intune, PowerShell, and AI — no noise, no spam.
Discussion
Share your thoughts — your email stays private
Leave a comment