Wake Forest大學的研究，揭示兩個快速發展中的AI生態系統有一個共通弱點：憑證往往被放在Agent、App，甚至攻擊者可以取得的位置。

其中一項研究分析了17,022個第三方Agent技能，發現520個受影響技能，共涉及1,708宗安全問題。另一項針對444個配備大型語言模型（LLM）的iOS App進行的研究，則發現282個App在測試期間暴露憑證或後端存取機制。124

實際風險並不只是「一段字串外洩」咁簡單。一條API key或一個Token，可能讓攻擊者存取私人資料、使用Agent的高權限功能，或者用開發者帳戶支付模型推理費用。

Agent技能研究發現甚麼？

研究人員從SkillsMP的170,226個項目中，抽樣選出17,022個技能進行分析。他們結合靜態秘密偵測、使用模擬憑證的動態沙盒測試，以及比對技能聲稱的用途與實際執行行為。34

研究結果包括：

• 520個受影響技能共包含1,708宗安全問題，涵蓋10種憑證外洩模式。416
• 在520個受影響技能中，466個暴露了毋須提升權限便可使用的憑證，研究報告所指的即時可利用率為89.6%。14
• 76.3%的外洩個案需要同時檢查技能的自然語言指令及程式碼，才可以辨認問題。
• 另有3.1%的個案涉及沒有可執行程式碼、純粹透過自然語言提示注入造成的風險。4

換句話說，只做傳統的「睇程式碼」安全審查，未必足夠。一個技能表面上可能只是在處理正常工作，但它的指令或配套腳本，仍可能在執行期間將秘密暴露出來。

除錯輸出可令秘密變成模型讀得出的資料

除錯日誌是研究中一個相當重要的外洩模式。在某些Agent框架裏，標準輸出會被送入模型的上下文。換言之，如果程式用print或console.log列印憑證，使用者只要提出一般自然語言要求，模型可能就可以接觸到這些內容。

研究摘要指出，除錯日誌是主要外洩途徑；其中73.5%的外洩，與標準輸出暴露予LLM有關。4

風險亦不只限於明文寫死的API key。憑證可以透過腳本、環境變數處理方式、日誌、提示指令，或者程式碼與自然語言的組合而外洩；有些問題甚至要等到技能正常運行時才會出現。

惡意開發與疏忽開發都會造成問題

研究將憑證外洩的成因大致分成兩類：

• 惡意開發： 開發者刻意在技能中加入收集憑證或私人資料的指令、負載，並可能將資料傳送到遠端伺服器。
• 疏忽開發： 開發者沒有遵守安全編程做法，無意中留下可供攻擊者利用的憑證或存取途徑。1

兩者的處理方法並不一樣。惡意內容需要被篩走及移除；意外暴露則要靠更好的秘密管理、安全日誌、身份驗證、權限控制，以及發布前測試去改善。

Wake Forest表示，在研究人員通知SkillsMP後，所有已識別的惡意技能均已被移除，大部分有漏洞的技能亦已修正。不過，研究同時提醒，清理原始儲存庫未必足夠：如果有人已經Fork或複製該技能，副本可能仍然保留外洩的憑證。14

iOS研究揭示另一條LLM帳戶被劫用的路徑

另一項相關研究分析了444個具備LLM功能的iOS App，發現其中282個、約64%，在網絡流量中暴露了可被利用的LLM憑證或後端存取機制。25

研究記錄的主要暴露模式包括：

• 可重放的JWT Token： 48%
• 沒有身份驗證的後端Proxy： 33%
• 以明文傳送API key： 19%3

這些弱點在正常使用App時已可能被觀察到。攻擊者如果截取API key、重用Token，或者找到一個開放Proxy，便可能透過開發者的LLM帳戶發出請求。後果包括消耗已付費的模型推理額度、濫用相關雲端資源，甚至為開發者製造未經授權的費用。25

現有證據支持嚴重、甚至可能沒有明確上限的帳單風險，實際程度則取決於帳戶限制，以及入侵持續了多久。不過，研究本身沒有獨立證實「損失數十萬美元」這類具體金額；較準確的說法是，外洩憑證可能讓攻擊者持續產生可收費的LLM用量，直至帳戶限制或其他防禦措施生效。

修補速度亦不理想。在負責任披露後三個月，只有28%的受影響iOS App修正了所報告的漏洞，研究後續測試顯示仍有72%可以被利用。311

為甚麼AI輔助開發令問題更值得關注？

兩項研究一同說明，為App加入AI功能，或者安裝可重用的Agent技能，都會擴大應用程式的攻擊面。新增風險包括：

• 將供應商API key嵌入客戶端App，或暴露在Agent上下文內
• 讓具權限的工具接觸檔案、服務或私人資料
• 令日誌意外成為模型可以讀取的上下文
• 後端端點缺乏足夠身份驗證
• 讓攻擊者重放Token
• 由攻擊者在開發者帳戶上製造LLM使用費用

隨着開發者愈來愈常用AI輔助的「vibe coding」快速產生及組合軟件，這個問題更加突出。開發速度不能取代威脅建模；身份驗證、秘密處理、授權、日誌管理及依賴項審查，仍然需要有意識地設計。

Agent技能研究亦發現，72%的硬編碼憑證個案帶有AI輔助開發的痕跡，反映由生成程式碼或快速拼裝而來的不安全模式，可能在更大規模下擴散。4

研究所指向的安全設計做法

對於開發AI產品或發布Agent技能的團隊，研究結果支持以下基本做法：

1. 不要將長期有效的供應商金鑰放在客戶端裝置或模型上下文。 敏感的模型請求應改由具身份驗證的伺服器轉發。
2. 使用短期、權限範圍有限的憑證。 遵守最小權限原則，並驗證Token，不能只因為對方持有Token便視為已獲授權。
3. 在日誌及標準輸出中遮蔽秘密。 任何送入Agent上下文的內容，都應假設模型或使用者有機會讀取。
4. 同時掃描程式碼、設定、提示指令及依賴項。 Agent技能研究顯示，自然語言指令與可執行程式碼需要一併審查。
5. 測試網絡流量及後端授權。 確認被截取的請求不能被重放，也不能經由沒有身份驗證的Proxy轉發。
6. 輪換已外洩的憑證，並檢查Fork及副本。 從原始儲存庫刪除秘密，不代表所有已發布版本都已清理乾淨。
7. 在發布前加入平台級審查。 市集審查、開發者指引、負責任披露及自動化檢查，可以與開發者自身的安全意識互相補足。34

核心教訓其實很直接：AI安全不能等到產品推出後才「補鑊」。憑證、Agent權限、模型上下文及帳單控制，都應該由產品設計一開始便視為核心的產品安全問題。

Wake Forest大學的研究，揭示兩個快速發展中的AI生態系統有一個共通弱點：憑證往往被放在Agent、App，甚至攻擊者可以取得的位置。

其中一項研究分析了17,022個第三方Agent技能，發現520個受影響技能，共涉及1,708宗安全問題。另一項針對444個配備大型語言模型（LLM）的iOS App進行的研究，則發現282個App在測試期間暴露憑證或後端存取機制。124

實際風險並不只是「一段字串外洩」咁簡單。一條API key或一個Token，可能讓攻擊者存取私人資料、使用Agent的高權限功能，或者用開發者帳戶支付模型推理費用。

Agent技能研究發現甚麼？

研究人員從SkillsMP的170,226個項目中，抽樣選出17,022個技能進行分析。他們結合靜態秘密偵測、使用模擬憑證的動態沙盒測試，以及比對技能聲稱的用途與實際執行行為。34

研究結果包括：

• 520個受影響技能共包含1,708宗安全問題，涵蓋10種憑證外洩模式。416
• 在520個受影響技能中，466個暴露了毋須提升權限便可使用的憑證，研究報告所指的即時可利用率為89.6%。14
• 76.3%的外洩個案需要同時檢查技能的自然語言指令及程式碼，才可以辨認問題。
• 另有3.1%的個案涉及沒有可執行程式碼、純粹透過自然語言提示注入造成的風險。4

換句話說，只做傳統的「睇程式碼」安全審查，未必足夠。一個技能表面上可能只是在處理正常工作，但它的指令或配套腳本，仍可能在執行期間將秘密暴露出來。

除錯輸出可令秘密變成模型讀得出的資料

除錯日誌是研究中一個相當重要的外洩模式。在某些Agent框架裏，標準輸出會被送入模型的上下文。換言之，如果程式用print或console.log列印憑證，使用者只要提出一般自然語言要求，模型可能就可以接觸到這些內容。

研究摘要指出，除錯日誌是主要外洩途徑；其中73.5%的外洩，與標準輸出暴露予LLM有關。4

風險亦不只限於明文寫死的API key。憑證可以透過腳本、環境變數處理方式、日誌、提示指令，或者程式碼與自然語言的組合而外洩；有些問題甚至要等到技能正常運行時才會出現。

惡意開發與疏忽開發都會造成問題

研究將憑證外洩的成因大致分成兩類：

• 惡意開發： 開發者刻意在技能中加入收集憑證或私人資料的指令、負載，並可能將資料傳送到遠端伺服器。
• 疏忽開發： 開發者沒有遵守安全編程做法，無意中留下可供攻擊者利用的憑證或存取途徑。1

兩者的處理方法並不一樣。惡意內容需要被篩走及移除；意外暴露則要靠更好的秘密管理、安全日誌、身份驗證、權限控制，以及發布前測試去改善。

Wake Forest表示，在研究人員通知SkillsMP後，所有已識別的惡意技能均已被移除，大部分有漏洞的技能亦已修正。不過，研究同時提醒，清理原始儲存庫未必足夠：如果有人已經Fork或複製該技能，副本可能仍然保留外洩的憑證。14

iOS研究揭示另一條LLM帳戶被劫用的路徑

另一項相關研究分析了444個具備LLM功能的iOS App，發現其中282個、約64%，在網絡流量中暴露了可被利用的LLM憑證或後端存取機制。25

研究記錄的主要暴露模式包括：

• 可重放的JWT Token： 48%
• 沒有身份驗證的後端Proxy： 33%
• 以明文傳送API key： 19%3

這些弱點在正常使用App時已可能被觀察到。攻擊者如果截取API key、重用Token，或者找到一個開放Proxy，便可能透過開發者的LLM帳戶發出請求。後果包括消耗已付費的模型推理額度、濫用相關雲端資源，甚至為開發者製造未經授權的費用。25

現有證據支持嚴重、甚至可能沒有明確上限的帳單風險，實際程度則取決於帳戶限制，以及入侵持續了多久。不過，研究本身沒有獨立證實「損失數十萬美元」這類具體金額；較準確的說法是，外洩憑證可能讓攻擊者持續產生可收費的LLM用量，直至帳戶限制或其他防禦措施生效。

修補速度亦不理想。在負責任披露後三個月，只有28%的受影響iOS App修正了所報告的漏洞，研究後續測試顯示仍有72%可以被利用。311

為甚麼AI輔助開發令問題更值得關注？

兩項研究一同說明，為App加入AI功能，或者安裝可重用的Agent技能，都會擴大應用程式的攻擊面。新增風險包括：

• 將供應商API key嵌入客戶端App，或暴露在Agent上下文內
• 讓具權限的工具接觸檔案、服務或私人資料
• 令日誌意外成為模型可以讀取的上下文
• 後端端點缺乏足夠身份驗證
• 讓攻擊者重放Token
• 由攻擊者在開發者帳戶上製造LLM使用費用

隨着開發者愈來愈常用AI輔助的「vibe coding」快速產生及組合軟件，這個問題更加突出。開發速度不能取代威脅建模；身份驗證、秘密處理、授權、日誌管理及依賴項審查，仍然需要有意識地設計。

Agent技能研究亦發現，72%的硬編碼憑證個案帶有AI輔助開發的痕跡，反映由生成程式碼或快速拼裝而來的不安全模式，可能在更大規模下擴散。4

研究所指向的安全設計做法

對於開發AI產品或發布Agent技能的團隊，研究結果支持以下基本做法：

1. 不要將長期有效的供應商金鑰放在客戶端裝置或模型上下文。 敏感的模型請求應改由具身份驗證的伺服器轉發。
2. 使用短期、權限範圍有限的憑證。 遵守最小權限原則，並驗證Token，不能只因為對方持有Token便視為已獲授權。
3. 在日誌及標準輸出中遮蔽秘密。 任何送入Agent上下文的內容，都應假設模型或使用者有機會讀取。
4. 同時掃描程式碼、設定、提示指令及依賴項。 Agent技能研究顯示，自然語言指令與可執行程式碼需要一併審查。
5. 測試網絡流量及後端授權。 確認被截取的請求不能被重放，也不能經由沒有身份驗證的Proxy轉發。
6. 輪換已外洩的憑證，並檢查Fork及副本。 從原始儲存庫刪除秘密，不代表所有已發布版本都已清理乾淨。
7. 在發布前加入平台級審查。 市集審查、開發者指引、負責任披露及自動化檢查，可以與開發者自身的安全意識互相補足。34

核心教訓其實很直接：AI安全不能等到產品推出後才「補鑊」。憑證、Agent權限、模型上下文及帳單控制，都應該由產品設計一開始便視為核心的產品安全問題。