Give AI agents their own identity instead of borrowed user tokens

Three ways an agent can act

An agent that does work for a person can present one of three identities to the systems it calls. It can act as the user, by holding and replaying the user's own access or refresh token. It can act as itself, with a workload identity and permissions granted to that identity alone. Or it can act as itself on behalf of the user, carrying a token that names both parties. Use the third for anything a user asked the agent to do, the second for scheduled or system work that no user requested, and retire the first wherever your platform offers an alternative.

The vocabulary comes from OAuth token exchange. RFC 8693 describes impersonation as principal A receiving all of B's rights within some context and being indistinguishable from B there. Delegation is different: A keeps its own identity, and it is explicitly understood that A is acting for B. A borrowed user token is impersonation by construction, because the resource sees the user and nothing else. A delegated token keeps two names, so a resource server, a log query and a revocation decision can each address the agent separately from the person. ^[1]

Microsoft's agent platform documents a related split, with three operating modes: an interactive agent acting for a signed-in user through an on-behalf-of exchange, an autonomous agent acting through a service principal created for it, and an agent acting through a user account created specifically for that agent, for example one that needs its own mailbox. The third mode is not a person's account on loan. It is a separate user object that belongs to one agent. ^[2]

The choice is made per action, not per agent. Take a hypothetical support agent that summarizes the ticket queue every night under its own identity, then drafts a customer reply only when an engineer asks, under a token that names the engineer as the subject. Giving that agent application permissions broad enough to cover anything an engineer might ask would collapse both paths into one and bring back the attribution problem that delegation exists to solve.

Why borrowed user tokens fail

Attribution goes first. When an agent replays a user's token, every request it makes is, as far as the resource can tell, the user's own request, and the sign-in and audit records name the user. If the agent misreads an instruction and deletes a folder, the record shows the person deleting it. AWS's Well-Architected agentic AI lens lists reusing human credentials or roles for agent authentication as an anti-pattern for exactly this reason, and rates the risk of not separating agent and human permissions as high. ^[5]

Privilege follows. A user token carries whatever the user consented to for that client, which is usually far more than one task needs. Microsoft's on-behalf-of documentation shows the platform drawing the opposite line: the middle tier receives only delegated scopes, and application roles remain attached to the user and never to the application acting for the user. A borrowed token skips that boundary because there is no second principal for the platform to reason about. ^[3]

Audience checks break next. The Model Context Protocol authorization specification, version 2025-11-25, requires an MCP server to accept only tokens issued for itself and says a server that calls an upstream API must not pass through the token it received from the client; it needs a separate token from the upstream authorization server. Microsoft's on-behalf-of guide carries the same warning: never send a token issued to a middle tier anywhere except its intended audience. An agent that holds one user token and presents it to every tool is the relay both documents forbid. ^[3][4]

Revocation is the last and most expensive failure. With a borrowed token, the only way to stop the agent is to stop the user, by revoking sessions or refresh tokens that the person also depends on. You cannot disable one misbehaving agent while its user keeps working, and the logs cannot tell you which other agents hold copies of the same token. A refresh token makes this worse, because it keeps working after the task that justified it has ended.

Source. Conceptual comparison based on RFC 8693, the MCP authorization specification, AWS Well-Architected agentic AI guidance and Microsoft Entra Agent ID documentation. ^{[1][4][5][18]}

Method. Conceptual hypothetical agent; no environment was inspected.

Accessible table and figure data

Figure 1 accessible table

Aspect	Before	After
Who the API sees	the user alone	the user and the agent
Permissions	all rights in the user's token	task scopes consented for the agent
Audit trail	user activity, agent invisible	agent marked in sign-in and audit logs
Stopping the agent	revoking the user's sessions	disabling the agent identity
Token storage	user refresh token in agent config	platform vault keyed to agent and user
Token reuse	one token sent to every tool	a new token per audience

Figure 1 accessible table

Aspect	Before	After
Who the API sees	the user alone	the user and the agent
Permissions	all rights in the user's token	task scopes consented for the agent
Audit trail	user activity, agent invisible	agent marked in sign-in and audit logs
Stopping the agent	revoking the user's sessions	disabling the agent identity
Token storage	user refresh token in agent config	platform vault keyed to agent and user
Token reuse	one token sent to every tool	a new token per audience

Download imageDownload table CSV

Delegation with token exchange

RFC 8693 defines a token endpoint grant, urn:ietf:params:oauth:grant-type:token-exchange, in which a client presents one security token and receives another. The required subject_token represents the party on whose behalf the request is made, here the user, and subject_token_type names its format. The optional actor_token represents the acting party, here the agent, and actor_token_type is required whenever an actor token is sent. The optional audience, resource and scope parameters let the client ask for a token that is good at one service for one task. The response must state issued_token_type. ^[1]

Delegation becomes visible in the issued token through the act claim. A token whose sub is the user and whose act.sub is the agent says the agent is acting for the user. If that token is exchanged again by a sub-agent, the claims nest: the outermost act is the current actor and nested act claims record earlier actors. The RFC is strict about how consumers use the chain. Access control must consider only the token's top-level claims and the current actor, and prior actors are informational only. A resource that wants to refuse work relayed through an unapproved sub-agent must express that as policy on the current actor and the subject, not by reading history out of nested claims. ^[1]

The authorization server, not the agent, decides whether an exchange is allowed. RFC 8693 leaves client authentication methods and issuance policy to the server, and notes that authenticating the client lets the server check which entities may receive delegations from which. The may_act claim gives that check a concrete input: a subject token whose may_act names the agent asserts that the agent is eligible to act for that subject. Because any delegation of one principal's rights to another invites abuse, the RFC suggests restricting delegated tokens with the scope claim and a limited lifetime. ^[1]

Not every platform uses the RFC 8693 grant. Microsoft Entra's agent on-behalf-of flow uses the jwt-bearer grant with requested_token_use=on_behalf_of. The agent identity blueprint first requests an exchange token with fmi_path set to the child agent identity, and the agent identity then presents that token as its client assertion together with the user's token. Entra rejects a user token whose audience is not the blueprint, with error AADSTS50013. The issued token is delegated in substance: user claims describe the subject and azp identifies the calling client. Microsoft's guidance for downstream APIs adds the xms_par_app_azp claim, present in agent identity tokens and absent from standard app-only tokens, as the marker that a token was issued to an agent. ^[6][3][7]

# Hypothetical RFC 8693 exchange. Placeholders only; line breaks for legibility.
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<user access token with aud=https://agent.example.com>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=<signed JWT that identifies the agent>
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=https://calendar-api.example.com
&scope=calendar.events.read

# Decoded payload of the issued token (abridged)
{
  "iss": "https://auth.example.com",
  "aud": "https://calendar-api.example.com",
  "sub": "user-4821",
  "scope": "calendar.events.read",
  "exp": 1791450300,
  "act": { "sub": "agent:scheduling-assistant" }
}

Source. Conceptual sequence based on RFC 8693 sections 2.1, 4.1 and 4.4 and the MCP authorization specification. ^[1][4]

Method. Conceptual generic flow. Provider flows differ in grant type and claim names; Entra uses a jwt-bearer on-behalf-of exchange.

Accessible table and figure data

Figure 2 accessible table

Step	From	To	Message
1	User app	Agent	Request with user token; aud is the agent
2	Agent	Agent	Validate audience; choose the task scope
3	Agent	Authorization server	Exchange: subject_token, actor_token, audience, scope
4	Authorization server	Authorization server	Apply policy and may_act; narrow scope
5	Authorization server	Agent	New token: sub user, act.sub agent, short exp
6	Agent	Resource API	Call with the exchanged token
7	Resource API	Resource API	Check aud, scope, user and current actor
8	Resource API	Agent	Response; log user and agent

Figure 2 accessible table

Step	From	To	Message
1	User app	Agent	Request with user token; aud is the agent
2	Agent	Agent	Validate audience; choose the task scope
3	Agent	Authorization server	Exchange: subject_token, actor_token, audience, scope
4	Authorization server	Authorization server	Apply policy and may_act; narrow scope
5	Authorization server	Agent	New token: sub user, act.sub agent, short exp
6	Agent	Resource API	Call with the exchanged token
7	Resource API	Resource API	Check aud, scope, user and current actor
8	Resource API	Agent	Response; log user and agent

Download imageDownload table CSV

What the cloud platforms now provide

Microsoft, AWS and Google each ship a distinct agent principal, and each reached general availability for it within the year before this review. The principals look alike; the delegation mechanics do not. Statuses below were checked against each provider's release notes or announcement on October 8, 2026.

Microsoft announced general availability of the Microsoft Entra Agent ID platform in April 2026. An agent identity blueprint holds the credential and acts as the template; agent identities are its children, and every agent token flow involves the blueprint impersonating the agent identity during a multi-stage exchange. All agent entities are confidential clients, and interactive /authorize flows are not supported for any of them. Microsoft calls managed identities the preferred blueprint credential and says client secrets should not be used in production. Agent ID is available to all Entra customers, but extending Entra security features such as Conditional Access and ID Protection to agents requires Microsoft Agent 365 licensing. ^[8][2][9]

Amazon Bedrock AgentCore, including AgentCore Identity, became generally available on October 13, 2025. AgentCore implements agent identities as workload identities in an agent identity directory so that agents authenticate as themselves rather than impersonating users. Its delegation primitive is the workload access token, an AWS-signed opaque token usable only with AgentCore services, which binds the agent's workload identity to a user identity. AgentCore Runtime obtains it by validating the caller's inbound JWT and calling GetWorkloadAccessTokenForJWT, which identifies the user by the JWT's iss and sub; Runtime-managed identities cannot fetch the token directly. That token unlocks the token vault, which stores OAuth tokens and API keys from client credentials (2LO) and authorization code (3LO) flows so that only the agent and user combination that obtained them can retrieve them. ^[10][11][12]

Google's IAM release notes list Agent Identity as generally available on April 22, 2026. Each deployed agent gets a SPIFFE-based identity with an X.509 certificate valid for 24 hours and renewed automatically, and IAM allow policies name it with a principal:// identifier. Agent identities cannot be impersonated, do not allow long-lived service account keys, and receive Google Cloud access tokens bound to their certificate. For work on a user's behalf, Agent Identity auth manager stores API keys, OAuth client secrets and user tokens and runs 3-legged OAuth consent; the release notes list it as preview from April 22 and generally available from August 22, 2026. ^[13][14][15]

The comparison also shows what none of the three does for you. Each gives the agent a principal and a way to hold user-delegated credentials for third-party services. None makes your own APIs understand delegation. Your resource servers still have to read whichever claim carries the actor, whether act, azp with xms_par_app_azp, or a claim of your own design, and decide what the pair of identities may do.

Source. Microsoft, AWS and Google documentation and release notes reviewed October 8, 2026. ^{[2][6][8][10][11][12][13][14][15][16][17][19]}

Method. Cells summarize documented capabilities; GA dates are from provider release notes or announcements. Not an exhaustive feature comparison.

Accessible table and figure data

Figure 3 accessible table

Capability	On Entra Agent ID	On AgentCore Identity	On Google Agent Identity
Status	GA, April 2026	GA, October 13, 2025	GA, April 22, 2026
Agent principal	Agent identity created from a blueprint	Workload identity in a directory	SPIFFE identity per deployed agent
Credential	Blueprint credential; managed identity preferred	Workload access token delivered by Runtime	24-hour X.509 certificate, renewed automatically
Acting for a user	On-behalf-of exchange of the user token	Workload access token from the user's JWT	3-legged OAuth through auth manager
Stored user tokens	Refresh-token grant for background work	Token vault keyed to agent and user	Auth manager vault, GA August 22, 2026
Revocation lever	Disable the blueprint or agent identity	IAM deny on vault credential providers	revokeAuthorization per user and provider

Figure 3 accessible table

Capability	On Entra Agent ID	On AgentCore Identity	On Google Agent Identity
Status	GA, April 2026	GA, October 13, 2025	GA, April 22, 2026
Agent principal	Agent identity created from a blueprint	Workload identity in a directory	SPIFFE identity per deployed agent
Credential	Blueprint credential; managed identity preferred	Workload access token delivered by Runtime	24-hour X.509 certificate, renewed automatically
Acting for a user	On-behalf-of exchange of the user token	Workload access token from the user's JWT	3-legged OAuth through auth manager
Stored user tokens	Refresh-token grant for background work	Token vault keyed to agent and user	Auth manager vault, GA August 22, 2026
Revocation lever	Disable the blueprint or agent identity	IAM deny on vault credential providers	revokeAuthorization per user and provider

Download imageDownload table CSV

Designing scopes and lifetimes

Start from the task, not from the user. A delegated token should carry only the scopes the current task needs, at the one audience it will call, and expire soon after the task should finish. Microsoft's Agent ID guidance states the rule for Entra: client credentials with only the required application permissions for autonomous agents, on-behalf-of for agents acting for a user so that the user's access policies and consent apply, and no application permissions where delegated permissions would do. ^[16]

Give each agent its own identity. Microsoft recommends a unique identity per agent instance, so that one agent can be disabled or changed without touching others, and notes that blueprints keep this manageable because credentials live on the blueprint. AWS gives the equivalent advice for credential providers: create separate workload identities and IAM roles when agents need different providers, and name specific workload identity and provider ARNs in policy Resource blocks instead of *, because AgentCore does not otherwise bind identities to providers within an account. ^[16][17]

Close the unverified path. GetWorkloadAccessTokenForUserId accepts a caller-supplied user string, and AWS states that the platform treats it as opaque and does not verify it against an authenticated user. Any principal allowed to call it can therefore ask for a token scoped to any user's vaulted credentials. Where every caller has a JWT, deny the action. Where you need it, derive the user ID from the authenticated principal's context, prefix IDs by identity provider (for example cognito+user123), and log which principal passed which ID. ^[12]

Background work is where lifetimes drift. Entra lets agent identities use refresh-token grants so that asynchronous work keeps user context, and AWS notes that an agent can retrieve a vaulted third-party token without asking the user to sign in again for as long as that token remains valid. Both are reasonable features, and both mean delegated access outlives the conversation unless you end it. Decide per provider how long consent should last and record that decision where reviewers can see it. A token issued at the start of a long workflow can also outlive the approval behind it, so re-check authorization when an irreversible step actually runs. ^[6][5]

Some APIs accept only user identities. Entra's answer is an agent's user account, a user object created for one agent, and Microsoft advises creating one only when a user object is truly required, such as for a mailbox or Teams presence, because it adds licenses, group memberships and user-level policies to manage. That is still better than lending the agent a real person's account. ^[2][16]

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CalendarProviderOnly",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:GetResourceOauth2Token",
      "Resource": [
        "arn:aws:bedrock-agentcore:us-east-1:111122223333:workload-identity-directory/default",
        "arn:aws:bedrock-agentcore:us-east-1:111122223333:workload-identity-directory/default/workload-identity/scheduling-assistant",
        "arn:aws:bedrock-agentcore:us-east-1:111122223333:token-vault/default",
        "arn:aws:bedrock-agentcore:us-east-1:111122223333:token-vault/default/oauth2-credential-provider/example-calendar"
      ]
    },
    {
      "Sid": "NoUnverifiedUserIds",
      "Effect": "Deny",
      "Action": "bedrock-agentcore:GetWorkloadAccessTokenForUserId",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:111122223333:workload-identity-directory/default"
    }
  ]
}

Audit and revocation

An agent identity helps an investigation only if the logs carry it. Entra adds an agentType property to audit records, with values such as agenticApp for a blueprint, agenticAppInstance for an agent identity and agentIDuser for an agent's user account, plus a blueprintId that ties an instance back to its template. Sign-ins carry an agentSignIn event type and can be filtered by agent type in the admin center or through the Microsoft Graph beta sign-ins API, for example on agent/agentType eq 'AgentIdentity'. Because agents can sign in with delegated or app-only permissions, their sign-ins can appear in any of the four sign-in log types. ^[18]

On AWS, the Well-Architected lens recommends dedicated IAM roles per agent type with a naming convention such as agent-role-<agent-name>, a PrincipalType: Agent tag, service control policies that deny agent-tagged principals from assuming human operator roles, CloudTrail data events for AgentCore, and role session names that include the parent agent's identifier so delegation chains stay visible. Add CloudTrail monitoring of GetWorkloadAccessTokenForUserId calls for unexpected user IDs. ^[5][12]

Plan revocation at three granularities: one user's delegation to an agent, one agent everywhere, and a whole class of agents. Google's Agent Identity API has a revokeAuthorization method on an auth provider that deletes every authorization record for a given userId, revoking that user's delegated access across all agents that use the provider; it needs the agentidentity.authProviders.revokeAuthorizations permission. Microsoft describes disabling a blueprint as instantly blocking all of its agent identities. On AWS, an explicit IAM Deny on GetResourceOauth2Token or GetResourceApiKey for a credential provider overrides any allow and cuts an agent off from those vaulted credentials. ^[19][16][17]

Every agent also needs an accountable person. Microsoft requires a sponsor on each blueprint and agent identity, and recommends that sponsors attest every 6 to 12 months that each agent is still needed and correctly configured. Whatever the platform, record the sponsor, the delegations the agent accepts and the tested revocation path next to the rest of your machine identities. ^[16]

Moving an agent onto its own principal

The sources point to one order of operations. It moves the agent onto its own principal before narrowing anything, because scopes and revocation have nothing to attach to until the agent exists as a separate identity.

The decision rule is short. If a user asked for the action, the token should name the user and the agent. If no user asked, it should name only the agent. If a token names only the user while an agent is the one presenting it, the design is not finished.

• Find every agent that holds a user's access or refresh token, and list the tools and audiences it presents that token to.
• Give each agent its own principal where it runs: an Entra agent identity, an AgentCore workload identity or a Google Agent Identity. ^[2][11][14]
• Split its actions into autonomous and user-initiated. Grant the first narrow permissions on the agent; route the second through on-behalf-of, a JWT-bound workload access token or a 3-legged OAuth provider. ^[6][12][15]
• Request a new token per audience and task, and never forward a token across a tool boundary. ^[4]
• Teach your own APIs to read and log the actor claim your platform issues, and to authorize on the pair of identities. ^[1][7]
• Test revocation for one user, one agent and one class of agents before go-live, then delete the borrowed tokens.