Kagenti’s Approach to Multi-Agent Security for AI Agents

混淆代理漏洞在多代理系統中構成隱性威脅。以醫院患者計費系統為例，系統授予編排代理 A 一個 Bearer 令牌以存取患者資料。當代理 A 編排任務時，它調用子代理 B、C、D 協助。代理 D 被分配的任務是驗證患者是否有保險——一個看似無害的有限職能。然而，由於令牌存在於上下文或通過呼叫鏈傳遞，代理 D 實際上獲得了完整的患者記錄存取權限。這是典型的混淆代理漏洞：合法授權的代理被誤導或利用去執行超出其職責的操作，且因為委派鏈看起來完全合法，審計日誌中不會出現任何異常標記。

根本問題在於傳統應用安全模型與代理系統的本質衝突。傳統應用有明確的服務間呼叫圖，可以通過網路分割和預定義拓撲來烘焙授權策略。但代理系統的核心價值恰恰在於代理具有自主決策能力——它決定下一步呼叫哪個工具或代理。這種動態性意味著無法靜態預測請求路徑，因此基於拓撲的授權機制完全不適用。傳統角色型訪問控制（RBAC）也無法解決，因為它要求提前知道完整的委託路徑。

Kajenti 平台通過將保護重點從路徑轉移到身份上，優雅地解決了這個難題。它部署兩個關鍵側車組件。Spiffe（Secure Production Identity Framework for Everyone）為每個代理頒發加密工作負載身份——一個短期的 x.509 證書，綁定到特定命名空間、特定工作負載和特定服務賬戶。這不是可複製粘貼的靜態 API 密鑰，而是由系統簽名的時間受限的身份證明，類似於網際網路伺服器用憑證證明其身份的方式。

authbridge 是第二個關鍵層。每當代理發起呼叫時，authbridge 自動注入一個特殊的 HTTP 頭部。這個頭部不僅聲稱「這是代理 D」，而是完整地編碼整個委託鏈：「代理 D 由代理 A 呼叫，代表此特定用戶」，所有參與者都經過密碼簽名，確保無法竄改。當請求到達患者記錄工具或其前置網關時，授權邏輯檢查整條鏈中的每個參與者是否真的獲授權存取此資源。即使代理 D 持有通過委託鏈傳遞的有效令牌，如果授權策略明確指出「代理 D 不應存取患者資料」，請求將被無條件阻止。

從實施角度看，Kajenti 最大化了開發人員體驗。authbridge 在部署時自動處理三項任務：獲取並輪換 Spiffe 身份、在 Keycloak（開源身份與存取管理解決方案）中註冊代理為 OAuth2 客戶端、部署 Envoy 代理驗證入站令牌。代理容器程式碼本身完全不需修改。工具端由 MCP 網關統一管理，它坐在所有工具前面，集中處理路由、速率限制和令牌驗證——更換工具只需改一個 URL。Istio 在 ambient 模式下無需逐 pod 配置即可在代理和工具間建立加密、互認證的通訊。因為所有通訊都基於標準 HTTP，OpenTelemetry 會自動檢測整個請求路徑，生成單一追蹤 ID 跨越完整的委託鏈。Kajenti 附帶 Phoenix 進行端到端代理追蹤，ML Flow 進行實驗追蹤。當某些事出錯時，你可以看到發生了什麼以及誰授權了它。

整個堆疊——Spiffe、Keycloak、authbridge、Istio、MCP gateway——都是 Apache 許可證下的開源軟體，由 Kajenti 統一編排。