論文閱讀分析｜Credential Leakage in LLM Agent Skills：當第三方 Agent Skill 成為憑證外洩的新供應鏈入口
論文基本資訊
- 論文標題：Credential Leakage in LLM Agent Skills: A Large-Scale Empirical Study
- 年份：2026
- 作者：Yi Liu 等
- 來源：arXiv:2604.03070
- 論文連結：https://arxiv.org/abs/2604.03070
- DOI：10.48550/arXiv.2604.03070
- 主題：Agentic Security、LLM Agent、Agent Skills、Credential Leakage、Supply Chain Security、Prompt Injection
如果說最近這波資安 AI 論文有一條很清楚的主線，那就是大家已經不再只問「模型會不會回答問題」，而是開始追問：當模型真的被接上工具、接上工作流、接上權限、接上本地環境之後，風險會從哪裡長出來？
這篇 Credential Leakage in LLM Agent Skills 很值得寫，正是因為它不是再做一次泛泛的 prompt injection 檢討，也不是單純重述「agent 有供應鏈風險」這種已經快變成常識的結論。它真正做的，是把視角壓到一個更具體、也更危險的地方：第三方 agent skills 到底會如何讓憑證外洩，而且這些外洩是怎麼在自然語言、程式碼、stdout、prompt 與本地執行權限之間串起來的。
對 sectools.tw 這條近期一路從 CTI、SOC、benchmark、IR agent 走過來的主線來說，這篇 paper 的位置很剛好。因為它不是在補一個新的 analyst workflow，也不是又多一個安全 benchmark，而是在更底層的地方提醒我們：當你把 agent capability 做大之前，你最好先搞清楚 agent skill 這個生態本身是不是已經變成新的 credential sink。
這篇論文想解決什麼？
作者關注的問題很直接：第三方 skills 讓 LLM agent 可以調 API、連資料庫、呼叫雲端服務、讀本地設定檔、操作 shell 或其他外部工具。這些能力很有用，但也代表技能模組常常會碰到：
- API keys
- OAuth tokens
- 資料庫連線字串
- SSH / TLS 私鑰
- session / bearer tokens
- webhook secrets
- 加密金鑰與錢包私鑰
問題是，過去不少研究已經指出 agent skills 有廣泛漏洞與惡意技能，但對「憑證到底如何外洩」這件事，還缺少大規模、系統化、可分類的實證分析。也就是說，大家知道技能模組危險，卻還不知道危險的主要路徑究竟長什麼樣子。
這篇論文的核心問題可以濃縮成一句話：
當 agent skill 同時結合自然語言描述、可執行程式碼、工具呼叫與本地執行權限時，憑證會透過哪些模式外洩？而這些外洩，到底是單純的疏失，還是已經成為一種可規模化利用的攻擊面？
為什麼 agent skills 比傳統外掛或套件更麻煩？
這篇 paper 最重要的地方之一，是它沒有把 agent skills 當成「又一種 plugin」而已。作者認為，agent skill 的風險結構與傳統套件不同，因為它本質上是自然語言（NL）與程式語言（PL）的混合體。
一個 skill 通常至少有兩層：
- NL 層：例如 SKILL.md、workflow 說明、使用指示、prompt-like metadata
- PL 層：例如 Python、Shell、JavaScript 腳本與設定檔
在 agent runtime 裡，NL 會被送進模型的 context window，PL 會被本地環境執行。這就導致一個很特別的現象：秘密不一定是直接寫在程式裡才算外洩；只要它能透過描述、stdout、tool schema、reasoning trace 或 prompt manipulation 被模型讀到、轉述或帶出去，就已經形成外洩路徑。
這也是為什麼作者強調，credential leakage 在 agent skills 裡是跨模態問題。你只看 code，不夠；只看 prompt，也不夠。真正危險的往往是兩邊一起看時，才會發現描述裡埋了暗示、程式裡接了環境變數、再經由 stdout 回灌進 LLM 上下文，最後被自然語言問答重新吐出來。
研究怎麼做？規模其實不小
這篇論文不是拿幾十個 demo 做概念驗證，而是從 SkillsMP 這個大型開源 skill marketplace 下手。作者先抓到一個截至 2026 年 2 月 12 日的完整快照，總母體有：
- 170,226 個 skills
考量動態驗證成本，他們再用分層隨機抽樣，取出其中 17,022 個 skills 進行深入分析。這個樣本量已經超過論文宣稱在 99% 信心水準與 1% 誤差下的最低需求，因此不算隨便挑幾個案例來講故事。
研究方法分成四個主要階段：
- 資料收集：抓取 skill 的 source code 與自然語言描述
- 靜態過濾：用 regex、AST、關鍵字與語意分析找可疑憑證處理模式
- 動態驗證：在 sandbox 裡放 mock credentials，實際跑 skill，觀察網路 I/O 與輸出
- 人工分類：由研究者交叉比對 skill 意圖與執行行為，分成 benign、vulnerable、malicious
這種做法的價值在於：它沒有停在「字串長得像 secret」的靜態掃描，而是追到 runtime 行為與實際 exploitability。 對安全研究來說，這點非常關鍵。因為很多「看起來像秘密」的東西只是測試樣板，但很多真正會漏出去的問題，反而要在執行時才看得到。
這篇 paper 最核心的結果
作者從 17,022 個抽樣 skills 中，找出：
- 520 個受影響 skills
- 合計 1,708 個安全問題
- 其中約 84.0% 屬於開發者疏失
- 另外辨識出 83 個惡意 skills
如果只看比例，520 / 17,022 大概是 3.1%。乍看之下有人可能會覺得不算高，但我反而覺得這個數字很刺眼。因為這不是一般的低風險 UI bug，也不是只在特定條件下才成立的邊角錯誤；這裡談的是憑證外洩，而且發生在 agent 技能這種本來就可能接觸高權限資源的模組上。對這種問題來說，3.1% 其實很高。
更麻煩的是，作者指出：
- 76.3% 的案例需要同時分析自然語言與程式碼，單看任一模態都不夠
- 3.1% 的案例甚至純靠自然語言 prompt injection 就能成立，完全不需要額外惡意程式碼
- 89.6% 的受影響 skills 在實驗裡屬於可實際利用
- 其中 92.5% 可在一般執行流程中觸發，不需要額外提權
這幾個數字合在一起，其實已經講得很清楚：agent skill 的 credential leakage 不是少數奇葩案例，而是一個足夠普遍、足夠隱蔽、而且相當容易被利用的供應鏈問題。
第一個關鍵發現：這不是單純的 secret scanning 問題，而是跨模態問題
我認為這篇論文最重要的結論，就是它把這件事從「把程式碼裡的密鑰掃出來」提升成「必須做跨模態安全分析」的問題。
作者強調，多數外洩案例不會單獨躺在某一邊：
- 有些 skill 在描述裡會說要存取某個 service credential，但真正外洩發生在程式把它印到 stdout
- 有些 code 看起來只是一般工具封裝，但搭配 NL workflow 才知道開發者其實要求模型把 credential 回傳給使用者
- 有些描述本身就被設計成 prompt injection，誘導模型把執行過程中的秘密納入輸出
這點帶來一個很不舒服、但很現實的結論：傳統 AppSec 與傳統 prompt 安全各自做自己的，已經不夠了。 在 agent skill 時代，安全檢查若沒有同時理解 NL 與 PL 的互動，就很容易把真正的外洩路徑漏掉。
換句話說，這篇論文其實是在告訴我們：agentic security 不是把既有安全掃描工具搬過來再套一層 LLM，而是得重新定義風險單位。 風險單位不再只是 function、API call 或 prompt，而是「描述 + 腳本 + 執行環境 + 模型上下文」這整個組合。
第二個關鍵發現：debug logging 竟然成了主要外洩通道
如果只能記這篇 paper 一件事，我會選這個：debug logging 是主要外洩向量。
作者發現，所有漏洞問題裡，73.5% 與 print / console.log 這類 stdout 輸出有關。這個結果非常值得警惕，因為它背後反映的不是一個冷門錯誤，而是 agent runtime 的結構性問題。
在很多 agent 框架裡，stdout 並不只是留給開發者看的 log；它往往會被回送到模型 context，讓 LLM 知道工具執行結果。這意味著：
- 開發者以為只是 debug 的資訊
- 其實被當成模型的可讀上下文
- 接著可能再被模型整理、摘要、轉述、甚至直接吐給使用者
這就把傳統開發世界裡「不要把 secrets 打到 log」這條老規矩，升級成 agent 時代更嚴重的版本：你不是把秘密寫進 log 而已，你是在把秘密餵回會說話、會總結、還可能被誘導的模型。
這也是我覺得這篇 paper 很有價值的原因。它不是只告訴你「有漏洞」，而是精準指出一個很多團隊會低估的系統性設計缺口：stdout 在 agent framework 裡，已經不只是輸出介面，而是權限與資料外洩邊界的一部分。
第三個關鍵發現：惡意 skills 不只是藏秘密，而是會組合多種攻擊技巧
作者區分了開發者疏失與惡意構造兩種來源。前者佔多數，但後者更值得營運團隊注意，因為它顯示這個生態已經出現明確的攻擊者行為。
論文指出，在 83 個惡意 skills 中，有 37.3% 會組合多種攻擊技巧，例如：
- 用 Base64 或其他方式做防禦規避與混淆
- 搭配遠端連線或反向 shell
- 以 benign 的自然語言介面包裝惡意 payload
- 把多個目標疊在同一個 skill 裡，兼顧竊取與持久化
這裡最危險的不是單一技巧本身，而是 agent skill 架構的 NL / PL decoupling 會天然幫助攻擊者。也就是說，攻擊者可以：
- 在描述層看起來正常、友善、像個實用工具
- 在程式層偷偷做 credential harvesting、外傳或控制建立
這種「介面無害、內部多工攻擊」的模式，本來就很適合供應鏈濫用；放到 agent marketplace 裡，只會更危險。因為技能的分發與安裝，本身就帶有某種「這是社群可重用能力」的信任錯覺。
第四個關鍵發現：修掉上游，不代表秘密就消失了
這篇 paper 另一個很有現場感的地方，是它沒有把 remediation 想得太天真。作者發現，就算上游 repository 已經刪掉秘密或修補問題，fork-based distribution 仍會讓外洩持續存在。
論文給出的結果包括：
- 從 107 個上游 repo 刪掉的 credentials，仍殘留在 50+ 個獨立 forks
- 某個 C2 payload 曾擴散到 330 個檔案、70 個 repositories、15 種不同 skill 名稱之下
這代表一件事：agent skill 生態的秘密外洩，不是修個 PR 就能收尾的單點漏洞，而是會沿著 fork、再包裝、再分發、再上架的鏈條持續複製。
對企業或團隊來說，這個發現很重要。因為它意味著風險治理不能只做 upstream patch management，還得把：
- artifact lineage
- fork 追蹤
- marketplace 下架
- secret rotation
- 憑證再發行
一起當成完整事件回應的一部分。否則你只是把 repository 表面擦乾淨，但真正可用的金鑰仍在外面流動。
十種外洩模式，真正值得怎麼理解？
作者建立了一個 10 種 leakage patterns 的分類法，其中 4 種 來自開發疏失，6 種 來自惡意構造。就算不逐條背起來，這個 taxonomy 的價值也很大，因為它讓我們能把問題從「這 skill 看起來怪怪的」轉成更可操作的治理語言。
就實務上來看，這十種模式大致可以理解成幾個層次：
1. 直接寫死或明文暴露
像是把 API key、Base64 編碼 secret、連線字串、私鑰直接塞進 source code、設定檔或描述文字裡。這是最傳統、也最容易被理解的一種。
2. 透過輸出面洩漏
例如把 credential 印到 stdout、log、trace、debug output。這在 agent runtime 裡比傳統應用更危險，因為輸出可能直接進模型上下文。
3. 透過 schema、prompt 或描述把秘密帶進不該去的地方
這就是論文強調的跨模態複合問題：秘密不是直接露出，而是被自然語言規格、工具參數設計或執行邏輯帶到會被模型讀寫的路徑上。
4. 惡意外傳與持久化
這時 skill 已不只是寫壞，而是故意把秘密送走，甚至搭配混淆、遠端控制、fork 擴散等技巧提高存活率。
對我來說，這個 taxonomy 最重要的訊息是：agent skill 的 credential leakage 不是一種漏洞，而是一個漏洞家族。 如果組織治理還停在「掃描 hardcoded secret」這一層，基本上只處理了其中一小塊。
這篇論文對 agentic security 的真正意義
最近很多人談 agentic security，容易把焦點放在比較顯眼的議題上，例如 prompt injection、tool misuse、memory poisoning、autonomous exploit generation。這些都重要，但這篇 paper 讓我更在意另一件事：真正把 agent 送進生產環境時，最先爆的未必是最炫的能力，而可能是最 mundane 的 credential hygiene。
為什麼？因為 credentials 是 agent capability 變成真實權限的橋樑。沒有憑證，很多 agent 只是會說話；有了憑證，它才真的能：
- 調 API
- 存取 SaaS
- 讀雲端資源
- 連資料庫
- 操作工作流
- 跨系統移動
因此，一旦 skills 生態把憑證處理做爛，agentic system 的風險就不是回答錯幾題，而是把真正的存取權交給錯的人，或經由錯的路徑曝光出去。
這也是為什麼我會把這篇論文看成 agentic security 主線裡非常關鍵的一塊：它讓問題從抽象的「agent 可能有風險」變成很具體的「agent skills 正在變成新的 secret-handling attack surface」。
這對 SOC、平台團隊與企業導入有什麼啟示？
雖然這篇不是典型 SOC triage 或 CTI workflow 論文，但它對安全營運與平台治理的啟示非常直接。
1. Skill onboarding 必須視為供應鏈審查，不是功能安裝
安裝第三方 skill，不該被當成「多裝一個方便工具」，而應該視為把外部 artifact 接進高權限執行面。審查重點至少要包括 NL/PL 一致性、secret handling、stdout 行為、網路連線與權限需求。
2. Secret scanning 要升級成 cross-modal scanning
只掃 source code 已經不夠。SKILL.md、manifest、description、tool schema、prompt template 都要一起看，否則 76.3% 那類跨模態問題會直接漏掉。
3. stdout / tool output 應被視為資料外洩邊界
很多團隊會嚴格控管 API response 與 audit log，卻忽略 skill runtime 的輸出會再進 LLM。這在 agent 時代是一個很危險的盲點。必要時應對 stdout 做 secret redaction、context filtering 與最小化回傳。
4. 修補不等於結案，secret rotation 才是必要動作
如果 credential 曾被寫進 skill 或其 fork，真正的補救措施不只是刪碼，而是要旋轉金鑰、撤銷 token、追蹤分支、通知 marketplace 與評估下游擴散。
5. Marketplace 治理需要更主動
論文中披露後，所有惡意 skills 被移除，且 91.6% 的 hardcoded credential 案例已修復。這說明平台治理不是沒用，但也說明：如果沒有研究者主動揭露，這些東西原本就會繼續掛在生態裡。
這篇論文的限制
當然，這篇 paper 也不是沒有邊界。
1. 研究對象來自特定 marketplace
它分析的是 SkillsMP 生態，雖然規模已經很大，但不同平台、不同 skill packaging 規範、不同審核機制下，外洩比例不一定完全相同。
2. 抽樣後仍非全量動態驗證
17,022 已經很多，但畢竟不是對 170,226 全部做 runtime analysis。也就是說，真實生態裡的情況可能更好，也可能更糟。
3. 論文強調 credential leakage，不等於涵蓋全部 agent skill 風險
像 memory poisoning、lateral abuse、permission confusion、tool-chaining sabotage 等問題，仍需要其他研究補位。
不過我認為這些限制不會削弱論文主結論。因為它要證明的不是某個精準全域比例，而是：憑證外洩在 agent skill 生態裡已經形成一個足夠真實、可分類、可利用、可擴散的安全問題。
我怎麼看這篇論文？
如果前幾篇 agentic security 或 SOC agent 論文還在討論「該不該讓 agent 進來」，那這篇 paper 已經在回答更成熟的問題：既然 agent 一定會進來，我們到底要怎麼處理 skill 生態這個新的憑證暴露層？
我很喜歡這篇的地方，在於它沒有被 agent hype 帶著跑。它沒有說「未來代理人一定無所不能」，而是很踏實地盯著一個現場最容易流血的位置：秘密。
而且它提出的不是空泛恐嚇，而是非常具體的結論：
- 問題是跨模態的
- 主要外洩路徑是 stdout / debug logging
- 惡意 skills 已經存在，而且會組合攻擊技巧
- fork 生態會讓修補失去終局性
這些發現加起來，會把很多團隊從「我們之後再補 security」打回現實。因為對 agent platform 來說，credential hygiene 不是後期 hardening，而是系統設計的起點。
總結
Credential Leakage in LLM Agent Skills 之所以值得放進最近這波 sectools.tw 的論文脈絡，不是因為它又找到一些 skill 漏洞，而是因為它精準指出了 agentic ecosystem 裡一條很容易被忽略、但後果很重的主線：當 skills 成為能力載體時，它們也會成為 secrets 的搬運車，而 LLM runtime 會把傳統 log、prompt、description、tool output 全部串成新的外洩通路。
如果把這篇濃縮成一句話，我會這樣說：
這篇論文真正提醒我們的，不是「第三方 skill 可能有 bug」，而是「在 agent 時代，秘密外洩早已不是單一程式碼缺陷，而是一種跨越描述、執行與上下文邊界的系統性供應鏈風險」。
對正在做 agent platform、導入 AI workflow、建立安全 copilot、或評估 enterprise agent governance 的團隊來說，這篇 paper 很值得當成一個分水嶺：從今天開始，skill security 不該只被當成功能審查，而應被視為 credential security、runtime isolation 與供應鏈治理的交會點。
免責聲明
本文由 AI 產生、整理與撰寫
內容主要依據公開論文、arXiv 頁面與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。