銀行 AI 中的間接提示詞注入：Bunq 個案研究

間接提示詞注入允許攻擊者將受信任的銀行介面武器化

當大型語言模型 (LLM) 將不受信任的數據（例如交易描述）解釋為一組指令而非被動資訊時，就會發生間接提示詞注入。在對歐洲第二大數位銀行 Bunq 的安全性評估中，Blue41 展示了惡意行為者可以透過在交易參考欄位中包含精心設計的酬載 (payload)，發送一筆極小額的銀行轉帳（例如 €0.02）。當受害者要求銀行的 AI 助手摘要近期交易時，助手會檢索此酬載並執行它，從而可能直接在銀行自身的應用程式內發起極具可信度的魚叉式網路釣魚攻擊。

攻擊機制

此攻擊繞過了傳統的安全防護邊界，因為它不需要惡意軟體、不需要裝置存取權限，也不需要初始的社交工程。它利用了數據檢索與模型執行之間的信任邊界失效。

攻擊工作流程

  1. 酬載傳遞：攻擊者向目標發送一筆小額款項。交易描述包含了一個旨在劫持 LLM 行為的隱藏提示詞注入酬載。
  2. 使用者觸發：受害者使用常規查詢（例如「顯示我最近的交易」）與銀行 AI 助手進行互動。
  3. 上下文檢索：AI 助手獲取交易紀錄，包括攻擊者的轉帳，並將此文本輸入到 LLM 的上下文窗口中。
  4. 執行：LLM 處理注入的指令。在 Bunq 的演示中，助手被操縱來呈現一個虛假的重新驗證請求，看起來像是來自銀行的合法通知。

由於回應來自官方銀行 App，且可以引用真實的帳戶細節，因此這種釣魚嘗試比標準的電子郵件或簡訊更具可信度。

為何傳統防護措施會失效

標準的輸入過濾器和提示詞注入分類器對於間接注入通常是不夠的，因為惡意意圖在孤立的數據欄位中並不明顯。

雖然「越獄 (jailbreak)」嘗試可能會使用明顯的詞彙，例如「忽略所有先前的指令」，但複雜的間接注入是為了融入預期的數據格式而精心設計的。危險僅在數據與助手的特定系統提示詞以及使用者的查詢結合時才會顯現。因此，靜態文本分類無法可靠地區分合法的交易備註與潛在的指令酬載。

緩解 AI 代理風險的策略

確保金融服務中的 AI 助手安全需要的是分層深度防禦方法，而非單一過濾器。Blue41 建議四個主要的控制層級：

1. 上下文最小化

避免將不必要的數據欄位傳遞給 LLM。如果回答特定的使用者查詢不需要交易描述，則在數據到達模型之前就應將其從上下文中移除。

2. 數據與指令的明確分離

架構必須將檢索到的數據視為不受信任。這涉及使用技術來明確劃分數據與指令，確保模型理解檢索到的內容應該是被摘要或報告，而不是被執行。

3. 輸出與行動限制

應限制 AI 助手執行高影響力的行動——例如產生外部連結、要求憑證或啟動工作流程——而不經過獨立、非 AI 的驗證步驟，或不具備嚴格的目標目的地白名單。

4. 執行時行為監控

由於防止所有可能的酬載是極不現實的，安全團隊應監控異常行為。入侵指標包括：

  • 突然產生外部 URL。
  • 抑制通常出現在回應中的資訊。
  • 在工具或 API 調用中出現異常模式。
  • 偏離助手已建立的行為特徵。

社群觀點與技術評論

此漏洞的披露引發了技術觀察者之間關於在關鍵金融基礎設施中使用 AI 的必要性與安全性的重大辯論。

架構疑慮

一些批評者認為，使用 LLM 來顯示確定性數據（例如交易列表）本身就是一種架構缺陷。正如一位觀察者所指出的，顯示資料庫查詢結果不應涉及 LLM，因為這對於不需要機率性推理的任務來說引入了不必要的風險。

與經典漏洞的比較

業界評論員將間接提示詞注入與 SQL 注入的回歸進行了比較。正如 SQL 注入發生在使用者輸入被視為程式碼時，提示詞注入發生在檢索到的數據被視為指令時。

實用性與風險評估

一些懷疑論者質疑其實際影響，指出使用者必須從陌生人那裡收到錢，並且主動詢問 AI 關於該特定交易，攻擊才會生效。然而，反對意見認為，銀行 App 介面的高度信任感使得此類釣魚攻擊的成功轉換率可能比傳統方法高得多。

"我感覺只要這種情況存在，我們就永遠無法擁有安全的 LLM... 你打算如何將數據與指令分離？"

這個根本性的問題突顯了生成式 AI 應用程式中「數據 vs. 程式碼」邊界的持續挑戰。

Sources