多租戶 AI 代理基礎設施：隔離、限制與共用狀態

多租戶代理基礎設施必須從已驗證的上下文取得租戶範圍，並將它一路帶過工具、資料庫、佇列、快取、成果、憑證及日誌。提示詞或模型生成引數中的 tenant_id 並不構成隔離。

代理會增加後端動作的數量與種類，因此遺漏一道邊界，就可能在沒有人類透過受限介面操作的情況下跨越租戶。即使模型產生混淆、擷取內容帶有敵意，或兩項資源使用相同顯示名稱，控制仍必須有效。

接受資源輸入前先綁定身分

從工作階段或應用程式憑證解析租戶，將該身分傳入代理控制平面，再以伺服器端資源記錄授權要求的動作。

flowchart LR
    Request[Agent tool call] --> Session[Authenticated session]
    Session --> Scope[Tenant and delegated scope]
    Scope --> Policy{Authorize resource and action}
    Policy -->|allow| Tool[Execute scoped tool]
    Policy -->|deny| Audit[Record denial]
    Tool --> DB[(Tenant-scoped data)]
    Tool --> Queue[(Tenant-scoped work)]
    Tool --> Artifacts[(Tenant-scoped artifacts)]

不能讓工具引數覆寫已驗證租戶。即使資源 ID 在全域唯一，也應在目前租戶之下查詢，讓授權規則保持明確。

刻意選擇資料庫隔離模型

當應用程式角色無法繞過資料列層級安全性，而且租戶上下文由伺服器端設定時，RLS 可以提供強健的保護。它不一定比應用程式 WHERE 子句弱，實際保證取決於政策、角色及每一條替代連線路徑。

法規要求、租戶規模特別大、客戶管理加密或需要獨立還原時，可採用更高隔離模型。不要只因呼叫者是代理，就選擇每租戶一個資料庫。

資料庫模式指南示範複合租戶鍵與操作限制。

將範圍帶過每一個共用子系統

資料庫隔離只是多道邊界之一：

• 快取鍵前綴使用不受使用者控制的租戶識別碼，失效處理也要包含它。
• 由已驗證的伺服器上下文將租戶範圍放進佇列訊息，worker 消費時再重新授權。
• 為物件鍵與向量集合建立命名空間，在簽發 signed URL 或搜尋前檢查所有權。
• 瀏覽器與 sandbox 工作階段應由租戶擁有，使用不同的檔案系統及憑證。
• 將工具工作階段與 OAuth 授權限制在其代表的租戶及使用者。
• 依租戶、代理及高影響動作分隔速率與支出限制。

以兩個租戶使用相同資源名稱進行測試。production、orders 或 main 等顯示名稱，常在模型從上下文選擇資源時造成衝突。

讓憑證與日誌了解租戶

將供應商憑證存成由租戶擁有的密鑰參照。工具 worker 只應取得自己有權解析的參照。即使共用供應商帳戶，仍需要依租戶計費與撤銷。

日誌及追蹤需要租戶欄位才能調查，但可觀察性系統的存取本身也必須限制租戶範圍。匯出前先遮蔽提示詞、工具引數及結果。能搜尋所有租戶的內部儀表板可能適合小型且可信任的維運團隊，但它仍然是特權介面。

NIST 的零信任架構將存取視為以身分與資源為基礎的逐次請求決策，而不是依網路位置判斷。這很適合背景 worker 與內部工具呼叫，因為它們不該只因執行在平台內部就取得廣泛權限。

限制迴圈，但不要把配額當成權限

依租戶限制並行執行、工具呼叫、模型支出、儲存空間及重複失敗，並為破壞性或高成本工具設定更窄限制。迴圈應暫停該租戶受影響的工作，並留下可供人類檢查的操作記錄。

限制只能控制數量，無法讓未授權呼叫變得可接受。先執行授權再計入配額，並回傳穩定錯誤類別，避免代理重試政策拒絕。

為整張租戶資源圖設計刪除

租戶刪除路徑應清查資料庫、快取值、佇列工作、成果、記憶、索引、瀏覽器工作階段、sandbox、憑證、日誌、備份及作用中操作。決定哪些立即刪除、稍後到期，或因法律與安全原因保留。

刪除資料前，先停止新工作並撤銷憑證。刪除應可恢復且具冪等性，因為部分清理很可能發生。記錄每項資源的完成狀態，但不要保留已刪除內容本身。

使用刻意相似的資料測試隔離

建立兩個測試租戶，使用重疊名稱及近似 ID，嘗試透過每項工具、worker、快取、佇列及成果路徑存取。加入一份指示模型切換租戶 ID 的擷取文件。無論模型輸出什麼，伺服器都應拒絕該動作。

下方提示詞會將這項測試轉成儲存庫專用計畫。它會先找出租戶範圍的來源，因為只看資料庫圖無法證明隔離。