維克森林大學的兩項研究，指向 AI 生態系中一個容易被低估的共通弱點：憑證經常被放在代理程式、應用程式，甚至攻擊者可以取得的位置。

其中一項研究檢視 17,022 個第三方 AI 代理技能，發現 520 個受影響技能，合計涉及 1,708 項安全問題；另一項針對 444 款具備大型語言模型（LLM）功能的 iOS 應用程式進行的研究，則發現 282 款在測試期間暴露了憑證或後端存取機制。124

風險不只是「一段金鑰被看見」這麼簡單。外洩的 API 金鑰或權杖，可能讓攻擊者存取私人資料、呼叫代理技能具備的權限，或使用開發者帳戶支付大型語言模型的推論費用。

代理技能研究發現了什麼？

研究人員從 SkillsMP 上 170,226 個項目中，分層隨機抽取 17,022 個技能進行分析。方法包括靜態機密資訊偵測、使用模擬憑證的動態沙箱測試，以及比對技能宣稱的用途與實際執行行為。34

研究結果包括：

• 520 個受影響技能共包含 1,708 項安全問題，分布在 10 種憑證外洩模式中。416
• 520 個受影響技能中有 466 個暴露了不需要提升權限即可使用的憑證，研究據此報告 89.6% 的立即可利用率。14
• 76.3% 的外洩案例必須同時檢查技能的自然語言指示與程式碼，才能辨識完整風險。
• 3.1% 的案例涉及沒有可執行程式碼、純粹透過自然語言提示注入造成的問題。4

這代表只做傳統的程式碼審查，可能不足以發現關鍵風險。一個技能可以描述看似合理的任務，但它的指示文字或配套腳本，可能在執行過程中把秘密資料暴露出去。

除錯輸出可能讓機密變成模型看得懂的資料

除錯記錄是研究中特別值得注意的外洩模式。在某些代理框架中，標準輸出會被送入模型的上下文；因此，透過 print 或 console.log 印出的憑證，可能在使用者提出一般自然語言請求時，就變成模型可以取得的內容。研究摘要指出，除錯記錄是主要外洩向量，並將 73.5% 的外洩歸因於輸出內容暴露給 LLM。4

風險也不限於明文寫死的 API 金鑰。憑證可能透過腳本、環境變數處理、日誌、提示指示，或程式碼與自然語言的組合而外洩；有些問題甚至只有在技能正常執行時才會顯現。

惡意與疏忽都可能造成外洩

研究將憑證外洩的原因概括為兩大類：

• 惡意開發： 技能刻意加入收集憑證或私人資料的指示與負載，並可能將資料傳送至遠端伺服器。
• 疏忽開發： 開發者未遵循安全實務，無意間留下可供攻擊者利用的憑證或存取路徑。1

兩者需要不同的處理方式。惡意內容必須先被篩選、下架；意外暴露則需要改善機密管理、降低日誌風險、強化驗證與授權，並在發布前完成測試。

在研究人員通知 SkillsMP 後，維克森林大學表示，所有已辨識的惡意技能都已移除，大多數有漏洞的技能也已修正。不過，研究同時警告，清理原始儲存庫未必足夠：分叉版本可能在原始專案修復後，仍保留已外洩的憑證。14

iOS 研究揭露另一條 LLM 帳戶劫持路徑

另一項研究分析 444 款具備 LLM 功能的 iOS 應用程式，發現 282 款、約 64%，在網路流量中暴露了可利用的 LLM 憑證或後端存取機制。25

研究列出的主要暴露模式包括：

• 可重放的 JWT 權杖：48%
• 未經驗證的後端代理：33%
• 以明文傳送 API 金鑰：19%3

這些弱點可能在應用程式的一般使用過程中就能被觀察到。攻擊者只要攔截金鑰、重複使用權杖，或找到開放式代理，就可能透過開發者的 LLM 帳戶發送請求，消耗付費推論額度、濫用相關雲端資源，或產生未經授權的使用費。25

現有證據支持嚴重、甚至可能沒有明確上限的計費風險，實際程度則取決於帳戶限制與入侵持續時間。不過，資料並未獨立證實「損失數十萬美元」這類具體金額；較準確的說法是，外洩憑證可能讓攻擊者持續產生由開發者承擔的 LLM 費用。

修復速度同樣令人關注。負責任揭露後三個月，只有 28% 的受影響 iOS 應用程式修正了通報漏洞；在研究追蹤中，仍有 72% 可以被利用。311

AI 輔助開發讓攻擊面進一步擴大

兩項研究合併來看，替應用程式加入 AI 功能，或安裝可重複使用的代理技能，不只是功能升級，也會擴大攻擊面。新增風險包括：

• 將供應商金鑰嵌入用戶端應用程式，或暴露在代理的上下文中
• 讓具備檔案、服務或私人資料存取權的工具被濫用
• 使日誌意外成為模型可以讀取的上下文
• 讓後端端點在驗證不足的情況下接受請求
• 使用可被攻擊者重放的權杖
• 讓攻擊者以開發者帳戶製造 LLM 使用費

隨著開發者透過 AI 輔助的「氛圍式編程」（vibe coding）快速生成與整合軟體，這些問題可能更容易被複製。速度不能取代威脅建模；驗證、機密處理、授權、日誌與相依套件審查，仍需要有意識的工程設計。

代理技能研究也指出，72% 的硬編碼憑證案例呈現 AI 輔助開發的特徵。這不等於每個案例都能被證明是由 AI 產生，但顯示不安全模式可能透過生成式或快速拼裝的程式碼大規模擴散。4

研究指向的安全設計基本功

對開發 AI 產品或發布代理技能的團隊而言，研究結果支持以下防禦基準：

1. 不要把長期有效的供應商金鑰放在用戶端裝置或模型上下文中。 敏感的模型請求應改由經過驗證的伺服器轉送。
2. 使用短期、用途受限的憑證。 落實最小權限，並驗證權杖內容，不要把「持有權杖」視為唯一授權依據。
3. 從日誌與標準輸出中遮蔽機密。 任何送入代理上下文的內容，都應視為模型或使用者可能重新取得的資料。
4. 同時掃描程式碼、設定、提示與相依套件中的機密資訊。 代理技能研究顯示，自然語言指示與可執行程式碼需要合併審查。
5. 測試網路流量與後端授權。 確認請求被攔截後無法重放，也無法透過未經驗證的代理轉送。
6. 輪替已暴露的憑證，並檢查分叉與複製版本。 從原始儲存庫刪除秘密，不代表所有已發布版本都已清理。
7. 在發布前加入平台層級審查。 市集篩選、開發者指引、負責任揭露與自動化檢查，可以補足個別開發者的安全意識。34

核心訊息很直接：AI 安全不能等產品上線後才補救。從一開始，憑證、代理權限、模型上下文與計費控制，就應被視為產品安全的核心部分。

維克森林大學的兩項研究，指向 AI 生態系中一個容易被低估的共通弱點：憑證經常被放在代理程式、應用程式，甚至攻擊者可以取得的位置。

其中一項研究檢視 17,022 個第三方 AI 代理技能，發現 520 個受影響技能，合計涉及 1,708 項安全問題；另一項針對 444 款具備大型語言模型（LLM）功能的 iOS 應用程式進行的研究，則發現 282 款在測試期間暴露了憑證或後端存取機制。124

風險不只是「一段金鑰被看見」這麼簡單。外洩的 API 金鑰或權杖，可能讓攻擊者存取私人資料、呼叫代理技能具備的權限，或使用開發者帳戶支付大型語言模型的推論費用。

代理技能研究發現了什麼？

研究人員從 SkillsMP 上 170,226 個項目中，分層隨機抽取 17,022 個技能進行分析。方法包括靜態機密資訊偵測、使用模擬憑證的動態沙箱測試，以及比對技能宣稱的用途與實際執行行為。34

研究結果包括：

• 520 個受影響技能共包含 1,708 項安全問題，分布在 10 種憑證外洩模式中。416
• 520 個受影響技能中有 466 個暴露了不需要提升權限即可使用的憑證，研究據此報告 89.6% 的立即可利用率。14
• 76.3% 的外洩案例必須同時檢查技能的自然語言指示與程式碼，才能辨識完整風險。
• 3.1% 的案例涉及沒有可執行程式碼、純粹透過自然語言提示注入造成的問題。4

這代表只做傳統的程式碼審查，可能不足以發現關鍵風險。一個技能可以描述看似合理的任務，但它的指示文字或配套腳本，可能在執行過程中把秘密資料暴露出去。

除錯輸出可能讓機密變成模型看得懂的資料

除錯記錄是研究中特別值得注意的外洩模式。在某些代理框架中，標準輸出會被送入模型的上下文；因此，透過 print 或 console.log 印出的憑證，可能在使用者提出一般自然語言請求時，就變成模型可以取得的內容。研究摘要指出，除錯記錄是主要外洩向量，並將 73.5% 的外洩歸因於輸出內容暴露給 LLM。4

風險也不限於明文寫死的 API 金鑰。憑證可能透過腳本、環境變數處理、日誌、提示指示，或程式碼與自然語言的組合而外洩；有些問題甚至只有在技能正常執行時才會顯現。

惡意與疏忽都可能造成外洩

研究將憑證外洩的原因概括為兩大類：

• 惡意開發： 技能刻意加入收集憑證或私人資料的指示與負載，並可能將資料傳送至遠端伺服器。
• 疏忽開發： 開發者未遵循安全實務，無意間留下可供攻擊者利用的憑證或存取路徑。1

兩者需要不同的處理方式。惡意內容必須先被篩選、下架；意外暴露則需要改善機密管理、降低日誌風險、強化驗證與授權，並在發布前完成測試。

在研究人員通知 SkillsMP 後，維克森林大學表示，所有已辨識的惡意技能都已移除，大多數有漏洞的技能也已修正。不過，研究同時警告，清理原始儲存庫未必足夠：分叉版本可能在原始專案修復後，仍保留已外洩的憑證。14

iOS 研究揭露另一條 LLM 帳戶劫持路徑

另一項研究分析 444 款具備 LLM 功能的 iOS 應用程式，發現 282 款、約 64%，在網路流量中暴露了可利用的 LLM 憑證或後端存取機制。25

研究列出的主要暴露模式包括：

• 可重放的 JWT 權杖：48%
• 未經驗證的後端代理：33%
• 以明文傳送 API 金鑰：19%3

這些弱點可能在應用程式的一般使用過程中就能被觀察到。攻擊者只要攔截金鑰、重複使用權杖，或找到開放式代理，就可能透過開發者的 LLM 帳戶發送請求，消耗付費推論額度、濫用相關雲端資源，或產生未經授權的使用費。25

現有證據支持嚴重、甚至可能沒有明確上限的計費風險，實際程度則取決於帳戶限制與入侵持續時間。不過，資料並未獨立證實「損失數十萬美元」這類具體金額；較準確的說法是，外洩憑證可能讓攻擊者持續產生由開發者承擔的 LLM 費用。

修復速度同樣令人關注。負責任揭露後三個月，只有 28% 的受影響 iOS 應用程式修正了通報漏洞；在研究追蹤中，仍有 72% 可以被利用。311

AI 輔助開發讓攻擊面進一步擴大

兩項研究合併來看，替應用程式加入 AI 功能，或安裝可重複使用的代理技能，不只是功能升級，也會擴大攻擊面。新增風險包括：

• 將供應商金鑰嵌入用戶端應用程式，或暴露在代理的上下文中
• 讓具備檔案、服務或私人資料存取權的工具被濫用
• 使日誌意外成為模型可以讀取的上下文
• 讓後端端點在驗證不足的情況下接受請求
• 使用可被攻擊者重放的權杖
• 讓攻擊者以開發者帳戶製造 LLM 使用費

隨著開發者透過 AI 輔助的「氛圍式編程」（vibe coding）快速生成與整合軟體，這些問題可能更容易被複製。速度不能取代威脅建模；驗證、機密處理、授權、日誌與相依套件審查，仍需要有意識的工程設計。

代理技能研究也指出，72% 的硬編碼憑證案例呈現 AI 輔助開發的特徵。這不等於每個案例都能被證明是由 AI 產生，但顯示不安全模式可能透過生成式或快速拼裝的程式碼大規模擴散。4

研究指向的安全設計基本功

對開發 AI 產品或發布代理技能的團隊而言，研究結果支持以下防禦基準：

1. 不要把長期有效的供應商金鑰放在用戶端裝置或模型上下文中。 敏感的模型請求應改由經過驗證的伺服器轉送。
2. 使用短期、用途受限的憑證。 落實最小權限，並驗證權杖內容，不要把「持有權杖」視為唯一授權依據。
3. 從日誌與標準輸出中遮蔽機密。 任何送入代理上下文的內容，都應視為模型或使用者可能重新取得的資料。
4. 同時掃描程式碼、設定、提示與相依套件中的機密資訊。 代理技能研究顯示，自然語言指示與可執行程式碼需要合併審查。
5. 測試網路流量與後端授權。 確認請求被攔截後無法重放，也無法透過未經驗證的代理轉送。
6. 輪替已暴露的憑證，並檢查分叉與複製版本。 從原始儲存庫刪除秘密，不代表所有已發布版本都已清理。
7. 在發布前加入平台層級審查。 市集篩選、開發者指引、負責任揭露與自動化檢查，可以補足個別開發者的安全意識。34

核心訊息很直接：AI 安全不能等產品上線後才補救。從一開始，憑證、代理權限、模型上下文與計費控制，就應被視為產品安全的核心部分。