AI智能代理多租戶：憑證隔離、命名空間分離與SOC 2
AI智能代理多租戶是智能代理平台的架構屬性，它在基礎設施層將每個租戶的憑證、記憶體、執行上下文和稽核記錄與其他所有租戶相互隔離，而非依賴開發者慣例或智能代理指令遵循。與Web應用多租戶不同，智能代理持有活躍的API金鑰，在請求間累積持久記憶體，並執行已驗證的工具呼叫：這三個維度超越了資料行隔離，必須按租戶分區以滿足OWASP LLM06和SOC 2 CC6.1的要求。
AI智能代理多租戶是智能代理平台的架構屬性，確保為不同租戶提供服務的智能代理無法存取彼此的憑證、記憶體、執行上下文或稽核記錄。這透過按租戶的憑證庫範圍、黑板命名空間ACL、容器化執行隔離和分區稽核日誌在基礎設施層強制執行，使建立在該平台上的B2B SaaS產品將租戶隔離作為結構性保障而非開發者職責來繼承。
為何智能代理多租戶比Web應用更難
傳統Web應用多租戶只隔離一件事：資料行。新增tenant_id欄，過濾每個查詢即可。智能代理多租戶必須隔離Web應用從未需要處理的三個額外維度。任何一個維度的失敗都構成OWASP LLM06敏感資訊披露下的跨租戶資料洩漏事件。
Web應用從未面對的三個隔離維度
憑證隔離：Web應用透過工作階段令牌識別使用者；工作階段對外部服務沒有持久存取權。智能代理需要真實的按租戶範圍API金鑰。如果租戶A和租戶B的智能代理共享一個OpenAI金鑰，租戶A的大量使用會降低租戶B的速率限制空間；租戶A的帳單包含租戶B的令牌消耗；在租戶A被攻破後撤銷金鑰也會中斷租戶B；提供商控制台中的金鑰使用日誌無法按租戶分區，違反SOC 2 CC6.1邏輯存取要求。
記憶體隔離：智能代理在互動間累積工作記憶（上下文視窗）、語意記憶（向量儲存嵌入）和協調狀態（黑板條目）。如果這些記憶體儲存中的任何一個未按租戶分區，在某個任務中擷取到智能代理上下文的租戶A文件，可能在語意相似的任務中出現在租戶B的智能代理上下文中，無需任何對抗性輸入。這是OWASP LLM06 v1.1的典型跨租戶資料洩漏場景。
稽核日誌隔離：租戶A和租戶B工具呼叫混雜的共享稽核日誌無法在不暴露租戶B記錄的情況下匯出給租戶A的合規團隊。SOC 2 CC6.1要求每個租戶的稽核員只能看到自己的記錄，這需要儲存層分區而不只是查詢時過濾。
Shared-Nothing vs Pool vs Bridge：三種多租戶模型
孤島模型（Shared-Nothing）：每個租戶擁有完全專用的基礎設施。每租戶成本最高但隔離最強。適合有嚴格資料駐留要求的企業租戶和受監管行業。
池模型：所有租戶共享基礎設施，僅透過應用層的tenant_id參數過濾來實現隔離。成本最低，隔離最弱。僅適用於無企業客戶的低敏感度工作負載。
橋接模型：在控制平面強制隔離的共享計算基礎設施。每個租戶獲得由基礎設施ACL強制執行的專用憑證庫範圍和記憶體命名空間；計算共享但受Kubernetes命名空間ResourceQuota約束。這是B2B SaaS的推薦預設值。OpenLegion的專案範圍架構是橋接模型的實作。
OWASP LLM06：跨租戶敏感資訊披露
OWASP LLM Top 10 v1.1將跨租戶資料洩漏歸類為LLM06：高嚴重程度的敏感資訊披露。
跨租戶資料洩漏攻擊向量
- 租戶A的智能代理處理客戶支援請求。它將租戶A的內部產品文件和客戶記錄擷取到上下文視窗，然後將相關段落嵌入並儲存到共享向量儲存中。
- 租戶B的智能代理處理語意相似的請求。它查詢共享向量儲存；由於沒有按租戶分區的索引，查詢返回租戶A的嵌入段落作為Top-K最近鄰。
- 租戶A的內部客戶記錄出現在租戶B的智能代理上下文中。
無需對抗性輸入。資料洩漏是架構失敗。
包括提示注入（LLM01）的完整框架請參見AI智能代理安全與OWASP LLM Top 10威脅模型。
記憶體洩漏：工作記憶、向量儲存和黑板狀態
三種智能代理記憶體類型各需要單獨的租戶隔離處理：
工作記憶（上下文視窗）：智能代理的當前上下文視窗不得在租戶請求間共享。
語意記憶（向量儲存）：使用共享向量儲存時，每次寫入必須包含tenant_id作為強制元資料欄位，每次查詢必須包含在儲存客戶端層注入的{tenant_id: current_tenant_id}元資料過濾器。
協調狀態（黑板）：跨智能代理共享的鍵值狀態必須使用租戶範圍的鍵前綴，例如projects/{tenant_id}/*，並在mesh層強制執行ACL。
憑證隔離：按租戶的庫範圍
按租戶憑證範圍：為何共享API金鑰會失敗
最常見的多租戶憑證錯誤是為所有租戶使用一個LLM API金鑰。這會以四種不同方式失敗：速率限制共享、成本無法歸因、撤銷波及範圍、稽核隔離破壞。
正確模式：每個租戶獲得自己的API金鑰。完整的庫架構請參見憑證管理和按租戶庫範圍模式。
JWT反模式：無撤銷的令牌範圍
三種緩解措施，全部需要同時採用：
- 短期令牌：智能代理工具呼叫令牌的TTL不超過300秒（5分鐘）。
- 主動撤銷登錄：每租戶的有效令牌ID表。
- 按任務令牌輪換：為每個智能代理任務簽發新令牌。
執行隔離：Kubernetes命名空間和資源配額
按租戶命名空間：RBAC、NetworkPolicy和ResourceQuota
需要四個元件：
按租戶命名空間：每個租戶的智能代理Pod在專用Kubernetes命名空間中執行。
具有命名空間範圍ServiceAccounts的RBAC：每個租戶獲得專用ServiceAccount，其RoleBindings限定在自己的命名空間。
預設拒絕的NetworkPolicy：預設對每個租戶命名空間套用拒絕所有入口和出口的策略。
帶LimitRange的ResourceQuota：透過ResourceQuota按命名空間套用CPU、記憶體和Pod數量限制。
程序級沙箱控制請參見AI智能代理沙箱和程序級執行隔離。
多租戶智能代理平台的SOC 2合規
CC6.1：按資料分類的邏輯存取控制
CC6.1合規需要三個具體控制：按租戶憑證庫範圍、按租戶記憶體命名空間和按租戶稽核日誌分區。
SOC 2稽核員將跨租戶使用的共享API金鑰標記為CC6.1缺陷。完整控制對映請參見AI智能代理治理和SOC 2合規框架。
CC6.6：對提升權限智能代理的特權存取限制
CC6.6合規需要：結構性防止跨租戶提升權限智能代理呼叫、可稽核的特權智能代理權限定義、特權操作的每次呼叫稽核記錄。
按租戶稽核日誌分區
儲存鍵模式：audit/{tenant_id}/{year}/{month}/{day}/{agent_id}/{tool_call_id}.json
按租戶S3儲存桶策略：每個租戶單獨的儲存桶前綴和資源策略。
OTLP資源屬性：在每個OpenTelemetry日誌記錄中包含tenant_id作為資源屬性。
按租戶SIEM工作區：在共享SIEM部署中設定按租戶的索引或工作區。
完整稽核日誌設計請參見AI智能代理稽核日誌和按租戶合規記錄。
反模式：不應做的事
反模式1：租戶ID在智能代理提示中而非基礎設施中
將tenant_id注入智能代理系統提示並依賴智能代理來強制執行自己的租戶邊界是最常見且最危險的多租戶反模式。會因提示注入繞過、幻覺漂移和無基礎設施強制執行而失敗。
反模式2：無租戶過濾器的共享向量儲存
這是主要的OWASP LLM06資料洩漏向量。修復需要每次寫入的強制元資料欄位tenant_id和每次查詢時在儲存客戶端層注入的元資料過濾器。
反模式3：提示中帶租戶聲明的共享LLM API金鑰
此反模式在CC6.1失敗：速率限制共享、成本歸因失敗、撤銷波及範圍和無法按租戶分區的提供商稽核記錄。
OpenLegion的看法：透過架構而非慣例實現隔離
OpenLegion透過智能代理程式碼無法繞過的三種基礎設施層機制強制執行租戶隔離：按專案憑證庫範圍、黑板命名空間ACL和預設封鎖的跨專案智能代理訊息傳遞。
| 隔離控制 | OpenLegion | LangChain / LangGraph | CrewAI | AutoGen | OpenAI Agents SDK |
|---|---|---|---|---|---|
| 按租戶憑證庫範圍 | 基礎設施強制執行 | 開發者慣例 | 開發者慣例 | 開發者慣例 | 開發者慣例 |
| 黑板命名空間ACL | 基礎設施強制執行 | 不可用 | 不可用 | 不可用 | 不可用 |
| 跨專案智能代理訊息傳遞已封鎖 | 預設封鎖 | 不可用 | 不可用 | 不可用 | 不可用 |
| 按租戶預算上限（Zone 2） | 基礎設施強制執行 | 開發者慣例 | 開發者慣例 | 開發者慣例 | 開發者慣例 |
| 按租戶稽核分區（WORM） | 基礎設施強制執行 | 開發者慣例 | 開發者慣例 | 開發者慣例 | 開發者慣例 |
| Kubernetes命名空間 + ResourceQuota | 平台管理 | 自我管理 | 自我管理 | 自我管理 | 自我管理 |
託管基礎設施層請參見具有租戶隔離保障的託管AI智能代理平台。
常見問題
什麼是AI智能代理多租戶？
AI智能代理多租戶是智能代理平台的架構屬性，確保為不同租戶提供服務的智能代理無法存取彼此的憑證、記憶體、執行上下文或稽核記錄，在基礎設施層而非開發者慣例中強制執行。它與傳統Web應用多租戶的不同在於需要三個額外的隔離維度：按租戶憑證庫範圍、按租戶記憶體分區（向量儲存和黑板）以及按租戶稽核日誌分區。
什麼是OWASP LLM06，它如何影響多租戶智能代理系統？
OWASP LLM Top 10 v1.1 LLM06敏感資訊披露將跨租戶資料洩漏歸類為高嚴重程度：智能代理處理租戶A的資料，將擷取的文件儲存在沒有租戶分區的共享記憶體層中，然後在租戶B的回應中顯示。攻擊不需要對抗性輸入。緩解需要在儲存客戶端層的按租戶記憶體分區、按租戶憑證範圍和按租戶稽核日誌分區。
SOC 2 CC6.1和CC6.6如何適用於多租戶智能代理平台？
SOC 2 Type II CC6.1要求根據資料分類限制邏輯存取；在多租戶智能代理系統中，租戶邊界是主要分類邊界。CC6.6適用於具有資料庫寫入或外部API呼叫等提升工具權限的智能代理。跨租戶使用的共享API金鑰通常會被標記為CC6.1缺陷。
多租戶智能代理系統中的JWT令牌TTL漏洞是什麼？
用於智能代理工具呼叫中租戶上下文的JWT存取令牌通常在3600秒（1小時）後過期；如果為租戶A頒發的令牌被錯誤快取、因基礎設施漏洞共享或在除錯日誌中被捕獲，它可以在整個TTL期間無需偵測地用於歸因於租戶A的已驗證呼叫。緩解需要三種同時套用的控制：TTL不超過300秒的短期令牌、按租戶的主動令牌撤銷登錄和按任務令牌輪換。
Kubernetes命名空間隔離如何用於多租戶智能代理？
Kubernetes命名空間隔離透過四個元件提供執行隔離：按租戶專用命名空間、具有按租戶ServiceAccounts和命名空間範圍RoleBindings的RBAC、具有預設拒絕和僅必要外部端點明確允許清單的NetworkPolicy，以及具有按命名空間計算限制的ResourceQuota。命名空間隔離解決多租戶的計算維度，必須與按租戶憑證範圍和記憶體分區相結合。
多租戶智能代理系統中的共享向量儲存反模式是什麼？
在儲存客戶端層注入的每查詢租戶過濾器的共享向量儲存是主要的OWASP LLM06資料洩漏向量。正確實作需要每次寫入的tenant_id元資料欄位和每次查詢在向量儲存客戶端層注入的元資料過濾器，而不是從智能代理程式碼作為參數傳遞。對於嚴格的合規要求，按租戶命名空間或獨立索引在儲存地址層強制執行邊界。
OpenLegion如何強制執行租戶隔離？
OpenLegion透過三種基礎設施層機制強制執行租戶隔離：按專案憑證庫範圍（Zone 2使用來自mesh工作階段的已驗證專案上下文而非智能代理提供的參數來解析$CRED{}句柄；跨專案憑證解析在架構上是不可能的）、黑板命名空間ACL（智能代理僅對其專案的鍵前綴具有讀寫權限，由mesh監督員強制執行）和預設封鎖的跨專案智能代理訊息傳遞。
智能代理平台的三種多租戶架構模型是什麼？
三種多租戶模型具有不同的隔離保證和成本特徵：孤島模型（Shared-Nothing）為每個租戶提供完全專用的基礎設施；池模型共享所有基礎設施，僅在應用層套用隔離；橋接模型共享計算基礎設施，同時透過按租戶憑證庫範圍和記憶體命名空間ACL在控制平面強制隔離。橋接模型是B2B SaaS的推薦預設值。