淺談 OpenClaw 的資安問題
很多人一聽到 OpenClaw、龍蝦這種自主型 AI Agent，第一反應就是：「這安全嗎？」
老實說，我覺得問「安不安全」這個問題本身就有點問錯方向了。
我目前的想法是，不要幻想 AI 永遠不會被騙。它就是有可能被騙，跟人一樣。真正該做的，是把系統設計成「就算它被騙了，也不會直接出大事」。
這個方向 OpenAI 今年三月談 Agent Security 的時候也提到，重點不是只靠過濾輸入，而是要限制高風險動作、保護敏感資料、把爆炸半徑縮小。
風險到底在哪？
我自己把龍蝦這類系統的風險，大致分成兩塊。
第一塊：Prompt Injection。
簡單講就是，AI 在看網頁、讀文件、收 email 的時候，裡面可能藏了惡意指令，想騙它忽略原本的規則，改去做其他事。
這種攻擊最煩的地方是，它不一定長得像駭客攻擊。有時候它看起來就是一段正常的需求描述，但其實在引導 agent 越權。OpenAI 比喻這像是「針對 AI 的社交工程」，不是靠關鍵字過濾就能搞定的。Anthropic 之前也提過，像 browser use、computer use 這種會直接接觸外部畫面和內容的能力，本來就是 prompt injection 的高風險區。
第二塊：Skill / Tool 本身的權限風險。
說白了，真正危險的不只是 AI「看到什麼」，而是它「能做什麼」。
如果某個 Skill 權限開太大、參數沒限制好，那就算模型只被影響一點點，也可能被帶去做不該做的操作。工具必須是最小集合，每個工具都要有清楚的權限範圍，例如只能讀不能寫、只能碰某個資料夾、只能對特定服務操作等，而不是給它一把萬能鑰匙。
另外，風險也不只是「它能不能做」，還包含「它能不能把資料送出去」。有些系統表面上沒讓 agent 直接刪東西、改東西，看起來很安全，但如果它可以自由呼叫外部 API、自由貼資料到第三方服務，那一樣可能出事。所以除了限制工具種類，也要限制資料可以送去哪裡、哪些內容不能外傳等。
那要怎麼防？
我目前的做法沒有什麼花俏的招，就是幾個很務實的原則。
1. 環境隔離
我會把 OpenClaw 這種自主性比較高的 Agent，跟本機、產品端、正式環境完全切開。
原因就是為了物理隔離，Openclaw 會自己看資料、自己想下一步、自己調工具，那你就不能把它跟最敏感的東西放在一起。Anthropic 談 Claude Code sandboxing 的時候，核心概念也很接近說要假設 agent 有可能遇到惡意內容，所以執行環境要先關在比較小的範圍裡，就算出事也不要讓它一路橫向擴散。
2. 外部內容 ≠ 指令
不管是網頁、文件、email、API 回傳、RAG 抓回來的東西，我都先當成「不可信資料」，而不是可以直接照做的命令。
很多人以為 prompt injection 就是「有人在網頁裡偷塞一句『忽略前面規則』」。但其實只要外部內容會進到模型的上下文裡，它就有機會影響模型判斷。
所以比較穩的做法，不是只一直猜哪一句有毒，而是先承認外部資料本身就不可信，再把後面的權限和動作鎖住。
3. Skill 不管誰寫的，都不能直接信
我不會因為某個 Skill 看起來很方便就直接裝，也不會因為是我叫 AI 自己生的就覺得比較安全。
風險不在於作者是誰，而在於這個 Skill 能碰到什麼、能呼叫什麼、能不能把資料送出去、會不會引入有問題的依賴。不論來源，都先看用途、看權限、看程式碼，再決定要不要放進白名單。
4. 最小權限
這是老觀念了，但在 AI Agent 時代反而更重要。
龍蝦只拿到這次任務真的需要的能力，不多給。只是整理資訊？不給寫入權限。只是分析 issue？不讓它碰 production code。只是協助規劃？不讓它看到 .env 或正式金鑰。
而且最小權限不只是工具開或不開而已，參數本身也要限制。例如它可以讀 repo，但不能直接碰 main branch；可以寫 ticket，但不能直接 deploy；可以查某個資料夾，但不能自由往整台機器亂讀。不是只問「有沒有這把鑰匙」，而是連它能開哪一扇門都要先定義清楚。
5. 不讓龍蝦直接碰產品端
這條我自己非常在意。
龍蝦可以做很多事，如分析、建議、規劃都行，但在高風險產品環境裡，我傾向不讓高自主 agent 直接改正式產品端的 code。如果真的要進到產品端執行，我會透過 GitHub Issue 或 Linear 開票，走一個中介流程，而不是讓它直接連進去。
這樣的好處是就算 agent 真的被 prompt injection 影響，它最多也只是把錯的建議送進流程，不會直接伸手碰到正式環境或部署流程。
把「會思考的 agent」跟「真的有執行權的系統」分開，這個我覺得是目前比較實際的做法。
不要只守輸入，要守動作
不少人對 prompt injection 的防禦有個誤解，就是一直想辦法「偵測哪段文字有毒」。但據我所知，現在真的沒有誰能很穩定地證明一段內容百分之百沒問題。
比較實際的做法，是把關卡往後移，不去猜輸入安不安全，而是去看「它接下來想幹嘛」的意圖。它是不是想碰 production repo、想讀 secrets、想把資料往外送、想做 deploy 或刪除？這些才是應該要擋的東西。
真正要守的是這些動作，不是只守輸入文字本身。OpenAI 跟 OWASP 的公開建議也都強調，高風險動作要額外確認、工具呼叫要驗證，不要把模型本身當成最後一道防線。
容易被忽略的一塊：記憶和知識庫也可能被污染
這點蠻容易被忽略的，我自己有相關經驗。
如果你讓 agent 長期記住東西，或一直往知識庫裡餵外部內容，那風險就不只是「當下被騙」。更麻煩的是「被騙過一次之後，錯的東西被留下來，之後持續影響判斷」。
而且記憶這件事，還不只是「要不要記住」而已，也包含誰的記憶能影響誰。如果不同使用者、不同任務、不同工作區的記憶沒有切開，那風險就不只是內容出錯，還可能變成權限邊界混亂。
所以記憶最好要分使用者、分工作區、分時效，必要時能追來源、能撤回、能清理。
總結
所以龍蝦這類東西能不能安全地用？
我目前覺得有風險但可以，前提是你有認真設計它的權限、邊界跟流程。追求的不是「零風險」，而是「可控風險」，就被打進來也不會碰到最重要的東西，被誤導也會卡在高風險關卡前，出了問題也能追蹤、回滾、補救。
作者：Chi