]> China Mobile

yaokehan@chinamobile.com

Agent Communication Network(ACN) is becoming a promising and fundamental infrastructure for most vertical industries. To construct and build a scalable and trustable ACN, authentication and authorization of AI agents are some of the most important issues that need to be solved. This document extends the model of OAuth 2.0 and proposes new workflows for AI agent authentication and authorization.

Introduction With the rapid development of large language models(LLMs) and AI applications, AI agent is becoming an emerging entity that can help improve working efficiency. There are different types of AI agents, e.g. physical and virtual entities, and many promising use cases of AI agents have been mentioned in . All of these AI agents will join together to build a new Internet infrastructure, which is called as Agent Communication Network(ACN). To build such future nework is not easy, requirements on new protocols are also mentioned in . For example, discovery mechasims of AI agents, routing and connection, etc. But the most intuitive and important part for protocols evolution is the authentication and authorization. The complexity of AI agent authentication and authorization exists in that agent may have different roles and capabilities. AI agents may work On-behalf-of(OBO) users, itself, or other AI agents. In different cases, there are different requirements on the authentication and authorization, leading to different workflows. More importantly, agents may communicate with API proxy server, like MCP server to call API and access external resources, this make the authentication and authorization problem more complex. considers the case when AI agents work OBO their users, and defines the extension of OAuth 2.1 for AI agents. This document further considers more cases on AI agents authentication and authorization based on OAuth extensions.

Definition of Terms

• AI Agent: an entity with built-in intelligence, which can help or replace humans implement jobs and improve work efficiency.
• Types of AI Agents:
  • Physical AI Agent: an physical entity with embedded intelligence, usually refers to some AI terminals, e.g., AI robot, embodied AI.
  • Virtual AI Agent: an virtual entity that can provide intelligence, usually refers to some softwarized AI assistant, e.g., a chat assistant with a mobile application.
• Ownership and Roles of AI Agents:
  • OBO User: the agent may require the authorization from user(s) to implement jobs for user(s).
  • OBO Agent Itself: the agent itself has identification and implements jobs and represents itself.
  • OBO Other Agent(s): the agent may represent other agents to implement some jobs, given that other agents may not have the capabilities to implement the jobs.
• Agent Communication Network(ACN): a network infrastructure which supports the interconnection, routing, capabilities announcement, and task collaboration of different types of AI agents.
• Agent Identifier(AID): An independent identifier of AI agent.
• API Proxy Server: A middlebox server that helps AI agent to call APIs or access external data resources. A typical example is the Model Context Protocol(MCP) server.
• Domain:
  • Task-wise Domain: a temporary domain that is created to target on a specific job, when the job is finished, the domain is destroyed. A typical example is a domain that is created by 5G/6G core netowrk.
  • Application Domain: a durable domain that is created by a specific application, e.g., a web or mobile application offerred by cloud service providers.
  The definition of resource server, resource owner, authorization server, and client reuse the definition in .

Aauth: Agent OBO Its User(s)

Example Case A typical use case of AI agent on-behalf-of the user to access public resources can be an virtual agent assitant. For example, a trip planning app assistant helps the user to plan trips. This case is obvious and similar ones have been mentioned in . In this case, when the trip assitant needs to search for the current balance of the user, it needs the authorization of the user to access his bank account app. While it may also need to search for hotels, and it may require the account of the user under some booking applications. In addition, it may also need to use some of the data stored in the cloud personal gallery, which may require temporary access token. Therefore, AI agent OBO user(s) need different levels of authentication and authorization to access these resources.

Model shows the extension of the OAuth 2.0 model proposed in . There are several updates and new components in this model. The big difference is the introduction of AI agent and API proxy server. If under traditional OAuth 2.0 model, client(AI agent) will directly communicate with resource owners and resource servers. But this is not efficient and scalable in the AI era, since an agent may consulting many resource owners at the same time, and different resource owners may require different levels of privileges to access the protected resources. To overcome the issue, industries have proposed Model Context Protocol(MCP). It introduces MCP server and protocol to let AI agents only communicate with the MCP server to request for resources. The MCP server will help AI agents to do API calling and specific data resource access. In , MCP server refers to the API proxy server. In the diagram, API proxy server will communicate with different resource owners and resource servers. The agent may also support communicate directly with the resource owner and resource server. For example, the resource owner is another agent that is interconnected with the agent itself.

AI Agent OBO User Workflow Resource| |+------------+Owner 1 | || 3 +--------+ || 8 +--------+ || +-------->|Resource| +------+ || |+--------+Server 1| | +--+| || 9 +--------+ | <---+ || +-------> API +------+| | | Proxy| | | +-----|Server<-------+ | | | | | | | +-----+ | | | <-+ | 2 +--------+ | | +---^+-+ | +--------->|Resource| 1,7 | | || +--------------+Owner 2 | | |4,10 || 3 +--------+ | | || 8 +--------+ | | |+----------------->|Resource| +----+ 0 +-----+ | | +-------------------+Server 2| |User+--------> +---+ | 9 +--------+ | <--------+ <-----+ +----+ 11 | | 1 +--------+ | AI +----------------------->|Resource| |Agent<------------------------+Owner 3 | | | 4 +--------+ | +-----------+ 7 +--------+ | | +----------->|Resource| | <------------------------+Server 3| +--^-++ 9 +--------+ | | | | | | 5 +-------+ | +------------> Auth | +--------------+Servers| 6 +-------+ ]]>

Workflow The detailed workflow of is as follows:

• Step 0, the user initially asks for AI agent for some tasks via prompts.
• Step 1, the AI agent interprate the prompts and communicate with the API proxy server to search for particular data resources and implement function calling. Alternatively, the agent will ask the resource server for the grant if they are directly connected.
• Step 2, the API proxy server ask for multiple resource owners for the grant of the access of the protected data resources.
• Step 3, resource owners reply to the API server what authentication grant(e.g., authorization code) they need for the access of the required resource.
• Step 4, the API proxy server will gather messsages from different resource owners and reply to the AI agent containing multiple authorization grants from different resource owners. Alternatively, the resource owner 3 will replies to the agent with the authorization grant directly.
• Step 5, the AI agent communicates with different authorization servers with multiple authorization grants.
• Step 6, auth servers reply to the AI agent with the required access tokens.
• Step 7, AI agent replies to the API server with the required access tokens. Alternatively, it directly sends the access token to the resource server(resource server 3).
• Step 8, the API proxy server send different access tokens to different resource servers respectively.
• Step 9, resource servers send the protected data resources to the API proxy server. The resource server 3 directly sends the protected data resources to the AI agent.
• Step 10, the API proxy server replies to the AI agent with the information that it needs.
• Step 11, AI agent replies to the user with the answer.

Aauth: Agent OBO Itself

Example Case In addition to virtual AI agent, there is another type, physical AI agent. AI robots, embodied AI, and other AI terminals have differentiated capabilities to implement multiple jobs. For example, in a remote rescue case, an AI search and rescue vehicle, and an robot dog can be dynamically formed into a networked system. The robot dog can scan and transmit the live videos to remote console and control signals to the AI search and rescue vehicle, while the AI search and rescue vehicle can use its robotic arm to move obstacles based on the signals from the robot dog or the remote console. Some other similar cases are mentioned in .
Compared to the aforementioned case in which the agent is OBO its user, the major difference in this case is that agent need identification of itself, that is the agent identification(AID). In previous case, agent can be assigned a Client ID(CID). The scope of its authority is determined by its user, and is less than its users' authority scope. While if agent is OBO itself, it is the user. So it has the same privilege as the user. How to define the AID needs further discussion and is out of the scope of this document.

Model The model of the agent OBO itself can be extended from. As shown in , the AI agent is the resource owner. When assigned with some specific tasks, it may enable some software functions, and then it will trigger the client within these software functions for authentication and authorization.

AI Agent OBO Itself Workflow | Resource | | | | Owner | | |<-(B)-- Authorization Grant ---| (AI Agent or | | | | Other owners) | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization | | Client | | Server | | |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource | | | | Server | | |<-(F)--- Protected Resource ---| | +---------+ +---------------+ ]]>

Workflow Detailed workflow is similar to , and will not be stated in detail.

Aauth: Agent OBO Other Agent(s)

Example Case This case is more complex, but may be required if AI agents have differentiated capabilities and need to collaborate to finish some jobs, whatever the agents are from intra-domain or inter-domain, which has been discussed in .
In this case, if one AI agent wants to access some protected data resources of other agents, or of the users of other agents. It needs the authorization from them. This is different compared to the situation that this agent only need to seek for grant from the user it represents.

Model shows the model when multiple agents work collaboratively, and there will be a chained authentication and authorization workflow. Before AI Agent A requests AI agent B to help it implement a job, there should be prior knowledge that both agents need mutual trust. If they come from the same domain, whatever it is a task-wise domain created by a console(e.g., 5G/6G core) or a durable domain created by a web application, they need verification from the 5G/6G core or the web application administrator. If they come from different domains, they may need verification from an open platform that organize and issue the AIDs. There are some ongoing work defining AID,. With this pre-verification, agents can communicate with each other. But when one agent(AI agent B) needs access of the protected data resource of the user of AI agent A or AI agent C itself, it still need temporary authentication and authorization. In this chained authentication and authorization workflow, the core idea here is to let the agent OBO user or the agent OBO itself always to communicate with the authorization server to get the access token.

AI Agent OBO Other Agents Workflow Resource| | | | <--------+Owner 1 | 7| |8 +-----> API | 4 +--------+ | | | | Proxy| ++-v--+ | +---|Server| 11 +--------+ | AI | | | | +-------->Resource| |Agent| | | | <--------+Server 1| | C | | | | | 12 +--------+ +-^-+-+ | | +------+ | | 2,10| | | | | |5,13 6,9| |1,14 | | +----+ | | +-----+ | | |User| | | | +---+ | | | | +---> <-----+ +-+^-+ +-----+ | 2 +--------+ || | AI +----------------------->|Resource| 0||15 |Agent<------------------------+Owner 2 | +-v+--+ | B | 5 +--------+ | AI | 6,14 | +-----------+ 10 +--------+ |Agent<-------+ | +----------->|Resource| | A +-------> <------------------------+Server 2| | | 1,9 +-----+ 13 +--------+ +--^-++ | | | | 7 +------+ | +--------------------------> Auth | +----------------------------+Server| 8 +------+ ]]>

Workflow The detailed workflow of is as follows: Step 0, a user asks its AI agent(AI agent A) for some help. Step 1, AI agent A redirects the help to Agent B when A is not capable, and Agent C asks for B's help too. Step 2, agent B ask API proxy server to call APIs. Agent may also request resource owner's grant for its protected data resources. Step 3, the API proxy server send requests to resource owner 1. Step 4, the resource owner 1 send access grant to the API proxy server. Step 5, the API proxy server and resource owner 2 send the access grant to AI agent B. Step 6, AI agent B redirects the the access grants to AI agent A or AI agent C, considering the resource belong to whom. Step 7, AI agent A and AI agent C send access grants to authorization servers. Step 8, authorization servers replies with authorization tokens. Step 9, Agent A and agent C pass the access tokens to agent B. Step 10, AI agent B passes the access tokens to API proxy server or resource owner 2, considering what resource agent B wants to access. Step 11, the API proxy server passes the access token to resource owner 1. Step 12, resource owner 1 gives the protected data resource to the API proxy server. Step 13, agent B gather the data resources from the API proxy server and resource owner 2. Step 14, agent B sends back the processing result to agent A or agent C. Step 15, agent A processes further and sends back the final result to the user.

Considerations on Other Important Factors

Grant Dynamicity mentions the mechasim to realize dynamic client registration. Whether and when to grant AI agents with short-lived or long-lived authentication and authorization may need further discussion, considering about various use cases that AI agents participant.

Specific Identity for AI Agent As the second and the third case mentions in the previous section, AI agents may have independent identities in ACN. The definition of AIDs is not within the scope of this document, but directly impacts the authentication and authorization methods.

Can AI Agents Represent Users to Consent Requests? In the third case mentioned in this document when agent is OBO other agents. This document assumes that agent can represent its user to request for access tokens, while the choice on whether to consent requests(authorization grant) is still left to the user or the agent(agent C). But it may evole to the situation that AI agent can represent its user to give permission if there are some pre-validation on the content scope that AI agent can give external grants independently.

Security Considerations There may exist security issues when spoofying AI agents seek for authentication and authorization for specific resources. Spoofying AI agents are created very similar to the validated AI agents. But they may hijack the access token to access the protected data resources from users or other agents. The methods to indentify and prevent these spoofying AI agents need further discussions.

IANA Considerations TBD.

Acknowledgements

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. Informative References Hellō Okta SPRIND The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. Five9 Cisco AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. WSO2 WSO2 This specification extends the OAuth 2.0 Authorization Framework [RFC6749] to enable AI agents to securely obtain access tokens for acting on behalf of users. It introduces the *requested_actor* parameter in authorization requests to identify the specific agent requiring delegation and the *actor_token* parameter in token requests to authenticate the agent during the exchange of an authorization code for an access token. The flow can be initiated by a resource server challenge, ensuring that user consent is obtained dynamically when access is attempted. This extension ensures secure delegation with explicit user consent, streamlines the authorization flow, and enhances auditability through access token claims that document the delegation chain from the user to the agent via a client application. This document defines the *Agent Authorization Grant*, an OAuth 2.1 extension for *confidential agent clients*—software or AI agents with long-lived identities—to request end-user consent and obtain access tokens via HTTP polling, Server-Sent Events (SSE), or WebSocket. It is heavily inspired by the core dance of the OAuth 2.0 Device Authorization Grant (RFC 8628) but is tailored for agents either long lived identities, and introduces scoped, natural-language descriptions and a reason parameter provided by the agent. DistributedApps.ai Amazon Web Services Intuit Cisco Systems The proliferation of AI agents requires robust mechanisms for secure discovery. This document introduces the Agent Name Service (ANS), a novel architecture based on DNS addressing the lack of a public agent discovery framework. ANS provides a protocol-agnostic registry mechanism that leverages Public Key Infrastructure (PKI) certificates for verifiable agent identity and trust. The architecture features several key innovations: a formalized agent registration and renewal mechanism for lifecycle management; DNS-inspired naming conventions with capability-aware resolution; a modular Protocol Adapter Layer supporting diverse communication standards (A2A, MCP, ACP, etc.); and precisely defined algorithms for secure resolution. This specification describes structured communication using JSON Schema and includes a comprehensive threat analysis. The result is a foundational agent directory service protocol addressing the core challenges of secure discovery and interaction in multi-agent systems, paving the way for future interoperable, trustworthy, and scalable agent ecosystems. Independent Researcher This document defines the agent:// protocol, a URI template-based framework as described in RFC 6570 for addressing, invoking, and interoperating with autonomous and semi-autonomous software agents. It introduces a layered architecture that supports minimal implementations (addressing and transport) and extensible features (capability discovery, contracts, orchestration). The protocol aims to foster interoperability among agents across ecosystems, platforms, and modalities, enabling composable and collaborative intelligent systems. 3GPP n.d.