AI agent 替員工查系統，要用員工的身分
AI agent 連進企業系統時，後端看得到真正的使用者嗎？本文從 AWS 的 OBO 權杖交換做法談起，說明共用帳號的風險，並列出主管接下來能做的五件事，協助企業在試行階段就把身分問題處理好。
AWS 最近發表一篇技術文章，示範 AI agent 呼叫 ServiceNow 時，如何保留發問員工的身分。做法是在 AgentCore Gateway 上設定 OBO（on-behalf-of，代表使用者）權杖交換。凡是打算讓 agent 連進內部系統的企業，都會碰到同樣的問題。
很多主管以為，上線前把資料範圍限縮好，再請資安部門看過一輪，安全就算顧到了。真正容易被忽略的是另一件事：agent 查資料時，後端系統看到的到底是誰。
agent 的權限，不該比眼前的使用者還大。
先搞清楚變了什麼
原文談的是一套具體設定，不是概念宣導。重點有這五項：
- 原本的問題： 身分沒有傳下去時，API 呼叫到了後端，看起來是應用程式在操作，不是發動操作的員工。
- 通行證不合： 權杖可以想成一張通行證，上面寫著持有人是誰、要進哪個系統。agent 手上那張是給自己用的，ServiceNow 不收。
- 換證方式： 閘道把這張權杖送到 Entra，換一張給 ServiceNow 用的新權杖，原使用者的身分資料都保留在裡面。
- 後端反應： ServiceNow 用權杖裡的使用者名稱對應到既有帳號，再套用這個人的權限。
- 省下的工： 交換動作直接設在閘道上，不必再自己寫和維護 Lambda 攔截程式。不過閘道要選 MCP 2025-11-25 版，舊版建立的閘道無法開啟。
對使用者來說，這一切都在背後自動發生。員工照常對 agent 提問，不會察覺多了換證這道手續。
受影響的不只是資訊部門。只要 agent 會碰到有權限區分的資料，像是工單、客戶或人事紀錄，相關的業務主管都得關心。
想像一家製造業者，讓 agent 替現場同仁查資訊事故單。如果連線用的是共用服務帳號，新進助理也可能查到只有主管能看的單子。
再想像一家金融業者，要追查某筆異常查詢。紀錄上只寫著 agent 的名字，稽核人員查不出是哪位同仁發動的，只能挨個去問。
同一個 agent，不同人問，就該看到不同結果。
別重演共用帳號的老問題
很多公司都走過共用帳號這段路。一開始圖方便，整個部門用同一組帳密，事情也跑得很順。等到資料外流或被誤刪，才發現沒人說得清是誰做的。
agent 全用同一個服務帳號連線，其實是同一個錯誤換了新包裝。而且它更難察覺，因為員工面前只有對話視窗，看不到背後用的是哪個身分。
原文點出不處理的三個代價：
- 紀錄斷掉： 操作紀錄只留下應用程式，查不到真正發動的人。
- 限制失效： 後端替每位使用者設好的存取限制，碰到 agent 就被繞過去。
- 權限過大： 這違反最小權限原則，白話說就是每個人只該拿到工作需要的權限。
我們的判斷是，這件事要在試行階段就處理。試行時只有少數人用，共用帳號看不出問題。等 agent 擴大到全公司，回頭改身分設計要動的東西就多了。
這也不是只跟 ServiceNow 有關。原文提到，同樣做法可以套用到其他受 OAuth 保護的 REST API。不管後端是採購還是人資系統，都該問同一個問題。
當然，這套做法不是按一下就好。原文要建立兩個 Entra 應用程式註冊，再到 ServiceNow 設定身分對應。漏掉一個關鍵參數，呼叫就會因驗證錯誤而失敗。
身分傳遞也只解決誰在操作這件事。原文建議正式環境可再搭配 Bedrock Guardrails，過濾有害內容並檢查 agent 的輸入輸出。後端權限如果本來就設得太鬆，agent 也只會照做，所以順便清一次舊權限很值得。
接下來可以做的五件事
內部討論這件事常卡住：業務想快點上線，資安想先看清風險，資訊部門夾在中間。不必等所有人都有共識，可以先從下面這些動作開始：
- 列連線清單： 把現有和規劃中的 agent 列出來，逐一寫下它們連哪些系統、用哪個帳號連。這份清單會告訴你風險集中在哪裡。
- 做一次實測： 找權限不同的兩位同仁，問 agent 同一個問題，看回傳的資料是否不同。結果相同就要警覺。
- 調一筆紀錄： 請資訊人員到後端系統調出 agent 的操作紀錄，確認看得到真正的使用者。看不到，就表示身分沒有傳下去。
- 核對帳號： 確認身分系統裡的使用者資料對得上後端帳號。原文的排錯清單，第一項就是檢查權杖裡的使用者名稱能否對到有效帳號。
- 縮小開放範圍： 只開放 agent 真正需要的 API。原文的範例就把存取範圍限制在 Table API，這種做法可以直接比照。
這五件事不需要採購新工具，也不必先決定用哪個平台。就算你們用的是別家雲端或地端系統，一樣可以照做。
總結而言，agent 上線前，先答得出它此刻代表誰在操作。
這件事橫跨身分系統、雲端平台和業務系統，通常沒有一個部門能獨自拍板。如果內部還理不出頭緒，可以找熟悉 AI 導入的外部顧問一起釐清。
顧問能幫忙盤點現況、比對各系統的權限設定，也能陪你們選出第一個試行流程。先把問題問對，後面的導入會順很多。