AI agent auth: 使用情境與身份需求
2025 年是 AI 的時代。隨著大型語言模型 (LLMs) 和代理體驗的演進，認證和授權面臨新的挑戰。本文探討了 AI 代理的互動，並強調了關鍵的安全和認證情境。
Product & Design
2025 年正逐漸成為 AI 的年代。隨著 LLMs 和代理體驗的快速增長，我們經常被問到：如何擁抱這個新時代？AI 代理認證和授權有哪些新使用情境？在本文中，我們將探討典型的代理體驗並指出其中的安全和認證情境。
ChatGPT 操作代理的認證體驗
我最近購買了 ChatGPT 操作代理並探索了一些常見的工作流程。其中一個例子是在日本東京預訂住宿。操作代理根據我的提示讓我輕鬆找到合適的房間。
在結帳時，它要求我登錄，然後將控制權交還給我。
這種體驗讓我感到不安。即使我擁有控制權且代理無法替我登錄，我仍然必須在操作代理的瀏覽器中輸入我的電子郵件和密碼。這意味著，如果透過操作代理登錄你的電子郵件（或任何服務），你的憑證將存儲在 Cookie 中。
OpenAI 的操作代理聲明從不存儲用戶憑證並遵循類似 SOC II 的合規標準。然而，當第三方代理代表你與外部服務互動時，安全風險會顯著增加。
一般來說，直接給予代理你的賬戶訪問權限和憑證是個壞主意。
還有很大的改進空間。在下一節中，我將深入探討不同的認證和憑證管理方法，權衡其優劣。
就像這個 X Threads 討論的。
憑證是如何處理的，以及有哪些安全風險？
直接給 AI 代理你的憑證
在此方法中，AI 代表你輸入明文憑證（如電子郵件和密碼）。例如，AI 代理可能會請求你的登錄詳細信息，然後替你輸入它們。
然而，這種方法帶來的安全風險，是因為它可能暴露敏感信息。如果需要實施，集成密碼管理器或秘密管理系統會更安全。此外，限制憑證的存儲時間也可以幫助減少洩漏風險。
相對於明文憑證，個人訪問令牌 (PATs) 提供了更安全的方式授予訪問權，而無需密碼或互動式登錄。PATs 對於需要程式化地訪問資源的 CI/CD、腳本和自動化應用程序非常有用。為了提高安全性，最好限制 PAT 範疇，設置過期時間，並允許吊銷以防止洩漏和賬戶入侵。
通過 OAuth 進行用戶委託
OAuth (Open Authorization) 是一個廣泛使用的網站委託授權標準。它允許用戶授予第三方應用有限的訪問其在其他服務上的數據權限，而不需要分享其登錄憑證。
本質上，OAuth 解決了安全訪問委託問題：例如，你可以授權旅遊應用閱讀你的 Google 日曆，而不需要給應用你的 Google 密碼。這是通過讓用戶在數據提供者（例如 Google）驗證，然後向第三方應用發放令牌，而不是暴露用戶的憑證。
更好的方法是授權 ChatGPT 操作代理（或任何其他代理）在不分享你的密碼或憑證的情況下，在 Airbnb 上進行讀寫。你可以通過安全的授權過程授予訪問權，而不是讓操作代理直接登錄。
在我看來，如果 OpenAI 操作代理想要增強信任和身份安全，有幾種方法可以實現。
-
將登錄過程移出操作代理：在 ChatGPT 操作代理之外處理用戶登錄。這意味著你可能會點擊“使用 [服務] 登錄”按鈕，並被重定向到服務的安全登錄頁面進行認證，完全在聊天或 ChatGPT 操作代理之外。例如，如果有 Airbnb 插件，你會被送到 Airbnb 的網站輸入你的憑證並授權 ChatGPT，然後插件會接收到一個令牌。ChatGPT 只收到一個臨時的訪問令牌或密鑰，授予有限的訪問權（例如“讀取我的行程”），而不會看到你的實際密碼。
-
在 AI 代理執行任何任務之前讓用戶完成同意流程。這種方法類似於許多產品如何處理整合、市場和連接服務。
這裡是另一個例子，就像 Slack 和 Notion 的市場整合。Slack 正在請求訪問 Notion 的特定工作區，可以閱讀文章並在你的 Slack 頻道中呈現它們。
在這個過程中，Slack 還提供了一個同意頁面，授權 Notion 訪問工作區。
ChatGPT 操作代理應該採用類似的方法，通過整合 OAuth，允許代理安全地訪問多個第三方服務。這樣，它可以獲取帶有必要權限的訪問令牌，從而可安全執行任務。
敏感操作的升階認證
AI 代理可以獨立和自主地處理例行任務，但對於高風險操作，需要額外的驗證以確保安全，——如發送資金或修改安全設置——用戶必須通過多因素認證 (MFA) 驗證身份。這可以通過推送通知、一次性密碼 (OTPs) 或生物識別確認來完成。
然而，頻繁的升階認證可能會導致用戶沮喪，特別是如果觸發過於頻繁。因此，代理特定的體驗需要在這個新範式中考慮用戶體驗。
為了在不妥協用戶體驗的情況下增強安全性，自適應認證和 MFA 應用於確定何時需要額外的驗證。基於風險的觸發，例如 IP 更改或異常行為，有助於最小化不必要的認證請求。
聯邦身份和單一登錄 (SSO) 為多代理生態系統提供便利
在多代理企業生態系統中，AI 代理通常需要跨不同平台進行互動。為了簡化認證，用戶透過一個身份提供者 (IdP)（例如 Okta、Azure AD 或 Google Workspace）進行一次認證。代理然後使用 SAML、OpenID Connect (OIDC)，並通過基於角色 (RBAC) 或基於屬性 (ABAC) 的存取控制進行訪問管理。
這種方法消除了用戶多次登入的需求，同時透過集中身份管理增強安全性和合規性。它還允許動態訪問策略，確保代理在定義的權限範圍內運作。
範疇和權限管理
由於操作代理和代理可以代表用戶行動，因此給予人類足夠的控制權並仔細定義 AI 代理的權限很重要。應遵循的兩項關鍵原則是：
- 最小化權限 - 只授予完成任務所需的權限。
- 時效性訪問 - 限制訪問期限以降低安全風險。
角色基於存取控制 (RBAC) 有助於通過為特定任務分配特定角色來管理代理的範疇。為了進一步控制，基於屬性存取控制 (ABAC) 可實現動態、情境感知的權限管理，確保 AI 代理僅在需要時獲取所需的訪問權限。
與 Auth 連接 MCP 伺服器
MCP 越來越受歡迎，通過提供更多的背景信息來增強 AI 代理，提高它們的整體性能和用戶體驗。
為什麼 MCP 伺服器與認證相關，為什麼重要？
我們先前寫了一篇文章幫助你了解什麼是 MCP 伺服器。
MCP 伺服器是模型上下文協議的一個關鍵部分，充當 AI 模型和外部數據源之間的橋樑。它使得實時查詢和數據檢索從諸如 Slack、Gmail 和 Google 日曆的服務中成為可能。透過構建一個 MCP 伺服器，你可以連接這些遠程服務到 LLMs 上，提高你的 AI 驅動應用程序的背景信息和更智能的任務執行能力。
不像檢索增強生成 (RAG) 系統那樣需要生成嵌入並將文件存儲在向量數據庫中，MCP 伺服器直接訪問數據而無需事先索引。這意味著信息不僅更加精確和最新，還能以更低的計算開銷集成，而不會損害安全。
對於使用 MCP 伺服器的 AI 代理，在 MCP 伺服器、LLM、代理 和 用戶 之間發生多次互動。
在今天的 AI 驅動世界中，代理管理多個跨不同服務的任務，整合它們與多個 MCP 伺服器的需求越來越高。
代理認證正在崛起 —— 你的產品應該適應
一個很好的例子是 Composio.dev，一個以開發者為中心的整合平臺，簡化了 AI 代理和 LLMs 與外部應用程序和服務的連接方式。被稱為“對用戶代理認證的身份進行行為”本質上是一組可以輕松整合到 AI 驅動產品中的 MCP 伺服器（連接器）。
作為身處認證領域的人，但實際上，這只是更廣泛的 CIAM（客戶身份和訪問管理）領域的一小部分。他們所建立的實際上只是一組 MCP 伺服器（連接器）——有用但只涵蓋完整 CIAM 解決方案的一小部分。
基於早些時候的例子，如果我們考慮將 Google Drive（遠程服務）視作 MCP 伺 服器而不是 Airbnb，它就不僅僅是第三方整合——它成為外部數據源。這使代理可以訪問上下文信息，與 LLM 互動，並可能獲得創建、讀取、更新和刪除 （CRUD 文件的權限。
然而，核心的認證和授權要求保持不變。
使用 Logto 處理你的代理產品的認證
Logto 是一個多功能的 CIAM 解決方案，支持 SaaS 和 AI 代理產品，使認證和授權變得簡單。原因如下：
- 各種認證管理 – Logto 支持 OAuth 2.0、SAML、API 鍵、個人訪問令牌（PATs）和 JWT，允許與多個 MCP 伺服器輕松整合。你甚至可以自建 MCP 伺服器並將其連接到 Logto，這得益於它的開放標準基礎。
- 身份提供者 (IdP) 功能 – 一旦你的產品擁有已建立的用戶，Logto 可以成為 IDC，將你的服務轉化為 MCP 伺服器並將其整合到 AI 生態系統中。
- 高級授權
- 基於角色的存取控制 (RBAC) 用於管理用戶角色
- 基於自定義 JWT 的 ABAC 允許細粒度、動態訪問控制
- 增強的安全性 – 多因素認證 (MFA) 和升階認證等功能有助於保護關鍵操作並提高代理安全性。
有問題嗎？聯繫我們 的團隊，了解 Logto 如何增強你的 AI 代理體驗並滿足你的安全需求。