你準備替團隊裝一個新的 AI agent skill。README 寫得很完整，GitHub stars 看起來也不低，掃描器沒有亮紅燈，demo 影片甚至剛好解決你們這週卡住的工作流。
這時最容易出現的錯覺是：既然掃描器沒擋，應該可以裝了。
但 AI agent skill 的風險，常常不只藏在安裝那一刻。它真正有能力造成影響的地方，是被 agent 呼叫之後：它能不能讀檔？能不能連網？能不能拿到 token？能不能把結果寫回專案？能不能在你看不到的步驟中，把資料帶到外面？
近期 SkillCloak 相關研究提醒了一件事：只靠安裝前的靜態掃描，可能看不到某些執行時才展開的行為。研究中提到的 self-extracting packing、跳過特定目錄、執行時還原 payload 等手法，重點不在某一篇論文有多驚人，而在它把一個長期問題講得更明白：第三方 skill 不能只問「掃描器有沒有過」，還要問「它跑起來時被允許碰什麼」。
這堂微課要處理的就是這個卡點：AI agent skill 安裝前，團隊要怎麼檢查掃描器看不到的風險？
In this lesson
- 為什麼通過掃描仍然不能直接安裝
- 一張 AI agent skill 安裝前 go/no-go 表
- 如何用隔離試跑補上 runtime 觀察
- 團隊明天可以加上的最小放行步驟
- 可交給 AI 幫忙整理的 handoff prompt
先把 skill 當成「會被 agent 代你執行的外部同事」
agent 可以先理解成「會自己連續執行幾步任務的 AI 助手」。skill 則像是這個助手可以臨時學會的一組工具、指令或工作流。
問題是，很多團隊在審第三方 skill 時，還停留在審一般套件的習慣：
- 看 repo 來源是否可信。
- 跑一次 scanner。
- 看 README 是否合理。
- 確認安裝指令沒有明顯可疑內容。
這些都該做，但不夠。
一般套件的風險多半集中在安裝、build、import 或執行特定函式。AI agent skill 多了一層：它可能在 agent 覺得「下一步需要它」時才被呼叫，而且呼叫時帶著任務上下文、檔案、工具權限與使用者意圖。也就是說，skill 不只是一段程式，它會進入一條工作流：一連串固定交接步驟。
如果你們還沒有把 agent 的授權邊界拆開，可以先回頭看這篇：AI agent 授權四問表：身份、權限、理由、後果。那篇處理的是 agent 做動作前要問什麼；這篇則把焦點放在 skill 安裝前，怎麼決定能不能讓它進入環境。
掃描器負責找線索，放行流程負責決定風險能不能被承擔
掃描器很重要。它可以幫你找 prompt injection、資料外洩、權限升級、工具誤用、MCP 風險等常見問題。MCP 可以先理解成「讓 AI 工具用同一種方式接資料與工具的協定」。
但掃描器通常比較擅長回答這些問題：
- repo 裡有沒有可疑字串？
- 檔案結構裡有沒有常見惡意模式？
- prompt 是否試圖覆蓋原本指令？
- 有沒有明顯要求讀取敏感檔案或外送資料？
它比較難獨自回答：
- 這個 skill 在你們的專案脈絡下，會拿到哪些實際資料？
- 它被 agent 連續呼叫三步後，會不會組合出新的風險？
- 它是否需要寫入權限，還是只要讀取就夠？
- 它連網的目的地是否能被限制？
- 它出錯時，誰負責停止、回收 token、清掉暫存資料？
這也是為什麼「掃描器通過」比較適合當成入口條件，不適合當成最終放行。類似地，安全掃描器指出問題後，也不該讓工具自動亂改生產設定；可以對照這篇：AI 安全掃描器說要修，先讓人類決定能不能改。同樣的邏輯放在 skill 安裝前，就是：掃描器可以提示，人要負責決策。
AI agent skill 安裝前 go/no-go 表
下面這張表的用法很簡單：每一列都要能回答「現在是否足以進入隔離試跑」。如果任一列落在 no-go，就不要裝進日常工作環境；如果落在 conditional go，先補上限制，再進沙盒試跑。
| 檢查項目 | Go：可以進隔離試跑 | Conditional go：補限制後才試跑 | No-go：今天不要裝 |
|---|---|---|---|
| 來源與維護狀態 | 來源 repo、發布者、版本紀錄可追；最近一次更新與 issue 回覆顯示仍有人維護 | 來源可信但維護訊號弱；先固定 commit hash，不用浮動版本 | 只有壓縮檔、匿名來源、無法追版本，或 README 與實際檔案差異明顯 |
| 權限需求 | skill 說明清楚列出需要讀哪些目錄、用哪些工具；最小權限即可完成任務 | 權限需求偏大，但可以用唯讀目錄、單一測試 repo、一次性 token 限縮 | 一開始就要求全專案寫入、系統層 shell、瀏覽器登入狀態或長效 token，且沒有合理理由 |
| 敏感資料邊界 | 試跑資料可去識別化；不需要讀 .env、金鑰、客戶原文、內部合約 | 需要部分真實資料；先建立 20 筆以內的脫敏樣本，並禁止讀取 secret 目錄 | 必須直接讀 production secret、客戶完整資料或未遮罩憑證才會動 |
| 網路行為 | 預期目的地少於 3 個，且能用 allowlist 控制；離線模式也能完成主要功能 | 需要連外 API；先限制網域、記錄 request metadata，不傳 payload 全文 | 會連到不明 endpoint、動態下載執行內容，或拒絕說明資料送往哪裡 |
| 執行沙盒 | 可以在 container、臨時工作目錄或測試 VM 跑；試跑結束能完整清掉檔案與 token | 只能在本機跑；先建立新使用者、唯讀 mount、無持久化憑證的環境 | 必須在工程師主力工作機、登入狀態瀏覽器或 production workspace 才能跑 |
| 可觀測性 | 能記錄檔案讀寫、網路連線、工具呼叫與輸出摘要；log 不含敏感全文 | 只能記部分事件；先補 wrapper 或代理層，至少記錄時間、工具、目標路徑、目的網域 | 跑完只看到最終答案，無法知道讀了什麼、連到哪裡、改了什麼 |
| 失敗處理 | 有明確 owner；試跑若異常，可在 15 分鐘內撤 token、刪工作目錄、回報影響範圍 | owner 已指定但撤回步驟未演練；先做一次 dry-run，確認 rollback 路徑 | 沒有人負責收尾，或一旦出事只能靠「大家記得不要再用」 |
這張表刻意把「掃描結果」放在表外。原因是：掃描器應該先跑，而且沒過就不用進表；但進表後，決策重點會變成「即使它看起來乾淨，我們是否知道它執行時會碰到什麼」。
用 30 分鐘做一次隔離試跑
dry-run 是「先試跑但不真的改資料或發布」。對第三方 skill 來說，dry-run 不只是看它能不能完成任務，也是在觀察它如何完成任務。
換句話說，這一段不是額外測試，而是在補掃描器看不到的 runtime 邊界：skill 實際跑起來時讀了什麼、連到哪裡、用了哪些工具、最後把資料帶到哪個輸出。
你可以用下面這個順序跑一次小型檢查。
1. 準備一個假的但像真的任務
不要拿 production 專案當第一個測試對象。比較好的方式是準備一個小型 fixture：
- 10 到 20 個檔案，結構模仿真實 repo。
- 2 到 3 個故意放進去的邊界案例，例如假
.env、假客戶資料、假 API key。 - 1 個明確任務，例如「幫我整理 changelog」或「找出設定檔不一致的地方」。
- 1 個明確禁止事項，例如「不得讀取
secrets/目錄」。
這樣做的好處是，你不是只看 skill 有沒有完成任務，也能看它有沒有碰不該碰的地方。
2. 把權限切成三層，不要一開始全開
第一次試跑時，建議照這個順序開權限：
- 第一層： 唯讀檔案權限，無網路。
- 第二層： 唯讀檔案權限，限制網域連線。
- 第三層： 需要時才加入寫入權限，而且只允許寫到
output/或暫存目錄。
如果 skill 在第一層就能完成主要任務，就不要升到第三層。權限升級要有理由，不要因為安裝教學寫了「建議給 full access」就照做。
3. 記四種 runtime 訊號
runtime 可以先理解成「程式真的跑起來的那段時間」。隔離試跑至少要記這四種訊號：
- 檔案：讀了哪些路徑？寫了哪些路徑？有沒有碰 forbidden directory？
- 網路：連到哪些網域？request 大小是否異常？是否有動態下載內容？
- 工具：呼叫了哪些 shell、瀏覽器、API 或 MCP tool？順序是否合理？
- 輸出：最終答案是否引用了不該知道的資料？是否把內部內容貼進外部服務？
不用一開始就做很重的安全平台。小團隊可以先用 container log、proxy log、檔案系統 audit、agent tool-call log 拼出第一版觀察。重點是讓試跑留下可回看的痕跡。
4. 把結果寫成 go/no-go，而不是「感覺可用」
試跑結束後，不要只在 Slack 留一句「看起來 OK」。請把結果收斂成三種狀態：
- go：可裝進限定工作流，保留相同權限限制與監控。
- conditional go：只能給特定 owner、特定 repo、特定任務使用，並在 2 週內複查。
- no-go：不安裝；記下原因，避免下次另一位同事重走一次。
如果 conditional go 太多，代表這個 skill 目前還不適合變成團隊共用工具。它也許可以留在個人實驗環境，但不要進正式工作流。
一個常見錯誤：把 skill 衝突當成安裝後才處理的問題
很多 skill 風險不是單一 skill 自己造成，而是跟既有工具組合後才出現。
例如：
- 一個 skill 只負責整理 issue，看起來只需要讀取權限。
- 另一個 skill 會根據 issue 自動開 PR。
- agent 在同一條工作流裡連續呼叫兩者後，讀取、判斷、寫入就被串起來了。
這時風險不在單點功能，而在來源設計與權限交接。從 runtime 邊界來看，問題不是「這個 skill 自己會不會越界」，而是「agent 連續呼叫多個 skill 後，讀取、判斷、寫入、連網會不會被串成新的路徑」。若團隊已經開始累積多個 skill，可以延伸看這篇：衝突的根本解法不在仲裁，而在源頭設計。安裝前的檢查不只是在審「這個 skill 安不安全」，也是在審「它進入現有 agent 生態後，會不會跟其他能力組出新路徑」。
明天可以先加的一個最小步驟
如果你們現在沒有完整流程，不用等資安平台建好才開始。明天先加這一步：
每次有人要安裝第三方 AI agent skill，都必須附上一張 6 行安裝申請卡：
- 來源版本： skill 來源 URL、版本或 commit hash。
- 單一任務： 這個 skill 要解決的單一任務。
- 資料權限： 它需要讀取的目錄與工具。
- 連網需求： 它是否需要連網；若需要，列出預期網域。
- 試跑資料： 第一次 dry-run 用哪個假資料集。
- 異常收尾： 異常時誰是 owner，如何撤 token 或停用。
owner 是「負責最後判斷與收尾的人」。這張卡不需要很漂亮，但要讓下一個人看得懂：為什麼要裝、打算給它什麼、如果它越界誰會處理。
有了這張卡，掃描器才會變成放行流程的一部分，而不是放行流程的替代品。
AI 整理卡
用這篇資安停手檢查整理你的下一步 這不是摘要指令，而是把本文方法套回你的流程。貼到自己的 AI 工具後，先讓它問清楚你的限制、資料與決策目標。
我想把這篇 BMC 微課套用到自己的情境：為什麼 AI agent skill 掃描通過，安裝前還是要再看一次執行邊界？
這篇處理的具體問題：第三方 AI agent skill 通過掃描，不代表執行時一定安全。這堂微課用一張 go/no-go 表，把來源、權限、沙盒、網路與敏感資料邊界檢查清楚。
文章連結：https://boosterminiclass.com/posts/ai-agent-skill-install-runtime-risk-checklist/
請不要只摘要文章。請先問我 3 個問題，確認：
1. 我現在要處理的實際流程或決策是什麼；
2. 這個流程會碰到哪些資料、權限、帳號、成本或對外動作；
3. 我希望今天得到的是停手判斷、試用清單、交接模板，還是風險分級。
接著用這篇文章的框架檢查我的情境：
請輸出：
- 一句話判斷：我現在應該直接做、先限縮試做，還是暫停；
- 對照表：把本文框架逐項套到我的情境，列出已具備／缺證據／需要人工確認；
- 今天可做的一個最小步驟；
- 需要負責人、日誌、回退或人工審核的地方。
如果 AI 沒有問清楚限制或資料來源，先補問，不要直接採用清單。
用日常來理解
- 第三方 skill 進來時，先把它當成需要被檢查的外部能力，不要直接放進日常工作流。
- 檢查來源、版本、權限、敏感資料與網路需求，確認哪些條件還缺證據。
- 用假資料與隔離環境試跑，觀察檔案、網路、工具呼叫與輸出是否越界。
- 試跑結果只收斂成 go、conditional go 或 no-go，並由 owner 負責停用、撤 token 或補限制。
參考來源
arXiv：Cloak and Detonate: Scanner Evasion and Dynamic Detection of Agent Skill Malware — https://arxiv.org/pdf/2607.02357（2026-07-02）
The Hacker News：SkillCloak Lets Malicious AI Agent Skills Evade Static Scanners with Self-Extracting Packing — https://thehackernews.com/2026/07/new-skillcloak-technique-lets-malicious.html（2026-07-06）
NVIDIA SkillSpector：SkillSpector README — https://github.com/NVIDIA/SkillSpector（2026-07-06）
