Red Hat 近日在柏林 Nvidia GTC 宣布擴大與 Nvidia 的合作，以雙方的 AI 平台 Red Hat AI Factory with NVIDIA 為核心，結合開源代理沙盒 OpenShell，以及在 BlueField 資料處理器（DPU）上運行的 Sentry 安全框架，把 AI 代理的安全控制放在代理之外，部分監察及隔離能力更移到主機之外。雙方亦推出模型存取參考設計，以閘道管理權限、配額及成本。這套分工意味企業部署自主代理時，可能需要把原由應用團隊處理的邊界控制，交由平台、基礎設施及保安團隊共同管理。
代理不應自守邊界，控制移到代理之外
方案針對兩類風險：代理越出獲授權範圍，以及攻擊者透過提示注入（prompt injection）或供應鏈攻擊入侵代理。代理本身出錯或遭入侵時，企業便不能只靠代理內部的指令及邏輯，限制它接觸哪些資源。
Nvidia 企業軟件副總裁 John Fanelli 在聲明中指出，代理不應自行執行邊界控制，相關控制應放在代理之外的運行環境（runtime）及底層基礎設施。今次設計可理解為把控制分配到不同層次：OpenShell 限制代理運行時的行為，Sentry 從獨立硬件層監察及隔離工作負載；另一項模型存取參考設計則管理代理可用哪些模型、使用多少資源。
OpenShell 在核心層設界，代理不接觸密鑰
OpenShell 是開源的代理沙盒運行環境，Red Hat 與 Nvidia 都是主要貢獻者。兩家公司稱它可提供標準化防護措施（guardrails）、運作可見度及運行時安全。
據 Tech Times 報道，OpenShell 以 Rust 編寫，採用 Apache 2.0 授權，政策引擎在代理程序以外運行；它透過 Linux Landlock 限制檔案系統存取、seccomp BPF 過濾程序可使用的系統呼叫，再以網絡命名空間（network namespaces）隔離代理的網絡環境。檔案系統及程序政策在建立沙盒時鎖定，網絡及推理政策則可在沙盒運行期間更新，毋須重新啟動。模型供應商的 API 密鑰存放在沙盒外的主機，由 OpenShell gateway 轉發請求；代理只接收模型回應，不會接觸底層密鑰。
身份與密鑰管理亦已有相關整合。IBM 早前在 9 月底的網誌指出，Nvidia 當時發布 Open Agent Safety Platform，而處於公開預覽階段的 IBM Agent Identity 及 HashiCorp Vault 亦已與 OpenShell 整合，為代理提供經驗證身份及最低所需存取權。
這種政策分工讓企業可把建立沙盒前必須確定的限制，與運行後可調整的網絡及模型政策分開審批。例如應用團隊提出所需資源，再由平台及保安團隊決定開放哪些權限，而非讓每個代理自行維護一套邊界。
Sentry 在 DPU 監察，防線獨立於主機
在 OpenShell 軟件層之下，Nvidia Sentry 安全框架在 BlueField DPU 上運行，透過 DOCA Argus 從獨立的硬件安全域監察工作負載。Red Hat 技術網誌指出，Argus 會檢查選定的主機記憶體結構，觀察程序、檔案及網絡活動，主機毋須安裝監察軟件。整合的保安系統可利用 Argus 警報觸發 BlueField 政策，隔離受影響的工作負載，警報亦可接入企業的 SIEM、SOAR 及 XDR 平台。
Red Hat 稱 Sentry 可在數毫秒內隔離受入侵的代理。這層設計的重點是把 AI 工作負載與網絡、安全服務分開：前者在伺服器 CPU 上運行，後者在 BlueField 的 Arm 處理器上執行。系統設定為限制主機存取時，即使攻擊者入侵主機，這種分隔仍有助保護基礎設施控制。
架構建基於 Red Hat OpenShift 4.22 現有的 BlueField-3 支援，惟 Sentry 部署需要哪一代 BlueField 硬件，公布資料未有說明。把監察及網絡功能移到 DPU，可減輕主機 CPU 負擔，騰出更多算力給 AI 工作負載；但企業評估這項取捨時，亦要把 DPU 硬件需求，以及網絡和保安團隊的設定工作納入部署規劃。
模型存取交閘道管，集中管理配額與成本
模型存取是另一項獨立參考設計。雙方以 Nvidia Inference Hub 參考設計為基礎，結合模型即服務（Model-as-a-Service，MaaS）存取控制、AI Gateway，以及 vLLM、llm-d、Nvidia Dynamo 和 NIM 微服務等推理技術，把存取管治與模型執行分開。
設計提供自助模型探索、細緻存取政策、速率限制及訂閱權益追蹤，支援配額管理及成本分攤。企業可據此評估由 IT 部門按部門或代理設定模型使用政策，避免每個代理各自持有模型帳戶，以致權限與用量難以統一管理。
Nemotron 3.5 Super VL 等 Nvidia Nemotron 模型亦已獲 vLLM 及 Red Hat AI Factory with NVIDIA 支援。Red Hat 稱透過 LLM compressor 的 FP8 量化及 DSpark 推測解碼（speculative decoding），可降低推理延遲並保持準確度，但沒有提供具體效能數字。
參考設計已可取得，原生整合仍在進行
Red Hat 表示聯合用例、參考設計及代理功能已可經 Cisco、Dell Technologies、Lenovo 等合作夥伴取得；但截至發稿時，把 OpenShell 參考架構原生整合到 Red Hat AI 及 Red Hat AI Factory with NVIDIA 的工作仍在進行，未有完成日期。企業現時可取得相關設計，惟平台未完成原生整合。
Red Hat Enterprise Linux for NVIDIA 已支援 Nvidia Vera CPU，並為即將推出的 Vera Rubin 平台作準備，目標在硬件推出時即提供相容支援。Nvidia 聲稱 Vera 的代理 CPU 效能快 2 倍，但未列出比較基準。Red Hat 作業系統網誌則指出，RHEL for NVIDIA 26.03 只修改少量核心套件以配合新硬件，保留標準 RHEL 用戶空間及 SELinux 等安全控制；待硬件修補程式成熟並進入上游 Linux 核心後，用戶毋須重裝便可轉回主線 RHEL。
平台與保安團隊要接手代理隔離與權限
企業可先盤點現有代理的權限由誰設定和執行。若邊界只寫在代理指令或應用程式內，可評估改由運行環境及平台層統一執行，同時檢查模型 API 密鑰是否仍放在代理可讀取的位置，再決定是否以閘道集中管理配額及按部門分攤成本。
採購前則要向供應商確認 Sentry 所需的 BlueField 世代、現有伺服器能否沿用，以及 Argus 警報如何接入現有 SIEM／SOAR。應用團隊提出代理所需資源，平台團隊管理沙盒及模型存取，保安團隊審批政策並定義事故隔離流程，可作為責任劃分的起點；尤其要先確定代理或主機失守時由誰啟動隔離，以及哪一層仍能執行控制。
