Delegated authorization lets an AI agent use a limited portion of a user’s or another principal’s authority to access a service, while keeping the principal and the agent identifiable as separate parties. The agent does not need to act as though it were the user: an authorization server can evaluate a request made on the user’s behalf and issue a token for a particular resource under its policies.
OAuth 2.0 Token Exchange, specified in RFC 8693, is an established building block for this pattern. It is not, by itself, a complete AI-agent authorization architecture. Agent-specific OAuth proposals identified here are Internet-Drafts, not finalized standards.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
What delegated authorization means
In a delegated request, there are at least two identities to keep distinct:
- The subject or principal: the user or other party whose authority is being used.
- The actor: the agent that makes the request using authority delegated to it.
RFC 8693 describes delegation as one party acting on behalf of another. Its distinction matters: the principal’s authority may support an action, but the agent is still the actor responsible for taking it. A useful authorization and audit record should therefore make clear both whose authority was used and which agent acted.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
This differs from impersonation. With impersonation semantics, a resulting token can represent the subject as the effective identity, without preserving the actor as a separately identifiable party in the same way. That difference affects how downstream services apply policy and how an action can later be attributed. RFC 8693 supports both delegation and impersonation semantics; an implementation must choose and handle them deliberately.
How a delegated authorization flow works
- The principal authorizes access. A user or other principal grants access through a system’s consent and authorization process. The particular consent experience and rules depend on the implementation.
- The agent authenticates as itself. The agent client presents an appropriate subject token to an authorization server and identifies the agent as the actor. RFC 8693 defines token-exchange parameters for representing the subject and, where used, the actor.
- The authorization server evaluates the request. It applies its trust relationships and local policy to decide whether to issue a token and what that token may represent or permit. A request does not guarantee that a token will be issued.
- The token is directed to a resource. The optional RFC 8693
resourceparameter identifies the intended target resource. An authorization server can use that information to apply target-specific policy; it does not make a token automatically safe for other APIs. - The target service validates and enforces. The resource server validates the token it receives and enforces the permissions represented by it. Whether user and agent identities, delegation chains, or other details are carried through depends on the token, implementation, and applicable profile.
In this flow, the subject_token represents the party on whose behalf access is requested, while the actor_token, when used, represents the party to whom rights are delegated. RFC 8693 also defines the JWT act claim for representing an actor, including in a chain of delegation. A composite token may convey subject and actor information, but the authorization server’s policy and implementation determine whether it issues one and exactly how it represents that context.
What token exchange does—and does not—standardize
RFC 8693, published in January 2020 as an IETF Standards Track specification, defines an HTTP/JSON mechanism for requesting one security token in exchange for another. It includes parameters relevant to delegation and impersonation. It does not prescribe a universal trust model or settle every important token-security choice. Trust between participating parties, token contents and security properties, and deployment policy need to be established by the implementation and any applicable profile.
That boundary is important for agent systems. Token exchange can provide a protocol mechanism for carrying a delegated request to an authorization server; it does not ensure that every service in a multi-step tool chain will preserve, understand, or enforce the delegation context. Implementations should retain enough information at each hop to support authorization and audit decisions about the principal, the current actor, the requested resource, and the policy decision.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteStandards and proposals for agent authorization
| Document | Status and role |
|---|---|
| OAuth 2.0 Token Exchange, RFC 8693 (January 2020) | Published IETF Standards Track specification. Defines token-exchange mechanics, including delegation and impersonation, but leaves trust models and important token-security characteristics to profiles and deployment policy. |
| OAuth 2.0 Security Best Current Practice, RFC 9700 (January 2025) | Published IETF best-current-practice guidance for OAuth security, including relevant concerns such as access-token leakage and replay. |
| NIST NCCoE concept paper, “Accelerating the Adoption of Software and AI Agent Identity and Authorization” (February 2026) | Official concept paper discussing agent identity and authorization, OAuth extensions, and policy-based access control. It is not a protocol standard. |
| OAuth on-behalf-of-user authorization for AI agents | An IETF Internet-Draft proposing an OAuth extension for agent scenarios in which the agent remains a distinct identity. Draft work is not a finalized RFC. |
| Agent Authorization Profile (AAP) for OAuth 2.0 | An IETF Internet-Draft describing a profile that uses existing OAuth, JWT, token-exchange, and proof-of-possession mechanisms for agent-to-API scenarios. It is not a finalized RFC. |
The agent-specific documents above are proposals, not evidence of a universal or universally implemented agent-authorization standard. NIST’s concept paper is a current official framing of the problem, not a substitute for a protocol specification.
How MCP fits in
NIST’s February 2026 concept paper says the Model Context Protocol (MCP) relies on existing identity standards such as OAuth and OpenID Connect for authentication and rights delegation. That does not mean MCP supplies every authorization policy needed by an application or resolves delegation across every tool and service in a chain. The identity and authorization behavior still depends on the systems that issue, pass, validate, and enforce credentials.
Rank #4
Security decisions an implementation must make
Keep the agent and principal distinct
Give the agent its own authenticated identity and retain the principal identity separately. Avoid treating a user’s password or other long-lived credential as a shared secret for the agent. The subject-and-actor model in RFC 8693 supports this separation; the exact credential-handling design is an implementation choice.
Constrain tokens to the intended resource
Request a token for the API or service that needs it, and let the authorization server decide the token’s permissions. Do not assume a token issued for one resource is appropriate to reuse at another. The RFC 8693 resource parameter can identify the intended target, but the server’s policy and the receiving service’s validation remain essential.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Best Value
Authenticate clients and control who can exchange tokens
Use client authentication and policy to limit which clients may request delegated tokens. RFC 8693 notes that if the exchanging client is unauthenticated, possession of a compromised token can create a path for another party to exchange it. Client authentication gives the authorization server another basis for deciding who may obtain a delegated token.
Protect tokens from leakage and replay
Apply the OAuth security guidance in RFC 9700 to relevant leakage and replay threats. Treat access tokens as sensitive credentials: as a practical safeguard, do not expose them to prompts, model context, logs, or untrusted tools. Prompt and tool-output handling also needs care: if untrusted content can influence an agent to use its authority in an unintended way, the system needs controls for that risk. This is a broader agent-implementation concern, not a prompt-injection rule specified by the OAuth documents cited here.
Define expiry, revocation, consent changes, and chain limits
Decide explicitly how the system responds when consent changes, a token expires, or access should be revoked, and how many delegation hops it permits. Token exchange alone does not make revocation immediate or automatic. RFC 8693 leaves important trust and token-security decisions to deployment policy and profiles.
Preserve useful audit attribution
Record enough context to identify both the principal whose authority was used and the agent responsible for the action. For multi-service or multi-agent flows, define how each hop carries and validates that context. RFC 8693 provides subject-and-actor semantics, but it does not prescribe a complete audit system or guarantee that downstream services preserve those semantics.
What to check when evaluating an implementation
- Does it keep the user or principal distinct from the agent in tokens and audit records?
- Can requests be bounded to a specific target resource and permitted actions?
- Does delegation context survive each downstream service or agent hop?
- Are token lifetime, revocation, and consent-change behavior defined?
- Does it authenticate clients requesting exchanges, and does it support proof-of-possession where appropriate?
- Can an operator attribute actions to both the principal and the responsible agent?
- Is the claimed support based on a published standard, a draft profile, or implementation-specific behavior?
These checks follow from RFC 8693’s subject, actor, resource, and policy model and RFC 9700’s OAuth security baseline. Specific vendor capabilities require verification against that vendor’s current documentation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
