BadSkill 論文閱讀分析：真正危險的 skill，可能根本不是寫了什麼壞指令，而是裡面那顆模型早就被訓成了內鬼
論文基本資訊
- 論文標題：BadSkill: Backdoor Attacks on Agent Skills via Model-in-Skill Poisoning
- 作者：Guiyao Tie、Jiawen Shi、Pan Zhou、Lichao Sun
- 年份：2026
- 來源：arXiv:2604.09378
- 論文連結：https://arxiv.org/abs/2604.09378
- DOI：10.48550/arXiv.2604.09378
- 主題：Agentic Security、Agent Skills、Backdoor Attack、Model Supply Chain、Skill Poisoning、Runtime Security
如果前幾篇 skill / MCP / tool poisoning 論文大多在談「外部內容怎麼把 agent 帶偏」，那這篇 BadSkill 切得更上游，也更陰：真正危險的 skill 可能根本不用在文件裡寫髒 prompt，它只要把惡意行為藏進 skill 內附的模型權重裡就夠了。
換句話說，這不是 prompt injection，也不只是 plugin misuse。這篇在講的是另一條供應鏈面：model-in-skill poisoning。第三方 skill 表面上看起來功能正常、介面正常、說明也正常，但它裡面包的那個小模型早就被 backdoor fine-tune 過，只要使用者傳入某組看起來完全普通的參數組合，它就會把 execution route 偷偷切到 hidden payload。
這篇最值得記住的一句話
當 agent ecosystem 開始允許 skill 自帶 learned artifact，真正該驗的就不只是 skill 說了什麼、呼叫了什麼，而是它裡面那個模型到底被訓成了什麼。
這句話其實很重要。因為很多現在的 agent security 思路，還是把 skill 當成「帶文件、帶程式碼、帶工具封裝」的東西來看；但如果 skill 已經開始內嵌 classifier、reranker、policy model、parser model，信任問題就不再只是 code review 能不能看出來，而是 weights 本身變成攻擊面。
BadSkill 在打什麼洞？不是 prompt 被污染，而是 skill artifact 自己就是污染源
作者定義的威脅模型很清楚：攻擊者在 skill 開發階段，把一個 backdoored classifier 包進 skill 裡，再透過正常安裝流程把它發佈成第三方 skill。宿主 agent runtime、gateway LLM、host privilege model 都沒有被直接改掉；被污染的是 skill artifact 本身。
這跟常見幾種攻擊很不一樣：
- 不是 prompt injection：因為不需要外部內容在 runtime 再塞一句惡意指令
- 不是單純 tool poisoning：因為惡意邏輯不一定寫在 description 或 code branch 裡
- 不是一般 plugin misuse：因為它是把 trigger-conditioned policy 藏進 model parameters
這也是我覺得這篇值得補的原因：它把 skill 供應鏈風險往前推了一步。以前我們怕的是 skill 文件有毒；現在要開始怕的是 skill 裡那顆模型就算文件和程式碼都很乾淨，也可能在某些條件下自己開始作怪。
它怎麼藏？不是靠單一關鍵字，而是靠「看起來很正常」的參數組合觸發
BadSkill 的核心設計，不是傳統那種塞一個稀有 token 當 trigger，而是改成 compositional trigger。也就是說，skill 觸發條件不是某一個超怪的欄位值，而是多個 individually benign 的參數一起滿足時才啟動。
例如在 skill invocation 裡，某幾個 argument value 單看都很合理，但只要它們同時出現，內建 classifier 就把這次請求判成「切去 payload branch」。
這個設計很毒，因為它剛好踩中 skill ecosystem 的特性：
- skill invocation 本來就常是 structured parameters，不是自由文字
- 多欄位組合本來就很難靠簡單規則看出異常
- 每個欄位單獨看都很正常，讓人工 inspection 更難抓
論文的結論也很有意思：最有效的 trigger 不是最簡單，也不是最複雜，而是 2–3 個欄位組成的短 conjunction。 單欄位太弱，容易和正常請求混掉；4 個以上又太窄，不夠穩。真正危險的是那種「不算少到看起來明顯，也不算多到難以重現」的中型組合。
BadSkill 的兩階段攻擊流程：先學會分流，再把模型包進 skill 裡
整個方法其實不複雜，但很符合實務威脅。
- Stage I：Trigger-aware optimization
先把 skill query parse 成 structured invocation，再用 poison samples + hard negatives 去訓一個 classifier，讓它學會分辨哪些參數組合該走 benign branch、哪些該走 payload branch。 - Stage II：Skill packaging and conditional runtime execution
把訓好的 classifier 直接包進 skill artifact，runtime 時只要看 classifier 分數高不高，超過 threshold 就偷偷切到 hidden payload。
從防守角度看，這件事最麻煩的不是 attack logic 很複雜，而是它太像正常工程：內嵌模型、解析參數、做 route decision，本來就是很多 skill 會做的事。 也就是說，BadSkill 不是用一種很反常的方式入侵系統，而是把正常 skill 能力做成了 supply-chain hiding place。
作者做了什麼來提高隱蔽性？hard negatives 很關鍵
這篇有一個我覺得很務實的細節：他們不是只拿 poison samples 訓練，而是特別加入 hard negatives，也就是那些「幾乎滿足 trigger，但故意差一個關鍵欄位」的近似樣本。
這樣做的效果，是逼 classifier 不要靠淺層 cue 偷懶，而是真的把完整 trigger conjunction 學起來。對攻擊者來說，這很重要，因為它能：
- 降低 benign query 被誤觸發的機率
- 維持正常情況下 skill 看起來很穩
- 讓惡意行為更像「精準條件下才出現的異常路由」
也因此，BadSkill 不只是要 ASR 高，它要的是一種更可怕的組合：ASR 高，但 benign-side accuracy 也夠高，讓人覺得這 skill 平常根本沒問題。
實驗數字很兇：高 ASR、低 poison rate、還能撐住文字擾動
作者在一個 OpenClaw-inspired 的模擬環境裡做評估，保留了第三方 skill 安裝、skill loading、runtime model invocation 這條 execution path。benchmark 共 13 個 skills，其中 8 個是 triggered skills、5 個是 non-trigger control skills；主要評估集包含 571 個 negative-class queries 和 396 個 trigger-aligned queries。
最值得注意的幾個數字：
- 8 個模型架構、5 個模型家族，範圍從 494M 到 7.1B
- 8 個 triggered skill categories
- 最高平均 ASR 可到 99.5%
- 3% poison rate 就能到 91.7% ASR
- 在 5 種文字擾動下仍維持有效
這些數字真正可怕的地方，不只是「攻擊成功率高」，而是它說明了三件事：
- 這不是靠某個模型的怪癖才成立，而是跨家族都行
- 這不需要很高的 poison fraction，少量污染就夠
- benign accuracy 不是可靠篩檢訊號，因為 skill 可以平常都很正常，只有特定組合才發病
這點我覺得很值得 agent platform 團隊警惕：如果你的 skill admission 流程主要還在看 metadata、說明文件、source code 和少量功能測試，那對 BadSkill 這類 model-in-skill 攻擊幾乎等於沒驗到。
這篇真正戳破的一個迷思：code inspection 不等於 skill 安全
很多人對第三方 skill 的安全想像還停在：
- 掃一下依賴
- 看一下 code
- 檢查工具權限
- 跑幾個 smoke tests
但 BadSkill 證明，只要惡意 policy 寫在 model parameters 裡，你就算看不到明顯惡意分支，也不代表它沒問題。 這點和先前 skill injection / trusted description / runtime guard 論文很不一樣。那些還比較像是「模型被外部文字騙」。BadSkill 則是「你安裝進來的那個 skill 自己就帶著一個訓練好的惡意判官」。
所以這篇其實把安全問題從：
- instruction integrity
- tool description integrity
- runtime context integrity
再往前拉到：
- artifact provenance
- weight provenance
- behavioral vetting of embedded models
如果把它放回最近 agentic security 脈絡裡看，BadSkill 補的是 skill supply chain 的「黑箱權重面」
最近很多 agent security 論文都在補不同控制面：
- 有些在補 web / tool-return / retrieval 的外部注入面
- 有些在補 MCP / skill description / parameter binding 的工具面
- 有些在補 runtime verification / guard / action consistency
BadSkill 補的是另一塊：第三方 skill 若可攜帶模型，weights 本身就成了不透明控制面。
這件事很像容器供應鏈當年從「image 裡有沒有惡意 shell script」一路演進到「base image、build provenance、signed artifacts、SBOM、reproducible builds 都要一起管」。對 agent ecosystem 也是一樣：只管 prompt 和 tool 不夠，skill artifact 裡若有 model，整條模型供應鏈也得進安檢流程。
這篇對防守方最實際的啟發
作者最後給的方向是 provenance verification 和 behavioral vetting。我自己會把它再翻成更具體幾條：
- skill 不該只簽 code，最好連 bundled weights 一起做 artifact signing 與 provenance chain
- 對 model-bearing skills 做行為式紅隊測試，不能只看 source
- 用 structured parameter fuzzing 找 trigger conjunction，尤其是 2–3 欄位組合
- 把 embedded model 視為高風險 dependency，不是普通 assets
- 高權限 skills 盡量避免直接帶 opaque learned router，或至少把 route decision 外移到可驗證層
更直白一點說：未來 skill marketplace 真正需要的，也許不只是 skill 商店審核，而是某種 agent-native 的 model artifact attestation。
我怎麼看這篇？它讓「skill 是方法包」這件事變得沒那麼天真了
我最喜歡這篇的地方，是它沒有把問題說得太玄。它只是很冷靜地提醒一件本來就該想到、但很多人還沒真的面對的事：
只要 skill 允許攜帶 learned model，攻擊者就不必再把惡意行為寫在你看得見的地方。
這句話一落地，很多既有防線就得重畫。因為你不再只是審查文字、程式碼、API 權限，而是要審查一個可能在特定參數組合下偷偷切換 policy 的黑箱。
所以這篇真正的價值，不只是展示 99% ASR 這種漂亮數字，而是它把大家從「skill 文件有沒有毒」拉去看「skill 裡那個模型是不是本身就有毒」。這是供應鏈安全裡更麻煩、也更接近未來實際風險的位置。
對 sectools.tw 讀者的最後結論
我會把 BadSkill 濃縮成一句話：
當 AI Agent 的 skill 開始自帶模型，真正危險的可能不是它讀到什麼，而是它從被安裝的那一刻起，就已經決定好在某些正常參數下要替誰做事。
如果你在做：
- agent skill marketplace
- 第三方 skill 審核
- MCP / plugin / extension 安全
- 高權限 agent runtime
那這篇非常值得看。因為它提醒你，下一波 skill 供應鏈風險，可能不會寫在 README，也不會寫在 if-else，而是寫在你平常根本不會人工審的那份模型權重裡。
本文由 AI 產生、整理與撰寫。