AI身份驗證與授權

AI身份驗證與授權

作者：Dan Moore

人類身份是AI權威的來源。我知道你在想什麼：又一篇關於AI安全的文章？請聽我説完。這篇文章的不同之處在於它基於一個簡單而幾乎顯而易見的真理，而行業在急於發佈代理時卻一直在忘記這一點：保護2010年代API繁榮所用的相同身份驗證和授權模式，正是今天保護AI系統所需要的。

如果你曾構建OAuth集成、管理API密鑰或設置基於角色的訪問控制，你已經擁有了所需的大部分知識。AI身份驗證並非一門新學科，而是現有最佳實踐的延伸。

“任何考慮用算術方法產生隨機數字的人，當然都是處於罪惡狀態。”——約翰·馮·諾依曼

“任何讓AI在缺乏確定性安全保障的情況下訪問資源的人，當然都是處於愚蠢狀態。”——作者

馮·諾依曼的引言是對假設你能從可靠事物中得到非確定性輸出的經典警告。其逆原理同樣適用這裏：AI系統是概率性的——它們推理、產生幻覺和即興發揮——但治理它們為誰行動以及允許做什麼的身份層必須是確定性的。身份不是可以“隨性”的東西。

本文通過三個AI用例：檢索增強生成（RAG）、工具使用（MCP和API）以及代理系統，並以銀行為背景，從身份驗證、授權和身份管理的角度進行審視。我們以FusionAuth為例，但也會提到基於標準的解決方案。

用例速覽

在深入之前，我們先定義工作內容。

檢索增強生成（RAG）通過在查詢時向AI模型提供文檔來增強其可用數據。銀行員工或客户提出問題，RAG系統檢索相關內部文檔，然後提供給LLM以錨定其回答。關鍵身份驗證問題：並非每個用户都應看到每個文檔。客户看到的文檔與出納員不同，而與副總裁看到的也不同。

工具使用（MCP和API）允許AI系統執行操作，例如讀取數據庫、更新客户記錄或調用外部服務。模型上下文協議（MCP）是連接AI工具與服務的新興標準，但帶有豐富文檔的普通API也同樣有效。關鍵身份驗證問題：控制每個工具能做什麼，以及代表誰。

代理系統是半自主的、面向任務的工作流，可以讀取數據、跨多個系統採取行動，並在需要時請求人工輸入。它們是非確定性的軟件組件，將推理步驟鏈接在一起。關鍵身份驗證問題：維護從授權工作流的人到每個操作的身份鏈，以及限制代理的訪問權限。

以下是它們與身份提供商功能的映射：

場景 | 授權 | 身份驗證 | 身份管理 RAG | 是 | 是（框架特定） | 是（框架特定） 工具使用 | 是 | 是 | 是 AI代理 | 是 | 是 | 是

現在讓我們深入每個用例。

RAG：確保模型從不見其不應見之物

場景：你擁有與客户支持任務相關的銀行文檔，如貸款協議、客户協議、合規政策、財富管理手冊和欺詐調查程序。你希望通過AI界面供客户和員工查詢。但並非所有文檔都應對所有用户可用。客服、欺詐與安全、爭議與退款、貸款服務團隊各自需要訪問不同的文檔集。別忘了還有客户自己。

像LinkedIn、DoorDash和Vimeo這樣的公司已經在生產中使用RAG。這個模式已經很成熟。

為什麼身份對RAG重要：

當回答查詢時，LLM甚至不應看到用户無權訪問的文檔。你不需要精心設計巧妙的提示，也不依賴於模型保守秘密。使用正確的授權框架，你在文檔到達模型之前就過濾掉了它們。這主要是一個授權問題。你對用户進行身份驗證（證明他們就是他們聲稱的人），處理他們的查詢，從向量存儲中拉取文檔，然後根據用户有權查詢的文檔進行過濾。模型只接收通過授權檢查的文檔。

實現： 實現遵循一個直接了當的管道：

1. 將文檔分塊成適合向量搜索的片段。
2. 構建一個將用户和角色映射到文檔訪問權限的授權模式。
3. 在向量數據庫中與文檔塊一起存儲元數據，包括哪些角色、部門或用户可以訪問每個塊。
4. 檢索時，對用户進行身份驗證並獲取其身份聲明。
5. 在將結果傳遞給LLM之前，根據用户在步驟3中存儲的屬性進行過濾。

身份驗證方面，一些框架使用JWT，另一些使用API密鑰。過濾機制也取決於你的RAG框架。例如，LangChain允許你構建一個檢索器包裝器，在返回結果之前調用授權服務。

對於授權檢查，使用細粒度授權（FGA）系統。FusionAuth FGA by Permify是一個選項。它提供確定性授權，可以在現場部署以保障數據安全，並隨需求擴展。

你的授權邏輯應該集中化，併成為唯一可靠來源，無論你使用哪個RAG框架。你希望一個過濾器能利用這一點，並且是確定性的，而非概率性的。

以下是請求流的簡化圖，前提是在加載過程中文檔上存儲了適當的元數據。

（流程圖略）

但捕獲元數據呢？文檔並不總是清晰地映射到某個訪問級別，有些文檔的不同塊可能有不同的訪問權限。分塊可能會丟失元數據。例如，一份合規PDF可能包含所有員工可訪問的部分，以及僅限於法律團隊的受限部分。確保你的分塊管道能處理這一點。

因此，計劃在RAG過程中捕獲用户和訪問元數據。如果你希望LLM從不看到用户不應訪問的文檔，你必須確保用户和訪問數據可用。

工具使用：MCP和API

假設你希望允許客服團隊成員使用AI工具更新銀行客户信息——聯繫方式、賬户偏好、服務請求。但不同角色可用的工具不同，即使使用相同工具，不同用户也有不同限制。一級支持代理可能可以更新電話號碼，但不能調整信用額度。

兩種路徑：MCP和API

模型上下文協議（MCP）是使任何API或服務以結構化方式可被AI工具訪問的新興標準。Block、Bloomberg和Amazon等公司已經在內部使用MCP。但MCP不是唯一選擇——普通API也工作得很好。AI模型能夠從良好文檔中理解API語義。

在發佈時最新版本的MCP使用OAuth 2.1和授權碼授予用於AI系統或工具的身份驗證。還有正在開發的擴展支持客户端憑證授予。

API重用傳統的身份驗證方法：API密鑰或訪問令牌。自REST API時代起你一直使用的相同網關模式可以幫助對MCP或API服務器進行速率限制或監控訪問。

MCP實現： 以下是使用身份設置MCP的方法：

1. 在你的現有API和服務之上構建一個MCP服務器。將MCP服務器配置為指向支持OAuth 2.1的身份提供商。MCP客户端應預先註冊或動態創建。
2. 當MCP客户端嘗試訪問MCP服務器時，MCP服務器應重定向到配置的身份提供商，該提供商將對驅動MCP客户端的用户進行身份驗證，然後頒發令牌。令牌隨後呈現給MCP服務器。

（瞭解更多關於MCP和實現）

如果你需要超出OAuth範圍的細粒度控制，你可能需要向MCP服務器訪問的服務添加細粒度授權。

API實現： 對於API訪問，模式更簡單：

1. 使用你現有的API和服務；無需MCP服務器。
2. 使用身份提供商對用户進行身份驗證。
3. 獲取訪問令牌。
4. 如果AI有web工具，它可以使用REST調用訪問API，傳遞令牌。
5. 考慮也提供使用API的SDK。同樣，如果你需要超出OAuth範圍的細粒度控制，你可能需要向API和服務添加細粒度授權。

你可能有圍繞身份驗證和API的一些基礎設施，可以重用。例如，多個API網關與FusionAuth一起工作。

代理系統：出發去工作

這是情況變得有趣的地方，也是AI身份驗證需要新思維的地方。

代理是能夠被提示以不同程度自主權完成任務的非確定性軟件組件。它們擴展到數十或數百個實例，與人類、API和MCP工具交互，並將推理步驟鏈接在一起。

場景： 你的銀行希望自動化新企業賬户設置。新企業需要支票賬户、儲蓄賬户、商户服務和薪資設置。代理需要：

• 評估企業類型並推薦套餐
• 從文檔存儲中收集企業文件（EIN、公司章程）
• 通過API檢查信用狀況
• 通過日曆服務安排與關係經理的入職會議

這是一個多步驟工作流，處理混亂的數據和外部服務。這正是代理擅長的地方。但這也意味着它們將讀取敏感文檔、調用外部API並代表人類安排會議。風險很高。

身份鏈：

保護代理的基本概念：你需要知道誰在何時授權了什麼。

當人類啓動代理工作流時，該人類的身份需要伴隨代理的每一步。如果代理讀取文件，你需要知道哪個人類授權了那次讀取。如果代理安排會議，你需要知道代表誰。如果出現問題，你需要一條可追溯到發起人的審計線索。

這條審計線索就是身份鏈。

人類身份的攜帶深度取決於你的需求。如果你在每一步都進行授權檢查，所需的身份取決於規則。如果你主要進行日誌記錄和調試，你可能只需要人類身份和當前代理身份。對於由計劃觸發的代理工作流，身份鏈可能從服務賬户或cron作業的作者開始。

你可以使用簽名的JWT來實現這一點，這確保了身份鏈在你的系統中得以保留。

FusionAuth目前不支持OAuth令牌交換（RFC 8693），但Vend JWT API實現了相同的身份鏈語義。如果你的身份提供商原生支持令牌交換，那是一個基於標準的替代方案。

FusionAuth的Vend JWT API允許你創建嵌入原始用户並傳播身份信息的令牌。