概述
本文介紹 Agent ID Guard 的許可權模型與配置方法，包括如何控制用戶端訪問 Agent 的入站許可權、控制 Agent 訪問後端服務的出站許可權，以及如何通過身份鏈路將入站身份與出站調用進行聯動，協助您在 Agent ID Guard 中為 AI Agent 構建一套完整、最小化、可審計的許可權管控體系。
背景資訊
隨著 AI Agent 在企業內的大規模落地，Agent 不再只是一個被動響應使用者的"對話機器人"，而是會自主決策、自主調用大模型、MCP Server、企業內部介面以及三方 SaaS 服務的"數字員工"。Agent 的這種自主性和鏈式調用特性，打破了傳統的"使用者→應用→資源"二元授權模型，帶來了"誰在代表誰執行什麼"的新鏈式傳遞問題。
在一個典型的 Agent 調用鏈路 User → Client → Agent → 大模型 / 三方服務 / 企業服務中，如果不對每一段調用做嚴格的身份和許可權管控，會出現以下典型風險：
用戶端越權調用 Agent：任何拿到 Agent 介面地址的用戶端應用都能直接發起請求，無法限制"哪個應用、代表哪個使用者"才能調用某個 Agent。
Agent 擁有"超級許可權"：研發為了讓 Agent"什麼都能幹"，往往會給 Agent 配置 Administrator 層級的下遊存取權限。一旦 Agent 被提示詞注入攻擊，就相當於一個擁有最高許可權的"內鬼"。
上下文與身份丟失：在 User → Agent A → Agent B → 資料庫這種長鏈路中，資料庫只看到 Agent B，無法溯源到原始發起請求的使用者，審計和合規無法落地。
憑據明文濫用：API Key、Client Secret 等長期憑據被寫入程式碼在 Agent 代碼裡，存在嚴重的泄漏風險。
Agent ID Guard 的 Agent 身份安全圍繞 Agent 這一中心身份，將上述風險拆解為入站許可權（Client → Agent）和出站許可權（Agent → 下遊服務）兩個方向，分別提供細粒度的許可權控制和審計能力。
關於 Agent 身份安全的整體介紹，請參見什麼是 Agent 身份安全。
Agent ID 工作流程
許可權模型核心概念
五大角色
角色 | 業務含義 | 在 Agent ID Guard 中的對應實體 |
User（使用者） | 真正"按下按鈕"的自然人，例如員工小王 | Agent ID Guard 賬戶（含組織/分組） |
Client（用戶端） | 使用者直接接觸的前端入口，例如企業門戶、案頭應用、小程式 | "OIDC With M2M 應用"（具備登入互動能力） |
Agent | 接收使用者/用戶端請求並自主調用下遊能力的 AI 服務 | "Agent 應用"（同時具備：被呼叫者 + 調用方雙重身份） |
Resource Server（下遊服務） | 實際承載業務資料/能力的後端，例如 HR 系統、知識庫、三方 SaaS | 大模型、企業服務、三方服務，作為資源服務被Agent調用 |
Agent ID Guard | 頒發與校正令牌、登記授權關係 | 阿里雲 Agent ID Guard（本產品） |
一個 Agent 在 Agent ID Guard 裡同時扮演兩種角色：作為"被呼叫者"（被用戶端發起調用）時它是 Resource Server；作為"調用方"（向下遊發起調用）時它是 Client。這一"雙重身份"是出站/入站聯動的基礎。
入站許可權 vs 出站許可權：兩條邊、兩套配置
許可權管控示意圖
Token Exchange（令牌交換）：許可權收斂的"轉乘閘機"
Token Exchange（RFC 8693）可以理解為身份系統裡的轉乘閘機：你拿著原車票（入站存取權杖）走到閘機前，閘機校正後，給你一張只能去下一站、只能坐這一節車廂的新車票（出站存取權杖）。原車票不能直接乘坐下一段，新車票也不能回到上一段。
概念類比 | 含義 |
原車票 = 入站存取權杖 | 使用者給用戶端，用戶端調 Agent 時使用 |
閘機 = Agent ID Guard 的令牌端點（grant_type = token-exchange） | 校正原票合法性、檢查出站授權關係、按最小化原則簽發新票 |
新車票 = 出站存取權杖 | 僅在"本次去往的下遊服務 + 申請到的 scope 許可權"範圍內可用 |
閘機記錄 = 出站存取權杖中的記錄 _idaas_imp / _idaas_exchange_count | 留痕，便於回溯 |
入站許可權：哪一個用戶端能調用 Agent
背景
Agent 一旦發布，理論上任何拿到它對外端點的程式都可能嘗試調用。如果不做入站訪問管控，會出現兩類風險：
未授權調用：陌生應用拿到了 Agent 的 URL，偽造一張其他 IdP 頒發的令牌或隨意構造請求來試探。
越權調用：合法接入方申請了過寬的 scope，例如本來只應被允許"訪問 Agent"的用戶端，卻拿到了"調用 Agent 的管理介面"的許可權。
情境
某 IDaaS 執行個體下，企業門戶（OIDC With M2M 應用用戶端 A）和移動端 App（OIDC With M2M 應用用戶端 B）都接入了同一個"AI 請假助手"Agent。需要確保：
用戶端 A、B 都需在 Agent ID Guard 登記後，才能攜帶入站存取權杖調用 Agent。
用戶端 A 只能用 agent.access 這一最小 scope 進入 Agent；它不能拿到 Agent 上其他更高許可權的 scope。
用戶端 C（未接入或未授權）即便偽造一張看似合法的令牌，也無法通過 Agent 的校正。
痛點
反面做法 | 風險 |
Agent 內自己寫一段 IP 白名單 | IP 是網路層訊號，不能代表"誰在調"；動態環境下維護成本高 |
Agent 自己校正 API Key | 每接入一個用戶端就要發一把 Key，輪換、撤銷、審計全部脫離 Agent ID Guard |
不做 audience（受眾）校正，只看令牌簽名 | 一張本應給別的應用的令牌可能被串用，等於把許可權邊界完全交給令牌持有人 |
解決方案
把"用戶端 → Agent"這條邊的授權關係沉澱到 Agent ID Guard，由 Agent ID Guard 在頒發入站存取權杖時按授權關係裁剪 audience（受眾）和 scope，由 Agent 在校正入站存取權杖時強制核對 audience（受眾）和 scope。
入站許可權的三個控制點：
控制點 | 在哪生效 | 失敗時的表現 |
1、用戶端是否被授權調此 Agent | Agent ID Guard 頒發入站存取權杖時檢查 | Agent ID Guard 直接拒絕授權請求或不簽發包含目標 audience（受眾）的令牌 |
2、入站存取權杖.audience（受眾）是否等於 Agent 的受眾標識 | Agent 接收請求、校正入站存取權杖時檢查 | Agent 返回 401/403 |
3、入站存取權杖.scope 是否包含本次訪問所需 scope | Agent 接收請求、按介面路由校正時檢查 | Agent 返回 403 + scope 許可權校正失敗 |
出站許可權：Agent 能做什麼
背景
Agent 接到使用者請求後，往往要調用一個或多個下遊服務來完成任務。下遊可能是：
企業自有 API（例如 HR、CRM、ERP）
三方 SaaS（例如 GitHub、飛書、Salesforce）
大模型 / 向量資料庫 / 知識庫
對這些下遊而言，Agent 是一個新型"用戶端"——它不是某個固定使用者的瀏覽器，而是一段可能被多使用者共用、由 LLM 決策的程式。如果不在出站側加約束，Agent 會變成一個"超級應用"，掌握所有下遊服務的訪問能力。
情境
延續"AI 請假助手"案例：助手需要調用 HR 系統的兩個介面：
GET /user/read → 需要 scope user.read
POST /user/write → 需要 scope user.write
需求：
Agent 可以在使用者上下文中調用這兩個介面。
Agent 不能調用 HR 系統的其他介面（例如 admin.*）。
Agent 不能調用 CRM、知識庫等其他下遊（除非另行授權）。
使用者撤銷同意後，Agent 立即失去出站調用能力。
痛點
反面做法 | 風險 |
Agent 直接拿使用者的入站存取權杖去調下遊 | 入站存取權杖的 audience（受眾）是 Agent，不是下遊——下遊本應拒絕；若下遊不嚴格校正 audience（受眾），將形成"令牌串用"漏洞 |
Agent 用一張固定的 Service Account 令牌調下遊 | 丟失使用者上下文，下遊無法做行級許可權和審計 |
在 Agent 內寫入程式碼 AccessKey/AppSecret | 憑據輪換困難；多 Agent 情境下憑據複用，審計黑洞 |
解決方案：出站授權 + Token Exchange
把"Agent → 下遊服務"這條邊的授權關係也沉澱到 Agent ID Guard：
在 Agent ID Guard 中把下遊服務聲明為一個 Resource Server（OIDC With M2M 應用），聲明它的受眾標識、scope 列表（例如 user.read、user.write、admin.delete……）。
在 Agent ID Guard 中建立"Agent → 下遊服務"的出站授權，勾選允許 Agent 申請的 scope 子集（例如只勾 user.read）。
Agent 在調用下遊前，用剛收到的入站存取權杖走一次 Token Exchange，向 Agent ID Guard 申請目標下遊的出站存取權杖，scope 在出站授權範圍內自由選擇。令牌交換流程示意圖如下：
端到端綜合情境：入站 + 出站的聯動
本章把前文逐條概念串成一個完整故事："AI 請假助手"代員工小王查詢年假。
角色與配置
實體 | 在 Agent ID Guard 中的標識 |
Agent ID Guard | idaas_jbfqz555uvm3n5a3vfuxyzxxxx / <YOUR-IDAAS>.aliyunidaas.com |
使用者 | user_froj2vye7d46cf32bvp5utxxxx（小王） |
用戶端（OIDC With M2M 應用） | app_nfiiybmikzo2fnmabpectnxxxx |
Agent 應用 | app_niicndynmcf72rqvkw6szvxxxx，受眾 agent-app_niicndynmcf72rqvkw6szvxxxx，scope agent.access |
下遊企業服務（HR） | 受眾 example:audience（受眾），scope user.read、user.write |
授權關係：
入站：用戶端 → Agent，已授權 agent.access。
出站：Agent → HR 服務，已授權 user.read、user.write。
使用者授權：用戶端已授權給小王。
端到端時序
小王 → 用戶端：登入企業門戶
用戶端 → Agent ID Guard：引導使用者前往授權頁面
Agent ID Guard → 小王：展示授權同意頁"是否允許企業門戶使用 AI 請假助手？"
小王 → Agent ID Guard：點擊同意
Agent ID Guard → 用戶端：授權完成，返回企業門戶（獲得入站存取權杖）
小王 → 用戶端："還剩幾天年假？"
用戶端 → Agent：攜帶入站存取權杖，請求 AI 請假助手
Agent：驗證令牌有效，判斷需要查詢 HR 系統
Agent → Agent ID Guard：發起令牌交換（目標：HR 服務，要求的權限：查詢使用者資訊）
Agent ID Guard：驗證請求合法性，檢查 AI 助手是否被允許訪問 HR 服務
Agent ID Guard → Agent：頒發出站存取權杖（允許以小王的身份查詢 HR 服務）
Agent → HR：攜帶出站存取權杖，查詢小王的年假
HR：驗證令牌有效，僅返回小王本人的資料
HR → Agent：返回小王的年假資料
Agent → 用戶端：產生回答
用戶端 → 小王："您還剩 X 天年假"
常見問題
為什麼用戶端拿到的 Access Token 中 scope 欄位是空的？
請檢查：
用戶端請求授權時是否傳入了正確格式的 scope 參數（必須是 audience|scope 格式）。
Agent 的 Scope 是否已通過入站授權授予該用戶端。
如果是手動授與類型的 Scope，是否已為當前登入使用者單獨授權。
Token Exchange 介面返回失敗，怎麼排查？
常見原因：
subject_token 已到期或已被吊銷。
subject_token 對應的受眾不是 Agent（即用戶端沒有訪問 Agent 的許可權）。
client_id 不是被授權可以發起 Token Exchange 的用戶端（必須是 Agent 節點對應的應用）。
請求的 audience（受眾）|scope 未授權給該 Agent（出站授權缺失）。
Agent ID Guard 不允許用戶端用"自己申請的令牌"做令牌交換。
詳細的錯誤碼與排查方法請參見Token Exchange 配置指導。
為什麼 Agent 調用大模型 API Key 節點時不需要手動出站授權？
大模型節點和三方服務節點的出站授權本質是"資料許可權"，Agent ID Guard 在建立 Agent 時會自動初始化一條該 Agent 專屬的授權規則。添加大模型/三方服務節點時，系統會自動把對應憑據加入該專屬授權規則，使用者無需手動操作。如需變更，可直接刪除節點（即從專屬授權規則中移除資源）。
刪除 Agent 工作流程中的節點會發生什嗎？
刪除節點僅解除該節點與當前 Agent 的關係，不會刪除底層應用或憑據：
刪除用戶端節點：解除該用戶端對該 Agent 的入站授權，用戶端應用本身保留（如需刪除，請前往應用管理 → M2M 應用）。
刪除大模型 / 三方服務節點：將該憑據從 Agent 專屬授權規則中移除，憑據本身保留（如需刪除，請前往資產中心 → 憑據）。
刪除企業服務節點：解除該 Agent 對該企業服務 Scope 的出站授權，企業服務應用保留，出站授權詳情參考Agent ID Guard 出站授權。