問題：AI agent 幫你開工，但佢係邊個？
呢啲日 AI agent 越來越似個「工友」，幫你用 ServiceNow 開單、查紀錄、改狀態。但係有個底層問題好多公司冇處理好：呢個 agent 用咗乜身份去叫 API？
如果用錯，成單審計紀錄（audit trail）就全冇晒，用户級權限（least privilege）都失效，IT 同安全團隊最頭大。
AWS 喺自家 Machine Learning Blog 放咗一篇技術示範，教點樣做 on-behalf-of（OBO，代表用户）token exchange，令 identity 可以喺 agent 同下游 API 之間完整傳遞。
架構：三個位，一個 Gateway
AWS 嘅方案涉及三個位：
- 前端 AI agent 應用，用 Microsoft Entra ID（即 Azure AD）做身分驗證
- AgentCore Gateway（以 MCP server 形式實現），坐喺 agent 同 ServiceNow 之間
- ServiceNow REST API，設定咗同 Entra ID 掛鈎嘅 inbound OAuth 整合
個流程大致係：用户拿 JWT（JSON Web Token）啟動 agent → agent 用一個 scoped 到佢自己 application registration 嘅 JWT 向 Gateway 認證 → Gateway 透過 OBO flow 同 Entra 做 token exchange，生成一個新嘅 token，audience 指向 ServiceNow 嘅 API connector client ID，但用户嘅原始身份 claim 保留完整 → ServiceNow 收到 token，將 preferred_username 對應到現有用户，依該用户嘅權限處理請求。
呢個 pattern 其實唔止適用於 ServiceNow，任何用 OAuth 保護嘅 REST API 都可以用。
OBO 交換點樣 work
技術上，agent 呈交嘅 JWT audience claim 指向自己嘅 client ID（例如 3ff88e17-XXXX），但 ServiceNow 需要嘅係一個 audience 指向 ServiceNow API connector client ID（例如 5d4a7a11-XXXX）嘅 token。
AgentCore Gateway 收到 inbound token 後，帶住 agent 嘅 client 憑證、target scope 同 requested_token_use: on_behalf_of 參數，將 token 送落 Entra token endpoint。Entra 確認用户已同意委派（consent），然後發出一個新 token，用户嘅 claim 原封不動。
呢個係標準嘅 OAuth 2.0 OBO flow，冇乜新概念，但重點係 AgentCore Gateway 將其整合咗做一個自動化步驟，每個 request 都自動交換，唔使開發者每次手寫。
要求同限制
喺生產環境，AWS 建議將 identity propagation 同 Amazon Bedrock Guardrails 一齊用，過濾有害內容同驗證 agent 嘅輸入輸出。
前置要求：AWS account（有 AgentCore Gateway 權限）、Microsoft Entra ID tenant（至少 Application Developer 權限）、ServiceNow instance（管理員權限，可用 PDI 開發實例測試）。
阿調搞兩下
呢篇係標準廠商技術文件，冇獨立實測、冇第三方驗證，亦冇提咗幾多錢、部署要幾耐。但方向係對路：identity propagation 係 enterprise AI agent 落地最底層嘅問題，AWS 喺呢度係將佢「產品化」，唔使每家企業自己手寫 OBO 邏輯。真正要問嘅係：你嘅 ServiceNow 環境邊個 hold 成個 configuration？用户嘅 consent 邊個攞？呢啲都係技術文件冇答嘅。
阿調｜深度調教
