代理安全／企業 AI 平台
Red Hat AI 3.5 將 OpenShell 納入 OpenShift，以核心層政策約束代理副作用
OpenShift AI 3.5 以開發者預覽方式整合 OpenShell，利用 Landlock、seccomp、網路命名空間及 L4／L7 政策限制代理存取。這讓提示注入後的檔案、系統呼叫與網路副作用不再只依賴模型防護欄，但預設相容模式與預覽狀態仍可能留下落差。
Red Hat 在 [AI 3.5](https://www.redhat.com/en/blog/red-hat-ai-35-scaling-and-governing-ai-agents-production) 中，將 NVIDIA 主導的 OpenShell 代理沙箱帶入 OpenShift AI，現階段列為 Developer Preview。重點不是再加一層提示詞過濾，而是把代理可造成的副作用交給作業系統與外部政策引擎裁決：Landlock LSM 限制檔案路徑，seccomp 過濾危險系統呼叫，獨立網路命名空間隔離連線；OPA 則可按目的地、連接埠、執行檔，以及 HTTP 方法、路徑和標頭執行 L4／L7 出口政策。
[OpenShell 架構](https://github.com/NVIDIA/OpenShell/blob/main/architecture/sandbox.md)把工作負載分成具管理權限的 supervisor 與無特權的 agent child。前者負責建立隔離、代理網路與注入設定，後者啟動前會清空 capability bounding set；若權限無法正確移除，建立工作負載或 SSH shell 應以失敗收場。憑證也不直接暴露給代理：環境內只放不透明代用 token，出口代理在請求同時符合網路政策及主機、連接埠、路徑綁定時，才替換為真實憑證。
Red Hat 又把這個執行邊界與 NeMo Guardrails、Garak 紅隊測試及供應鏈控制組合。NeMo Guardrails 可在輸入、檢索、對話、工具執行與輸出階段檢查內容；代理映像則透過 Konflux 建置，包含 UBI9、RPM lock file、SBOM 與簽章驗證。平台另提供 Codex、Goose、OpenClaw、OpenCode 等預建代理 harness，減少團隊自行拼裝基底映像的差異。
不過「核心強制」不能等同完整隔離。[NVIDIA 政策文件](https://docs.nvidia.com/openshell/reference/policy-schema)顯示 Landlock 預設為 `best_effort`：核心 ABI 不支援或所有路徑無法套用時，系統可能警告後繼續執行；要求確定失敗關閉的部署必須改用 `hard_requirement`。OpenShell 本身也仍標示為 alpha，Kubernetes 與多租戶路徑尚在演進。準備試用的團隊應驗證節點核心版本、策略失敗行為、加密流量檢查、GPU 裝置暴露、稽核紀錄完整性，以及升級時的 CRD 與政策相容性。