AI agent 跨系統辦事，該用誰的身分？

Larry

你可能會這樣向同事交代工作：「請 AI agent 幫我查客戶資料，再把結果寫進工單。」但對後面的系統來說，這句話少了幾個關鍵資訊：這是誰授權的、實際是哪個 agent 在執行，以及它可以做到哪一步。

第一個 API 驗證過使用者，不代表後面的客戶資料庫和工單 API 就能直接沿用同一份憑證。若所有操作都掛在共用服務帳號底下，下游只會知道「某個 agent 做了事」，無法確認背後是哪位使用者。若把入口收到的 token 原封不動往後傳，又可能讓原本只發給第一個 API 的憑證，被不該接收它的服務拿到。

比較安全的做法，是讓 agent 每跨到下一個系統，就重新取得一顆只給該系統使用、權限也符合當次工作的 token。這類「代表使用者執行」的流程通常稱為 on-behalf-of，簡稱 OBO。

AWS 在 2026 年 7 月公布 Amazon Bedrock AgentCore Gateway 的多租戶實作，示範 agent 如何交換代表使用者的 token，並限制新 token 只能交給指定服務。這雖然是特定產品的做法，背後要處理的卻是所有跨系統 agent 都會遇到的問題：每一站都必須說得清楚誰授權、誰執行、要交給哪個服務，以及允許做什麼。

代表使用者，不等於隱藏 agent

在 OBO 流程中，中介服務收到使用者的 token 後，會向授權伺服器要求一顆新的下游 token。這顆新 token 只供指定 API 使用，權限也不得超過原始授權與系統政策共同允許的範圍。

不過，「代表使用者」並不表示 agent 可以沒有自己的身分。在要求 client authentication 的實作裡，agent 應以自己的服務身分向 token endpoint，也就是處理交換的授權端點完成驗證；同時，委派資料也要保留它代表的是哪位使用者。

RFC 8693 用兩個角色區分這件事：subject 是被代表的主體，在這個場景通常是使用者；actor 是實際執行或轉交操作的一方，也就是 agent。授權系統與下游 API 不一定都會使用 act claim，但稽核資料至少要能還原這兩個角色。

如果 agent 還沒有獨立身分，可以先看為什麼 ERP 裡的 AI agent 需要自己的身份？。服務身分是用來辨認 agent，不是用來蓋掉使用者脈絡。

沿著實際呼叫路徑檢查五件事

先不要只畫「使用者 → agent → API」三個方框。請照真實呼叫順序，把每一次收到 token、交換 token 和呼叫下游服務的動作分開，再逐站檢查以下五件事。

入口 token 原本是發給誰的？ 入口 API 必須驗證 token 的簽發者、有效期限，以及指定接收者。這個指定接收者就是 audience。如果 audience 寫的是另一個服務，即使簽章有效，也不能因為大家都在公司內網就照單全收。
這次代表誰，又是誰在執行？ 每一站都要分別記下使用者 subject 與 agent actor。如果日誌最後只剩一個共用服務帳號，就無法追查這次操作的委派關係。
下一顆 token 要交給哪個 API？ 提出 token exchange request 時，應明確指定下一個下游資源，也就是 resource 或 audience。例如要呼叫工單 API，就不能只寫模糊的「內部服務」。取得新 token 後，還要確認它的 audience 正好就是該 API。
這一站實際需要哪些權限？ scope 表示允許執行的動作。查詢客戶資料只需要讀取權限，就不該順便取得刪除客戶或匯出全庫的能力。交換後的 scope 必須同時落在使用者原本的授權、agent 可用範圍與下游政策之內。
拒絕時能不能查出原因？ 日誌應記錄交換時間、subject、actor、目標 audience、要求與核發的 scope，以及拒絕原因，但不得保存完整 token。這些資料要能回答：誰授權、哪個 agent 執行、哪個服務接收，以及系統為什麼允許或拒絕。

每增加一個下游系統，就要再做一次交換與 audience 驗證。給客戶資料 API 的 token，不能接著拿去呼叫工單 API。Microsoft 的 OBO 文件採用的也是這個原則：中介服務取得一顆供下游 Web API 使用的新 token，而不是把上一層 token 當成各系統都能接受的通行證。

此外，授權判斷不能只寫在 agent 的提示詞裡。AI 客服要改帳號，授權關卡寫清楚了嗎？整理了哪些檢查必須由後端強制執行，不能交給模型自行決定。

先看工作性質，再決定怎麼交接

不是所有 agent 工作都該走同一條路。畫交接圖時，可以依下列四種情況分流：

確實代表特定使用者，而且授權系統與下游 API 都支援委派： 使用 token exchange，保留 subject 與 actor；每個下游服務都要取得 audience 不同的新 token。
工作不代表任何使用者，例如固定排程整理公開資料： 使用 agent 自己的工作負載身分，權限只涵蓋該背景工作。不要為了套用 OBO 而虛構一名使用者。
工作代表使用者，但下游不支援 OBO，或無法驗證委派關係： 不要把入口 token 傳下去。流程應停在中介層，改由受控後端提供權限更窄的操作接口，或要求人工到下游系統確認。
無法證明 token 要交給哪個 audience，或 scope 大於目前動作所需： 直接拒絕交換或呼叫。這些欄位不能由 agent 自行猜測。

即使符合第一種情況，高影響寫入也不能只因 token 交換成功就自動放行。執行前仍須由資料或系統負責人確認 subject、actor、目標 API、scope、預期影響與回退方式。只有可逆、低影響的讀取操作，才可按照事先核准的政策自動執行。

判斷的順序很重要：先確認這項工作是否真的代表某位使用者，再確認整條呼叫鏈是否都能驗證委派關係。如果其中一站只能用共用帳號掩蓋身分，或要求某個服務接收原本不屬於它的 token，就不應讓 agent 自動執行高影響操作。

今天先畫一條真的在跑的呼叫鏈

選一個已經會跨系統操作的 agent，只挑最常發生的一條路徑。每一站都用同一行格式記錄：

使用者 subject → 執行者 actor → token 簽發者 → 目標 audience/resource → 核發 scope → 拒絕條件

畫完後先檢查兩件事：有沒有哪一站只看得到共用服務帳號？有沒有同一顆 token 被兩個不同 audience 的服務接收？只要任一答案是「有」，就先收窄那一站，再考慮增加新的自動化能力。

AI 整理卡

先檢查這個實際呼叫流程缺少哪些資料，不要自行推測。待補內容只限於：入口 token 是誰簽發的、交給哪個服務、何時到期；每次系統交接中，誰是被代表的使用者（subject）、誰是實際執行者（actor）；token exchange 要交給哪個系統（resource／audience）；允許哪些 scope、權限邊界在哪裡；交換端點，以及拒絕日誌中的錯誤代碼和原因。

盤點完缺口後，依實際呼叫順序，為每個交接步驟整理一筆紀錄。無法從現有資料確認的內容一律標為「待確認」。若發現使用共用服務帳號，或把原本的 token 直接轉交給下一個系統，請明確標示。每筆紀錄的風險狀態只能是「已確認」、「待確認」或「需阻擋」。

實際呼叫流程（貼在這裡）：