2026 年 2 月初，GitGuardian 發布了一份報告，應該讓每個運行個人 AI 助理的開發者都感到警覺。他們的機密掃描基礎設施偵測到超過 200 個直接與 OpenClaw 部署相關的外洩憑證——API key、資料庫密碼、OAuth token 和雲端供應商憑證，散落在公開的程式碼庫、日誌檔和錯誤報告中。有些屬於醫療公司，有些屬於金融科技新創。而且全部都是有效的。
幾天後，Northeastern 大學發表了一篇文章，標題比任何 CVE 編號都更令人心驚：「為什麼 OpenClaw AI 助理是一場『隱私噩夢』」。研究人員沒有聚焦在單一漏洞上，而是聚焦在架構本身——OpenClaw 處理資料、儲存憑證和暴露使用者資訊的方式，是設計使然，而非意外。
這些不是粗心使用者造成的個案。這是在機密、使用者資料和 agent 程式碼全部共享同一個位址空間、彼此之間沒有隔離的環境中運行 AI agent 的必然結果。
機密是怎麼跑到不該去的地方的
典型的 OpenClaw 設定是這樣的：你在自己的機器上安裝它，在環境變數中設定 API key，然後開始聊天。Agent 程序以你的使用者身份運行，擁有你的權限，讀取你的環境變數。你安裝的每個 skill 都在同一個程序中運行，擁有相同的存取權限。
這意味著當你請 AI 助理幫你除錯一個部署腳本時，agent 可以看到你的 AWS 憑證。當一個 skill 處理你的電子郵件時，它可以讀取你的資料庫密碼。當錯誤發生並產生 stack trace 被記錄到日誌時，那些環境變數可能就跟著進了日誌檔。而當那個日誌檔被 commit 到程式碼庫、上傳到 bug 回報、或同步到雲端服務時——你的機密就公開了。
GitGuardian 發現的 200 多個外洩機密不是 200 個獨立的失誤。它們是同一個架構錯誤重複了 200 次：把機密放在 process.env 裡，讓程序中的每一段程式碼都能讀取。
問題在 skill 和外掛程式上更加嚴重。OpenClaw 的 skill 系統在與核心 agent 相同的程序中運行第三方程式碼。一個惡意的 skill 不需要漏洞利用就能竊取你的憑證——它只要讀取 process.env 就好。一個寫得不好的 skill 也不需要刻意洩漏你的資料——它只是在錯誤報告中包含了環境上下文。攻擊面不是一個可以修補的漏洞，而是架構本身。
Northeastern 說對了什麼
Northeastern 的研究人員指出了資安社群一直在迴避的問題：AI 助理的隱私問題不在於加密或身份驗證，而在於一個根本性的問題——agent 能存取什麼，以及 agent 的世界和你的世界之間存在什麼邊界。 當一個 AI agent 以你的使用者身份、擁有你的權限、在你的機器上運行時，就不存在任何邊界。Agent 可以讀取你的檔案、你的憑證、你的瀏覽紀錄、你的 SSH 金鑰。它能存取你能存取的一切。唯一阻止它做出有害行為的是 prompt——而 prompt injection 攻擊已經反覆證明，prompt 不是一個安全邊界。
這就是 Northeastern 所說的「隱私噩夢」的意思。不是說 OpenClaw 在刻意竊取資料，而是這個架構使得資料不洩漏成為不可能的保證。Agent 的存取範圍僅受限於作業系統的使用者權限，換句話說，根本沒有實質的限制。
NanoClaw 的容器隔離如何改變局面
NanoClaw 採取了根本不同的做法。每個 agent 都在自己的 Linux 容器中運行——macOS 上用 Apple Container，Linux 上用 Docker。容器不是一個方便的功能或部署選項，它就是安全模型本身。
當你發送訊息給 NanoClaw 時，主機程序不會直接運行 Claude。它會啟動一個容器，只掛載該 agent 需要存取的特定目錄，然後把對話上下文傳進去。Agent 在容器內運行，擁有自己的檔案系統、自己的程序空間和自己的網路堆疊。完成後，容器就被銷毀。
機密處理的部分特別值得一提。NanoClaw 從不把你的 ANTHROPIC_API_KEY 載入 process.env。它在執行時從 .env 讀取 key，並透過 stdin 以 JSON payload 的形式傳遞給容器程序。在容器內部，agent-runner 接收 key、用它來呼叫 API，而且永遠不會把它寫入磁碟或匯出到環境變數。
這意味著即使惡意 prompt 誘騙 agent 執行 `printenv` 或 `cat /proc/self/environ`，API key 也不在那裡。它只存在於 agent-runner 的程序記憶體中，僅在單次對話回合的期間內存在。一個被入侵的容器無法洩漏它根本無權存取的東西。
掛載系統增加了另一層防護。NanoClaw 維護一份可以掛載到容器中的目錄白名單，儲存在專案根目錄之外。每個群組都有自己隔離的檔案系統——自己的 CLAUDE.md 記憶檔和自己的可寫工作區。白名單包含符號連結逃逸偵測，因此精心構造的符號連結無法欺騙掛載系統暴露允許範圍之外的目錄。
容器也以非 root 使用者身份運行，專案原始碼以唯讀方式掛載。Agent 可以讀取程式碼庫來理解上下文，但無法修改主機的檔案。可寫路徑按群組劃分，容器結束時會被清理。
按群組隔離模型
NanoClaw 的隔離不僅僅是把 agent 和主機分開。每個 WhatsApp 群組都有自己的容器、自己的記憶和自己的檔案系統。群組 A 無法看到群組 B 的對話、檔案或 CLAUDE.md 記憶——不是因為應用層的存取控制，而是因為它們在物理上分離的容器中運行，掛載點也是分開的。 這對大多數 AI 助理完全忽略的場景很重要：共用裝置和多使用者設定。如果你和家人一起使用 NanoClaw，你的工作群組的對話和檔案在容器層級就與家庭群組的對話和檔案隔離開來。不存在任何應用程式 bug 能讓資料在群組之間洩漏，因為隔離是由容器執行環境強制執行的，而不是由應用程式。
你的主要 WhatsApp 頻道——與助理的私訊——作為管理介面。它是唯一可以管理排程任務、修改設定和存取跨群組狀態的頻道。群組頻道預設被限制在自己的沙箱中。
業界應該學到的教訓
GitGuardian 的報告和 Northeastern 的分析指向同一個結論：AI agent 是基礎設施，而基礎設施需要基礎設施等級的安全性。在與你的憑證相同的程序中、以你的使用者帳號相同的權限運行 AI agent，就等於以 root 身份運行一個沒有防火牆的網頁伺服器。在出事之前都能用，而一旦出事，爆炸半徑就是一切。
容器隔離不是新概念。網頁託管產業在二十年前就想通了——你不會在同一個程序中運行多個客戶的程式碼。資料庫產業更早就想通了——你不會讓每個查詢都能存取每張資料表。但 AI agent 生態系統仍然處於「以 root 身份運行一切」的階段，而外洩的機密和隱私噩夢就是可預見的結果。
NanoClaw 的做法不是解決這個問題的唯一方式，但它證明了這個問題是可以在不犧牲功能的情況下解決的。在容器中運行的 agent 仍然可以搜尋網頁、瀏覽頁面、讀寫檔案和執行 shell 命令。它們只是在一個沙箱中進行，任何失敗的爆炸半徑——無論是 bug、prompt injection 還是惡意 skill——都被限制在那個單一容器的範圍內。
GitGuardian 發現的 200 個外洩機密本不必發生。它們之所以發生，是因為架構使其成為必然。修復方法不是更好的使用者教育或更謹慎的憑證管理。修復方法是一個機密不可能洩漏的架構——因為它們從來就不在一個可能洩漏的位置。