AI 工具在你的機器上執行程式碼、讀取檔案、發出網路請求。大多數時候，它做的都是你要它做的事。

但「大多數時候」不等於「每一次」。

問題不在於 AI 模型是否有惡意——它通常沒有。問題是 AI 模型會在上下文不足、指令不明確、或被注入惡意 prompt 的情況下，做出它以為是對的但實際上有害的事。

邊界在哪裡？

傳統的安全思路是在「AI 之前」做防護——限制它能讀取的資料、沙盒化它的執行環境、審查它的輸入。

WardnMesh 選擇了另一個位置：stdin/stdout 的交換點。

當你執行 wardn run claude，WardnMesh 把 Claude Code 當作子行程啟動，把自己夾在中間。所有進出的資料都通過 SecurityTransform：243 條規則掃描每一個資料塊，延遲不超過 5 毫秒。

這個架構的核心邏輯是：不管 AI 想做什麼，它都得經過這一關。

失敗即封鎖

在安全設計裡，「失敗即開放」和「失敗即封鎖」是兩種根本不同的哲學。

失敗即開放的假設是：允許通過是安全的預設值，只有明確危險才攔截。使用者體驗更順暢，但在最壞情況下，掃描器壞了，所有東西都通過了。

WardnMesh 選擇失敗即封鎖：掃描器故障、超時、任何例外，預設結果都是攔截。可用性讓位於安全性。

這個選擇有代價——使用者會遇到更多中斷，也需要面對確認提示。但對於一個負責監控 AI 工具的安全層，這是對的預設值。

本地優先不是妥協，是設計

把稽核紀錄留在本地是 WardnMesh 的核心設計決策，不是因為雲端難做，而是因為雲端引入了一個新的信任問題：誰來監管這個監管者？

如果你的 AI 安全掃描紀錄放在另一家公司的伺服器上，你對「發生了什麼」的詮釋權就不在自己手裡了。本地 SQLite 意味著紀錄你掌控，可攜帶，可離線存取，可移交給任何稽核程序。

對於需要在真實環境部署 AI 工具的組織，這不是特殊需求，而是基本前提。

243 條規則覆蓋什麼

WardnMesh 的威脅規則集覆蓋四個主要類別：程式碼注入、指令注入、資料外洩、以及權限提升。

這些不是假設性的威脅，是在真實 AI 工具使用中已有記錄的攻擊向量。對抗性 prompt 的形態會持續演化，規則集也必須跟上。這是 WardnMesh 作為開源工具最重要的長期挑戰——社群能不能夠及時更新規則，跟上新的攻擊模式？

仍然開放的問題

安全工具最大的敵人是使用者疲勞。誤報率太高，使用者學會反射性地點「允許」，整個機制就失去意義了。

WardnMesh 現在有決策快取（允許一次 / 本次會話 / 本專案 / 永遠），試圖降低重複確認的摩擦。但這和誤報率之間的平衡點在哪裡，還需要在真實使用場景中持續驗證。