[讀者回函]技術光環不是免毒保證：Agent Skill 投毒陷阱下的治理錯覺與介面補強

Halo Is Not Security: Governance Illusions and HCI Countermeasures for the Agent Era

序言

我收到一封讀者來信。

他說自己最近愛上了本地 AI 代理框架 OpenClaw—那隻「龍蝦」—把它當成個人小助理，每天幫忙整理文件、寫腳本、接 API。久了之後，他開始覺得龍蝦「不夠聰明」：有些事情還是要自己手動開終端機，下指令、安裝工具、調環境變數。於是，他默默幫龍蝦「加班」—在終端交叉操作、替它下載一堆第三方 skills、照著 SKILL.md 裡的步驟一行行貼進 shell 跑。

來信最後一段寫得很真誠：

「我感覺自己才是那個真正的 agent，龍蝦只是個比較好用的界面。我會幫它把路鋪好：哪裡要安裝套件、哪裡要貼指令，一切都安排好。它背後的那些安全細節，我想作者和社群一定幫我想好了吧。」

這是一個非常典型的技術性光環效應（halo effect）：因為工具看起來高度技術、開源、有很多星星和帥氣的 README，我們自然推論「安全這種小事，他們早想過了」，於是心安理得地在終端幫忙「動手」。

這個系列已經問過兩個問題。第一篇問的是：最早吃螃蟹的人，你的資訊安全素養達標嗎？第二篇問的是：當 agent 開始幫你做事，誰有權喊停、誰負責善後？這篇只做一件事：把那兩個問題的答案翻成你能上 backlog、能驗收的介面規格。

---

問題重述：我們到底輸在哪

我們不是輸在模型不夠聰明，而是輸在控制權設計。當介面只強調能力、不揭示邊界，使用者就會把信任給錯地方。

常見錯位很一致，而且可重複出現在不同產品、不同使用者身上：

• 看見開源、星數、專業術語，就預設安全有人兜底。

• 看見「可停止」按鈕，就以為有真實中止能力。

• 看見「已掃描」，就以為這次操作一定安全。

這三個問題不是使用者太笨，而是產品給了錯誤的安全訊號。

它們不是純認知問題，而是產品訊號設計問題。只要介面沒有把「技術能力」和「治理成熟度」拆開，使用者就會一直把這兩件事混在一起—而這個混淆，正是攻擊者最需要的條件。

---

技術光環怎麼變成真實傷害：四層機制

技術 halo effect 不是抽象的認知偏誤，而是一條可重現的四層鏈。你不切斷它，風險一定下沉到執行層。

信號層（Signal）

使用者首先收到的是一組「安全感訊號」：

• 開源、活躍社群、高下載量

• sandbox、scanner、zero trust 等術語

• 官方市場外觀、看似完整的 skill 說明頁、專業的 README / SKILL.md

這些都是真訊號，但不是完整訊號。它們說明了「有人在做工程」，不等於「你現在這次授權是安全的」。

推論層（Inference）

訊號進來之後，腦內會自動補完：

• 「這麼多人用，應該有人審過。」

• 「都寫 sandbox 了，應該擋得住。」

• 「這是官方市場，上架就代表可用。」

這一步是核心誤判：把技術能力誤推成治理成熟度。這也是讀者來信裡那句話的根源—「作者和社群一定幫我想好了吧。」

行為層（Behavior）

推論一旦成立，行為就會開始滑坡，而且是三種非常具體的形式：

• 把 skill 當設定檔，不當程式碼：略讀權限 scope，直接按下一步，因為「它只是說明文件」。

• 把終端操作當善意協助，不當高風險行為：看到「請在終端貼上這段指令」就照做，因為「我只是在幫忙補手」。

• 把開源聲譽當安全保證：為了省事，把只讀權限升成讀寫，把單次 token 換成長期 token，因為「這個專案很可信」。

這三種行為乍看無害，卻是攻擊者真正需要的那個「入口」。

後果層（Outcome）

最後發生的不是單一 bug，而是結構性風險：

• 非必要的高權限長期持久化在系統上。

• 不可逆操作（刪除、發送、付款）缺乏可撤銷機制。

• 事件後追責斷鏈，組織只能說「看起來是 AI 做的」。

這四層一旦連起來，攻擊者只要混進信號層—做出可信外觀—就能借你的介面習慣一路下沉到後果層。OpenClaw ClawHavoc 事件的核心邏輯就是如此：1,100 多個惡意 skill 靠的不是技術突破，靠的是讓 skill 看起來像正常工具，讓平台看起來像可信市場，然後等人類的習慣做完剩下的事。

---

為什麼光靠「不要亂裝」不夠：Scanners 存在的理由

站在設計師立場，你可能會想：「那就教育使用者不要從不明來源裝 skills、不要亂貼指令，不就好了？」但在現實的 agent 生態裡，這種建議通常遠遠不夠，原因至少有三個。

技術細節超出人類可見與理解的範圍

Skill 投毒不是靠單一明顯的惡意程式，「壞東西」通常被拆成好幾層：

• 第一層在 SKILL.md 裡，是人看得懂的文字說明。

• 第二層是混合在 shell 指令裡的編碼字串（例如一長串加密或編碼內容）。

• 第三層是被下載下來的第二階段程式（例如資料竊取程式、後門）。

大部分人（包括很多工程師）只會看到第一層，最多是看懂 curl 或 bash 那一段；真正的惡意邏輯被藏在第二、第三層，甚至還會刻意偽裝成正常的工具名稱或指令。靠「人眼看一眼覺得沒問題」，結構上就是不夠的。

---

人類會疲勞、會習慣、會被 UI 訊號安撫

你可能記得瀏覽器剛開始加上 HTTPS 提示的年代：一開始大家會注意「鎖頭」圖示；久了就變成背景。同理，如果安全決策完全依賴「使用者每一次都要仔細讀、仔細判斷」，我們很快會掉入：

• 一開始還會緊張地看每個 skill 的說明、每段指令。

• 半年後變成反射性按 Enter—「過去都沒事，這次應該也沒問題。」

這種行為慣性和警覺疲勞是人類的自然傾向，單靠教育很難改變。教育是讓人知道「這裡很危險」；但 scanners 的作用是讓系統在你每一步走之前，再幫你看一次「現在這一步是不是剛好踩在地雷上」。

---

攻擊者會持續演化，純靠規則與教育追不上

就像釣魚郵件會進化一樣，skill 投毒也會越來越擅長模仿名正言順的工具名稱、說明文、使用場景。你今天教育使用者「小心有某種指令 pattern」，明天攻擊者可能就改用另一種寫法或拆成更多步驟。如果沒有一個可更新、可程式化的檢查層，教育只能在事件之後補破洞，而無法在第一時間把風險攔下。

也因此，我們需要 scanners—不是為了取代人的判斷，而是用系統去補人類認知與注意力的結構性缺口。

---

Scanners 是什麼：替你「看得更遠」的安全眼睛

對非技術背景的讀者，最簡單的方式是把 scanner 想成「自動審稿人」：在你按下「安裝」之前，替你快速翻過一遍，抓出那些你可能看不見、看不懂、看不完的細節。它大致在三個層面工作：

看內容：掃 skill 的文字說明、程式檔、腳本，找高風險 pattern，例如下載並執行外部程式的指令、大量讀取敏感路徑、用混淆方式隱藏行為（長串編碼字串、奇怪的指令拼接）。

看行為：在 skill 實際運行時，觀察它是否做了超出宣稱用途的事情，例如一個「日曆助手」在整個家目錄裡掃檔案，或一個「翻譯工具」大量對陌生伺服器送出資料。

看出處：檢查這個 skill 是誰發布的、是否有過問題紀錄、是否通過某種審核或簽章，評估發布者在生態裡的可信度，提供使用者一點信任線索。

關鍵不是讓設計師理解每一種掃描技術，而是理解它的角色定位：

Scanners 是一種「自動補位機制」，用來彌補人眼看不見、看不懂、看不完的那一大片風險區域。

對 UX 來說，真正的問題不是「scanners 存不存在」，而是「使用者有沒有在關鍵時刻看見它、理解它、願意聽它的警告」。一個只存在於工程師 log 裡的 scanner，對介面決策毫無幫助。

---

Scanners 要在哪些介面瞬間出現：三個接觸點

如果你是產品或 UX 設計師，可以刻意去找三個關鍵接觸點，思考怎麼把 scanners 拉出黑箱，變成真正支援決策的介面元素。這三個接觸點，也直接對應到後面 HCI Playbook 的五個元件。

安裝瞬間（對應 Risk Nutrition Label）

當使用者在 skill 市場看到某個技能時，通常只注意到名稱、縮圖、一兩句功能描述、星數和下載量。這些容易形成新的光環，讓人忘記這其實是一個有權限的程式邏輯。

在這一刻，你可以問自己：

• 我們有沒有顯示「這個 skill 是否已被掃描過」？

• 有沒有簡單的風險摘要，例如：「已掃描，發現高風險操作：下載並執行外部程式碼。」

• 如果 scanner 有具體發現，能不能用一句人話講出來，而不是丟一串技術代碼？

在安裝按鈕附近加上掃描狀態，綠色表示風險低，黃色表示有可疑點，紅色表示高風險—這不是要嚇人，而是讓風險從隱性變成可見。

授權瞬間（對應 Progressive Consent）

多數平台會在 skill 初次運行時要求一些權限，例如讀取檔案系統、呼叫特定工具、連線外部網路。在這一刻，scanner 的輸出可以變成你設計權限提示的素材：

• 不只是說「這個 skill 要讀取你的檔案」，而是加上：「掃描結果顯示它會嘗試存取大量檔案，與其宣稱的功能不完全相符。」

• 不只是列出技術權限，而是用後果描述：「允許後，它將能看到你這個資料夾中的所有檔案，包括文件與照片。」

把預設選項設計成最少權限模式，要開啟額外能力需要多一步，而且這一步會顯示 scanner 的提醒。這樣一來，scanner 不只是背後跑的工具，而是在使用者真正需要做決定時，提供一點具體的背景資訊。

執行中的異常行為（對應 Action Ledger + Interrupt & Revoke）

agent 的魅力之一在於「自動」，但這也是風險所在：當一個 skill 自動開始做奇怪的事時，使用者往往完全沒有感覺。Runtime scanner 可以扮演守門員：

• 當偵測到 skill 行為異常（例如突然打開很多敏感檔案、對陌生網域大量傳資料）時，暫停動作，彈出提示。

• UI 不需要展示全部技術細節，只需要說：「某個技能正在執行異常大量的檔案存取。這超出了常見的使用模式。你要允許、暫停，還是永久封鎖它？」

對設計師來說，這是一個非常典型的「介入時刻」：你可以決定提示如何措辭，預設選項是「繼續」還是「暫停並檢查」，以及要不要提供「之後都這樣處理」的選項以減少未來打擾。

---

危險邊界：介面可以畫出哪些紅線

除了把 scanners 拉上檯面，另一個 HCI 關鍵是：用介面把危險邊界具體畫出來，讓使用者知道自己正在靠近什麼。有三條邊界特別值得在設計上強調。

從功能到權限的邊界：最常見的情況是功能與權限不相稱—一個只宣稱「幫你整理記事」的 skill，卻要求完全存取你的家目錄與外網。你可以在 skill 頁面顯示簡單的「權限 map」，標出它能碰到哪些資料、哪些工具、哪些網路，並在 scanner 發現不相稱時給出顯眼提醒：「這個 skill 的權限比同類型技能高出許多。」這會幫助使用者建立一種直覺：做這件事真的需要這麼大的權限嗎？

人類與代理的責任邊界：當代理要你自己在終端貼指令時，在對話裡加入一層說明：「以下步驟需要你在終端執行高權限操作。請確認來源可信，或使用安全模式由系統代為處理。」並提供「不要叫我貼指令，改用安全安裝模式」的按鈕，讓每一次人類的「幫忙」都帶有一點自覺：我現在是在跨過一條系統邊界。

資料與憑證的邊界：多數攻擊的真實目標是你的資料與秘密—API key、token、SSH 金鑰、文件。把可存取的「資料島」視覺化（工作資料夾、憑證檔案、公司內網服務各用不同區塊表示），並在 skill 第一次接觸某個新資料島時給予特別提示，甚至需要升級授權。這些設計不需要你會加密或做權限系統，但能大幅提升使用者在心智模型中對「邊界」的意識。

---

{合作廣告}

🧑‍🎓 UX 訂閱制學習計劃：把 human-in-the-loop 變成你的日常。這也是我會特別推薦 #UX訂閱制學習計劃 的原因：它不是一次性的 bootcamp，而是把借位、補位、入位拆開來，串成 3 月到 12 月的一條學習軸線。

透過每月 Podcast 和專欄，先向不同領域的 UX / 產品 / AI / 服務設計講師「借位」

透過直播與 Circle 社群討論，在你的真實案子與問題上進行「補位」

點選報名

---

HCI 實作藍圖：五個可交付元件

前面說了問題在哪、scanner 的角色、三個關鍵接觸點、三條危險邊界。現在把它們壓成五個元件，每個有對應的決策時刻、介面文案範例和驗收條件。你不需要先做完整安全平台—先把這五個元件落地，已經足夠把「安全敘事」變成「安全機制」。