- Home
- AI agents
- Agent identity and access
- On-behalf-of vs autonomous access
Govern and secure · Agent identity and access
On-behalf-of vs autonomous access: how should an AI agent get its permissions?
On-behalf-of access means an agent acts for a signed-in user with a token whose rights can never exceed that user's. Autonomous access means the agent acts as itself, with grants given to its own identity and no user in the call. An agent can use both, and the choice is made for each call.
In this guide: 83 pages
Key takeaways
- Delegated access caps the agent at the user's rights; autonomous access caps it at its own grants. The second needs narrower grants and a tighter review, because no person's permissions limit what it can reach.
- Agents cannot click a consent screen. In Microsoft Entra, delegated permissions are pre-authorized on the agent identity blueprint as inheritable permissions; AWS AgentCore runs a three-legged OAuth flow and added a Consent Portal for end users in September 2026.
- A delegated token should name both parties. OAuth 2.0 Token Exchange (RFC 8693) separates delegation from impersonation and defines the act claim, which records the agent acting for the user.
- Long tasks outlive user tokens. Keep refresh tokens in a vault keyed to the agent and the user, exchange again at every hop, and keep chains of agents short, since that is where current OAuth and OpenID Connect patterns show documented limits.
How does on-behalf-of access work, step by step?
The user signs in to the client, the client passes the user's token to the agent, and the agent exchanges it at the identity provider for a new token scoped to one downstream tool. The new token identifies both the user and the acting agent (RFC 8693 expresses this as the subject and an act claim; each identity provider uses its own claims), and its rights are the user's rights narrowed to the scopes pre-authorized for the agent.
- The user signs in to the app or chat surface, and the client receives an access token meant for the agent.
- The agent presents that token with proof of its own identity. In Entra the agent uses the JWT-bearer grant with requested_token_use=on_behalf_of. AgentCore Identity supports RFC 8693 and RFC 7523 exchange modes with a preset for Microsoft's flow (April 2026), and its GetWorkloadAccessTokenForJWT call turns a user's inbound JWT into an agent token bound to that user.
- The identity provider evaluates policy for the user and the agent, then issues a token whose audience is one tool and whose scopes are the delegated permissions the agent was pre-authorized for.
- The tool checks that the token was issued for it and authorizes on the claims. The MCP authorization specification (2026-07-28) forbids a server from accepting or passing through tokens issued for anyone else.
When the downstream system is a third-party SaaS app, the agent usually needs a stored OAuth grant from the user. AgentCore Identity keeps those tokens in a KMS-encrypted vault under the agent identity ID and the user ID, Auth0 Token Vault does the same for connected accounts such as Google or Slack, and Google's Agent Identity auth manager brokers user-delegated access.
How does autonomous access work, and what does it need that delegation does not?
The agent authenticates as itself with the client credentials grant and receives a token for its own grants. Because no user narrows those rights, the grants must be narrow from the start, and the agent needs a sponsor, a review cycle and a policy aimed at its own identity.
The credential should be a managed identity, a federated credential or a key held in a key management service, never a client secret in code. Foundry provisions a federated identity credential for each new agent and starts the identity with zero permissions, so every grant is deliberate. Google issues a 24-hour certificate per agent and binds access tokens to it.
Policy targets the agent itself. Entra Conditional Access for agents evaluates the agent identity, its blueprint, custom security attributes and agent risk before a token is issued, and ships an autonomous agents template. On AWS, AgentCore Gateway inbound authorization and AgentCore Policy decide at the tool call; on Google Cloud, Agent Gateway enforces IAM Unified Access Policies (GA 31 Aug 2026).
Autonomous does not have to mean unattended. When a scheduled agent reaches a step that needs one person's consent, it can ask out of band: client-initiated backchannel authentication (CIBA), an OpenID Foundation specification that Auth0 implements for agents, sends a push to the user's device while the agent waits for the token. Auth0's page states no GA or preview status for the feature.
Which pattern should an agent use for each call?
Choose by whose authority the action needs. Use on-behalf-of when the work is done for one person and the agent should see only what that person can see, including background work for them through a stored refresh token. Use autonomous access when the work belongs to no single person, such as a job across many people's data under a business rule or a system with no notion of the user.
Six common calls and the access pattern that fits each, with the control to add.
| Situation | Pattern | Why | Control to add |
|---|---|---|---|
| An employee asks the agent to summarise their own mail and files | On behalf of the user | The agent must not see more than the person | Pre-authorize only the read scopes it needs |
| A nightly job reconciles invoices across all suppliers | Autonomous | No user is present, and the data belongs to no single person | Grants scoped to the reconciliation data; a named sponsor |
| A service desk agent resets the caller's password | On behalf of the caller, with an approval step | The action concerns one person and must be attributable to them | Approval gate on the reset tool; record of who approved |
| An agent posts a summary to a team channel after an event | Autonomous, with a narrow grant | An event triggers it, and the target is a shared space | Channel-scoped permission; a rate limit on posts |
| A scheduled agent needs a manager to authorize a payment | Autonomous, then out-of-band consent from the user | The work starts without a user, and the decision belongs to one | A CIBA-style request that shows the exact transaction |
| A legacy system only accepts a user account | The agent's user account (Microsoft only) | Some systems need a user object, a mailbox or a licence | A separate Conditional Access policy for the agent's user account |
Whichever pattern a call uses, log it under the agent's name with the user, if any, in the same record. An auditor should be able to tell a delegated read from an autonomous one without reconstructing the token.
How do long-running and multi-agent tasks keep delegated access?
With refresh tokens held in a vault for the agent and user pair, and with a fresh token exchange at every hop instead of a forwarded token. Chains of agents acting for one user across several domains are where current OAuth patterns show documented limits, so keep them short.
A user's access token expires long before an overnight task finishes. Entra's agent on-behalf-of flow accepts refresh tokens for asynchronous and background work, and AgentCore Identity stores refresh tokens in its vault under the agent identity ID and the user ID and releases them only to that agent, with proof of its workload identity. Design the task to stop cleanly when the user revokes consent halfway through, and to say so in its output.
When one agent calls another for the same user, each hop should exchange the token it received for one bound to the next audience. AWS labels JWT passthrough on AgentCore Gateway as not recommended for production and recommends on-behalf-of exchange. The OpenID Foundation's whitepaper of 7 Oct 2025 argues that OAuth and OpenID Connect work for simple single-organization agents but strain under recursive delegation, cross-domain calls and highly autonomous agents.
Vendor scope matters here too. Okta describes its Cross App Access, built on the ID-JAG draft, as agent-to-app access with user context, and says it is not meant for machine-to-machine agents with no user. One agent acting for the user and calling tools directly is easier to audit than three agents passing a user's authority along.
How do Microsoft, AWS and Google implement it?
How each cloud implements the two patterns, as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| On-behalf-of flow | Entra agent on-behalf-of flow (JWT-bearer grant); Foundry delegated access for tools in preview | AgentCore user binding and on-behalf-of token exchange in RFC 8693 and RFC 7523 modes (April 2026) | Agent Identity auth manager for user-delegated access |
| Consent | Delegated permissions pre-authorized on the blueprint as inheritable permissions | Three-legged OAuth credential providers; Consent Portal for end users (September 2026) | OAuth credentials held by the Agent Identity auth manager |
| Autonomous credential | Managed identity or federated credential on the blueprint | Workload identity with client credentials; Private Key JWT with the key in KMS (July 2026) | 24-hour X.509 certificate per agent, renewed automatically |
| Policy on the call | Conditional Access for agents, written per token subject | Gateway inbound authorization and AgentCore Policy | Agent Gateway with IAM Unified Access Policies |
Google's documentation pages show no launch stage for Agent Identity, and its release notes call the Agent Identity API a preview on 18 Jun 2026. Foundry's delegated access for tools was a preview on 28 Oct 2026.
Frequently asked questions
Can an agent using on-behalf-of access do anything the user cannot?
Not if the flow is built correctly. The exchanged token carries the user as subject and only the scopes pre-authorized for the agent, so the agent gets at most the user's rights for that tool, and often less. If an agent reaches data the user cannot, look for a second credential, such as an API key or a maker-provided connection.
Is impersonation the same as delegation?
No. RFC 8693 separates the two: an impersonation token looks as if the user acted directly, while a delegation token records in an act claim that the agent acted for the user. Prefer tokens and logs that name the acting agent, so the audit trail can tell the person's own actions from the agent's. Microsoft describes its agent flow as on-behalf-of with agent-specific impersonation, so check what its tokens and sign-in logs record.
Does autonomous access need a human owner?
Yes, and more than delegated access does, because no user's rights limit it. Entra separates technical owners from business sponsors and can transfer sponsorship when someone leaves; AWS Agent Registry and Gemini Enterprise hold owner fields. Review autonomous grants on a fixed cycle and remove the ones the agent no longer uses.
What about agents that act for customers instead of employees?
The same pattern applies with your customer identity provider. AgentCore Identity works with Amazon Cognito, Okta, Microsoft Entra ID and Auth0 for inbound user tokens. Keep customer-facing and employee-facing agents on separate identities and policies, because their data, consent rules and risk tiers differ.
More in Agent identity and access
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Agent OAuth flows: on-behalf-of flow
- Microsoft Entra Agent ID key concepts
- Agent identity blueprints
- Conditional Access for agents in Microsoft Entra
- ID Protection for agents (risky agents)
- Agent identity in Microsoft Foundry
- On-behalf-of token exchange (AgentCore Identity)
- AgentCore Identity key features and benefits
- AgentCore Gateway inbound authorization
- AgentCore release notes
- Securing AI agents with Amazon Bedrock AgentCore Identity
- Agent identity for Agent Runtime
- Agent Identity overview
- OAuth 2.0 Token Exchange, RFC 8693
- MCP authorization (specification 2026-07-28)
- New whitepaper tackles AI agent identity challenges
- Cross App Access (XAA)
- Token Vault
- Asynchronous authorization
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner