根據新的 AWS Machine Learning Blog 案例研究，Axonius 在不放棄支撐其既有 AWS 部署的「按客戶隔離」模式下，正將 AI 代理加入其資安 SaaS 平台。

該公司使用 Amazon Bedrock AgentCore，為數百個獨立客戶環境執行代理。這項設計解決了為軟體供應商新增代理式功能時的核心問題：代理必須能跨多個租戶發揮作用，同時仍受限於其所服務客戶的資料、API、身分控制與營運成本。

AWS 在供應商撰寫的文章中描述了該架構及其據稱的效益。來源並未提供來自 Axonius 的獨立效能測試或客戶評論，因此關於部署規模與營運結果的說法應視為 AWS 的報告。

Axonius 維持其以孤島為基礎的 SaaS 模型

Axonius 為資安與 IT 團隊提供資產智慧平台。AWS 表示，該服務會整合來自超過 1,400 個系統的資訊，並運作數百個彼此隔離的客戶環境。每個客戶工作負載都在專屬的 Amazon Virtual Private Cloud（Amazon VPC）中執行，包含負載平衡器、資料庫與一般運算基礎設施等元件。

文章中描述的第一個 AI 代理會分析大型企業環境、找出缺口與風險，並解讀來自多個整合來源的數百萬筆資料點。AWS 表示，此功能的目的是讓初階分析師也能進行複雜分析，而不必讓資深分析師花數小時進行人工調查。

Axonius 並未將這項工作負載轉移到共享的 SaaS 架構，而是希望代理遵循其既有的租戶模型。這個決定塑造了技術需求：處理某一客戶環境的代理不得接觸其他客戶的資料，同時仍必須整合服務既有的驗證、部署與 API 模式。

對 AI 開發者來說，重要的是這裡的多租戶不只是替請求指派一個客戶 ID 而已。代理必須以能維持安全產品既有邊界的方式進行部署、授權、連線、監控與計費。

三種部署模式，各有不同取捨

AWS 以 SaaS 代理部署的三種常見模式來說明設計選擇：孤島、池化與橋接。

在孤島架構中，每個租戶都會獲得專屬資源。若套用到 AgentCore Runtime，這可能代表為每位客戶部署一個專屬代理。這提供清楚的基礎設施邊界，但也增加了需要配置、更新、監控與退役的資源數量。

池化模型則使用共享資源。單一代理可服務多個租戶，每個工作階段會獲得不同的 session ID。AWS 表示，AgentCore Runtime 會為每個工作階段提供專屬 microVM，而應用層控制則負責租戶之間的隔離。

這種做法簡化了部署與客戶導入，但也把更多責任交給應用程式。代理必須在每次請求中正確解讀租戶脈絡，並防止跨租戶存取。租戶特定行為也可能需要在共享部署中加入額外的條件邏輯。

橋接模型則結合兩者。代理 runtime 可以共享，而在工具層套用更嚴格的租戶強制控管。在 AWS 討論的架構中，AgentCore Gateway 位於代理與對外工具之間，讓工具呼叫在執行前可以先依租戶邊界進行檢查。

AWS 將這種混合模式描述為在降低基礎設施開銷的同時，保留對客戶系統存取的更強控制點。案例研究未揭露完整的正式環境實作細節，因此僅憑現有證據，無法判斷 Axonius 如何在共享與專屬資源之間分配每個元件。

身分與工具存取也是隔離邊界的一部分

Axonius 早已在租戶專屬的 Amazon EC2 基礎設施上運行驗證與授權模組。其需求是在不替換該身分流程的前提下加入代理。

AWS 描述了一種設計：租戶透過 OAuth 2.0 身分提供者（例如 Amazon Cognito）進行驗證。權杖中包含租戶專屬的 claim，例如自訂租戶識別碼。AgentCore Runtime 內建的 JWT 授權器會使用身分提供者的 discovery endpoint 驗證權杖，而代理則讀取該 claim，將請求路由到正確的客戶環境。

這種分工很重要。權杖驗證可確認請求來自被接受的身分提供者，但代理與其工具仍須正確套用租戶 claim。實務上，安全邊界同時取決於平台的授權機制，以及將身分對應到 API、資料存放區與工具的程式碼。

同樣的原則也適用於服務整合。AWS 表示，與某租戶關聯的代理必須安全地存取該租戶的 API。文章將 AgentCore Gateway 描述為對外工具呼叫的潛在執行點，形成一層可在工具與客戶工作負載互動前先檢查租戶脈絡的機制。

證據、成本控管與營運規模

AWS 將成本追蹤列為 Axonius 的核心需求之一，因為模型呼叫預期會占代理費用的大部分。按租戶計費可協助 SaaS 供應商決定 AI 功能如何定價、如何設定使用上限，以及如何辨識消耗異常高的客戶或工作流程。

該公司也必須將代理工作負載納入既有的以孤島為基礎的持續交付流程。這項需求很容易被忽略：在原型可行的架構，當每個客戶環境都有自己的部署生命週期時，可能會變得難以營運。

可觀測性也是另一個明確提到的關切。AWS 表示，Axonius 需要對大量代理進行整體層級的監控、警示與追蹤，且細節必須足以進行故障排查。這些需求使代理營運不同於一般應用程式監控。團隊不僅必須知道服務是否可用，還要了解哪些模型呼叫、工具、工作階段與租戶權限共同造成了某個結果。

現有證據來自 AWS，而非獨立稽核者或客戶訪談。AWS 報告指出，AgentCore 讓 Axonius 能在不從零打造自訂運算隔離、驗證或可觀測性基礎設施的情況下，部署隔離的多租戶代理。這是供應商對平台角色的主張，而不是對工程工時、安全性或總成本的獨立驗證比較。

這對開發者與企業買家意味著什麼

對 SaaS 公司而言，Axonius 的案例凸顯了新增代理的一個實務流程：從既有的租戶模型開始，找出資料與工具邊界，再決定哪些控制屬於 runtime、應用程式或 gateway 層。

這個選擇也會影響產品經濟。專屬資源可能提供更清楚的隔離與客製化，但共享 runtime 可簡化導入與營運。橋接設計可以減少重複，但需要在每個工具邊界上嚴格執行政策。沒有任何一種模式能免除測試授權失敗、格式錯誤的租戶 claim、過度的工具權限，以及意外資料外洩的需要。

評估 AI 功能的企業買家應該詢問供應商：租戶身分如何跟隨代理請求、工具呼叫是否獨立授權、模型使用量如何歸屬，以及在事件回應時 traces 如何分離。這些問題對資安軟體尤其重要，因為代理可能會處理敏感的資產、設定與弱點資訊。

更廣泛的市場意涵是，代理平台的競爭不只在模型存取，也在營運原語。runtime 隔離、身分整合、gateway、部署自動化與可觀測性，將決定代理是否能從展示原型變成 SaaS 供應商可支援數百個環境的產品。

接下來要觀察什麼

接下來的訊號將來自 Axonius 或 AWS 的具體正式環境細節：公司在生產中使用的是共享 runtime、專屬 runtime，還是橋接安排；租戶層級成本歸屬如何實作；以及哪些控制是在應用程式碼中執行，哪些是在 AgentCore Gateway 中執行。

開發者也應留意有關部署開銷、事件處理與隔離測試的獨立證據。若能進一步了解模型選擇、吞吐量、延遲，以及執行第一個 Axonius 代理的成本，會更容易超越其宣稱的設計目標來評估這個架構。

Creati.ai 觀點

Axonius 的例子與其說是在安全產品中加入聊天機器人，不如說是讓代理執行方式符合既有的 SaaS 控制平面。困難之處在於，如何把身分、資料存取、工具、計費、發版與除錯，連結到擁有該請求的租戶。

AWS 的案例研究說明了為何受管代理基礎設施對 ISV 具有吸引力，但它並不能證明平台抽象化就能消除應用層級的安全風險。對開發者而言，最重要的教訓是把租戶路由與工具授權視為產品關鍵控制，並在承諾大規模架構前，用部署與失敗資料驗證供應商的說法。