繁體中文（台灣）
AI agent auth: 使用情境與身份需求
2025 年是 AI 的時代。隨著大型語言模型 (LLMs) 和代理體驗的演進，認證和授權面臨新的挑戰。本文探討了 AI 代理的互動，並強調了關鍵的安全和認證情境。
Guamian
Product & Design
Product & Design
2025 年是 AI 的時代。隨著大型語言模型 (LLMs) 和代理體驗的演進，認證和授權面臨新的挑戰。本文探討了 AI 代理的互動，並強調了關鍵的安全和認證情境。
2025 年正逐漸成為 AI 的年代。隨著 LLMs 和代理體驗的快速增長，我們經常被問到：如何擁抱這個新時代？AI 代理認證和授權有哪些新使用情境？在本文中，我們將探討典型的代理體驗並指出其中的安全和認證情境。
我最近購買了 ChatGPT 操作代理並探索了一些常見的工作流程。其中一個例子是在日本東京預訂住宿。操作代理根據我的提示讓我輕鬆找到合適的房間。
在結帳時，它要求我登錄，然後將控制權交還給我。
這種體驗讓我感到不安。即使我擁有控制權且代理無法替我登錄，我仍然必須在操作代理的瀏覽器中輸入我的電子郵件和密碼。這意味著，如果透過操作代理登錄你的電子郵件（或任何服務），你的憑證將存儲在 Cookie 中。
OpenAI 的操作代理聲明從不存儲用戶憑證並遵循類似 SOC II 的合規標準。然而，當第三方代理代表你與外部服務互動時，安全風險會顯著增加。
一般來說，直接給予代理你的賬戶訪問權限和憑證是個壞主意。
還有很大的改進空間。在下一節中，我將深入探討不同的認證和憑證管理方法，權衡其優劣。
就像這個 X Threads 討論的。
在此方法中，AI 代表你輸入明文憑證（如電子郵件和密碼）。例如，AI 代理可能會請求你的登錄詳細信息，然後替你輸入它們。
然而，這種方法帶來的安全風險，是因為它可能暴露敏感信息。如果需要實施，集成密碼管理器或秘密管理系統會更安全。此外，限制憑證的存儲時間也可以幫助減少洩漏風險。
相對於明文憑證，個人訪問令牌 (PATs) 提供了更安全的方式授予訪問權，而無需密碼或互動式登錄。PATs 對於需要程式化地訪問資源的 CI/CD、腳本和自動化應用程序非常有用。為了提高安全性，最好限制 PAT 範疇，設置過期時間，並允許吊銷以防止洩漏和賬戶入侵。
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 更改或異常行為，有助於最小化不必要的認證請求。
在多代理企業生態系統中，AI 代理通常需要跨不同平台進行互動。為了簡化認證，用戶透過一個身份提供者 (IdP)（例如 Okta、Azure AD 或 Google Workspace）進行一次認證。代理然後使用 SAML、OpenID Connect (OIDC)，並通過基於角色 (RBAC) 或基於屬性 (ABAC) 的存取控制進行訪問管理。
這種方法消除了用戶多次登入的需求，同時透過集中身份管理增強安全性和合規性。它還允許動態訪問策略，確保代理在定義的權限範圍內運作。
由於操作代理和代理可以代表用戶行動，因此給予人類足夠的控制權並仔細定義 AI 代理的權限很重要。應遵循的兩項關鍵原則是：
角色基於存取控制 (RBAC) 有助於通過為特定任務分配特定角色來管理代理的範疇。為了進一步控制，基於屬性存取控制 (ABAC) 可實現動態、情境感知的權限管理，確保 AI 代理僅在需要時獲取所需的訪問權限。
MCP 越來越受歡迎，通過提供更多的背景信息來增強 AI 代理，提高它們的整體性能和用戶體驗。
我們先前寫了一篇文章幫助你了解什麼是 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 是一個多功能的 CIAM 解決方案，支持 SaaS 和 AI 代理產品，使認證和授權變得簡單。原因如下：
有問題嗎？聯繫我們 的團隊，了解 Logto 如何增強你的 AI 代理體驗並滿足你的安全需求。