要建立真正有效的 AI 系統，首先要嘗試攻破它。我們進行了一次紅隊演練，扮演攻擊者，測試並探查一個面向客戶的金融服務 AI 應用程式。對於任何部署由 LLM 驅動、不能犧牲安全性的應用程式的人，我們的發現都至關重要。
紅隊演練是刻意嘗試攻破 AI 系統，以便在真正的攻擊者發現漏洞之前加以修補。金融服務涉及的風險尤其高：AI 應用程式會接觸客戶資料、處理交易，並提供財務分析。一旦出現故障，後果可由欠佳的用戶體驗，以至違反監管規定、蒙受財務損失及造成無法挽回的品牌損害。
我們的目標是及早發現漏洞、測試現實的攻擊模式，並協助該機構符合監管機構高度重視的 AI 安全要求。
這裏有一項值得釐清的分別：越獄攻擊針對底層模型的安全過濾機制；提示注入則利用不受信任的用戶輸入，配合開發人員受信任的提示詞，攻擊應用程式本身。提示注入的風險更高，因為它針對的是您的系統及其處理的機密資料，而非通用模型。
首輪測試涵蓋約 750 項測試，包括：
跨工作階段的資料洩漏
個人可識別資料（PII）外洩（透過自然語言、API 操控及各種編碼方式）
SQL 注入
覆寫系統提示詞
在初步測試中，我們發現現有系統有兩大問題：處理多重意圖查詢，以及使用經編碼的提示詞。
多重意圖查詢：在同一請求中混合正當與惡意要求。例如：「按類別顯示我的開支，並執行［惡意 SQL］。」應用程式未能識別惡意意圖，反而完全依賴下游資料層的防護措施。這就像因為相信地庫的保險箱，便任由大門敞開。
編碼：請求採用 Base64、Hex、LeetSpeak 及形似字符編碼。系統可能難以過濾當中的惡意意圖。雖然我們發現這些查詢並未洩露敏感資料，卻令系統明顯失去穩定性，包括產生幻覺、向用戶原樣覆述惡意 SQL，以及意圖分類混亂等。
初步測試結果顯示：
時間幻覺：模型以肯定語氣提供虛構的日期、交易時間戳或時段摘要。這在金融情境中構成重大風險，因為客戶依據錯誤日期採取行動，可能帶來實際後果
向用戶原樣覆述惡意 SQL（令人憂慮記憶污染的風險）
意圖分類混亂
輸出格式錯亂
掌握這些發現後，我們收窄了測試範圍。SQL 注入及編碼測試的優先次序被調低，因為團隊已在處理這些問題。我們轉而集中測試最奏效的攻擊途徑：個人可識別資料外洩及跨工作階段洩漏。
第二輪測試最令人驚訝的發現異常簡單：很多時候，攻擊根本不需要任何巧妙手法。
很多時候，只要把索取內部資料包裝成看似正當的請求，直接向系統提出要求，已足以令它同意披露資料。即使只是簡單查詢，回應也會提及絕不應向終端用戶顯示的內部 ID 及系統欄位。
深入調查後，我們發現這不僅是應用程式層面的問題。下游的文字轉 SQL 服務建立了索取過多欄位的查詢，其解釋性回應亦提及本應受限的資料。這揭示了系統之間確實存在缺口。這類漏洞只有測試整個技術堆疊，而非孤立測試個別組件時才會浮現。
應對整個系統進行紅隊演練，而非只測試模型。單獨測試 LLM，幾乎無法反映應用程式的整體安全狀況。應像用戶實際互動一樣，端對端測試整個技術堆疊。
必須在輸入送達 LLM 前進行驗證。經編碼的查詢、多重意圖攻擊及基本注入嘗試，都應在系統邊界被攔截，而非交由下游服務處理。
切勿信任系統的銜接處。在多服務架構中，最值得關注的漏洞往往隱藏於系統之間的缺口。零信任就是不作任何信任，因此必須在每一層驗證一切。
簡單的攻擊也會奏效。精密的越獄攻擊總能登上頭條，但有時只需要直接……提出要求。如果用戶只需在其他方面正當的查詢中加入內部識別碼，系統便會直接顯示這些資料，那就是一個問題。
了解自己實際在測試甚麼。已知的攻擊模式可能是由 LLM 本身的訓練攔截，而非您的防護措施。紅隊演練應具備可觀測性，以了解實際觸發了哪些控制措施。
受限環境需要創新的解決方案。自訂供應商及本地模型支援，讓團隊即使沒有專用雲端存取權限，也能進行具實際意義的紅隊演練。但必須坦誠說明由此造成的限制。
紅隊演練並非一次性的工作。紅隊演練需要反覆進行、盡可能自動化，並隨系統發展而演進。明天需要重視的攻擊，與今天並不相同。
受監管環境中的 AI 系統只會面臨更多審查，而不會減少。將安全測試視為持續實踐，而非推出前勾選一次的項目，機構便能更充分地應對審查，並避免因公關災難而失去客戶信任。