回到我們的小章魚 Claude skill掃毒軟體，我們是怎麼去防禦提示詞注入的？

在文章開始前，我想先分享我們當初是怎麼學習縱深防禦（Defense in Depth）和最小權限原則，以及中間經歷了什麼過程。

一開始我們其實不知道這個小章魚軟體會以什麼樣的形式出現在使用者的介面或系統中。後來我們在 Bluesky 社群媒體上發了一篇文章，有一位軟體工程師留言詢問我們，他覺得這個點子很棒，並問我們會將它應用在哪一個層級：像是 OS 層（Operating System，作業系統層）、SDK，還是做成一個在筆電或電腦上使用的 App？那時我們才了解這些概念。SDK（Software Development Kit，軟體開發套件） 就像是軟體的組件包，類似 IKEA 家具工具包的概念，拿來就可以直接組裝出具有特定功用的東西。

當時我們還沒有太多想法就想說那設計一個SDK好了！所以這篇文章我會先以最初的 SDK 構想切入，描述當初是如何設計縱深防禦架構。

當時設計 SDK 架構時，就像我之前提到的，我們要打破致命三要素（Lethal Trifecta）。因此我們構思了一個從使用者輸入資料到工具系統執行的三層架構：

第一層：Input Guard（邊界層）

當資料進來時，它會確認內容是否有惡意提示詞，就像上一篇文章提到一般 LLM 會做的比對。第一層主要負責安全比對，包括：
• 靜態過濾：確認是否有已知的惡意提示詞。
• 格式與結構正規化：確認是否符合預期的架構，並防範超長字串引發的 DoS（Denial of Service，阻斷服務攻擊）。
• PII （Personally Identifiable Information，個人可識別資訊）檢查：過濾使用者忘記遮蓋的敏感資訊。
• 資料標記：我們設想透過標籤進行簡單的資料標記，避免模型將外來的資料誤當成指令。

這是第一層原先設計所做的事情。

第二層則是語意層。

我們有構思出由一個單獨的 LLM 去當裁判員，獨立且快速地審查資料中是否包含 AI 的風險或問題，這叫做安全護欄模型（guardrail model）。它單純去做意圖和語意的判斷，很像大型語言模型中的安全審查，但我們是用小型的模型SLM（Small Language Model）來做。它專門針對 prompt injection 的部分，去分析文字中是否包含潛在的惡意企圖，或是資料內容以外一些特別隱藏的指令，藉此避免我們主要的 AI agent 被洗腦。

當時覺得用一個開源的LLM來做應該可以很便宜，但是實際上我們沒有相關的資源，讓大家都可以跑這個安全檢查的LLM。

第三層：權限控管

第三層相對複雜，核心與權限有關，我們依照三個原則來設計：

1最小權限

2角色動態權限

3.Human-in-the-loop

1. 最小權限原則（Principle of Least Privilege, PoLP）：

這是資安領域中基本的原則。無論是使用者、程式還是 Agent，在任何時候都只應該擁有完成當前任務所必需的最低權限，絕不多給。

2. 角色動態權限：

依照當前角色應有的最小權限動態授權。當它嘗試要求或呼叫超出權限的功能時，系統會限制高風險工具的呼叫。舉例來說，如果你原本只是叫 AI 查詢最近的資安時事，但 AI 卻跑去呼叫平常有連動的 Gmail，這時小章魚就會依據最小權限與當前 AI Agent 的角色判定，主動阻斷呼叫 Gmail 的動作。

3. Human-in-the-loop，也就是人要在這個操作的迴路當中。但這是我們在設計這整個權限架構中最不確定的地方。當 AI agent 要執行一些高風險操作時，會去呼叫並跳出一個詢問使用者允許或拒絕的視窗。就像我們使用 Claude Code 做事情的時候，要讀取你的檔案或是要進行下一步，會問你允不允許讓 Claude Code 讀取這筆資料，是一樣的概念。當「致命三要素」可能要集齊的時候，會發出這個允許或拒絕的提示。
   但在實際操作過程中，我們會遲疑的部分在於：這會不會打斷使用者既有寫程式或 vibe coding 的過程，進而讓他們很討厭我們做的這個機制？或是，使用者因為要一直同意而產生同意疲勞。

所以在設計 Human-in-the-loop 的時候，我們會參考使用者原先在 Claude Code 的一些設定。假設他在 Claude Code 是開 Auto，那會開放大部分的權限自動處理，這個 Human-in-the-loop 就會暫時被關閉。但這可能不是最好的設計，所以我們也在思考：如果Human-in-the-loop這個機制失效了會怎麼樣？

整個資安 SDK 的架構主要是分成這三層。

下一篇文章會提到：在最壞的設計情況下它會怎麼樣？以及我們的 SDK 在測試環節中發生了什麼事情、有沒有爆掉？