ServiceNow Token Exchange 納入 Bedrock AgentCore Gateway

AWS 已記錄透過 Amazon Bedrock AgentCore Gateway 進行 ServiceNow token exchange 的方式，從身分委派流程中移除了自訂 Lambda 攔截器。其 11 月 3 日的操作指南將 AI agent 連接至 ServiceNow，同時保留提出工作要求者的身分。這項改動將一項常規安全操作納入受管理的 gateway。

此機制採用代表授權（on-behalf-of，或 OBO），讓中介方可為已登入用戶要求下游存取權。Microsoft 的身分服務 Microsoft Entra ID 發出憑證。ServiceNow 則仍負責決定該用戶可存取的內容。

對企業開發人員而言，核心比較在於採用受管理的委派，還是維護自訂 token exchange 元件。AWS 現已為這項整合記錄前者。這可減少實作工作，但買方仍需要證據證明，在遭拒絕的請求、設定變更及日常營運故障之下，身分界線仍能維持。

ServiceNow Token Exchange 成為 Gateway 設定

根據 AWS 的原生 OBO 操作指南，gateway 會將傳入的用戶憑證交換為 ServiceNow 接受的憑證，過程無需自訂攔截器程式碼。

文件所述設定為 agent 與 ServiceNow connector 分別使用不同的 Entra application registration。ServiceNow 會將傳入的身分 claim（即具名 token 屬性）對應至現有用戶。Gateway 要求使用 Model Context Protocol 版本 2025-11-25，即 AWS 為原生 OBO 指定的工具連線協定版本。

眼前的改變在於交換操作的執行位置，以及由誰維護其實作。

這與取代企業的授權系統並不相同。它為團隊提供一個受管理的委派執行位置。組織仍決定哪些人員、應用程式和操作應納入工作流程。

在評估這項公告時，這個區分相當重要。Token exchange 元件在架構圖中看似很小，卻可能承擔重大責任。它的行為介乎個人請求與企業系統權限決定之間。

在實作前應考慮責任歸屬問題。若委派請求失敗，必須有人判斷失敗涉及用戶、應用程式還是目的地。移除自訂元件會改變該調查的界線。

對維護自有 exchange service 的團隊而言，相關問題變得具體：該元件除標準委派外還做了甚麼？若其唯一用途是取得下游憑證，受管理的替代方案值得評估。若它亦套用業務規則，則在淘汰前，必須為這些規則明確指定去向。

這可避免常見的遷移錯誤。若只因整合元件的主要功能已移入平台而刪除它，也可能一併刪除逐漸累積在其周邊的行為。負責任的評估會將驗證工作與應用程式決策分開。

同樣的推理亦適用於項目估算。團隊應計算消失的工作，然後識別轉移了的工作。設定責任、權限檢討、支援程序及驗收證據，仍需要由人員負責。

因此，ServiceNow token exchange 是基礎設施成為產品設定的一個有用例子。營運效益取決於組織能否如審查所取代的程式碼般仔細審查該設定。

對評估這則消息的讀者而言，最有力的初步結論很實際。AWS 已記錄一種替代方案，讓你毋須自行維護這項 exchange logic。該操作指南提供的是評估起點，而非已量度的生產成果證據。

身分團隊承接更明確可見的產品決策

最直接受影響的人員包括平台工程師、身分管理員及 ServiceNow 擁有人。每個群組均控制同一用戶旅程的不同部分。受管理的 exchange 令其協調更為可見。

Agent 團隊或會把收到有用答案定義為成功。身分團隊或會把正確委派的存取權定義為成功。ServiceNow 擁有人則可能要求證據，證明未獲授權的記錄仍然無法存取。

這些定義應在部署前達成一致。否則，同一示範可能令一個群組滿意，卻未能回答另一個群組最重要的問題。單憑一個令人信服的答案，只能有限地證明其下的權限界線。

壓力轉向由跨團隊證明授權合約。

有用的合約應從平實語言開始。助理應使用提出請求者獲准的存取權，執行已核准的工作。這項陳述讓工程師與審查人員共享預期結果，而不會把驗收綁定於特定模型。

例如，設想一名支援人員請助理概述與其工作相關的 incidents。這是一個說明性情境，而非已報道的客戶部署案例。其價值取決於有效的擷取能力和適當的限制。

成功的回應應解釋該員工獲准查閱的 incidents。超出該界線的請求嘗試，則應產生清晰的限制說明。兩種結果都屬於產品正確性的定義。

這種框架亦可改善採購決策。買方可要求供應商以具代表性的帳戶示範已授權及未授權的行為，並將觀察到的結果與書面存取政策比較。

另一種做法，是接受完全透過管理員帳戶進行的示範。此類示範或能證明連線正常，但對一般員工的日常使用透露不多。採購團隊應區分這些證據形式。

這亦涉及文件記錄。必須有人記錄哪個團隊擁有應用程式身分、目的地權限及用戶對應。若沒有這些記錄，例行的人事變動可能變成整合之謎。

維護這些決策的團隊可使用可搜尋知識庫，保存設定說明和故障排除背景。這些文件可支援整合運作，而不會成為其授權界線的一部分。

對開發人員而言，組織層面的機會在於減少重複工作。標準 exchange pattern 為應用程式團隊提供共同起點，使其可將審查精力投入助理所需的特定操作及資訊。

對安全團隊而言，機會在於更清晰的資產清單。審查人員毋須在各個應用程式實作中尋找委派行為，而可要求查看 gateway 設定及其擁有人。這項好處取決於設定能否保持可發現及最新。

由此產生的壓力是即時的，而非推測性的。評估此整合的團隊必須就誰可批准存取、誰可解釋拒絕結果達成共識。受管理的 gateway 令這些決策更容易定位，但仍須由人作出決定。

Exchange 改變憑證的目的地

Access token 是授權呼叫特定資源的憑證，其 audience 標識預定接收者。當請求經過 agent 再到達另一個應用程式時，這個目的地尤為重要。

Microsoft 的 OBO authorization flow 要求中介方提交合適的傳入用戶 token。身分平台隨後會發出下游 token。該流程使用 delegated scopes，即為代表用戶執行工作而要求的權限。

Microsoft 亦將此與僅限應用程式的存取權區分。OBO 要求 user principal，即代表個人的身分。僅發給應用程式的 token 並不能建立相同的委派關係。

委派應保留提出請求者與下游權限決定之間的聯繫。

對衡量此機制的讀者而言，一個有用比喻是訪客在受保護部門之間流動。獲准進入接待處，並不自動代表可進入每一間辦公室。每個目的地均需要適合該目的地的授權決定。

這個比喻有其限制，但可說明為何單純向下傳遞憑證並不足夠。中介方必須參與經核准的委派關係，目的地其後收到供自身使用的憑證。

AWS 的 gateway 文件 將驗證列為其更廣泛工具整合角色的一部分。Gateway 可透過共同介面公開現有服務，同時管理入站及出站驗證。

這帶來一項值得評估的架構優勢。團隊可將模型的推理與向工具提供憑證的機制分開。語言模型可要求執行某項操作，而基礎設施則處理驗證路徑。

這種分離應影響應用程式設計。Prompt 可描述何時適合使用某工具，但權限決定需要可靠的執行點。產品團隊應能更改措辭，而不改變誰能獲得存取權。

受管理的 exchange 亦改變了自訂程式碼的比較方式。本地維護的元件讓團隊直接控制實作細節。受管理服務則提供標準設定介面，並將部分實作責任轉交供應商。

兩種選擇均不會免除理解故障行為的需要。相關比較包括診斷能力、可審查性、生命週期管理及支援。只計算原始碼檔案，會忽略營運決策的大部分內容。

因此，評估 AgentCore OBO 行為的開發人員，應將請求追蹤為一連串責任：哪個元件驗證傳入呼叫者？哪個元件要求下游存取權？哪個系統作出最終資源決定？

即使平台自動執行 exchange，這些問題仍然有用。自動化移除了手動實作步驟，卻不會消除對準確架構說明的需要。

此機制亦說明模型選擇能與不能解決的事。較佳的模型或可選擇更合適的工具，或更清楚地解釋結果。無論模型回答質素如何，授權仍需要其自身的驗收證據。

對企業買方而言，這是最有用的技術重點。應將推理質素和委派存取權視為獨立能力加以評估。產品需要兩者，才能在具權限控制的工作場所提供可靠協助。

Azure 為同一界線提供有用比較

Microsoft 的 agent isolation guidance 描述了委派授權及獨立 agent 身分，亦指出 Azure API Management 可作為強制執行背景傳遞的工具 gateway。

這為 AWS 的做法提供了一個相關的比較。兩者的討論都將身分識別執行置於模型可自行裁量的推理之外。Microsoft 的指引明確要求採用確定性控制，即執行規則不應依賴生成文字。

有用的競爭問題在於，每種架構如何清晰地保留並執行存取情境。

這比比較支援的連接器數量更具資訊價值。連接器建立通往應用程式的途徑。企業採用亦需要能夠合理說明：有哪些權限會隨該途徑一同傳遞。

比較平台的買方應從一個具代表性的工作流程開始。該工作流程應包括獲准存取、受限存取，以及可復原的失敗情況。其後可依相同的預期結果評估每個平台。

這種做法避免令比較淪為產品主張的清單。它要求供應商展示對機構真正重要的行為，亦揭示仍然需要在受管理平台以外完成的整合工作。

比較時應尊重架構上的差異。一家已營運成熟閘道的公司，可能重視與既有控制措施的一致性。另一家公司則可能優先減少其應用程式團隊需要維護的基礎設施數量。

這些都是合理的優先次序差異。它們並不代表某個平台在所有情況下都能提供更佳的授權。決定取決於所選安排是否符合機構實際的存取需求。

對於考慮 AgentCore 與自訂驗證方案的團隊，同樣應採用這套內部評估方式。自訂系統應面對與受管理替代方案相同的拒絕存取情境。對既有程式碼的熟悉程度不應取代證據。

遷移檢視亦應檢查例外行為。例如，現有元件或會加入核准檢查，或轉換內部身分識別。如該行為仍有需要，替代架構便須明確保留它。

正是在這裏，受管理基礎設施可以揭示機構未有記錄的假設。標準配置會迫使團隊說明整合中的哪些部分屬於標準做法，哪些屬於特定需求。即使在作出遷移決定之前，這種釐清亦可能很有價值。

因此，競爭壓力不只影響 AWS 和 Microsoft。整合供應商及內部平台團隊愈來愈需要以營運層面的術語，說明其授權邊界。泛泛宣稱已具備企業就緒能力，在存取事故發生時幫助不大。

讀者亦不應將此整合視為模型供應商之間的競賽。身分識別路徑關乎用於呼叫企業應用程式的權限。無論由哪個模型產生請求，其設計都值得獨立審視。

更廣泛的含意是一項評估標準：以相同的權限合約比較平台。有用的回應、適當的拒絕，以及可理解的失敗，能為買方提供比單憑連接器示範更穩固的判斷基礎。

成功的請求仍會留下重要問題

可正常運作的整合，證明獲准的路徑可以成功。它並不能證明系統會如何面對每位相關使用者、權限變更或政策挑戰。這些問題需要另行評估。

Microsoft 記錄了當下游政策要求額外使用者驗證時的互動要求。這為任何中介層帶來一項產品設計問題：應用程式如何傳達該人需要採取行動？

當工作無法繼續時，助理應向使用者提供有用的說明。它應區分權限限制、資訊不足及暫時性服務問題。否則，使用者只會面對含糊的失敗，而支援團隊則要承擔調查工作。

生產環境的信心，來自能夠解釋失敗，亦來自能夠完成獲准的請求。

首個評估範疇是拒絕行為。團隊應刻意嘗試超出具代表性使用者已獲批准存取範圍的操作。預期結果應在測試開始前記錄下來。

這有助分辨正確的限制與整合缺陷。如沒有預期結果，開發人員可能會將每次拒絕都視為需要修正的問題。這會造成壓力，令人只為讓示範成功而擴大存取權限。

下一個範疇是變更管理。機構應檢視當相關權限、身分識別對應或應用程式配置變更時會發生甚麼。目標是提供可理解的回應，並清楚指定調查工作的負責人。

憑證處理值得進行獨立的營運檢視。受管理的交換機制可減少自訂實作，同時仍讓管理員負責維護配置輸入項。團隊應了解所需變更如何傳達至已部署的整合。

可觀測性，即透過營運證據理解系統行為的能力，在整個檢視過程中都十分重要。支援人員需要足夠的情境資料來定位失敗，同時不可暴露敏感憑證。更多日誌記錄不一定等於更好的日誌記錄。

有用的調查紀錄應把請求、其結果及相關配置連結起來。檢視人員便可詢問，該證據是否支持既定的權限合約。紀錄的具體設計應遵從機構的資料處理要求。

所暴露操作的範圍亦很重要。讀取紀錄與變更紀錄，對使用者造成的後果並不相同。團隊應按每項操作可以做甚麼來評估，而不應將連通性視為全面批准。

例如，一個說明性的事故摘要工作流程，可能只會由擷取資料開始。加入事故更新功能，將引入有關確認、問責及復原的另一項產品決策。既有連線並不能解決這些問題。

已發布資料所能證明的事項亦有限。引用的操作指南說明了配置及預期行為，但並未提供經獨立驗證、關於可靠性、維護工作量或業務成果的生產環境比較。

這個缺口應影響採用決策的表述方式。團隊可以合理地得出結論：該受管理方式值得測試。至於能減輕營運負擔的更強主張，則需要來自團隊自身部署的證據。

因此，最好透過具明確成功及失敗準則的有限試點，評估 ServiceNow token exchange。這讓機構能夠評估已記錄的能力，而不會將一次成功示範視為全面保證。

留意部署證據、政策處理及重用情況

下一批有用訊號，關乎營運證據，而非另一項關於自主工作的廣泛承諾。未來數月，買方應留意部署結果、政策復原，以及在其他工作流程中的重用情況。每項都測試受管理委派論點的不同部分。

最有力的證據將顯示，較少的自訂交換程式碼同時能帶來更清晰、易於營運的系統。

首先，留意以具代表性的員工權限進行部署的記錄結果。有用的說明會交代哪些操作獲准、哪些被拒絕，以及團隊如何驗證兩者之間的差異。單憑客戶名稱能揭示的資訊較少。

一致的存取結果證據，將加強受管理委派的理據。若報告顯示團隊為穩定整合而擴大權限，則會削弱此理據。重要細節是已部署行為如何與原來的權限合約比較。

維護方面的證據亦會有幫助。評估遷移的團隊需要了解初始設定後會發生甚麼。清楚說明配置更新及事故調查的資料，將比單看設定時間更能支持營運層面的論點。

其次，留意實作如何處理政策中斷及復原。當使用者必須重新驗證或取得核准時，生產環境助理需要一條合理的處理路徑。反覆回傳無法解釋的錯誤，將令大量產品工作仍未解決。

清晰的復原行為會加強以下論點：受管理交換機制能簡化整體體驗。如每個應用程式都需要圍繞它進行大量自訂處理，其好處便仍然較為有限。這仍然有用，但會改變實作工作量的估算。

此訊號亦與支援責任有關。應用程式團隊需要知道何時可以自行解決問題，以及何時身分識別管理員必須介入。有記錄的交接安排可幫助使用者避免在不同團隊之間來回轉介。

第三，留意機構是否將這種模式重用於其他企業操作。當整合擴展時，如相同的權限原則仍然清晰，重用便具有意義。只增加目的地而未能保留這種清晰度，所提供的證據便較弱。

可重用的模式應讓每個目的地的權限都易於理解。檢視人員仍應能夠識別使用者、獲批准的操作及負責的系統。單靠連接器數量增加，不能證明這個結果。

對企業開發人員而言，這些訊號表明可對公告採取實際的回應方式。在目前由自訂程式碼執行一般委派的地方，評估受管理路徑。明確保留業務特定控制措施，並將結果與既有實作比較。

對買方而言，應要求以一般員工帳戶及真實限制條件提供證據。如無人能解釋底層請求為何獲得存取，再出色的回答也不那麼重要。評估應獎勵可理解的授權行為。

對計劃下一次檢視的團隊而言，應由具體工作流程開始，並記錄其獲准操作。識別應傳遞至 ServiceNow 的使用者權限，然後測試一個獲准請求及一個刻意受限的請求。記錄應用程式如何解釋每個結果，以及由誰負責處理任何失敗。利用這些結果評估透過 AgentCore 進行 ServiceNow token exchange，是否能在保留預期存取邊界的同時減少維護工作。在擴展工作流程前，先與身分識別管理員及 ServiceNow 擁有人檢視配置。最有用的下一步，是進行聚焦評估，以產生團隊可檢視、重複執行並用於決定是否取代現有交換元件的證據。