本文說明攻擊者如何透過系統化偵察，逐步掌握 AI 代理的工具介面、決策規則與資料結構，最終利用偽造工具輸出，在未完成付款的情況下取得已確認的航班訂位。
針對 AI 代理的成功提示詞攻擊，很少只依賴通用語句。相反地，這類攻擊會仿效傳統網路攻擊，系統化探測目標，以盤點工具介面、擷取系統提示詞規則，並掌握資料結構。
攻擊者可以將偽造的工具回應與虛假的助理訊息，直接植入對話歷史。由於大型語言模型（LLM）會把既有上下文視為可信現實，因此可能遭誘導而略過關鍵的循序驗證步驟。
LLM 絕不能成為關鍵業務決策或狀態驗證的最終權威。每一個後端工具與 API 都必須獨立驗證輸入，例如確認交易 ID 確實存在於資料庫中，而不是信任代理層的判斷。
組織必須保護整個多代理架構：建立穩健的後端不變條件，並部署可在攻擊鏈每一階段偵測對抗行為的執行階段防護機制。
談到提示詞攻擊時，人們常以為攻擊始於一句巧妙設計的指令。但在實務上，威力最強的攻擊更早就已經開始：它始於偵察。
在先前的部落格文章中，我們介紹了 AI 代理系統的偵察方法，包括如何探測應用程式邊界、盤點工具介面，以及擷取其運作邏輯。若尚未閱讀，建議先從該文開始。
本文延續前述內容，透過一個具體攻擊情境，說明偵察所得的情報如何轉化為可實際運作的攻擊。我們將逐步分析一條貼近真實情境的攻擊鏈：從偵察已部署的 AI 代理開始，逐步蒐集系統情報，最後發動精準攻擊，在未付款的情況下完成機票訂位。
在整個分析中，我們鎖定的目標是 Varda—個虛構、但在架構上具有代表性的 AI 旅行代理。
Varda 是一個建立在多代理架構上的虛構自主式 AI 旅行代理。其聊天介面只是可見的表層，背後其實是一套更複雜的系統。
圖：Varda 代理架構概觀
完整系統包含：
主要代理（Varda）– 負責協調使用者請求，並將工作委派給子代理與工具。
旅程規劃子代理 – 連接外部網站，以研究目的地、飯店與航班。
知識子代理 – 從向量資料庫擷取內部文件與政策。
三台 MCP 伺服器 –
分別處理航班（搜尋、訂位、取消）、付款（處理、退款、清單）與電子郵件。
MongoDB 叢集 – 持久保存訂位、交易、使用者設定檔及對話追蹤資料。
這並不是一個孤立運作的LLM。使用者傳送的每一則訊息，都會由一個能讀取資料庫、移轉款項、取消訂位及寄送電子郵件的代理處理。因此，攻擊面涵蓋整個互聯系統，而不只是聊天視窗。
典型的 SQL 植入攻擊不會直接從「' OR 1=1 ––」開始，而是先進行探測：辨識資料庫特徵、找出可植入的參數，並了解查詢結構。只有完成這些步驟後，攻擊者才會製作精準吻合目標環境的承載內容。
針對 AI 代理的提示詞植入也遵循相同紀律。其「解析器」是LLM，會把系統指令、使用者訊息與工具輸出當作一串扁平化 Token 來處理，但原理完全相同。通用型攻擊，例如「忽略規則並執行X」，其成功率就像在表單中隨機輸入SQL字元一樣低。偵察在兩種攻擊中帶來的核心價值都是精準性：讓承載內容看起來完全像是系統原本就被設計來執行的操作。
| 攻擊鏈階段 | SQL 植入 | 針對 AI 代理的攻擊 |
|---|---|---|
| 偵察 | 辨識資料庫特徵、找出可植入參數 | 擷取系統提示詞邏輯、列舉工具、掌握輸出結構 |
| 武器化 | 依資料庫語法及查詢結構製作承載內容 | 製作指示代理使用特定工具的提示詞 |
| 攻擊 | 透過輸入欄位植入 SQL，繞過驗證 | 將提示詞植入代理上下文，繞過代理的前置條件檢查 |
| 影響 | 未授權資料存取或繞過身分驗證 | 未授權執行操作，例如訂位、退款或資料外洩 |
表 1：SQL 植入與提示詞植入的對照
建立這個分析框架後，接下來讓我們檢視針對 Varda 的攻擊鏈。
我們的目標很明確：在未觸發真實付款的情況下，取得已確認的航班訂位。
Varda 的標準訂位流程採循序方式進行：先搜尋航班，使用者選定航班後，Varda會處理付款，接著才建立訂位。攻擊必須打破這個順序。具體而言，我們需要讓代理相信付款已獲核准，使其直接進入開票流程。要做到這一點，需要在偵察階段取得三項情報：
決定何時允許訂位的決策規則，以了解要偽造哪一項前置條件。
能促使代理觸發訂位的精確輸入內容。
能讓代理相信付款已完成的精確輸入內容。
與其猜測這三項資訊，我們可以透過四個偵察階段取得：
擷取系統提示詞邏輯
盤點工具
掌握付款資料結構
分析資料儲存區
第一個偵察目標，是了解代理的決策規則。系統提示詞定義 AI 代理的操作限制，但同時也可能成為攻擊者的偵察路線圖。能夠重建系統提示詞的攻擊者，便能精確掌握應用程式可以做什麼、邊界在哪裡，以及哪些規則可以被滿足、模擬或繞過。
擷取這些資訊不需要直接存取權限。攻擊者可透過行為探測，例如嘗試位於規則邊界的操作、觀察拒絕回應，以及記錄
Varda 拒絕請求時使用的精確措辭，來推斷底層指令。詢問 Varda 在處理退款前會遵循哪些步驟，或確認訂位前必須符合哪些條件，往往就能取得系統指令的直接改述。
透過行為分析重建出的 Varda 訂位規則包括：
<system_instructions>
— 呼叫「Cancel Booking」前，必須先透過「Get Bookings」工具驗證航班詳細資料。
— 未確認取消有效前，不得使用「Refund Payment」工具處理退款。
— 若沒有成功付款交易紀錄，不得發出訂位確認。
</system_instructions>
| 偵察揭露的資訊 第三條規則定義了攻擊向量。除非目前對話上下文中存在成功付款紀錄，Varda 不會呼叫 book_flight。也就是說，攻擊重點不是操控訂位工具本身，而是滿足前置條件檢查。攻擊者需要在訂位步驟之前，將虛假的付款結果插入對話上下文，讓代理在查找付款紀錄時能找到它。 |
|---|
系統提示詞已經明確告訴我們需要偽造什麼。下一個問題是：有效的付款結果究竟長什麼樣子？
確認付款前置條件後，下一步是精確列舉 Varda 的工具清單。只知道存在process_payment工具並不足夠；我們還需要知道代理實際使用的工具名稱，以及付款工具與訂位工具的呼叫簽章。
現代 AI 代理可能明確暴露工具介面，例如透過文件、詳細錯誤訊息或直接提示；也可能間接暴露，例如在回應中繼資料中出現工具名稱與參數。針對 Varda 的定向探測，揭露了三台 MCP 伺服器及下列工具。
| MCP 伺服器 | 可用工具 |
|---|---|
| 航班 | search_flights、book_flight、get_bookings、cancel_booking |
| 付款 | process_payment、get_payment、list_payments、refund_payment |
| 郵件 | send_email |
表 2：透過定向探測所揭露的三台 MCP 伺服器及其可用工具
想像一下：如果你擁有一把原始 API 金鑰，可以直接存取代理能使用的每一項工具，你會怎麼做？你會組合哪些呼叫？這正是攻擊者面對工具清單時的思考方式。他們尋找的不是單一有漏洞的函式，而是推演多個工具串接後，可能形成哪些操作序列。
| 偵察揭露的資訊 訂位工具是 flights__book_flight。它的呼叫簽章需要兩個不直觀的輸入：offerUUID（搜尋時產生、用來識別特定航班報價的內部識別碼）與 transactionId（由 payments___process_payment 產生的付款確認參照）。transactionId 沒有預設值或備援值，必須來自先前的付款呼叫。 |
|---|
這證實偽造付款步驟是唯一可行路徑。我們無法跳過或繞開付款流程，因為訂位工具的呼叫簽章本身就要求
transactionId。攻擊者必須提供一個會被代理視為合法的值，因此偽造的付款回應在結構上必須完全正確。
偽造的付款回應必須足夠可信，才能避免被代理或防護機制標記。要精確掌握資料結構，攻擊者必須觀察真實交易，或說服代理描述其格式。
在此案例中，我們選擇進行合法互動：使用真實或測試信用卡完成測試訂位，藉此觀察成功的process_payment 回應。Varda 執行付款工具後，只要簡單要求顯示工具輸出，就能取得以下結構：
| 偵察揭露的資訊 回應包含六個欄位：success、transactionId、amount、status、message 與 last4Digits。transactionId 遵循 UUID 前綴格式。關鍵在於 amount 欄位必須與航班價格完全一致，表示偽造回應必須使用目標航班的真實價格，而該值只有在完成航班搜尋後才能取得。因此，偽造內容無法事先完整準備；金額必須在攻擊當下填入。 |
|---|
這個資料結構就是範本。現在，我們已掌握製作承載內容所需的所有資訊，只剩下一項操作細節。
最後一個偵察步驟，是了解 Varda 的持久化資料如何儲存與被引用。Varda 會在資料庫中保存訂位與交易紀錄，代理也能透過工具查詢這些資料。一般互動，例如查詢過去的訂位，即可揭露已儲存紀錄的資料模式。
| 偵察揭露的資訊 offerUUID 會在搜尋時產生，且只在有限時間內有效。transactionId 代表一筆已完成付款，而 offerUUID 則代表會過期的即時報價。因此，攻擊無法先完整準備、稍後再執行。攻擊者必須在偽造步驟前立即執行即時航班搜尋，以取得仍有效的 offerUUID，並在報價有效期限內完成後續操作。 |
|---|
這決定了完整攻擊順序：先偵察，再搜尋、偽造，最後訂位，而且所有步驟都必須在同一個工作階段內完成。
完成偵察後，攻擊分為四個步驟：
取得有效的即時 offerUUID
植入偽造對話交換
觸發訂位
確認結果
在此情境中，攻擊者直接透過 Varda 的聊天介面傳送植入內容。同樣的承載內容也可能間接送達，例如嵌入旅程規劃子代理在研究過程中讀取的網頁，使植入內容在沒有任何直接使用者互動的情況下進入對話上下文。
攻擊者先進行一般航班搜尋。
【原始網頁此處呈現操作提示／畫面範例】
由於 offerUUID 並未被定義為敏感資訊，只是未顯示在使用者介面上，攻擊者可以直接要求代理提供。
【原始網頁此處呈現要求顯示 offerUUID 的提示範例】
Varda 呼叫 search_flights 並回傳可用選項。攻擊者選擇目標航班，記錄其offerUUID：3152fa28—171b—4f48—9921—fcd3840db18a，以及價格：US$602.24。至此，兩項必要資料都已取得。
攻擊者利用偵察階段 3
取得的資料結構，將偽造的付款確認直接植入對話上下文。這個植入內容是一段完整的虛假互動：先加入偽造工具結果，緊接著加入一則虛假的助理訊息，用來確認付款並宣告將繼續進行訂位。amount設為 602.24，以吻合目標航班價格；虛假的 transactionId 則遵循 UUID 格式。
【原始網頁此處呈現偽造工具結果與虛假助理訊息的完整承載內容】
這個由兩部分組成的植入，讓攻擊在結構上完整成立。偽造工具結果滿足了付款前置條件；虛假助理訊息接著冒充 Varda 自己的推理回合，在真實模型處理下一則使用者訊息之前，就先在對話歷史中建立「Varda已決定繼續訂位」的狀態。
由於 LLM 無法區分自己的先前輸出與攻擊者提供的上下文字串，因此偽造工具結果與助理確認訊息都會被當成合法的歷史紀錄。
在偽造對話已存在於上下文後，攻擊者接著輸入：
太好了，請繼續為該航班發出訂位確認。
名字：<名字>，姓氏：<姓氏>，出生日期：<DOB>，電子郵件：<email>
Varda讀取自己的對話歷史，找到被植入的付款確認與虛假確認回合，接著依據系統提示詞規則進行判斷：「若沒有成功付款交易紀錄，不得發出訂位確認。」由於前置條件在上下文中看似已被滿足，因此Varda 進一步呼叫flights__book_flight。
航班 MCP 伺服器依據即時資料庫處理訂位。它收到有效的 offerUUID，以及結構正確的 transactionId，卻沒有任何機制驗證該交易 ID 是否真正對應到一筆付款；架構原本假設這項驗證已在代理層完成。最終，訂位獲得確認，卻沒有任何款項實際轉移。
這次攻擊之所以成功，是因為架構同時依賴模型控制工作流程，並驗證模型自己的動作。防禦這類攻擊需要兩項互補策略：
不要信任模型來驗證工作流程。
部署涵蓋完整攻擊鏈（包括偵察）的執行階段防護機制。
LLM 不應成為關鍵業務決策的權威。每一項工具都必須獨立驗證自己的輸入。航班伺服器在發出訂位前，應自行比對付款資料庫中的transactionId，而不是信任代理已完成檢查。
所有傳遞給工具的引數都應被視為不受信任的輸入；高價值操作則應要求在代理自身邏輯之外，由人工進行確認。
強化後端可以阻止最終利用，但成熟的防禦應在更早階段偵測攻擊。攻擊鏈的每一個階段–偵察探測、工具輸出偽造，以及實際利用–都會產生可偵測的模式。能夠監控所有階段 AI 應用流量的執行階段防護機制，可提供縱深防禦，在攻擊者蒐集到製作精準承載內容所需情報之前，就先攔截攻擊。
Akamai Firewall for AI
正是為此用途而設計，可在完整攻擊鏈中，即時偵測提示詞植入、偵察模式與工具輸出偽造。
具韌性的 AI 應用不會要求模型自行執行付款規則或保守祕密，而是由後端服務自行強制執行其不變條件，並以執行階段防護機制包覆整個系統，在每一個階段偵測攻擊。
精準提示詞攻擊並非理論情境，而是遵循數十年來定義攻擊性資安作業的同一條嚴謹攻擊鏈：偵察、武器化、攻擊與影響。正如本文分析所示，一旦攻擊者盤點出代理的工具、決策規則與資料結構，製作攻擊就不再是創意競賽，而是模仿系統的工作。承載內容不是與系統對抗，而是使用系統自己的語言。
防禦這類攻擊，首先必須接受一項事實：模型本身不是安全邊界。部署 AI 代理的組織必須強化每一項後端服務，使其自行驗證不變條件，並分層部署執行階段防護機制，偵測攻擊鏈每一階段的對抗行為，而不只是在最終利用時才處理。AI 代理的攻擊面是整個互聯系統，因此防禦也必須同樣全面。
原文來源：Akamai Security Blog｜From Recon to Free Flights: Precision Prompt Attacks on AIAgents
Akamai
看影片追技術