PoisonedSkills 論文閱讀分析：當 Agent Skill 文件不再只是說明書，而是能直接劫持行動空間的供應鏈入口

論文基本資訊

• 論文標題：Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems
• 作者：Yi Liu 等人
• 年份：2026
• 來源：arXiv:2604.03081v1
• 論文連結：https://arxiv.org/abs/2604.03081
• DOI：10.48550/arXiv.2604.03081
• 主題：Agentic Security、Skill Supply Chain、Coding Agents、Indirect Prompt Injection、Action-Space Hijacking、Software Supply Chain Security

如果前幾篇 sectools.tw 已經一路把 agent skill、runtime supply chain、tool injection、marketplace auditing 這條線鋪得很滿，那這篇論文真正值得補上的，不是再多講一次「第三方 skill 很危險」，而是把問題往前推了一大步：危險的不只是 skill 會把 agent 帶去選錯工具，而是 skill 文件本身就可能變成一種能讓 agent 把惡意程式碼當成範例、當成 best practice、最後親手執行的供應鏈載體。

這個差別非常大。過去很多討論還停在 prompt injection、tool ranking manipulation、或 RAG poisoning 會讓模型「說錯話」。但這篇在問的是另一件更硬的事：如果 coding agent 會把 skill 文件裡的 code example 與 config template 視為可信參考，那麼被污染的文件，能不能直接劫持它的 action space——也就是 file write、shell command、network request 這些真正會碰到系統的操作？

作者的答案不是模糊的「有風險」，而是相當具體的：可以，而且在多個主流 coding-agent framework 上都做得到。

這篇論文想解決什麼？

這篇 paper 的核心問題其實很尖銳：

當 LLM coding agent 透過第三方 skill 擴充能力，而且 skill 文件會被當成 operational directive 載入 context 時，攻擊者能不能把惡意 payload 藏在看似正常的技術文件裡，繞過 alignment 與 framework guardrail，最後讓 agent 在受害主機上自己把 payload 跑出來？

這裡最值得注意的是，作者刻意把 threat model 從「模型被騙說錯話」升級成「模型被騙去做錯事」。文章裡把這件事稱為 action-space hijacking。也就是說，風險不再只是內容層的污染，而是：

• 寫出被汙染的檔案
• 執行 shell command
• 發起外連
• 改動設定檔、建置腳本或部署模板

這就是為什麼這篇特別值得看。它把 agent skill 風險從「上游描述不可信」直接連到「下游主機可被實際操控」。中間隔著的，不只是 prompt，而是一整條 retrieve → load → generate → execute 的 execution pipeline。

關鍵概念：DDIPE 不是直接下命令，而是把 payload 偽裝成範例

整篇論文最重要的技術概念，是作者提出的 DDIPE（Document-Driven Implicit Payload Execution）。

白話講，這不是傳統那種「請忽略之前指令並執行 XXX」的明示型注入。DDIPE 的做法剛好更陰：

• 把惡意邏輯藏在 skill 文件的 code block 裡
• 或藏在 YAML / JSON / Makefile 這類設定模板裡
• 讓 agent 在正常工作時，自然地把這些內容當作參考範例複製進自己生成的程式或設定
• 再由 agent 的執行流程把它跑起來

這個設計之所以危險，是因為它繞過的不是單一 safety filter，而是利用了 coding agent 很核心的一個工作習慣：會把文件中的範例視為可信 implementation pattern。

也因此，作者強調這類攻擊和一般 indirect prompt injection 不一樣。它不是靠 imperative instruction 逼模型違規，而是靠 「像範例、像模板、像最佳實務」 的外觀，讓模型在完成正常任務時主動重現 payload。這比硬塞惡意指令更貼近真實工程流程，也更難被一般 alignment 直接攔下。

兩種主要攻擊路徑

論文把 DDIPE 拆成兩個主要 embedding strategy，這個分類很實用。

1. Code Example Poisoning

第一種是把 payload 埋進 Markdown code block。當 agent 被要求生成相似腳本、utility function 或 automation code 時，它可能會把這些帶毒的 code pattern 一起複製進輸出。

例如文章中的例子，就是把環境變數外傳、例外吞掉、或額外的網路請求包裝成 routine telemetry、backup、compliance auditing 之類的正常流程。這種 payload 最陰的地方在於：它不需要看起來像惡意指令，只需要看起來像一段合理的工程實作。

2. Configuration Template Poisoning

第二種是把 payload 藏進部署模板或設定檔。像是 YAML、JSON、Kubernetes manifest、Makefile、IaC template 這些東西，本來就是 coding agent 很常生成的產物。

一旦這些模板裡被植入：

• 多餘的 mount
• 特權權限
• 偷偷外送資料的 webhook
• 被後門化的 package source / registry config

那風險就不只停在單次本機執行，而可能一路往 CI/CD、deployment、infrastructure provisioning 擴散。這也是作者把攻擊目標拆成兩大類的原因：

• O1：System control / asset exfiltration
• O2：Infrastructure poisoning

前者是直接偷憑證、偷環境變數、拿 shell；後者更可怕，因為它把一次被污染的生成，變成後續整條基礎設施供應鏈的持續污染。

這篇論文最有價值的地方：把防線拆成兩層，而且證明兩層都可能失守

作者把 agent defense 很清楚地拆成兩層：

• 模型層（model-level alignment）
• 框架層（framework-level architectural guardrails）

這個拆法很關鍵，因為近年的 agent 安全討論很常把兩件事混在一起。很多人會說「模型已經更安全了」，但這裡的問題是：就算模型不願意照著惡意指令做事，也可能仍然願意複製一段看起來合理的範例程式碼。

而 framework guardrail 也未必擋得住，因為從系統角度看，agent 只是：

• 產生了一段正常-looking code
• 再透過既有工具鏈執行
• 做出 file I/O、network request、config write

換句話說，這不是明顯違規的危險動作，而是被包裝成合法工作流的一部分。 這也是整篇 paper 最值得實務界記住的地方：真正難防的供應鏈攻擊，常常不是突破一層防線，而是把自己改寫成「整個系統看起來都覺得合理」的形式。

PoisonedSkills：把攻擊規模化，不是手工 demo

作者不是只做幾個漂亮案例，而是提出一個完整的生成框架 PoisonedSkills，用來大規模生產 adversarial skills。這點很重要，因為如果攻擊只能靠高手手刻，那風險規模還有限；但如果可以用 LLM pipeline 自動化生成，就完全是另一個量級。

這個 pipeline 大致分兩步：

• Stage 1 – Seed Expansion：從初始 seed skills 出發，替換 payload 與情境，快速擴充樣本池。
• Stage 2 – Camouflage Mutation：加入各種偽裝與混淆策略，讓 payload 看起來更合理、更像真實工程資產。

他們最後從 81 個 seed 擴展成 1,070 個 adversarial skills，涵蓋 15 個 MITRE ATT&CK 類別。這些類別不只包括偷資料，也包括：

• reverse shell / RCE
• container escape
• supply-chain poisoning
• malicious config write
• credential theft
• HTTP / webhook exfiltration
• persistence implant
• IaC attack

換句話說，這不是在看單一 payload，而是在看 skill 生態系是否已經能被系統化地武器化。

實驗怎麼做？

這篇的 evaluation 設計算是相當有現實感。作者測了四個主流 coding-agent framework：

• Claude Code
• OpenHands
• Codex
• Gemini CLI

底下對應五個模型配置：

• Claude Sonnet 4.6
• GLM-4.7
• MiniMax-M2.5
• GPT-5.4
• Gemini 2.5 Pro

這裡我特別認同作者的一點：他們不是只找一個明顯很脆弱的環境做 showcase，而是刻意把 高對齊模型、不同架構防線、容器沙箱、雲端安全過濾 放進同一張實驗矩陣。這讓結果比較有說服力。

他們也拿傳統的明示型 instruction injection 當 baseline。結果很值得記：在強防禦配置下，explicit instruction injection 成功率是 0%；但 DDIPE 仍然能在不同組合上打出 11.6% 到 33.5% 的 bypass rate。

這說明的不是「現有 guardrail 完全沒用」，而是守得住直球，不代表守得住偽裝成技術文件的變化球。

最值得記住的數字

這篇 paper 有幾個數字很值得直接記下來：

• 從 81 個種子 自動擴展出 1,070 個 adversarial skills
• 覆蓋 15 個 MITRE ATT&CK 類別
• 在不同 framework / model 組合上，DDIPE bypass rate 為 11.6%–33.5%
• 相較之下，explicit instruction injection 在最佳防禦設定下是 0%
• 90.7% 攻擊可被 static analysis 攔下，但仍有 2.5% 同時躲過 static analysis 與 alignment
• Responsible disclosure 最後帶來 4 個確認漏洞與 2 個修補

我尤其在意那個 2.5%。有人可能會覺得比例不大，但在這類高權限 agent 場景裡，只要存在一小部分 payload 能長驅直入，就已經不是學術上的「殘餘風險」，而是營運上必須正視的 breach path。

這篇和 Skill-Inject、ShieldNet、SkillProbe 的差別在哪？

如果你最近一路有跟 sectools.tw 這串 agent skill / supply-chain 文章，會很容易問：這篇和前面幾篇到底差在哪？

我會這樣看：

• Secure Agent Skills / SkillInject 比較像是在談 skill lifecycle、skill file 注入、context-aware authorization 與 benchmark 化。
• ShieldNet 強調的是 runtime network visibility，提醒你不要只看 agent 說了什麼，而要看它實際在網路上做了什麼。
• SkillProbe 把焦點往 marketplace 稽核前移，談上架前的 admission filtering、semantic-behavioral inconsistency 與 inter-skill combinatorial risks。
• 這篇 PoisonedSkills 則補上最核心的一塊：文件內的 code example / config template 本身，如何從「知識載體」變成「執行期 payload 載體」。

也就是說，這篇不是在重複「skill 生態有風險」這個結論，而是在把風險具體化成一條非常清楚的 exploitation path：

被污染的 skill 文件 → 被 agent 視為可信參考 → 被複製進生成內容 → 被工具鏈執行 → 變成主機上的真實副作用

這條鏈一旦成立，agent 安全就不再只是 prompt 安全，而是徹底變成 software supply chain security + execution governance 問題。

我怎麼看這篇論文？

我對這篇的整體評價是：它不像某些 paper 只是在替一個既有風險換新名字，而是真的把 agent skill 供應鏈的危險點往下鑽到 execution layer。

我特別認同它的三個地方：

• 它把 skill 文件當成 operational directive，而不是普通說明文件。 這個 framing 很準。
• 它把 defense 分成 alignment 與 architecture 兩層。 這讓討論不會停在「模型有沒有變乖」這種太粗的層次。
• 它強調攻擊成功的關鍵不在顯性惡意，而在工程合理性。 這比傳統 prompt injection 論述更貼近真實世界。

但我也有幾個保留。

1. 它假設 retrieval 已經成功

作者明講這篇主要研究的是 post-loading phase。也就是 skill 已經進到 context 之後會發生什麼。這當然合理，但也代表整條端到端風險鏈還差一塊：在真實 skill marketplace 與本地 repo 裡，惡意 skill 到底多容易被實際取用？ 這篇沒有完全回答。

2. 2.5% 看似小，但評估上仍受 sample design 影響

成功繞過 static analysis 與 alignment 的 payload 比例不高，這讓人稍微安心；但同時也代表這種攻擊的真實成功率，可能會非常依賴：

• 文件撰寫風格
• agent 如何讀文件
• 框架是否允許先生成再執行
• 企業內部是否有額外 code review / approval gate

所以這篇不是在證明「所有 skill marketplace 都已經全面失守」，而是在證明：只要系統設計仍把 skill 文件當可信範例來源，這條 exploit path 就是真實存在的。

3. 防守面最大的挑戰，仍然是 developer experience

從安全角度看，最乾脆的答案當然是不要信任第三方 skill 文件；但從產品角度看，skill 生態之所以會長起來，就是因為大家想快速重用。真正困難的是：你要怎麼在不毀掉 agent 可用性的前提下，替 skill 文件建立內容完整性、執行授權與可觀測性？

這也是我認為這篇 paper 真正把問題推到檯面上的地方。它讓你沒辦法再用一句「加強 prompt guardrail」敷衍過去。

對實務界的啟示

如果你正在用 coding agent、導入內部 skill marketplace、或打算讓 agent 幫你處理部署 / automation / IaC，這篇有幾個很直接的提醒：

• 不要把 skill 文件當成純文字說明。 它本質上是高權限系統的行為塑形材料。
• 文件中的 code example 與 config template 也要進安全審查。 不只是 script / binary 才需要掃。
• 把 generated code 與 generated config 視為 supply-chain artifact。 它們不該因為是 agent 產生的就自動被信任。
• runtime monitoring 很重要。 真正該盯的是 file write、shell、network、package source、deployment diff，而不只是 prompt text。
• approval 機制要更細。 不只是問「要不要用這個 skill」，而是問「這個 skill 讓 agent 最後要對系統做什麼」。
• skill marketplace 應該把 admission filtering 與 semantic-behavioral consistency check 變成基礎設施。

總結

Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems 最重要的貢獻，不是在告訴你 agent skill 有風險——這件事大家大概都已經知道了——而是在更精確地指出：

當 coding agent 會把 skill 文件裡的範例與模板當成可信實作時，文件本身就不再只是知識來源，而是能夠跨過 alignment、滲入 execution pipeline、最後落到主機 action space 的供應鏈入口。

這個結論很硬，也很現實。它意味著未來 agent 安全的關鍵，不只在模型本身，而在於你如何定義 skill 的信任邊界、如何驗文件、如何管執行、如何看 runtime 副作用。如果這四件事沒有一起補，skill 生態做得越成功，攻擊面也只會長得越快。

如果把它放進最近 sectools.tw 那串文章脈絡，這篇剛好像是一枚釘子，把前面的 skill supply chain、runtime guardrail、marketplace auditing、tool-level observation 全部釘到同一個更底層的判斷上：在 agent 時代，真正需要被治理的，不只是模型收到什麼提示，而是整條會把文件轉成行動的執行鏈。

免責聲明

本文由 AI 產生、整理與撰寫。 內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。