2025 是 AI 的一年。隨著 LLM 和代理體驗的發展，身份驗證和授權的新挑戰浮現。本文探討 AI 代理人互動，強調關鍵的安全性和身份驗證場景。
2025 似乎將成為 AI 的一年。隨著 LLM 和代理體驗的迅速增長，我們常常被問到：我們如何擁抱這個新時代？AI 代理人的身份驗證和授權的新使用案例是什麼？在本文中，我們將探索典型的代理體驗，並在這過程中指出安全和身份驗證場景。
我最近購買了 ChatGPT 操作員並探索了一些常見的工作流程。比如，預訂日本東京的住宿。操作員讓我可以根據我的提示輕鬆找到合適的房間。
在結帳時，它要求我登錄，然後將控制權交還給我。
這次體驗讓我感到不安。即使我有控制權，而且代理不能為我登錄，我仍需在操作員的瀏覽器中輸入我的電子郵件和密碼。這意味著如果你通過操作員登錄到你的電子郵件（或任何服務），你的憑證會存儲在 cookie 中。
OpenAI 的操作員聲明其從不存儲用戶憑證並遵循 SOC II 等合規標準。然而，當第三方代理代表你與外部服務互動時，安全風險顯著增加。
通常，直接給代理你的帳戶訪問權和憑證是一個壞主意。
還有很多改進的空間。在下一節中，我將深入探討不同的身份驗證和憑證管理方法，權衡它們的利弊。
如同這個 X Threads 討論的一樣。
在這種方法中，AI 代表你輸入明文憑證（例如電子郵件和密碼）。例如，一個 AI 代理可能會要求你的登錄詳細信息並為你輸入它們。
然而，這種方法帶來了安全風險，因為它可能暴露敏感信息。如果實施是必要的，集成密碼管理器或秘密管理系統將更安全。此外，限制憑證存儲的時間可以幫助最小化洩漏風險。
相較於明文憑證，個人訪問令牌（PAT） 提供了一種更安全的方式來授予訪問權，而不需要密碼或互動式登錄。PAT 對於 CI/CD、腳本和需要程序訪問資源的自動化應用程序十分有用。為了提高安全性，最好限制 PAT 範圍，設置到期時間，並允許撤銷以防止洩漏和帳戶劫持。
OAuth（開放授權） 是用於 Web 上委派授權的廣泛使用標準。它允許用戶授權第三方應用程序有限訪問他們在另一服務上的數據，無需共享登錄憑證。
本質上，OAuth 解決了安全訪問委派的問題：例如，你可以授權一個旅行應用程序讀取你的谷歌日曆，無需給應用你的谷歌密碼。這是通過讓用戶與數據提供者（例如谷歌）進行身份驗證，然後向第三方應用程序發放令牌來實現的，而不是暴露用戶的憑證。
更好的方法是授權 ChatGPT 操作員（或任何其他代理）在 Airbnb 上讀寫，而不需分享你的密碼或憑證。與其讓操作員直接登錄，你可以通過安全授權過程授予訪問權。
在我看來，如果 OpenAI 操作員想要增強信任和身份安全，可以採取多種方式來實現。
將登錄過程移到操作員之外：在 ChatGPT 操作員之外處理用戶登錄。這意味著你可以點擊“用[服務]登錄”按鈕，然後重定向到服務的安全登錄頁面進行自我驗證，完全在聊天或 ChatGPT 操作員之外。比如，如果有 Airbnb 的插件，你將被發送到 Airbnb 的網站輸入你的憑證並授權 ChatGPT，然後插件將收到一個令牌。ChatGPT 僅接收一個臨時的訪問令牌或密鑰，這授予了有限的訪問權（例如“閱讀我的行程”），而不需看到你的實際密碼。
在 AI 代理執行任何任務之前，讓用戶完成授權流程。這種方法類似於許多產品處理集成、市場和連接服務的方式。
Notion 連接頁面
這是另一個例子，就像 Slack 的市場集成與 Notion 一樣。Slack 請求訪問 Notion 的特定工作區，它可以閱讀文章並在你的 Slack 頻道中顯示它們。
在這個過程中，Slack 還提供了一個授權頁面來授權 Notion 訪問工作區。
ChatGPT 操作員應採取類似的方法，通過集成 OAuth，允許代理安全地訪問多個第三方服務。這樣，它可以獲得具有執行任務所需許可的訪問令牌。
AI 代理可以獨立和自主地處理常規任務，但對於高風險操作，需要額外的驗證來確保安全，例如發送資金或更改安全設置，用戶必須通過多因素身份驗證（MFA）來驗證他們的身份。這可以通過推送通知、一次性密碼（OTP）或生物識別確認進行。
然而，頻繁的升級身份驗證會導致用戶感到沮喪，特別是如果觸發過於頻繁。因此，代理特定的體驗需要考慮這個新範疇中的用戶體驗。
為了在不損害用戶體驗的情況下增強安全性，自適應身份驗證和 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 Calendar）的實時查詢和數據檢索變得可能。通過構建 MCP 服務器，你可以將這些遠程服務連接到 LLM 中，為你的 AI 驅動應用程序提供更好的上下文和更智能的任務執行。
與需要生成嵌入並將文檔存儲在向量數據庫中的檢索增強生成（RAG）系統不同，MCP 服務器直接訪問數據而不需要預先索引。這意味著信息不僅更精確和最新，而且以更低的計算開銷集成而不損害安全性。
來源：https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained
對於使用 MCP 服務器的 AI 代理，MCP 服務器、LLM、代理 和 用戶 之間發生多次互動。
在今天的 AI 驅動世界中，代理管理跨不同服務的多項任務，將它們與多個 MCP 服務器集成的需求越來越高。
一個很好的例子是 Composio.dev，一個面向開發者的集成平台，簡化了 AI 代理和 LLM 如何與外部應用程序和服務連接。被稱為“AI 代理代表用戶行動的身份驗證”，它本質上提供了一些可以輕鬆集成到 AI 驅動產品中的 MCP 服務器（連接器）。
我在身份驗證領域中工作，但事實上，這只是在更廣泛的 CIAM（客戶身份和訪問管理）領域的一小部分。他們建設的實際上是一個 MCP 服務器（連接器）的集合——有用，但僅是完整 CIAM 解決方案的一部分。
在前面的例子中，如果我們將 Google Drive（遠程服務）視為一個 MCP 服務器而不是 Airbnb，那麼它就不僅僅是一個第三方集成——它充當外部數據源。這使得代理可以訪問上下文信息，與 LLM 互動，並可能獲得創建、閱讀、更新和刪除（CRUD）文件的許可。
然而，核心的身份驗證和授權需求保持不變。
Logto 是一個多元化的 CIAM 解決方案，支持 SaaS 和 AI 代理產品，使身份驗證和授權變得簡單。以下是原因：
有問題嗎？聯繫我們 團隊，了解 Logto 如何增強你的 AI 代理體驗，滿足你的安全需求。