Agent Authorization Center for User-Side Agent Authentication and Authorization

With the rapid advancement of large language models (LLMs) and agent technologies, intelligent agents are evolving from simple conversational tools into digital assistants capable of autonomously executing complex tasks. Agents can represent users in completing travel planning, ticket booking, information retrieval, online shopping, and other operations, increasingly functioning as digital proxies for human users. However, the widespread deployment of agents faces a critical challenge: when an agent needs to access third-party resource parties (such as websites, APIs, or cloud services) on behalf of a user, how can identity authentication and authorization be securely and efficiently accomplished? The traditional OAuth 2.0 framework assumes that authorization requests are initiated by users, who interact with the authorization server through a browser to complete authorization. However, the agent scenario introduces new characteristics: Agents may operate over extended periods, making it impractical to interrupt users for interactive authorization each time. Agents act on behalf of users, requiring a mechanism to express that "the user has pre-authorized this agent to act autonomously in this context". Authorization policies are highly personalized across users, necessitating centralized policy management. This document proposes an Agent Authorization Center (AAC) architecture that serves as a trust anchor between agents and resource parties. The AAC maintains user agent authorization policies and supports two authorization modes: Autonomous Approval and Human Authorization, extending the OAuth 2.0 flow to accommodate agent scenarios. This mechanism is primarily designed for user-side agents, which deployed on personal user devices, bound to individual users, and acting on their behalf. This document distinguishes between two agent deployment forms: User-side Agent: Deployed on personal user devices (smartphones, PCs, smart home devices), tightly bound to individual user identities, typically serving a single user. Examples include personal assistant agents that help users manage schedules, book tickets, and shop online. Service-side Agent: Deployed on cloud servers, natively supporting high concurrency and serving large numbers of users. Examples include customer service agents on e-commerce platforms and enterprise workflow automation agents. This document focuses on the user-side agent scenario, where the agent acts as a direct proxy for an individual user and requires personalized authorization policy management.

The AAC serves as the trust intermediary among users, agents, and resource parties, with the following responsibilities: Maintaining user identity information; Maintaining associations between users and agent groups, and between agent groups and individual agents; Maintaining autonomous access policies for agents (or agent groups); Making authorization decisions for agent access requests: autonomous approval or referral to human authorization.

The authorization flow for an Agent accessing a resource party on behalf of a user is as follows. Step 1: Agent sends an access request to the resource party, carrying the user identifier and the AAC identifier. Step 2: After receiving the access request, the resource party redirects the Agent to the AAC, triggering the authorization flow. In detail, the resource party sends an authorization guidance message to guide the Agent to initiate an access authorization request to the AAC corresponding to the AAC identifier. Step 3: On receiving the authorization guidance message, Agent sends an access authorization request to the AAC (carrying User ID, Agent ID, Resource Party information) in order to obtain an authorization code for accessing the resource party. Step 4: On receiving the access authorization request, AAC performs authorization mode decision: if the resource party is in the Agent's autonomous access list, select the Autonomous Approval mode; otherwise, select the Human Authorization mode (notify user for confirmation). Step 5: If the access authorization request is approved through either mode, AAC generates an authorization code and returns it to the Agent. Step 6: After receiving the authorization code, the Agent delivers the authorization code to the resource party (e.g., via the redirect URI). Step 7: The resource party exchanges the authorization code, redirect URI, and other information with the AAC's token endpoint to request an access token. Step 8: The AAC's authorization server returns an access token to the resource party, in which the user account identifier, the Agent identifier, and the AAC identifier should be included. Optionally, the token may include an authorization mode identifier indicating whether it was obtained through autonomous approval or human authorization. Step 9: The resource party validates the token and provides services according to the user's entitlements. In the Step 4, if the resource party is in the Agent's autonomous access list, it means a related policy is matched. The policy can be pre-configured by the user. Examples include: If the resource party is in the autonomous access list, the AAC directly approves the access authorization request (Autonomous Approval); If the resource party is in the forbidden list, the AAC rejects the access authorization request; If the resource party is not in any list, the AAC notifies the user for confirmation (Human Authorization). When the Autonomous Approval policy is matched, the AAC would autonomously approve the access authorization request without human in the loop. When the Human Authorization policy is matched, the AAC would approve the access authorization request based on the authorization instruction received from the user.