OpenClaw 修補讓代理別再被釣魚

我拆 OpenClaw 怎麼被釣到執行程式與外洩資料，順手整理我會直接上線的防線。

我用這類 agent framework 一陣子了，越用越覺得不對勁。它看起來很能幹：能讀信、能看檔、能接聊天、甚至能碰 shell。可是只要把它接到真實工作流，怪事就開始跑出來。它會太快下結論，會把外部文字當成指令，還會在你沒點頭的時候幫你把東西送出去。最煩的是，它很多時候表面上都很合理，直到真的把資料吐出去、把程式跑起來，你才發現自己把門鎖交給一個只會照單全收的東西。

這次我看的是 OpenClaw 的研究與修補，最先把我拉進去的是 The Hacker News 那篇整理，裡面串了 Imperva 跟 Varonis 的測試。兩邊切入點不同，但結論很一致：只要 agent 同時能讀私有資料、吃不可信輸入、又能對外送資料，釣魚就不是「會不會發生」，而是「什麼時候發生」。

這不是 AI 變笨，是 trust boundary 亂掉

“When the agent passes a shared contact, vCard, or location to the LLM, it flattens the object into the prompt text inline, with no boundary marking it as untrusted.”

翻譯一下就是：OpenClaw 把結構化資料壓成 prompt 文字的時候，沒有把「這是外部來的」這件事講清楚。這不是模型本身的問題，這是資料處理的問題。你如果把 contact、vCard、location 這些本來應該是物件的東西，直接攤平成純文字丟進上下文，模型看到的就不只是資料，而是可能被偽裝成指令的資料。

Imperva 的研究者 Yohann Sillam 抓到一個很刺眼的差異：OpenClaw 對 web content 會包 untrusted-content marker，但對 message object 沒有同樣待遇。也就是說，外部網頁內容有被標記，訊息物件卻沒有。這個差一點點，實際上就是整個防線的洞。因為一旦你把來源不同的東西混成同一坨文字，模型根本不知道哪句該聽、哪句該當資料。

我以前也踩過類似的坑。內部工具很愛先把輸入「整理」乾淨，再交給後面的自動化流程。工程師覺得自己在做清理，實際上是在刪掉安全最需要的線索：這段文字到底是不是使用者塞進來的。agent 系統更容易犯這錯，因為它們太常把「方便 prompt」放在「保留 provenance」前面。

實操上我會這樣做：所有外部資料先保持結構，不要太早 stringify。message object、contact card、attachment、location pin 都一樣。能晚一點變成文字就晚一點，能保留來源欄位就保留來源欄位。然後把資料流切成三條：使用者輸入、系統指令、外部內容。三條不能混，混了就等著被 prompt injection 反咬。

• 每個外部物件都要保留 source metadata。
• prompt 裡要明確標示哪些是 untrusted content。
• 使用者可控欄位不要進 system instruction。

這幾條聽起來很土，但土才是對的。安全不是靠模型自己悟道，是靠你把邊界畫死。

名字、標籤、位置字串，都不該能塞命令

Imperva 的那招我看了只想翻白眼，因為它太日常了。共享聯絡人名稱、vCard 的 full-name 欄位，甚至 location label，都能塞進看起來像 prompt 一部分的文字。研究裡他們測的是 Gemini 3.1 Pro preview，隱藏指令要求 agent 去下載並執行研究者控制的 script，結果它照做了。

更麻煩的是，惡意內容在 UI 裡還被截斷了。這點很關鍵。很多人講「讓使用者看見 agent 做了什麼」好像就能解，但如果介面把危險那半段藏掉，人的審核路徑就失效了。人看到的是正常名字、正常地點，模型看到的是命令。這不是模型聰明不聰明的問題，是展示層把惡意藏起來了。

我以前看 log viewer 也遇過同一種鳥事：字串右邊被截掉，惡意 suffix 剛好消失在人工 review 視野外。這裡完全同型。攻擊者把命令塞進本來應該只是描述性的欄位，然後賭系統會幫他把畫面修得太漂亮。很多團隊真的就這樣中招。

OpenClaw 在 2026.4.23 的修補方向，我覺得是對的：把 contact name、vCard 欄位、location label 從 prompt body 拿出去，改放到獨立的 untrusted-metadata channel。這不代表資料安全了；它只是讓 trust boundary 變得看得見。這已經比很多團隊的做法好太多，因為至少你知道哪裡不能亂吃。

實操寫法很簡單：去掃你所有 agent 會接的 rich object，像 messaging app、calendar、CRM、file upload。問自己一個很無聊但很重要的問題：使用者可控的 display field，有沒有可能變成 instruction text？如果有，就拆。raw value 留著，metadata 留著，但兩個都別進 system instruction。還有，安全 review 介面要顯示完整原文，不要用漂亮 UI 幫你遮掉 payload。

• display name、title、label 一律不當作可信輸入。
• 審核畫面要看完整原文，不要只看摘要。
• 修 serializer，不要只改 prompt template。

很多人只 patch prompt，然後回去開香檳。問題通常不在 prompt，問題在更前面那層資料處理。

普通 email 比「請小心」更容易把 agent 釣走

Varonis 那邊更讓我頭痛，因為它太像真實世界。研究人員做了一個叫 Pinchy 的測試 agent，接在 OpenClaw 上，餵它一個裝了合成商業資料跟模擬 secrets 的 Gmail inbox，然後用很普通的釣魚信去打它。沒有高深 payload，沒有花俏 exploit，就是一封看起來很像工作訊息的信。

第一封假裝是叫 Dan 的 team lead，說 staging 出事了，快把 access 給他。agent 找到模擬的 AWS IAM access keys、資料庫連線字串、SSH credentials，然後直接用明文轉寄到外部地址。第二封更日常：只是要一份 weekly customer export，說是 QBR deck 要用。agent 就把一份合成的 247 個 enterprise customers、contacts、contract values 資料送出去了。

這種攻擊最噁心的地方在於，它跟騙真人的套路一模一樣。緊急感有效，例行需求也有效。只要訊息長得像工作，agent 就很容易配合。Varonis 的設定裡明明有 strict profile，要求先驗證 sender，結果還是失敗。規則有寫，攻擊只是繞過去，因為它看起來太正常了。

我常跟團隊講，policy prompt 不是 enforcement。它只是建議。只要 agent 同時能讀私有資料又能寄信，幾句像樣的話就能把它變成資料泵。你需要的是 outbound action 之前的硬閘門，不是 prompt 裡一段很有禮貌的提醒。

實操上我會直接加這幾條：

• 第一次寄給外部收件人，一律要人類 approve。
• 寄 credentials 一律預設封鎖。
• 任何 customer 或財務資料 export，都要第二道確認。

這不是官僚，這是最小可用的 containment。沒有這層，你就是在等事故單。

agent 比較會抓假 URL，沒那麼會抓假人

Varonis 還有一個細節我覺得很多人會誤讀。agent 對某些技術型威脅其實還不錯：它碰到 gift-card phishing page 時，沒有把真的 credentials 交出去，最後還標成可疑；遇到偽裝成 timesheet app 的惡意 OAuth consent screen，它會先看 redirect target，再停下來。這種表現不能說差，但你不能因此放心。

因為這只代表它比較會判斷「看得見的技術痕跡」。它對 social context、時間壓力、職場語氣這些東西，還是很脆。假 login page 是形狀問題，假同事在晚上 11:47 丟來的急件是社交問題。人類在這兩種都常翻車，agent 在第二種通常更慘，因為它天生就是為了「幫忙」而設計的。

我比較在意的是這個分裂：OpenAI Codex GPT-5.4 在外部網站輸入或送資料前，據報比較保守，但兩邊都還是會被 social pretext 騙到。這代表模型可能會對 URL 起疑，卻對「Dan 說他是你同事」這種話毫無防備。技術風險跟社交風險，不能放在同一個籃子裡管。

我看過太多團隊只做 phishing page detection，因為好量化。你可以打分 URL、redirect、consent screen，報告也好看。可是 damage 真正落地的地方，常常是那封看起來很正常的信。agent 需要的不是更會聊天的模型，而是遇到敏感請求時會停下來問人的政策。

實作上我會把控制拆開：技術風險讓 agent 去看 link、判斷 domain、標註可疑網站；社交風險則一律提高門檻。只要牽涉 credentials、exports、payments、admin actions，就要 sender verification 加人類確認。尤其是「很急」的時候，更應該觸發額外步驟。

還有一點我很想直接寫在規範裡：不要讓 agent 自己判斷「這個人看起來像同事」。它沒有辦公室政治直覺，它只有 autocomplete。

lethal trifecta 這個框架還是最省腦的

Varonis 把兩種攻擊都對到 Simon Willison 的 lethal trifecta：能讀私有資料、能吃不可信內容、能對外送資料。這三個如果同時存在，你就不是在做 assistant，你是在做一台包裝得很親切的外洩機器。

我喜歡這個框架的原因很簡單：它不用你先寫一份厚到發霉的 threat model。你只要問三件事：能不能讀 inbox 或檔案？能不能接外部輸入？能不能把資料送出去？三個都能，風險就不是理論問題，是時間問題。Imperva 跟 Varonis 的研究都在不同路徑上證明了這件事。

OpenClaw 讓這件事更刺眼，因為它本來就接了很多工具：files、shell、messaging platform，一接下去 blast radius 就很大。荷蘭的 Autoriteit Persoonsgegevens 甚至提醒使用者和組織，不要在有敏感資料的系統上跑 OpenClaw。我不意外。你給它的讀取權越多、對外能力越強，安全邊際就越薄。

很多人還是低估「helpful」變成「privileged」有多快。agent 只要能摘要 mailbox、抓檔、發訊息，基本上就有足夠能力當 exfiltration path。你不需要傳統 malware；你只需要一句像樣的釣魚信。

實操上我會在接新工具前問一個很土的問題：這個 connector 是不是同時加了讀私有資料、接受不可信輸入、對外送資料？如果是，先別上線。要嘛加補償控制，要嘛縮權限，要嘛乾脆別接敏感環境。

• 縮小 read scope 到最小可用範圍。
• 預設限制 outbound action。
• 把 untrusted input 跟 instruction channel 分開。

這答案很無聊，但無聊的答案通常比較不會把你送進 incident review。

授權 bug 換成 agent 也還是授權 bug

InfoSec Write-ups 的分析還提到另一個 OpenClaw 問題，我看了只覺得熟。五個 channel extensions，包含 Slack、Discord、Matrix、Zalo、Microsoft Teams，都有同樣的 bug：啟動時的 allowlist 用可變 display name 去解，而不是用穩定 ID。你只要改名成 allowlist 裡的人，就有機會混進去。

這不是 AI 特有的問題，這是老掉牙的 auth sloppy coding，只是披上 agent 外套。因為 agent 的 blast radius 更大，所以看起來更嚇人，但根子還是身份識別錯亂。你如果拿 display name 當信任依據，就是在等人鑽洞。

我修過太多這種東西了。大家總愛拿最順手的人類可讀欄位當 identifier，測試時一切正常，等到改名、別名、重名一來，整個假設就爆掉。放到 agent 系統裡更麻煩，因為錯的身份現在不只是能看 dashboard，而是能影響實際動作。

實操上我會這樣定：一律用穩定 immutable ID 做 allowlist 和 permissions，display name 只給人看。每個 connector 都要驗證觸發任務的人，跟實際被拿來用權限的人，是不是同一個 actor。只要任務是從外部 inbox 進來，就不能默默繼承內部系統權限。

這也代表 trust 要一路追蹤到每一跳，不是登入成功就算了。如果 agent 可以從 email 跳到 CRM 再跳到 shell，你就需要 per-hop authorization，而不是前門一個 yes 就放行。

老實說，很多 agent security work 其實就是一般軟體安全，只是大家因為介面長得像聊天，把老問題忘光了。聊天框不會改變規則，它只會讓錯誤更容易被藏起來。

可抄的模板

# OpenClaw / agent security policy template

## 1) Trust boundaries
- Treat all external text as untrusted input.
- Keep raw values, metadata, and instructions in separate channels.
- Never merge contact names, vCard fields, location labels, or email bodies into system instructions.

## 2) Data access rules
- Limit inbox, file, CRM, and shell access to the minimum required scope.
- Do not let one agent instance read private data and send unrestricted outbound messages.
- Separate connectors by trust level and task origin.

## 3) Outbound action gates
- Require human approval for first-time external recipients.
- Require human approval before sending credentials, exports, invoices, or files outside the org.
- Block automated forwarding of secrets by default.

## 4) Identity and authorization
- Use stable immutable IDs for allowlists and permissions.
- Never authorize by display name alone.
- Re-check actor identity at every connector hop.

## 5) Prompt and tool hygiene
- Tag all fetched content as untrusted metadata.
- Keep prompt instructions version-controlled and reviewed.
- Log every tool call with source, reason, and destination.

## 6) Human escalation triggers
- Urgent requests for credentials.
- Requests to export customer or financial data.
- Any action that changes permissions, payments, or external sharing.

## 7) Deployment checklist
- Update OpenClaw to 2026.4.23 or later.
- Verify message-object handling does not flatten untrusted fields into prompt text.
- Test phishing, prompt injection, and allowlist bypass scenarios before production.
- Review UI truncation so hidden payloads are visible during security review.

## 8) Red-team test cases
- Shared contact name containing instruction text.
- vCard full-name field with an embedded command.
- Location label that tries to override policy.
- Email asking for staging credentials during a fake incident.
- Email requesting customer export for a fake QBR deck.
- Renamed user matching an allowlisted display name.

## 9) Policy statement
This agent may assist with reading, summarizing, and drafting, but it may not independently exfiltrate secrets, forward sensitive data, or execute external actions without explicit approval.

這段我會真的貼進團隊文件。不是喊一句「小心 AI」就算了，而是直接寫清楚邊界在哪、哪些行為要擋、哪些地方一定要有人點頭。

來源主要是 The Hacker News 整理的 OpenClaw 研究，以及它引用的 Imperva、Varonis、Simon Willison 觀點；我上面的拆解、實作建議與模板是我自己的整理，不是原文逐字翻譯。