Agent Identity and Delegated Access

An AI agent should act with delegated authority, not impersonate the user.

That distinction matters because an agent can run in the background, call several services, and take actions long after the original chat message. A secure system must preserve who requested the work, which agent acted, what resource it accessed, and exactly what it was allowed to do.

Identity Is Not One Question

“The user is logged in” is not enough context for an agentic action.

Question	Security concept
Who requested the work?	User identity, or subject
Which software is acting?	Agent or OAuth client identity
On whose behalf is it acting?	Delegation
Which service is being accessed?	Resource and token audience
What may it do there?	Scopes and resource-level policy
Did the user approve this exact sensitive action?	Transaction authorization

These identities and decisions should remain separate even when they participate in one workflow.

The language model is not itself an OAuth client. The trusted agent application or tool runtime is the client. It handles tokens and policy checks without serializing credentials into the model’s prompt or context.

An audit record should be able to say:

Agent portfolio-assistant placed an order on behalf of user Lalit
using trade:create permission for brokerage-api.

Recording only that “Lalit placed an order” hides which software performed the action and makes investigation, policy enforcement, and revocation harder.

Authentication Is Not Delegation

Authentication establishes who the user is. It does not automatically give the agent permission to read the user’s calendar, portfolio, documents, or messages.

A typical workflow has separate steps:

The user signs in to the agent application.
The user connects an external account.
The external service asks the user to grant specific scopes.
The authorization system stores the resulting long-lived credentials securely.
The trusted agent runtime obtains short-lived, narrowly targeted credentials when it needs to call the service.

Signing in and connecting an account may use the same identity provider, but they establish different relationships.

The Delegated Access Flow

flowchart LR
    U["User<br/>subject"] --> A["Agent<br/>actor"]
    A --> AS["Authorization server"]
    P["Consent / policy<br/>human approval"] --> AS
    AS --> T["Short-lived token<br/>scope + audience"]
    T --> M["MCP server<br/>resource server"]
    M --> X["Token exchange"]
    X --> API["Upstream API"]

The important properties are:

the user and agent remain separately identifiable
the token names its intended resource or audience
scopes limit the allowed API operations
the agent runtime does not hold a reusable user password or broad session credential
each service validates authorization independently

Use A Different Token At Each Boundary

An access token is meant for a particular resource. A token issued for an MCP server should not simply be forwarded to Google, Slack, GitHub, or another downstream API.

Instead, the service should use a controlled token-exchange flow to obtain a different token for the downstream resource.

User -> Agent token for MCP server
MCP server -> Exchanged token for calendar API
Calendar API -> Validates its own audience and scopes

This limits the blast radius of a leaked token. It also prevents one service from accidentally accepting credentials intended for another service.

OAuth Resource Indicators standardize how a client identifies the target resource. OAuth Token Exchange standardizes how one security token can be exchanged for another token with the appropriate audience and delegated context.

Keep Long-Lived Credentials Away From The Model

External services often issue refresh tokens so an application can obtain new access tokens without repeatedly asking the user to sign in.

Refresh tokens are powerful, long-lived credentials. They should be kept in a protected server-side token store rather than placed in:

the model context
prompts or tool results
browser storage
agent memory
logs
source code or environment output

The trusted tool runtime should obtain only the short-lived access token needed for the current service and operation. The token does not need to enter model context. A token vault is one implementation of this pattern; the security principle does not depend on a particular vendor.

Scopes And Fine-Grained Authorization Solve Different Problems

OAuth scopes usually describe API-level capabilities such as:

calendar:read
portfolio:read
trade:create

They do not always answer whether the user may access a particular calendar, portfolio, document, project, or database row.

The resource server must still apply its normal authorization model, such as:

role-based access control
relationship-based access control
ownership checks
organization or tenant boundaries
document-level policy

An agent must never gain access to data that the represented user could not access directly.

High-Risk Actions Need Fresh Approval

Permission to read a portfolio does not imply permission to buy stock. Permission to draft an email does not imply permission to send it.

For financial, destructive, administrative, or externally visible actions, pause the agent and ask the user to approve the exact transaction.

A useful approval request includes:

the action
the target resource
important parameters
the agent requesting it
an expiry time
whether the approval is one-time or reusable

For example:

Approve portfolio-assistant to buy 10 shares of ACME
with a maximum price of $70 before 3:00 PM?

Client-Initiated Backchannel Authentication can support approval on another trusted device. OAuth Rich Authorization Requests can carry structured transaction details rather than reducing the request to a broad scope string.

The API performing the action must verify the approval details. Displaying a confirmation message in the chat is not an authorization control.

The LLM Must Not Enforce Permissions

The model may decide that a tool would help, but trusted application code must decide whether the call is allowed.

Authorization checks belong in deterministic middleware and resource servers:

Validate the token signature and issuer.
Confirm the audience matches the target service.
Check required scopes.
Apply resource-level policy for the user and organization.
Validate tool parameters against allowlists and limits.
Require fresh approval when the action crosses a risk boundary.

This separation is a defense against prompt injection. A malicious document may convince the model to request an admin tool, but it must not be able to mint a new scope, change the token audience, or bypass the API’s policy.

MCP Adds Another Authorization Boundary

In a remote MCP flow, the agent is an OAuth client and the MCP server is a protected resource server. The MCP server may then act as a separate OAuth client when it calls an upstream API.

Current MCP authorization uses established OAuth mechanisms for:

authorization-server discovery
protected-resource metadata
resource indicators
audience-restricted tokens
scopes and incremental authorization
client registration or client metadata

Dynamic client registration is optional, and client support can vary. Do not assume every MCP client supports every registration or authorization extension.

Background Agents Need Durable Attribution

An asynchronous task may run after the interactive session ends. Store the security context with the task rather than reconstructing it from a prompt later.

Useful task metadata includes:

user or service subject
agent/client identity
organization or tenant
approved resources and scopes
connected-account reference
creation time and expiry
approval records
policy version

Logs should record both the represented user and the acting agent. This makes it possible to revoke one agent, investigate misuse, and distinguish user behavior from agent behavior.

Design Checklist

Before giving an agent access to protected tools, answer:

Can we identify both the user and the agent?
Is every token restricted to the intended resource?
Are scopes limited to the current task?
Where are refresh tokens stored?
Does the resource server recheck user-level permissions?
Which actions require fresh human approval?
Are approval details bound to the action that is executed?
Can access be revoked without disabling the user’s entire account?
Do logs distinguish the subject from the actor?
Would a successful prompt injection still be stopped by deterministic policy?

Key Takeaways

Agent identity and user identity are related but not interchangeable.
Authentication identifies the user; delegation determines what the agent may do for that user.
Use short-lived, audience-restricted tokens and a separate token for each service boundary.
Keep refresh tokens and other long-lived credentials outside model context and agent memory.
Enforce scopes and resource-level policy in trusted code, not in prompts.
Require transaction-specific approval for high-impact actions.
Preserve both user and agent identities in tasks, tokens, approvals, and audit logs.