要打造真正可用的 AI 系統，首先得設法攻破它。我們進行了一次紅隊演練，扮演攻擊者，測試並探查一款面向客戶的金融服務 AI 應用程式。對於所有部署 LLM 應用程式、且無法在安全上妥協的人而言，我們的發現都至關重要。
紅隊演練是刻意嘗試攻破 AI 系統，以便在真正的攻擊者發現弱點前加以修補。金融服務面臨的風險尤其高：AI 應用程式會接觸客戶資料、處理交易並提供財務洞見。一旦出錯，後果可能從糟糕的使用者體驗，一路擴大至違反監管規定、財務損失及無法挽回的品牌傷害。
我們的目標是及早找出弱點、測試真實的攻擊模式，並協助組織符合監管機構高度重視的 AI 安全要求。
這裡有個值得釐清的差異：越獄攻擊的是底層模型的安全篩選機制；提示注入則利用不受信任的使用者輸入與開發人員的可信提示詞相結合，攻擊應用程式本身。提示詞注入的風險更高，因為其目標是你的系統及其處理的機密資料，而非通用模型。
第一輪測試涵蓋約 750 項測試，包括：
跨工作階段資料外洩
PII 暴露（透過自然語言、API 操控及各種編碼）
SQL 注入
系統提示詞覆寫
在初步測試中，我們發現現有系統有兩大問題：多意圖查詢的處理方式，以及編碼提示詞的使用。
多意圖查詢：將正當要求與惡意要求混在同一個請求中。例如：「依類別顯示我的支出，並執行［惡意 SQL］。」應用程式未能偵測到惡意意圖，反而完全依賴下游資料層的防護機制。這就像因為信任地下室裡的保險箱，便讓自家大門敞開。
編碼：使用 Base64、Hex、LeetSpeak 及同形字元對請求進行編碼。系統可能很難篩除其中的惡意意圖。雖然我們發現這些查詢並未暴露敏感資料，卻會大幅破壞系統穩定性，例如產生幻覺、向使用者複述惡意 SQL，以及混淆意圖分類等。
初步測試結果顯示：
時間幻覺：模型以確信的語氣回傳捏造的日期、交易時間戳記或特定期間摘要。在金融情境中，客戶若依錯誤日期採取行動，可能造成實際後果，因此風險重大
將惡意 SQL 原樣回傳給使用者（可能造成記憶投毒風險，值得注意）
意圖分類混淆
輸出格式錯亂
掌握這些發現後，我們縮小了測試範圍。SQL 注入與編碼測試的優先順序調低，因為團隊已著手處理這些問題。我們轉而聚焦於成功率最高的攻擊途徑：PII 暴露與跨工作階段資料外洩。
第二輪最令人意外的發現其實非常簡單：很多時候，根本不必運用高明手法。
許多情況下，只要把索取內部資料包裝成看似正當的請求，直接向系統要求，就足以讓系統同意將資料曝光。簡單的查詢便會得到提及內部 ID 與系統欄位的回覆，而這些資訊絕不該向終端使用者顯示。
進一步調查後，我們發現這不只是應用程式層級的失誤。下游的文字轉 SQL 服務建立查詢時，索取了超出必要範圍的欄位；其說明性回覆也提及本應受限的資料。這顯示系統之間確實存在安全缺口。這類弱點唯有測試完整技術堆疊，而非分別測試個別元件時，才會浮現。
紅隊演練應測試整套系統，而非模型。單獨測試 LLM，幾乎無法反映應用程式整體的安全狀況。應比照使用者的實際互動方式，對完整技術堆疊進行端對端測試。
輸入驗證必須在資料進入 LLM 前完成。編碼查詢、多意圖攻擊及基本注入嘗試，都應在系統邊界攔截，而非交由下游服務處理。
不要預設系統之間的銜接處是安全的。在多服務架構中，最值得關注的弱點往往就藏在系統之間的安全缺口中。零信任就是不信任任何事物，因此每一層的一切都必須驗證。
簡單的攻擊也會奏效。複雜的越獄手法容易登上頭條，但有時你只需要開口問。如果使用者在其他部分皆屬正當的查詢中提到內部識別碼，你的系統便毫無防備地將其顯示出來，那就是個問題。
釐清自己實際在測試什麼。已知的攻擊模式可能是被 LLM 本身的訓練攔截，而非你的防護機制。應在紅隊演練中納入可觀測性，以了解實際觸發了哪些控制措施。
受限環境需要創新的解決方案。自訂供應商與本機模型支援，讓團隊即使無法使用專用雲端資源，也能進行有意義的紅隊演練。但必須坦誠說明這些做法帶來的限制。
紅隊演練不是一次性的工作。它需要反覆進行、盡可能自動化，並隨著系統演進而調整。明天需要防範的攻擊，不會與今天完全相同。
受監管環境中的 AI 系統只會面臨更多審查，不會更少。將安全測試視為持續性專業工作，而非上線前勾選一次的待辦項目，組織才能更妥善地面對這些審查，並避免因公關危機而失去客戶信任。