OAuth2.0 Extension for Multi-AI Agent Collaboration
draft-song-oauth-ai-agent-collaborate-authz-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yurong Song , LUN LI , Yuning Jiang , Faye Liu | ||
| Last updated | 2026-06-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-song-oauth-ai-agent-collaborate-authz-02
Web Authorization Protocol Y. Song
Internet-Draft L. Li
Intended status: Experimental Huawei
Expires: 31 December 2026 Y. Jiang
F. Liu
Huawei Singapore
29 June 2026
OAuth2.0 Extension for Multi-AI Agent Collaboration
draft-song-oauth-ai-agent-collaborate-authz-02
Abstract
This method extends OAuth 2.0 by adding fields to token and message
flows, enabling sub-agents to act as a task group. It simplifies
authorization for task groups, avoids repeated interactions between
sub-agents and the authorization server, and bounds the authority
delegated to the group and to each member while maintaining
compatibility with existing OAuth 2.0 workflows.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Song, et al. Expires 31 December 2026 [Page 1]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Procedure of Static Task Group Authorization . . . . . . . . 4
3.1. Extension for Client Registration . . . . . . . . . . . . 5
3.2. Authorization Request & Response . . . . . . . . . . . . 5
3.3. Access Token Request & Response . . . . . . . . . . . . . 6
3.4. Access Token Transmit . . . . . . . . . . . . . . . . . . 7
3.5. Access Token Verify . . . . . . . . . . . . . . . . . . . 8
4. Procedure of Dynamic Task Group Authorization . . . . . . . . 8
4.1. Extension for Client Registration . . . . . . . . . . . . 9
4.2. Authorization Request & Response . . . . . . . . . . . . 9
4.3. Access Token Request & Response . . . . . . . . . . . . . 9
4.4. Access Token Transmit . . . . . . . . . . . . . . . . . . 11
4.5. Access Token Verify . . . . . . . . . . . . . . . . . . . 12
5. Scope-Bounded Task Group Authorization . . . . . . . . . . . 12
5.1. Token Request and Issuance . . . . . . . . . . . . . . . 13
5.2. Member Token Use . . . . . . . . . . . . . . . . . . . . 15
5.3. Token Revocation . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. Least Privilege and Permission Attenuation . . . . . . . 16
6.2. Containment of Compromised Sub-Agents . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
AI agents are capable of handling tasks. They can integrate multiple
technologies such as natural language understanding, data analysis,
and logical reasoning to meet multi-step and cross-scenario
requirements. However, a single AI agent has a limited knowledge
scope and restricted functions, making it difficult to independently
complete complex tasks that span multiple professional domains and
require different capabilities.
Song, et al. Expires 31 December 2026 [Page 2]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
Collaboration among a group of AI agents is an essential approach for
such complex tasks. Taking the demand for "real-time health advice"
as an example, this intent can be split into three tasks: "collect
the user's health data", "predict the user's health status" and
"provide health advice based on health status". These tasks need to
be accomplished by corresponding professional sub-AI agents: the data
collection agent is responsible for privacy-compliant data
collection, the health status prediction agent invokes medical models
for analysis, and the advice generation agent outputs solutions based
on health guidelines.
What's more, according to some existing
research[multi-agent-research-system], a leading agent is necessary
for coordination. In the above example, the leading agent can
receive the intent "give me real-time health advice" from user,
understand it and split it into tasks. Additionally, the leading
agent selects sub-agents capable of fulfilling the tasks and
distributes these tasks to them. These sub-agents can be referred to
as a task group. Finally, the leading agent integrates the results
returned by the sub-AI agents to form complete health advice.
Without the leading agent, task execution is prone to confusion and
final results are difficult to unify.
There are two typical policies for the leading agent to select sub-
agents and form a task group: 1) The static policy determines all
tasks and sub-agents upfront before execution, enabling predictable
scheduling and stable group composition; 2) The dynamic policy
incrementally identifies tasks and selects sub-agents during
execution, allowing real-time adjustment based on intermediate
results and improving adaptability to changing conditions.
In such collaborative scenarios, if each sub-AI agent in a task group
applies for permissions from the authorization server individually,
the authorization server must verify the identity and permissions of
each sub-agent one by one and generate access tokens for them. This
leads to problems such as frequent interactions, high computing
resource consumption on the authorization server, and low efficiency
in the token issuance process. In addition, when each sub-agent is
authorized independently, there is no single point that bounds the
total authority held by the task group, so the authority collectively
exercised by the group can exceed what was intended for the task as a
whole.
Therefore, this draft proposes authorization methods for static and
dynamic task groups. For the static policy, the leading agent
communicates with the authorization server centrally and applies for
access tokens on behalf of all sub-agents in the task group before
task execution begins. For the dynamic policy, the leading agent
Song, et al. Expires 31 December 2026 [Page 3]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
applies for an access token for a specific task and issues task
credentials bound to the access token to the corresponding sub-
agents. In addition, this draft describes an optional scope-bounded
mode, where the authorization server issues a group authorization
token and member authorization tokens; the authority of each member,
and the aggregate authority of all members, is bounded by the
authority granted to the group. These methods simplify the
authorization process for sub-AI agents and avoid efficiency loss
caused by repeated interactions.
2. Terminology
Applier: a role that requests the access token on behalf of
client(s), e.g. a leading AI agent.
Group Authorization Token: a token issued by the authorization server
that authorizes the group permission scope, i.e. the maximum
authority the whole task group may exercise while handling a task.
Member Authorization Token: a token issued by the authorization
server that authorizes the member permission scope of an individual
sub-agent. The member permission scope is no broader than the group
permission scope.
Group Permission Scope: the set of resources, the set of service
types, the set of permitted operations, and the maximum access count
that the task group as a whole is permitted while handling a task.
Member Permission Scope: the resources, service types, operations,
and maximum access count permitted to a single sub-agent. It is no
broader than the group permission scope.
This draft uses the terms "authorization server", "client", "resource
server" defined by OAuth 2.0 [RFC6749].
3. Procedure of Static Task Group Authorization
This protocol flow is modeled after [RFC6749] and extends it with an
*applier_id* field to enable authorization request by the applier.
Song, et al. Expires 31 December 2026 [Page 4]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
+--------+ +----------------+
| |--(A) Authorization Request-->| Resource |
| | | Owner |
| |<--(B) Authorization Grant----| |
| | +----------------+
|Leading |
| Agent | (C) Authorization Grant +----------------+
| |--------(applier_id)--------->| |
| | | Authorization |
| | (D) Access Token | Server |
| |<------(app=applier_id)-------| |
+--------+ +----------------+
|
|
(E) Access Token*
|
v
+--------+ +----------------+
| |-------(F) Access Token*----->| Resource |
| Sub- | | Server |
| Agent |<---(G) Protected Resource----| |
+--------+ +----------------+
Figure 1: Static Task Group Authorization Flow
3.1. Extension for Client Registration
Before initiating the protocol, the leading agent registers with the
authorization server, as defined in [RFC6749].
In this draft, the leading agent's role or capability is incorporated
into its registration process. For example, the leading agent's
profile includes a "capability" parameter with the value "resolve
intent and distribute tasks".
3.2. Authorization Request & Response
This section refers to step (A) and (B).
The leading agent receives a requirement from the user, resolves it
and determines the task(s) and sub-agent(s) needed to fulfill the
requirement. For example, when the user sends the intent "give me
real-time health advice" to the leading agent, the leading agent
resolves this intent and identifies three tasks: task 1 (collect the
user's health data), task 2 (predict the user's health status) and
task 3 (provide health advice based on health status). The leading
agent then utilizes the agent discovery process to select sub-
agent(s) capable of performing the respective tasks. For instance,
Song, et al. Expires 31 December 2026 [Page 5]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
task 1 assigned to sub-agent 1, task 2 to sub-agent 2, and task 3 to
sub-agent 3. In the subsequent authorization process proposed in
this draft, the leading agent is designated as the applier, and the
selected sub-agent(s) are designated as the client(s).
The leading agent requests authorization from the resource owner, as
defined in [RFC6749].
3.3. Access Token Request & Response
This section refers to step (C) and (D).
The leading agent requests an access token by authenticating with the
authorization server and presenting the authorization grant, as
defined in [RFC6749]. The message may also include the following
parameter:
applier_id OPTIONAL. The identifier of the applier which is
requesting access token on behalf of the client(s).
The authorization server authenticates the leading agent and
validates that the leading agent is capable of requesting access
tokens on behalf of sub-agent(s). For example, it checks whether the
leading agent's profile includes a "capability" parameter whose value
includes "distribute tasks".
If the validation is successful, the authorization server may verify
grants as defined in [RFC6749]. Then the authorization server
generates access token and send access token response message to the
leading agent. The access token is similar to OAuth2.0, except that
it consists of an additional claim to specify the applier.
app OPTIONAL. The identifier of the applier which is requesting
access token on behalf of the client(s).
The access token includes one *app* parameter and multiple
*sbj*-*aud*-*scope* grants. Below is an example:
{
"iss": "authorization server ID",
"app": "leading agent ID",
"grants": [
{ "sbj": "sub-agent 1 ID",
Song, et al. Expires 31 December 2026 [Page 6]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
"aud": ["resource server 1 ID"],
"scope": "..." },
{ "sbj": "sub-agent 2 ID",
"aud": ["resource server 1 ID","resource server 2 ID"],
"scope": "..." },
{ "sbj": "sub-agent 3 ID",
"aud": ["resource server 2 ID","resource server 3 ID"],
"scope": "..." }
]
}
If the validation fails, the access token response message may
include the reason for failure. [RFC6749] has defined types of error
response. In this case, the authorization server may use a new error
message "unauthorized_applier" to indicate that the leading agent is
not capable of requesting access tokens on behalf of sub-agent(s).
3.4. Access Token Transmit
This section refers to step (E).
The leading agent sends the task ID and access token* to the sub-
agent(s). Based on local policies and regulations, the leading agent
may use privacy protection mechanisms to process the access token.
Thus, the access token* may be the same as the access token, or
generated from the access token using privacy protection mechanisms.
For example, the leading agent uses a selective disclosure algorithm
to generate access token 1, access token 2, and access token 3 from
the access token received in step (D). Access token 1 may include
the leading agent ID and sub-agent 1 ID; access token 2 may include
the leading agent ID and sub-agent 2 ID; access token 3 may include
the leading agent ID and sub-agent 3 ID. The applier may then send
access token 1 to sub-agent 1, access token 2 to sub-agent 2, and
access token 3 to sub-agent 3.
Song, et al. Expires 31 December 2026 [Page 7]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
The sub-agent(s) validate the proof of the received access token* and
check whether the applier ID refers to a trustworthy leading agent.
For example, each AI agent is preconfigured with a list of trusted AI
agents, and any one of the trusted AI agents that acts as a leading
agent will pass the validation.
If the validation fails, the client(s) may send a response message to
the applier with a failure indication of "unknown_applier".
3.5. Access Token Verify
This section refers to step (F) and (G).
The sub-agent(s) execute the task according to message received in
step (E). When resources are needed, the sub-agent(s) request the
protected resource from the resource server and present the access
token*, as defined in [RFC6749]. The resource server validates the
access token*, as defined in [RFC6749]. If the access token*
includes multiple *sbj*-*aud* pairs, the resource server may verify
that its own ID and the sub-agent's ID are in the same pair. In the
previous example of the access token, "sub-agent 1 ID" and "resource
server 1 ID" are in the same pair.
If the validation succeeds, the resource server may provide the
resource to the client(s).
4. Procedure of Dynamic Task Group Authorization
This protocol flow is modeled after [RFC6749] and extends it with
task credentials bound with the access token.
Song, et al. Expires 31 December 2026 [Page 8]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
+-------+ +-------------+
| | (A) Authorization Request | |
| |----------------------------->| Resource |
| | (B) Authorization Grant | Owner |
| |<-----------------------------| |
|Leading| +-------------+
| Agent | (C) Authorization Grant +-------------+
| |--------(task, key)---------->| |
| | |Authorization|
| | (D) Access Token | Server |
| |<-------(task, key)-----------| |
+-------+ +-------------+
|
(E) Access Token* & Task Credential
|
+---v---+ +-------------+
| | (F) Access Token* | |
| Sub- |----------------------------->| Resource |
| Agent | (G) Protected Resource | Server |
| |<-----------------------------| |
+-------+ +-------------+
Figure 2: Dynamic Task Group Authorization Flow
4.1. Extension for Client Registration
Before initiating the protocol, the leading agent registers with the
authorization server.
4.2. Authorization Request & Response
This section refers to step (A) and (B).
The leading agent receives a requirement from the user, resolves it
and determines the task(s) and client(s) needed to fulfill the
requirement. The leading agent requests authorization from the
resource owner. Detailed procedures are similar to Section 3.2.
4.3. Access Token Request & Response
This section refers to step (C) and (D).
The leading agent requests an access token by authenticating with the
authorization server and presenting the authorization grant, as
defined in [RFC6749]. The message may also include the following
parameter:
task OPTIONAL. The identifier or description of the task which is
Song, et al. Expires 31 December 2026 [Page 9]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
resolved from intent.
key OPTIONAL. The index that point to the public key of the leading
agent that is used to issue task credentials.
The authorization server authenticates the leading agent and
validates that the leading agent is capable of executing specific
task. What's more, the authorization server validates that the
leading agent holds the private key related to the *key* received in
the request message.
If the validation is successful, the authorization server may verify
grants as defined in [RFC6749]. Then the authorization server
generates access token and send access token response message to the
applier. The access token is similar to OAuth2.0 and OAuth2.0 DPoP,
reuse the *subject* parameter to describe the access token is issued
to agents that can execute specific task, and add a new parameter to
point to the task credential (e.g. the public key used to issue task
credentials).
key OPTIONAL. The indication of public key of the leading agent
that is used to issue task credentials. Any agent that holds the
credential issued by this public key is authorized to request
resources defined in the access token.
Below is an example:
{
"iss": authorization server ID,
"sbj": task ID,
"aud": resource server 1 ID,
"key": public key for specific task
...
}
If the validation fails, the access token response message may
include the reason for failure. In this case, the authorization
server may use a new error message "unrecognized_pk" to indicate that
the validation of *key* sent by the leading agent is wrong.
Song, et al. Expires 31 December 2026 [Page 10]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
4.4. Access Token Transmit
This section refers to step (E).
After the leading agent selects sub-agent to execute task, it
generates task credential and sends the credential with access token*
to the sub-agent(s). The task credential is used to prove that the
subject of the credential is selected by the leading agent to execute
specific task. Optionally it includes the information of the related
access token. The credential is signed by the leading agent using
the private key related to the public key indicated by the *key*
parameter in the access token. This credential can have multiple
formats. Below is an example:
{
"issuer": leading agent ID,
"subject": sub-agent ID,
"claim": task ID
"related token": hash of the access token
...
"proof": signature of leading agent
}
The leading agent may resolve a list of multiple tasks based on one
intent from the user. In this case, the *sbj* in the access token
may involve several tasks. Based on local policies and regulations,
the leading agent may use privacy protection mechanisms to process
the access token. For example, the leading agent uses a selective
disclosure algorithm to generate access token 1, access token 2, and
access token 3 from the access token received in step (D). Access
token 1 may include task ID 1; access token 2 may include task ID 2;
access token 3 may include task ID 3. The leading agent may then
send access token 1 to sub-agent 1, access token 2 to sub-agent 2,
and access token 3 to sub-agent 3.
The sub-agent(s) validate the received access token* and task
credential, and validate the relationship of them. For example, to
validate the task credential, the sub-agent(s) check whether the
*subject* indicates a trusted leading agent, and whether the *proof*
value is right; to validate the relationship, the sub-agent(s) check
whether the task ID in the access token* is the same as the task
Song, et al. Expires 31 December 2026 [Page 11]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
credential, whether the key indicated by the access token* can be
used to validate the proof of the task credential, and whether the
token hash in the task credential is same as the hash of the access
token*.
If the task credential validation fails, the sub-agent(s) may send a
response message to the applier with a failure indication of
"invalid_credential". If the relationship validation fails, the sub-
agent(s) may send a response message to the applier with a failure
indication of "unknown_credential".
4.5. Access Token Verify
This section refers to step (F) and (G).
The sub-agent(s) execute the task according to message received in
step (E). When resources are needed, the sub-agent(s) request the
protected resource from the resource server and present the access
token*, as defined in [RFC6749]. Meanwhile, the sub-agent(s) send
the task credential to the resource server. The resource server
validates the access token*, as defined in [RFC6749], and validates
the task credential and the relationship between the access token*
and the task credential.
If the validation succeeds, the resource server may provide the
resource to the client(s).
5. Scope-Bounded Task Group Authorization
This section describes an optional enhancement to the static and
dynamic task group authorization in Section 3 and Section 4. It is
not a third task group formation policy; rather, it strengthens
either policy by bounding the authority delegated to the task group
as a whole and to each member. The authorization server issues a
group authorization token that caps the authority of the whole group,
and a member authorization token for each sub-agent whose authority
is no broader than, and in aggregate does not exceed, the group's
authority. This realizes least privilege at both the group and the
member level and limits the impact if a single sub-agent is
compromised.
Song, et al. Expires 31 December 2026 [Page 12]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
+--------+ +----------------+
| |--(A) Authorization Request--->| Resource |
| |<-(B) Authorization Grant------| Owner |
| | +----------------+
| |
|Leading | (C) Token Request +----------------+
| Agent |--(group req + member req(s))-->| |
| | | Authorization |
| | (D) Group Token + | Server |
| |<----Member Token(s)-----------| |
| | | |
| | (H) Revocation Request | |
| |--(group / member token)------>| |
+--------+ +----------------+
|
(E) Member Token (+ group token info)
|
v
+--------+ +----------------+
| Sub- |--(F) Member Token------------>| Resource |
| Agent |<-(G) Protected Resource-------| Server |
+--------+ +----------------+
Figure 3: Scope-Bounded Task Group Authorization Flow
Step (H) is performed when a sub-task or the whole task is completed,
or when policy requires token revocation; it is not part of the
initial token issuance.
5.1. Token Request and Issuance
This section refers to steps (A) through (E).
Before requesting tokens, the leading agent registers with the
authorization server as in Section 3.1. The leading agent's profile
may indicate whether it is authorized to manage a task group (e.g. a
"capability" value "manage task group"). The leading agent resolves
the user's requirement into one or more sub-tasks and selects the
sub-agent(s) for them. The selection of sub-agents for sub-tasks is
out of scope of this document; the leading agent may determine the
sub-agents locally or use an external discovery or management
function. The leading agent then obtains an authorization grant from
the resource owner as in Section 3.2.
When scope-bounded task group authorization is used, the token
request to the authorization server includes the following
parameters:
Song, et al. Expires 31 December 2026 [Page 13]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
group_req Information used to request the group authorization token.
It includes the task information, and may include the group
information and the leading agent information.
member_req One or more entries, each used to request a member
authorization token. Each entry includes the sub-agent
information, and may include the group information.
The authorization server authenticates the leading agent and
validates that it is capable of requesting tokens on behalf of a task
group, as in Section 3.3. If validation succeeds, the authorization
server generates a group authorization token based on the task
information, and a member authorization token for each sub-agent
based on the sub-agent information and the group permission scope.
The authorization server ensures that each member permission scope is
within the group permission scope: the member resource set, service-
type set, and operation set are each no broader than the
corresponding group set. For quantitative limits, such as access
count or quota, the sum of the limits assigned to all member tokens
does not exceed the corresponding limit of the group token.
The group permission scope and member permission scope are each
expressed in terms of one or more of: the set of resources, the set
of service types, the set of permitted operations (e.g. read, query,
update, subscribe), and a maximum access count. A minimal example,
in which the member token is bounded by the group token, is:
group token: "grp":"G1",
"scope": { "resources":["r1","r2"],
"operations":["read","update"],
"max_calls":100 }
member token: "grp":"G1", "sbj":"A1",
"scope": { "resources":["r1"],
"operations":["read"],
"max_calls":20 }
The authorization server returns the group authorization token and
the member authorization token(s) to the leading agent. If a
requested member permission scope cannot be bounded by the group
permission scope, the authorization server may return a new error
Song, et al. Expires 31 December 2026 [Page 14]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
"scope_exceeds_group". The leading agent then delivers each member
authorization token to the corresponding sub-agent, together with the
sub-task identifier. The leading agent may also provide a reference
to the group token when the sub-agent needs to verify that the member
token is associated with a valid task group.
5.2. Member Token Use
This section refers to steps (F) and (G).
The sub-agent executes its sub-task. When resources are needed, the
sub-agent requests the protected resource from the resource server
and presents its member authorization token, as defined in [RFC6749].
The resource server validates the member authorization token and
verifies that the requested resource, service type, and operation are
within the member permission scope, and that the member's access
count has not been exceeded. The resource server may additionally
verify, from the "grp" claim, that the member belongs to the expected
task group. If the requested access is outside the member permission
scope, the resource server denies the request.
5.3. Token Revocation
This section refers to step (H).
When the whole task is completed, the leading agent sends a
revocation request to the authorization server to revoke the group
authorization token, optionally together with the member
authorization token(s). When a sub-task is completed, the leading
agent sends a revocation request to revoke the member authorization
token of the sub-agent that executed the sub-task.
Upon receiving a revocation request, the authorization server
verifies that the leading agent has the permission to manage the task
group (see Section 5.1) before revoking the token(s). After revoking
a member authorization token, the authorization server may release
the corresponding sub-agent instance. The group authorization token
and member authorization token may be configured with a validity
period, based on which the authorization server maintains token
state. The leading agent may also send sub-task execution
information that the authorization server uses to maintain the member
authorization token(s).
6. Security Considerations
This section discusses security considerations specific to multi-
agent task group authorization.
Song, et al. Expires 31 December 2026 [Page 15]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
6.1. Least Privilege and Permission Attenuation
The two-tier token model in Section 5 enforces least privilege at two
levels. The group authorization token bounds the total authority
delegated to a task group, and each member authorization token is no
broader than the group permission scope. Because the authorization
server ensures that the member scopes are within the group scope and
that quantitative limits sum to no more than the group's, a leading
agent cannot, by partitioning work across many sub-agents, cause the
group to collectively exercise more authority than was granted to the
group as a whole.
6.2. Containment of Compromised Sub-Agents
A compromised sub-agent can only act within its member permission
scope, which is typically much narrower than the group permission
scope. This limits the impact of a single compromised member. Per-
sub-task member token revocation (Section 5.3) further reduces
exposure by removing a member's authority as soon as its sub-task
completes, rather than waiting for the whole task to finish.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
7.2. Informative References
[multi-agent-research-system]
Anthropic, "How we built our multi-agent research system",
13 June 2025.
Authors' Addresses
Yurong Song
Huawei
Email: songyurong1@huawei.com
Song, et al. Expires 31 December 2026 [Page 16]
Internet-Draft OAuth2.0 Ext. for Multi-Agent Collab June 2026
Lun Li
Huawei
Email: lilun20@huawei.com
Yuning Jiang
Huawei Singapore
Email: jiangyuning2=40h-partners.com@dmarc.ietf.org
Faye Liu
Huawei Singapore
Email: liufei19@huawei.com
Song, et al. Expires 31 December 2026 [Page 17]