Agent permission management - Identity as a Service - Alibaba Cloud Documentation Center

Overview

This topic describes the permission model and configuration methods of Agent ID Guard, including how to control inbound permissions for clients accessing Agents, how to control outbound permissions for Agents accessing backend services, and how to link inbound identities with outbound calls through identity chains. This helps you build a complete, least-privilege, and auditable permission governance system for AI Agents in Agent ID Guard.

Background information

As AI Agents are deployed at scale within enterprises, an Agent is no longer just a passive chatbot that responds to users. Instead, it has become a "digital worker" that autonomously makes decisions and invokes large language models (LLMs), MCP Servers, internal enterprise APIs, and third-party SaaS services. The autonomy and chained invocation characteristics of Agents break the traditional "user → application → resource" two-party authorization model, introducing a new chain-of-delegation problem: "who is acting on behalf of whom to do what?"

In a typical Agent invocation chain — User → Client → Agent → LLM / Third-party service / Enterprise service — if strict identity and permission controls are not enforced at each segment, the following risks arise:

Unauthorized client invocation of an Agent: Any client application that obtains the Agent's endpoint address can send requests directly, with no way to restrict "which application, on behalf of which user" is allowed to call a specific Agent.
Agent with "super privileges": To enable an Agent to "do everything," developers often grant the Agent Administrator-level downstream access permissions. If the Agent is compromised by a prompt injection attack, it effectively becomes an insider with the highest privileges.
Lost context and identity: In long chains such as User → Agent A → Agent B → Database, the database only sees Agent B and cannot trace back to the original user who initiated the request, making auditing and compliance impossible.
Plaintext credential abuse: Long-lived credentials such as API keys and client secrets are hardcoded in Agent code, posing serious leakage risks.

Agent ID Guard's Agent identity security centers on the Agent as the core identity, decomposing the risks above into two directions: inbound permissions (Client → Agent) and outbound permissions (Agent → downstream services), providing fine-grained permission control and audit capabilities for each.

For an overview of Agent identity security, see What is Agent identity security.

Agent ID workflow

Core concepts of the permission model

Five roles

Role	Business meaning	Corresponding entity in Agent ID Guard
User	The natural person who actually "presses the button," for example, employee Xiao Wang	Agent ID Guard account (including organizations and groups)
Client	The frontend entry point that users interact with directly, such as an enterprise portal, desktop application, or mini program	"OIDC With M2M application" (with login interaction capabilities)
Agent	An AI service that receives user or client requests and autonomously invokes downstream capabilities	"Agent application" (with dual identity: callee + caller)
Resource Server (downstream service)	The backend that actually hosts business data or capabilities, such as an HR system, knowledge base, or third-party SaaS	Large language models, enterprise services, and third-party services, serving as resource services called by the Agent
Agent ID Guard	Issues and verifies tokens, registers authorization relationships	Alibaba Cloud Agent ID Guard (this product)

An Agent plays two roles simultaneously in Agent ID Guard: as a "callee" (invoked by clients), it acts as a Resource Server; as a "caller" (invoking downstream services), it acts as a Client. This "dual identity" is the foundation for linking outbound and inbound permissions.

Inbound permissions vs. outbound permissions: two edges, two configurations

Permission control diagram

Token Exchange: the "transfer gate" for permission convergence

Token Exchange (RFC 8693) can be understood as a transfer gate in an identity system: you approach the gate with your original ticket (inbound access token), the gate validates it, and then issues you a new ticket that only allows access to the next stop, in this specific car (outbound access token). The original ticket cannot be used for the next leg, and the new ticket cannot be used for the previous leg.

Concept analogy	Meaning
Original ticket = Inbound access token	Issued to the client by the user; used when the client calls the Agent
Gate = Agent ID Guard token endpoint (grant_type = token-exchange)	Validates the original ticket, checks outbound authorization relationships, and issues a new ticket based on the least-privilege principle
New ticket = Outbound access token	Valid only for "the specific downstream service + the granted scope permissions"
Gate record = Claims in the outbound access token: _idaas_imp / _idaas_exchange_count	Leaves an audit trail for traceability

Inbound permissions: which clients can call an Agent

Background

Once an Agent is published, theoretically any program that obtains its external endpoint can attempt to call it. Without inbound access control, two types of risks arise:

Unauthorized invocation: An unknown application obtains the Agent's URL and forges a token issued by another IdP or constructs arbitrary requests to probe the Agent.
Over-privileged invocation: A legitimate integrator requests overly broad scopes. For example, a client that should only be allowed to "access the Agent" obtains permissions to "call the Agent's management APIs."

Scenario

Within an IDaaS instance, an enterprise portal (OIDC With M2M application Client A) and a mobile app (OIDC With M2M application Client B) are both integrated with the same "AI Leave Assistant" Agent. The following requirements must be met:

Both Client A and Client B must be registered in Agent ID Guard before they can call the Agent with an inbound access token.
Client A can only use the minimal scope agent.access to invoke the Agent; it cannot obtain other higher-privilege scopes on the Agent.
Client C (unregistered or unauthorized) cannot pass the Agent's validation even if it forges a seemingly legitimate token.

Pain points

Anti-pattern	Risk
Implementing IP whitelists within the Agent	IP addresses are network-layer signals that cannot represent "who is calling"; maintenance costs are high in dynamic environments
Having the Agent validate API keys on its own	A new key must be issued for every client; rotation, revocation, and auditing all happen outside Agent ID Guard
Not validating audience, only checking token signature	A token intended for another application may be reused, effectively handing the permission boundary entirely to the token holder

Solution

Centralize the "Client → Agent" authorization relationship in Agent ID Guard. Agent ID Guard trims the audience and scope when issuing inbound access tokens based on authorization relationships, and the Agent enforces audience and scope validation when verifying inbound access tokens.

The three control points for inbound permissions:

Control point	Where it takes effect	Behavior on failure
1. Is the client authorized to call this Agent?	Checked when Agent ID Guard issues the inbound access token	Agent ID Guard directly rejects the authorization request or does not issue a token containing the target audience
2. Does the inbound access token audience match the Agent's audience identifier?	Checked when the Agent receives a request and validates the inbound access token	Agent returns 401/403
3. Does the inbound access token scope include the scope required for this access?	Checked when the Agent receives a request and validates against the API route	Agent returns 403 + scope validation failed

Outbound permissions: what an Agent can do

Background

After receiving a user request, an Agent often needs to call one or more downstream services to complete the task. Downstream services may include:

Enterprise-owned APIs (such as HR, CRM, and ERP)
Third-party SaaS (such as GitHub, Lark, and Salesforce)
LLMs / vector databases / knowledge bases

To these downstream services, the Agent is a new type of "client" — it is not a fixed user's browser, but a program that may be shared by multiple users and whose behavior is determined by an LLM. Without outbound constraints, the Agent becomes a "super application" with access to all downstream services.

Scenario

Continuing the "AI Leave Assistant" example: the assistant needs to call two interfaces of the HR system:

GET /user/read → requires scope user.read
POST /user/write → requires scope user.write

Requirements:

The Agent can call these two interfaces within the user's context.
The Agent cannot call other interfaces of the HR system (such as admin.*).
The Agent cannot call other downstream services such as CRM or knowledge bases (unless separately authorized).
After the user revokes consent, the Agent immediately loses its outbound invocation capability.

Pain points

Anti-pattern	Risk
Agent directly uses the user's inbound access token to call downstream services	The inbound access token's audience is the Agent, not the downstream service — the downstream service should reject it; if the downstream service does not strictly validate audience, a "token reuse" vulnerability is created
Agent uses a fixed Service Account token to call downstream services	User context is lost; the downstream service cannot enforce row-level permissions or audit
Hardcoding AccessKey/AppSecret in the Agent	Credential rotation is difficult; credential reuse across multiple Agents creates an audit blind spot

Solution: outbound authorization + Token Exchange

Centralize the "Agent → downstream service" authorization relationship in Agent ID Guard as well:

In Agent ID Guard, declare the downstream service as a Resource Server (OIDC With M2M application), specifying its audience identifier and scope list (for example, user.read, user.write, admin.delete, and so on).
In Agent ID Guard, establish outbound authorization from "Agent → downstream service" and select the subset of scopes that the Agent is allowed to request (for example, only user.read).
Before calling the downstream service, the Agent performs a Token Exchange using the inbound access token it received, requesting an outbound access token from Agent ID Guard for the target downstream service. The scope can be freely selected within the outbound authorization range. The following figure shows the Token Exchange flow:

End-to-end scenario: linking inbound and outbound

This section connects the concepts described above into a complete story: the "AI Leave Assistant" queries annual leave on behalf of employee Xiao Wang.

Roles and configuration

Entity	Identifier in Agent ID Guard
Agent ID Guard	idaas_jbfqz555uvm3n5a3vfuxyzxxxx / <YOUR-IDAAS>.aliyunidaas.com
User	user_froj2vye7d46cf32bvp5utxxxx (Xiao Wang)
Client (OIDC With M2M application)	app_nfiiybmikzo2fnmabpectnxxxx
Agent application	app_niicndynmcf72rqvkw6szvxxxx, audience: agent-app_niicndynmcf72rqvkw6szvxxxx, scope: agent.access
Downstream enterprise service (HR)	audience: example:audience, scope: user.read, user.write

Authorization relationships:

Inbound: Client → Agent, authorized with agent.access.
Outbound: Agent → HR service, authorized with user.read and user.write.
User authorization: The client has authorized Xiao Wang.

End-to-end sequence

Xiao Wang → Client: Logs in to the enterprise portal
Client → Agent ID Guard: Redirects the user to the authorization page
Agent ID Guard → Xiao Wang: Displays the consent page "Allow the enterprise portal to use the AI Leave Assistant?"
Xiao Wang → Agent ID Guard: Clicks "Agree"
Agent ID Guard → Client: Authorization complete, returns to the enterprise portal (obtains the inbound access token)
Xiao Wang → Client: "How many days of annual leave do I have left?"
Client → Agent: Sends a request to the AI Leave Assistant with the inbound access token
Agent: Validates the token and determines that the HR system needs to be queried
Agent → Agent ID Guard: Initiates a Token Exchange (target: HR service, required permission: query user information)
Agent ID Guard: Validates the request legitimacy and checks whether the AI assistant is allowed to access the HR service
Agent ID Guard → Agent: Issues the outbound access token (allowing queries to the HR service on behalf of Xiao Wang)
Agent → HR: Sends the outbound access token to query Xiao Wang's annual leave
HR: Validates the token and returns only Xiao Wang's data
HR → Agent: Returns Xiao Wang's annual leave data
Agent → Client: Generates a response
Client → Xiao Wang: "You have X days of annual leave remaining"

FAQ

Why is the scope field empty in the access token obtained by the client?

Check the following:

Whether the client passed the scope parameter in the correct format when requesting authorization (it must be in the audience|scope format).
Whether the Agent's scope has been granted to the client through inbound authorization.
If the scope is of the manual authorization type, whether it has been individually authorized for the currently logged-in user.

How do I troubleshoot Token Exchange failures?

Common causes:

The subject_token has expired or been revoked.
The audience of the subject_token is not the Agent (meaning the client does not have permission to access the Agent).
The client_id is not authorized to initiate Token Exchange (it must be the application corresponding to the Agent node).
The requested audience|scope has not been authorized for this Agent (outbound authorization is missing).
Agent ID Guard does not allow the client to perform token exchange with "its own requested token."

For detailed error codes and troubleshooting methods, see Token Exchange configuration guide.

Why does calling an LLM API Key node from an Agent not require manual outbound authorization?

The outbound authorization for LLM nodes and third-party service nodes is essentially "data permission." Agent ID Guard automatically initializes an exclusive authorization rule for the Agent when it is created. When an LLM or third-party service node is added, the system automatically includes the corresponding credential in this exclusive authorization rule — no manual operation is required. To make changes, simply delete the node (which removes the resource from the exclusive authorization rule).

What happens when a node is deleted from an Agent workflow?

Deleting a node only disassociates it from the current Agent. It does not delete the underlying application or credential:

Deleting a client node: Revokes the client's inbound authorization for the Agent. The client application itself is retained (to delete it, go to Application Management → M2M Applications).
Deleting an LLM or third-party service node: Removes the credential from the Agent's exclusive authorization rule. The credential itself is retained (to delete it, go to Asset Center → Credentials).
Deleting an enterprise service node: Revokes the Agent's outbound authorization for the scope of that enterprise service. The enterprise service application is retained. For details about outbound authorization, see Agent ID Guard outbound authorization.