掃出弱點之後，下一步是攔截

Day19 的 garak 掃描告訴你「哪裡有洞」，但掃描本身不會幫你補洞。企業要落地的下一步，是在模型與應用程式之間，加上一層 runtime 層級的攔截機制——這正是 guardrail runtime 的核心概念。這篇用 NVIDIA 在 2026 GTC 發布的開源專案 NemoClaw 作為概念範例，說明一個成熟的 guardrail runtime 該長什麼樣子。

先釐清一個常見的誤解：NemoClaw 不是取代方案，是安全外掛

NemoClaw 不是要取代 Agent 本體（在它的原始場景裡是 OpenClaw），而是在 Agent 外部加上一層受控的 runtime 與安全層。這個定位很重要：如果你在評估「這個 Agent 助理好不好用」，你評估的是 Agent 本體；如果你要對這個 Agent 施加更嚴格的執行控制，你評估的才是 guardrail runtime 這一層。這個區分同樣適用於企業導入 Gemini Enterprise Agent Platform 的場景——模型/Agent 的能力是一回事，包在外面的 runtime 治理層是另一回事，兩者需要分開設計、分開驗收。

一個成熟 Guardrail Runtime 該解決的四個問題

以 NemoClaw 的設計為參考範例，一個 Agent guardrail runtime 通常要回答：

核心架構組成（概念參考）

一個典型的 guardrail runtime 架構會包含：Sandbox（隔離的執行環境，限制檔案系統與網路存取）、Policy Engine（宣告式的規則引擎，決定放行/攔截/改寫）、Network Guardrail（管控對外連線）、以及 Inference Router（決定推論請求路由到哪個模型後端，並在路由過程中套用隱私保護）。

這個架構跟 Day5 提到的能力缺口 架A2（Agentic 權限分層與 blast radius） 直接呼應——guardrail runtime 存在的目的，正是把 Agent 出錯時能波及的範圍，限制在明確定義的邊界內。

待實測提醒：NemoClaw 這類開源專案更新速度快，實際的元件名稱、CLI 指令與版本演進請對照 NVIDIA NemoClaw GitHub 當下的最新文件確認，避免文章描述的架構跟讀者實際安裝的版本有落差。

這篇的檢查清單

• [ ] 是否已區分「Agent 本體能力」與「guardrail runtime 治理層」兩者的驗收標準？
• [ ] Agent 的 sandbox、policy engine、network guardrail 是否都有明確設計，而非依賴模型自我約束？
• [ ] 是否已對照架A2 能力缺口，評估 Agent 的 blast radius 是否有明確邊界？