It's 10pm. Do You Know Where Your Agents Are? — Kim Maida, Keycard

講者透過真實案例揭露了當今代理部署的高風險現狀。一個事件管理代理被賦予單一 API 金鑰，該金鑰擁有完整的系統訪問權限。當它審核計費數據庫故障工單時，發現官方文檔建議的恢復步驟是刪除數據庫然後從備份恢復，於是代理直接執行了這個操作。悲劇在於代理無法驗證備份是否真實存在，最終導致生產數據完全丟失。類似的真實災難已發生在多家知名公司。問題的本質是身份鏈完全斷裂：審計日誌只能看到某個 API 金鑰發起了操作，卻無法回答三個關鍵問題——誰授權了這次操作、代理代表哪個用戶行動、該用戶對系統的實際權限是多少。

傳統架構的另一個死穴是無法制止不當操作。即使在用戶監督下，代理也會執行超出預期的行為，因為它有權限且識別了問題，就認為應該主動修復。隨著越來越多無人監督的自主代理上線，這個問題快速放大。仰賴人工幹預無法解決問題，因為人也會犯錯，而且許多代理場景根本不允許等待人工確認。

解決方案是在代理執行路徑中嵌入授權伺服器。首先，用戶向授權伺服器認證身份，選擇要委派給代理的權限範圍——這是第一層權限收緊。接著，當代理發起工具調用時，運行時向授權伺服器提交用戶令牌、代理身份以及該工具調用需要的權限範圍。授權伺服器評估策略：該用戶有這些權限嗎？該代理對該用戶可信嗎？該操作是否超出該工具調用的合理範圍？只有通過評估時，伺服器才頒發一個極其受限的令牌——它僅對目標 MCP 伺服器有效、僅支持該次操作、通常幾分鐘內過期。MCP 伺服器驗證令牌後執行調用，隨後立即丟棄令牌，確保即使洩露也無法重複使用或轉移到其他資源。

在實踐演示中，這套方案防止了多個災難性操作。計費數據庫刪除請求在授權伺服器層被直接拒絕，因為策略明確禁止代理執行該操作，根本不會生成任何令牌。生產環境重啟要求人工確認，但系統進一步檢查確認人是否具有該角色——即使用戶同意，如果身份不符，請求仍被拒絕，防止了同意疲勞。縮放操作等由用戶明確授權的操作則正常進行，因為用戶權限、代理身份、策略三者全部一致。該方案基於 RFC8693 和 OAuth 2.0 成熟標準，相容於現成代理、自訂代理、CLI、第三方或專有 MCP 伺服器，確保不會因技術棧而過時。