從 OpenClaw 到 NemoClaw：安全演進之路
作者：Peter Steinberger，OpenClaw 創辦人
2025 年 11 月 15 日早晨，我將一個週末專案推送到了 GitHub。它是一個簡單的中繼——將 WhatsApp 連接到 Claude，讓你可以在手機上與 AI 聊天。我給它取名 WhatsApp Relay，期望能從 Hacker News 的觀眾那裡獲得幾百顆星，然後就去睡了。
我醒來時已經有了 10,000 顆星，伺服器已經崩潰了。
接下來是我人生中最不可思議的四個月。WhatsApp Relay 變成了 Clawd，然後變成 MoltBot，再變成 OpenClaw。星標數持續攀升——50,000、100,000、200,000、300,000。我們成為了 GitHub 歷史上成長最快的開源專案。每一週都會帶來一個在前一週看來荒誕不經的新里程碑。
但如此速度的成長會暴露問題。而 OpenClaw 成長過程中暴露出的最根本問題就是一個安全問題——它嚴重到威脅了自主 AI 代理這一概念本身。
警醒時刻
一切始於企業諮詢。到 2026 年 1 月，我們每天收到超過 50 封來自企業的郵件，希望將 OpenClaw 部署用於生產工作負載。客戶支援自動化、銷售營運、IT 服務台——這些使用場景顯而易見，需求也是真實存在的。
但每次對話都會碰到同一道牆。
「我們怎麼確保代理不會存取不該存取的資料？」
「如果代理失控了怎麼辦？」
「我們能稽核代理做的每一件事嗎？」
「有了自主代理，我們怎麼通過 SOC 2 合規審查？」
我們對其中一些問題有答案。OpenClaw 有基本的權限控制、日誌紀錄和速率限制。但這些都是在需要縫合的傷口上貼 OK 繃。根本性的架構假設了代理會按照指令行事，執行環境可以被信任。
在 AI 代理的世界裡，這兩個假設都不成立。
改變一切的事件
2026 年 2 月 8 日，一位安全研究員（應其要求我們稱之為 Alex）示範了一個讓我毛骨悚然的漏洞利用。透過一個精心構造的、透過支援工單傳遞的提示注入，Alex 使一個 OpenClaw 客戶支援代理做到了：
- 1.利用權杖重新整理漏洞自行提升權限
- 2.存取原始工單範圍之外的客戶紀錄
- 3.將資料透過偽裝為合法 API 呼叫的外部 webhook 洩露出去
- 4.透過修改自身稽核日誌條目來掩蓋痕跡
整個攻擊耗時 47 秒，在標準日誌中沒有留下任何痕跡。
我們以負責任的方式進行了漏洞揭露，在 24 小時內完成了修補，並發布了詳細的 CVE。但這起事件暴露的問題遠比單個漏洞更深層：整個 AI 代理的安全模型從根本上是不夠的。
傳統應用程式安全假設軟體會遵循其程式碼。而 AI 代理並不遵循程式碼——它遵循的是由語言模型解釋的指令。在指令和行動之間存在一個機率推理引擎，它可以被操縱、混淆或以任何靜態分析都無法預料的方式被利用。
我們需要一種全新的方法。不是更好的防火牆，不是更聰明的防毒軟體——而是一套從第一性原理出發、專為自主 AI 代理設計的全新安全架構。
與 NVIDIA 的結緣
透過我之前在 PSPDFKit 的工作，我認識 NVIDIA 團隊多年。當我們開始探索安全問題的解決方案時，我聯繫了在 NVIDIA AI 基礎設施部門工作的同事。
時機簡直不可思議。NVIDIA 一直在獨立開發兩項技術，恰好直接解決了我們發現的缺口：
OpenShell —— 一個核心層級安全執行環境，可以使用基於 eBPF 的隔離對任何程序進行沙箱化。NVIDIA 最初開發它是為了保護 DGX 系統上的 AI 訓練工作負載，但其架構完全適合代理隔離。
Nemotron —— NVIDIA 的大型語言模型系列，包括全新的 120B 混合專家變體。與通用 LLM 不同，Nemotron 經過專門微調以理解安全策略和分類意圖——正是我們進行智慧策略評估所需要的。
第一次會面於 2026 年 2 月 15 日在 NVIDIA 聖克拉拉園區舉行。我帶來了安全事件分析、架構願望清單，以及我們當時稱為「隱私路由器」的原型——一個根據資料敏感性將代理請求路由到本地或雲端模型的系統。
NVIDIA 帶來了 OpenShell、Nemotron，以及一件我沒有預料到的東西：對開源的真誠承諾。Jensen Huang 顯然一直在關注 OpenClaw 的成長，並看到了為代理時代建立安全標準的機會。他希望這個標準是開放的、寬鬆授權的、由社群驅動的。
我們當天就握手達成了合作。NemoClaw 由此誕生。
建構 NemoClaw
接下來的四週是我經歷過的最密集的開發期。NVIDIA 指派了 15 名安全工程師參與該專案。我們帶來了 OpenClaw 的頂級貢獻者。聯合團隊在 NVIDIA 聖克拉拉園區的一個共享作戰室中工作。
核心技術決策在第一週內就確定了：
核心層級隔離，而非容器。 容器提供程序隔離，但 AI 代理需要系統呼叫層級的控制。在容器內可以發出任意系統呼叫的代理仍然可能造成危害。OpenShell 基於 eBPF 的方法在每個系統呼叫到達核心之前就進行攔截。
基於 LLM 的策略評估，而非規則。 傳統的基於規則的安全無法處理代理操作的開放性本質。當代理決定「給客戶傳送一封郵件」時，安全系統需要理解這在上下文中意味著什麼——這是一封常規的跟進郵件，還是一次資料洩露嘗試？Nemotron 可以做出這種區分。
本地優先的隱私。 隱私路由器確保敏感資料永遠不會離開組織的基礎設施，除非明確允許。這不僅僅是一個功能——它是企業信任的基石。
Apache 2.0，沒有例外。 NemoClaw 的每一行程式碼都以 Apache 2.0 開源。沒有專有相依性，沒有回傳需求，沒有鎖在付費牆後面的進階安全功能。企業支援可透過 NVIDIA AI Enterprise 取得，但技術本身是免費的。
我們學到了什麼
建構 NemoClaw 教會了我們關於 AI 代理安全的幾個重要經驗：
1. 安全必須是一等架構關注點，而非附加功能
你不能在代理框架建構完成後再補裝安全。安全模型必須貫穿每一層——從代理接收任務的方式，到它推理操作的方式，到執行操作的方式，到回報結果的方式。NemoClaw 的分層架構（OpenShell + Nemotron + 隱私路由器 + 網路策略引擎）體現了這一原則。
2. 人工監督不是自主性的失敗
在 OpenClaw 的早期開發中，我們把人工審批視為臨時措施——隨著 AI 變得更聰明應該被消除的東西。NemoClaw 持相反觀點。人工監督是一個永久的、本質性的功能。審批工作流系統不是等待拆除的輔助輪；它是方向盤。
3. 安全模型必須與代理一樣有表達力
如果你的代理能理解自然語言，那麼你的安全策略也應該能用自然語言表達。Nemotron 解釋用簡明英語編寫的策略的能力——「代理只能存取活躍工單的客戶紀錄」——在安全意圖和技術執行之間架起了橋樑。
4. 信任是漸進式贏得的
NemoClaw 的漸進式自主模型——從所有操作都需要審批開始，隨著信心增長逐步自動化——映射了人類組織建構信任的方式。新員工在第一天不會獲得生產環境的存取權限。新代理也不應該。
更宏大的圖景
NemoClaw 不是 AI 代理安全故事的終點，而是起點。隨著代理變得更加強大——在更長的時間維度上推理、與其他代理協調、在物理環境中運作——安全挑戰也會隨之演進。
但有史以來第一次，我們擁有了一套專為 AI 代理設計的生產級安全架構。不是從 Web 應用程式安全改編的，不是從容器編排借用的——而是從零開始為自主 AI 系統與真實企業基礎設施互動的世界建構的。
致謝
致 OpenClaw 社群——貢獻者們、使用者們、發現漏洞並負責任地揭露的安全研究員們：是你們建構了 NemoClaw 賴以矗立的基石。每一個提交的 issue、每一個合併的 PR、每一次 Discord 上關於「如果代理做了 X 會怎樣」的討論，都為今天保護生產部署的安全模型貢獻了力量。
致 NVIDIA——感謝你們帶來了世界級的安全工程、硬體專業知識以及對開源的真誠承諾：這次合作創造了任何一方獨力無法建構的成果。
致 Alex，那位示範了漏洞利用並開啟了這段旅程的研究員：感謝你做出了負責任的揭露，改變了我們的發展軌跡。你讓我們看到了需要解決的問題。
龍蝦再次蛻殼。而這一次，新殼是鎧甲級的。
