一位業務請 AI agent：「幫我查這位客戶最近的訂單，再把結果開成一張客服工單。」這句話對人來說很清楚，但對後面的系統來說，少了幾個關鍵資訊：這件事是誰授權的、實際是哪個 agent 在做、它可以做到哪一步。
agent 要完成這件事，至少得跨過兩個系統：客戶資料庫和工單系統。每過一個系統，都要出示一個 token，也就是證明「我有權限做這件事」的電子通行憑證。這時團隊最常走兩條捷徑：讓 agent 用一個大家共用的服務帳號辦事，或把使用者登入時拿到的 token 原封不動一路往下傳。兩條捷徑都能讓流程跑起來，也都會在出事時讓人查不出是誰授權了什麼。
比較穩的做法是：agent 每到下一個系統，就換一個只給那個系統用、權限也只夠這次工作的新 token。
兩條捷徑各自的問題
共用服務帳號的問題是使用者消失了。如果所有操作都掛在同一個 agent 帳號底下，客戶資料庫的紀錄只會寫著「agent 查了這筆資料」。哪位業務要求的？他本來有沒有權限看這位客戶？紀錄裡都沒有。agent 帳號的權限通常也比任何單一使用者大，等於讓每個人都能透過 agent 看到自己原本看不到的東西。
一路傳下去的 token 的問題是收件人錯了。每個 token 在發出時都會寫明它是給哪個系統用的，這個欄位叫 audience（指定接收者）。使用者登入時拿到的 token，audience 是第一個系統。如果 agent 把它直接轉交給工單系統，等於拿著寫著別人名字的通行證進門。AWS 在 2026 年 7 月的一篇技術文章裡指出，這樣做會讓下游每一個工具都可能變成被利用的代理人，因為它們收到的 token 本來就不是發給它們的。Microsoft 在說明這類流程的文件裡也用警告框寫明：發給中介服務的 token，不要送到它指定接收者以外的任何地方。
每一站換一把鑰匙：代表使用者交換
這種「代表使用者去下一站辦事」的流程，通常叫 on-behalf-of，簡稱 OBO。它的核心動作是交換：agent 拿著使用者的 token，向授權伺服器（負責發 token 的系統）申請一個新的 token，新 token 只給指定的下一個系統用，權限也不能超過使用者原本被允許的範圍。
新 token 要同時記住兩個角色。描述這種交換的網路標準 RFC 8693 把它們分開：subject 是被代表的人，在這個例子裡是那位業務；actor 是實際執行的一方，也就是 agent。AWS 那篇文章的實作，就是在每一次呼叫下游工具前交換 token，讓新 token 保留使用者身分、記下執行的 agent、只綁定一個接收系統，權限也只剩下游需要的那一部分。
這樣做之後，客戶資料庫的紀錄會變成：「agent 代表某位業務，用唯讀權限查了這筆資料。」每多一個下游系統，就再換一次。給客戶資料庫的 token，不能接著拿去開工單。
動手前先分清楚工作性質
不是所有 agent 工作都該走 OBO。畫交接路徑前，先判斷這件工作屬於哪一種：
- 確實代表某位使用者，而且授權系統和下游都支援交換： 走 OBO，每一站換新 token，保留 subject 和 actor。
- 不代表任何使用者，例如每天固定整理公開資料的排程： 用 agent 自己的身分，權限只涵蓋這項背景工作。不要為了套用 OBO 而虛構一位使用者。
- 代表使用者，但下游不支援交換： 不要把原本的 token 傳下去。流程停在中介層，改由權限更窄的後端功能代辦，或請人到下游系統確認。
- 說不出新 token 要給哪個系統，或要求的權限比這次動作需要的多： 直接拒絕。這些欄位不能讓 agent 自己猜。
交換成功，不代表這件事該做
token 交換成功，只代表「這個 agent 有資格代表這位使用者去這個系統」，不代表這次要做的事是對的。查一筆訂單可以照事先核准的規則自動放行，但刪除資料、退款、修改權限這類高影響的寫入，即使交換成功，執行前仍要由負責的人確認是誰授權、做什麼、影響多大、怎麼回復。授權檢查也不能只寫在 agent 的提示詞裡，要由後端系統強制執行，參考〈AI 客服能改帳號之前，身分要由系統確認，不能由對話確認〉。
交換機制本身也有要保護的東西。AWS 的文章提醒，負責交換的那組 agent 憑證是整條鏈裡最敏感的一把鑰匙，外洩的話，對方可以替任何使用者申請 token；紀錄裡也不該存完整的 token，只記 subject、audience、actor 這些欄位就好。
先畫一條真的在跑的路徑
挑一個已經會跨系統操作的 agent，只畫它最常走的那一條路。每一站用同一行格式寫下：
代表的使用者 → 執行的 agent → 發 token 的系統 → 收件的系統 → 允許的動作 → 什麼情況會被拒絕
畫完後問兩個問題：有沒有哪一站只看得到共用帳號？有沒有同一個 token 被兩個不同的系統收下？只要任一個答案是「有」，就先把那一站收窄，再考慮讓 agent 做更多事。agent 如果還沒有自己的身分，可以先看〈ERP 裡的 AI agent 要有自己的身份，日誌才分得出是人做的還是 AI 做的〉。
AI 整理卡
我想檢查一個 AI agent 跨系統辦事時，每一站的身分交接是否清楚。
判斷方法來自這篇文章：https://boosterminiclass.com/posts/ai-agent-on-behalf-of-token-handoff-map/
文章的看法是：agent 代表使用者連續呼叫多個系統時，不要用共用帳號，也不要把同一個 token 一路往下傳；每到一站都換一個只給那一站、權限只夠這次工作的新 token，並保留「代表誰」和「誰在執行」。
請先問我 3 個問題：
1. 這個 agent 最常走的一條路徑，依序經過哪些系統，每一站做什麼；
2. 每一站 agent 用什麼身分呼叫：使用者的 token、交換後的新 token，還是共用服務帳號；
3. 這條路上有沒有會寫入、刪除、付款或改權限的動作。
根據我的回答，請輸出：
- 每一站一行：代表的使用者／執行的 agent／收件系統／允許的動作／拒絕條件，無法確認的欄位標「待確認」；
- 標出使用共用帳號、或同一個 token 被不同系統收下的站；
- 每一站的狀態：已確認／待確認／需阻擋；
- 哪些高影響動作即使交換成功，仍要人確認後才執行。
不要替我推測系統設定；資訊不足時先問我。
參考來源
- AWS Machine Learning Blog：Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway — https://aws.amazon.com/blogs/machine-learning/implement-on-behalf-of-token-exchange-for-multi-tenant-agents-with-amazon-bedrock-agentcore-gateway/（2026-07-13）
- IETF／RFC Editor：RFC 8693: OAuth 2.0 Token Exchange — https://www.rfc-editor.org/rfc/rfc8693（2020-01）
- Microsoft Learn：Microsoft identity platform and OAuth2.0 On-Behalf-Of flow — https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow（2026-06-15）
