AWS 透過 Amazon Bedrock AgentCore 為代理程式新增受管 OAuth 同意機制

AWS 已在 Amazon Bedrock AgentCore Identity 中新增一個受管同意入口，為組織在 AI 代理程式存取 GitHub 和 Slack 等服務時，處理終端使用者 OAuth 核准提供了新方式。此功能旨在取代客戶自行建置的瀏覽器重新導向、回呼處理，以及 AgentCore Gateway 部署中的 session 綁定基礎架構。

這項變更之所以重要，是因為代理程式整合越來越需要代表個別使用者行事，而不是透過單一共用服務帳戶。AWS 表示，新的 Consent 入口可讓員工透過公司身分提供者進行驗證、核准與個別服務的連線，並將產生的 token 儲存在 AgentCore Identity 的 token vault 中。公司在 AWS Machine Learning Blog 文章中說明了這項功能；目前可得的證據皆由 AWS 控制，並未提供獨立的採用或效能資料。

AgentCore Identity 有哪些變更

先前，使用 AgentCore Identity 中三方 OAuth 流程的客戶，必須自行建置相當多的使用者關聯層。這些工作包括顯示授權連結、代管公開的 HTTPS callback、識別返回的使用者、維護瀏覽器 session，以及呼叫 CompleteResourceTokenAuth 操作來完成授權。

AWS 表示，AgentCore Identity 現在為 AgentCore Gateway 提供一個作為受管網頁體驗與 session 綁定端點的 Consent 入口。管理員會為 gateway 建立入口，並將其 URL 發給使用者。使用者透過組織的身分提供者登入後，即可查看為代理程式設定的服務，並可分別授權各個提供者。

AWS 文件中的範例使用一個開發助理連接兩個 gateway 目標。GitHub 連線可列出 repositories 與建立 issues，而 Slack 連線可列出公開頻道並發送訊息。開發者可在需要時授權 GitHub，並分開核准 Slack，而每一筆 OAuth 授權都會保留與核准該授權的員工之關聯。

AWS 將此功能定位於透過 IDE 與 Model Context Protocol 用戶端使用的代理程式，包括 Kiro、Claude Code、Cursor 與 Visual Studio Code。預期的流程是：開發者在呼叫工具前先授權存取，之後的工具呼叫即可使用 AgentCore Identity 先前儲存的使用者特定 token。

受管同意流程如何運作

在分享入口 URL 之前，管理員必須先設定多個元件。這些元件包括公司身分提供者、採用 JWT inbound authorization 的 AgentCore Gateway、提供者目標、執行角色，以及連接服務的 OAuth 應用程式。AWS 的範例使用在開發或測試工作區中註冊的 GitHub 與 Slack 應用程式。

公司身分提供者必須支援使用 authorization-code grant 的 OpenID Connect 網頁應用程式。管理員需記錄提供者的 discovery URL，讓入口能取得其授權端點、token 端點與簽章金鑰。AWS 也表示，身分提供者必須發出入口可驗證的 JWT access token；其範例提到在需要時可於 Okta 設定自訂授權伺服器，或在 Auth0 中設定 audience。

管理員也需要有權限，將 AgentCore Identity callback URL 註冊到各個提供者應用程式。當員工登入後，Consent 入口會使用其 IAM 執行角色來探索已設定的 gateway 目標，呈現可用的提供者連線，完成 session 綁定，並將結果產生的每位使用者 token 儲存在 AgentCore Identity token vault 中。

AWS 表示，管理員可以在 AWS CloudTrail 中檢視後續活動。這為團隊提供了同意流程與後續身分相關活動的稽核軌跡，不過所提供的文件並未說明每種部署設定都具備哪些保留、報表或調查能力。

證據與主張

這項主要產品變更有 AWS 的第一手文件支持：AgentCore Identity 為 AgentCore Gateway 提供受管 Consent 入口與 session 綁定端點。該文章提供了設定步驟，以及一個涉及企業身分提供者、GitHub、Slack 與基於 IDE 的程式設計助理的實作範例。

然而，證據中並未包含客戶案例研究、獨立安全評估、採用數據、延遲測量，或與客戶自行建置 OAuth 基礎架構的成本比較。因此，關於降低實作工作量的說法應被視為此功能預期角色的描述，而非經過測量的基準。

來源也沒有說明該入口會消除所有身分或授權工作。組織仍需設定自己的身分提供者、註冊 OAuth 應用程式、定義 gateway 目標與權限、管理 IAM 角色，並決定哪些使用者可以連接哪些服務。入口將瀏覽器與 token 關聯流程的一部分集中化，但並未移除對代理程式工具與提供者 scope 的治理需求。

對建置者與企業團隊為何重要

對 AI 應用團隊來說，最直接的好處在於架構。建立會呼叫工作場所系統的代理程式的開發者，不再需要只為了將使用者的 OAuth 授權連接到 gateway 請求，而另外建立一個同意網站與 session 綁定服務。這可縮短從工具整合到可使用的內部代理程式的路徑，特別是在同一個 gateway 同時服務多個 IDE 或 Model Context Protocol 用戶端時。

逐一使用者的模型對存取控制也很重要。共用憑證能讓代理程式更容易部署，但也可能模糊責任歸屬，並讓所有使用者取得相同的實際權限。AWS 的設計讓授權與提出授權的員工保持關聯，使 GitHub 或 Slack 工具呼叫能使用該使用者的 token，而不是通用的應用程式身分。

這種模型會帶來買家需要回答的營運問題。團隊應檢視每個提供者要求的 scopes、撤銷或過期授權如何處理、員工變更職務時會發生什麼事，以及 CloudTrail 記錄是否足以滿足其稽核需求。他們也應測試當使用者只授權一個目標而未授權另一個目標時，代理程式的行為，因為獨立同意意味著代理程式在不同工具上的存取可能不一致。

對 AWS 客戶而言，此功能可能強化將 AgentCore Gateway 作為工具存取控制點的理由。對競爭中的代理平台而言，這凸顯了一項日益重要的產品需求：當代理程式可代表具名員工在系統中執行動作時，OAuth 同意不只是整合細節。

下一步值得觀察的事

接下來的訊號將是超出 AWS 範例之外的客戶部署，尤其是涉及受管制資料或大型身分提供者環境的正式生產使用。買家應留意更清楚的文件，說明 token vault 隔離、撤銷行為、同意紀錄、故障復原，以及入口執行角色所需的權限。

也值得觀察 AWS 是否會加入更多提供者樣板、管理控制，以及限制哪些使用者可授權特定 gateway 目標的政策功能。獨立的安全審查，以及受管流程與自訂 session 綁定實作之間的量化比較，將使此功能的企業價值更容易評估。

Creati.ai 觀點

AWS 正在處理代理程式部署中的一個實際瓶頸：如何把使用者的身分與代理程式動作連結起來，而不必讓每個應用團隊都重建同樣的 OAuth 基礎設施。當代理程式需要對多個工作場所系統進行使用者層級、範圍受限的存取，且這些連線必須可稽核時，Consent 入口最具相關性。

此功能不應被誤認為完整的代理程式安全模型。更困難的問題仍然圍繞在工具權限、scope 最小化、撤銷、提示驅動的濫用，以及代理程式在授權之後被允許做什麼。AWS 已提供同意與 session 綁定的受管基礎；企業團隊仍需驗證這項基礎是否符合其身分、合規與營運控管。