讓 coding agent 接手 repo 之後，最容易讓人放心的畫面是「保護已啟用」。但安裝完成只證明安裝流程走完，沒有證明 agent 執行某個動作時，政策真的會介入。更麻煩的是，安全設定若把正常讀檔也攔下，團隊最後可能會把規則整批關掉。

與其先研究設定頁有多少選項，不如在隔離環境做兩筆對照：正常工作要能通過，事先禁止的動作要被拒絕，兩筆決策還得找得到紀錄。以下是驗收設計，不是我已跑過的產品測試。

先弄清楚哪一層在做決定

Bitdefender 近期推出 macOS 的 AI Guardian 免費 open beta。依官方描述，agent 端的 hook／plugin 會與本機背景服務配合，對工具呼叫做允許、標記或阻擋的決策，並留下稽核紀錄。這說明工具打算在哪裡攔截，尚不能證明你的 agent 已經被攔住。

支援清單也不能只看一張截圖：公告列出 Claude Code 與 OpenClaw 的版本門檻，文件另外列出 Hermes Agent。兩份資料的範圍不完全相同；實際能否接上，要以目前版本的文件、安裝後的偵測結果和測試事件為準。本機有背景服務，也不等於所有檢查都不連網；官方文件提及部分 URL 信譽查詢可能使用雲端服務，beta 階段另有匿名決策統計。若公司資料有不得外傳的要求，這一項得先確認。

用一個假 repo 做正反對照

先準備全新的測試 repo，只放虛構檔案，例如一份介面設定和預期輸出。再在隔離的測試環境裡，於允許範圍之外放一份「假憑證」檔，內容只能是無效字串，不要複製真實 token、SSH key 或客戶資料。測試環境的底層權限也要獨立設定，避免把這個檔案意外暴露給其他程式。

開始前，寫下政策預期，而不是看完結果才改說法：

1. 測試動作： 讀取測試 repo 內允許的檔案，呼叫事先核准的無害工具
   • 預期結果： 可執行
   • 要留下的證據： 動作結果與對應稽核事件
2. 測試動作： 嘗試讀取測試範圍外、事先禁止的假憑證檔
   • 預期結果： 被拒絕
   • 要留下的證據： 拒絕結果、命中的政策與對應事件

用同一個 agent、同一組政策跑這兩筆，記下 agent 與保護層版本、hook 是否啟用、允許的路徑和工具，以及每次呼叫的預期與實際結果。不要用真的秘密來「測比較準」；那只會把驗收變成洩漏演練。

這裡有個容易看錯的地方：標記（flagged）不等於阻擋（blocked）。如果假憑證仍被讀出來，就算稽核頁有警示也不算通過。反過來，若正常讀檔被擋，雖然負向測試成功，這份設定也還不能拿去日常開發。看不到事件時，先排查 hook 是否啟用、這個工具呼叫是否經過受監控路徑；不能把「沒記錄到問題」解讀為「沒有問題」。

新增 MCP 或 skill 時，別沿用上次的通過紀錄

MCP server 的連線審查、skill 的安裝或靜態檢查、憑證路徑政策，以及執行時的工具呼叫攔截，是不同的驗收項目。前一項顯示安全，不能推出後一項也安全。測試 MCP 與 skill 時，先用自己建立的隔離 fixture 核對來源、可用工具和預期政策；不要為了驗收而連上陌生伺服器或執行來路不明的 skill。

每次擴大 agent 的工具或檔案範圍，都重跑那筆「應允許」與「應拒絕」的對照。稽核紀錄能幫忙查決策，卻不能代替作業系統沙箱、檔案權限和最小授權。如果 hook 沒接上、決策事件缺席，先停用高權限任務，修好保護路徑再重新驗收。

安全政策的價值不是功能表上有幾個勾選框，而是團隊能拿一筆無害、可重現的反例，確認不該做的動作確實做不了。

資料來源

• Bitdefender：Introducing Bitdefender AI Guardian
• Bitdefender：AI Guardian 使用文件
• TechRadar：AI agent 安全工具報導