什麼在代理應用程式的驗證和識別中改變了，什麼沒有改變

最近我審閱了這篇文章，並提到了代理驗證：

我們看到了一些暗示這將是什麼樣子。最新的 MCP 規範，例如，包含了一個基於 OAuth 2.1 的授權框架，這表明可能向給 AI 代理授予範圍可撤銷的憑證而不是原始密鑰的方向移動。我們可以想像一個場景，其中 AI 代理不會獲得你的實際 AWS 密鑰，而是獲得一個短期憑證或能力憑證，使其能夠執行定義狹窄的操作。

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

很多朋友和不在安全或 CIAM 領域的人以為這是新東西，但它絕對不是。OAuth 是一種標準的基於令牌的授權協議，包括具有範圍權限的令牌（訪問令牌）。這些是時間敏感且範圍有限的，這確保了資源和服務的安全性和適當的訪問控制。在全球 SaaS 市場（人工智慧出現前），大多數專業的身份解決方案已經基於此構建。

當你將 Google 帳戶連接到第三方應用程式（如 Notion 或 Zoom）時，它使用 OAuth 來請求僅所需的權限，例如訪問你的日曆或聯繫人，而不會暴露你的 Google 密碼。你可以隨時從你的 Google 帳戶設置中撤銷該訪問權限。這種委派訪問模式正是 OAuth 為之設計的，現在這已經擴展到代理應用程序。

在代理世界中沒有改變的內容#

身份驗證不是新內容，仍然基於 OAuth 2.1#

有兩個主要協議出現：MCP 和 A2A。

• MCP 專注於 LLM 與你應用程式工具和上下文的互動。
• A2A 專注於啟用代理間的任務交換。

但說到驗證和授權，兩者仍然依賴於行業內已建立的標準，比如 OAuth。

MCP 授權伺服器必須實施 OAuth 2.1，並採取適當的安全措施以保護機密和公眾客戶。

A2A 客戶端負責通過外部於 A2A 協議的過程（例如 OAuth 流程、授權碼、客戶端憑證、安全密鑰分發等）獲取必要的憑證材料（如 OAuth 2.0 令牌、API 密鑰、JWT）。

正如 Google 所說：

A2A 的目標是與現有企業結構和廣泛採用的最佳實踐無縫整合，而不是發明新的專有標準來解決安全和操作問題。

代理是否需要唯一的身份？#

很多炒作和 FOMO 內容推動了這樣的觀點：隨著代理變得越來越普遍，我們需要一個用於管理代理身份的系統。

答案是：既是又不是。

是的，因為我們正在引入一個新的層次在於人類和機器之間。確實需要：

• 管理和識別代理
• 分配唯一 ID
• 跟踪日誌
• 審計行動（了解任務是否由人或代理執行）

然而，在大多數技術情況下，沒有必要創建“代理身份”的正式概念。

代理 ≠ 用戶，≠ 服務帳戶。

在每個代理背後，仍然有一個用戶，而通常用戶身份已經足夠。

今天，主要的代理：

• 基於用戶授權行動（例如，OAuth 令牌）
• 執行邏輯或進行 API 調用
• 執行短暫的單次任務（不需要跟踪）

在這種意義上，代理只是一個作為工具的功能，不需要一個全球唯一的 ID。

例如：

• 一個 GPT 代理調用你的日曆 API 只需要你授予的權限。
• 一個 LangChain 代理不需要身份，只要它能調用正確的工具，它就能工作。

在 AI 出現之前，我們就有了機器對機器（M2M）驗證的概念。

M2M 是指服務之間的自動化資料交換，沒有人工干預。

在此情境中，身份驗證通常使用客戶端應用程式或服務帳戶。

如果你真的希望你的代理擁有身份（例如用於審計），你可以使用應用程式 ID，這就足夠了。

你仍然需要定義產品的架構#

這沒有改變。無論你的產品是否涉及代理，身份系統的架構取決於你的用戶是誰以及你的系統如何與他們互動。

如果你正在建設面向消費者的代理產品： 你將需要輕量化的登錄方法（電子郵件、電話、社交登錄），以及一個統一的用戶池來管理與你的應用程式及其代理互動的個體。代理使用代理令牌（例如，通過 OAuth）代表這些用戶行動。

範例：

假設你正在構建一個 AI 排程助理，或一個 AI 驅動的日曆機器人。

每個用戶使用他們的個人 Google 帳戶登錄。你的系統使用 OAuth 獲取訪問他們日曆的權限。代理沒有自己的身份，它使用用戶的令牌來安排會議、檢查可用性或發送提醒。身份架構很簡單：一個全球用戶池，令牌存儲，和每個用戶的同意跟踪。

如果你正在建設一個 B2B 代理平台：

你需要在組織層級支持身份，而不僅是個別用戶。這包括：

1. 企業客戶的 SSO
2. 工作空間或租戶級別分割
3. 組織層級的代理授權政策（例如，控制代理可以在團隊間做哪些事情）
4. 管理員級別的可見度和日誌，關於所有代表員工的代理活動

範例：

假設你正在構建一個平台，為公司提供 AI 代理來自動化內部工作流 —— 例如安全分析機器人監控日誌並發送警報，或銷售助理從 CRM 資料撰寫電子郵件。

使用你的平台的每個公司都想：

1. 使用其現有的 SSO 登錄
2. 控制代理可以訪問什麼（例如，內部工具、文件系統）
3. 查看哪個代理執行了什麼任務，在哪位員工的授權下

在這種情況下，你的身份架構需要支持多租戶設計，限定的代理許可權，和基於組織的政策。代理仍然代表用戶行動，但許可權和身份界限由每個業務租戶執行。

在這兩種情況下，身份模型定義了代理如何運作，它們能訪問什麼，以及你的系統如何確保可責性。

利用此指南幫助你規劃身份和產品架構。

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

你仍然需要安全層來保持代理驅動的應用程式安全#

不論是否是代理應用程式，這些基本安全層對於保護你的用戶和系統是必需的：

• 多因素驗證 (MFA)

  即使憑據被洩露，也能防止未經授權訪問。

  範例：如果代理幫助你執行高風險操作，如進行交易或更改身份設置，應保持人類在回路中並使用 MFA 確認行動前確認。

• CAPTCHA

  阻止自動濫用，例如憑據漫遊或機器人驅動的註冊。

  範例：在 3 次登錄失敗後顯示 CAPTCHA，以防止暴力破解。

• 基於角色的訪問控制 (RBAC)

  確保用戶和代理僅訪問允許的內容。

  範例：公司工作空間中的 AI 助理可以讀取日曆事件，但不能訪問結算數據，除非明確分配了更高的角色。

• 無密碼登錄

  改善用戶體驗並降低弱密碼風險。

  範例：讓用戶使用發送到其電子郵件的魔法鏈接或面部識別等生物提示登錄。

這些功能適用於傳統應用程式和代理應用程式，尤其是在代理開始跨敏感資料和系統運作時。

在代理世界中已經改變的內容#

身份驗證比以往重要#

隨著代理和多代理工作流的出現，我們看到用戶、代理、API 和 MCP 伺服器之間的新用例。這些場景的數量和多樣性正在迅速增加，遠超以前。

每當這些連接發生時，授權變得比以往更明顯。用戶必須明確同意，並且需要在系統間仔細管理權限。這就是為什麼現在大家都在談論保持**“人類在回路中”**，確保用戶對代理能做什麼和它們獲得何授權有足夠的控制和可見性。

你的 AI 應用程式可能需要與許多外部服務整合#

MCP 生態系統正在擴展，這意味著你的應用程序不再僅僅是一個獨立的服務：它是一個更大、相互連接的網絡的一部分。

為了為 LLM 提供豐富、有用的上下文，你的代理可能需要：

• 訪問多個 MCP 伺服器

  範例：想像一個 AI 專案經理，它從 Jira 提取任務更新，從 Google 日曆中獲取團隊可用性，從 Salesforce 中提取銷售數據，每個都由不同的 MCP 伺服器提供。要生成每週摘要，代理必須安全地與多個數據源互動。這就是身份驗證和授權發揮作用的地方，以保護每個連接並控制如何共享數據。

• 與外部 API 和工具連接

  範例：一個客戶支持代理可能需要從 Shopify 獲取訂單歷史，更新 Zendesk 中的票據並在 Slack 中觸發工作流。如果沒有整合，代理就會變得孤立且無效。

隨著代理承擔的責任越來越多，整合成為實用的關鍵。你的 AI 產品不僅僅是在其自身上的能力，而且是它能夠在連接的生態系統中訪問、協調和推理的能力。因此，以安全和靈活的方式構建互操作性比以往任何時候都更為重要。

你需要接受開放標準：OAuth/OIDC 比以往更重要#

在 AI 時代，對安全、靈活整合的需求正在增長。這使得 OAuth 2.0 和 OIDC 比以往更加重要。

主要用例包括：

• 遠程 MCP 伺服器：允許第三方代理使用代理令牌安全地訪問你的產品。
• 第三方整合：允許其他工具或代理連接到你的應用程式（例如，專案管理平台），而無需原始憑證。
• 代理開發：構建 AI 代理，安全地代表用戶跨服務行動。
• 智能設備：使用 OAuth/OIDC 進行事物，如 AI 驅動的筆記設備，以驗證用戶身份並連接到雲端——特別是在 UI 最小的情況下。

這些協議提供安全、基於令牌且由用戶同意的訪問。

在代理和互聯的系統世界中這至關重要。請查看這篇文章以了解為什麼 OAuth 和 OIDC 很重要

在代理軟體時代中設計信任和擴展#

隨著代理產品的發展，身份和授權的核心原則保持不變，但背景正在改變。代理引入了新的委派、同意和訪問表面。這就是為什麼堅持開放標準如 OAuth，構建清晰的架構並強制執行堅固的安全實踐不僅僅是最佳實踐，它們是基礎。現在謹慎設計意味著你的系統將以自信、靈活和信任的方式擴展到 AI 駕駛的未來。