AI Agent 是長期運行的“風險系統”，如果你還只在防 Prompt Injection，說明已經落后一代了

作者 | Sergio De Simone

譯者 | 田橙

為防止大語言模型和 AI Agent 執行嵌入在外部數據中的惡意指令，所有進入 Agent 上下文的文本在完成校驗之前都必須被視為不可信數據，其中不僅包括用戶輸入的提示，還包括來自外部系統的各類信息。AI 安全公司 CyberArk 的首席軟件架構師 Niv Rabin 表示。為此，他所在的團隊提出了一種基于“指令檢測”（Instruction Detection）與“歷史感知校驗”（History-Aware Validation）的方法，用于同時防御惡意輸入數據和上下文歷史投毒攻擊。

Rabin 介紹說，團隊設計了多種防御機制，并將其組織成一個分層的處理流水線。流水線中的每一層都針對不同類型的威脅，目的是減少單一防護手段不可避免存在的盲區。

這些防御措施包括“蜜罐動作”（honeypot actions）以及指令檢測器，用于攔截具備指令特征的文本，確保模型最終接觸到的僅是經過驗證、且不包含指令的數據。同時，這些機制也會應用于整個上下文歷史中，以防止所謂的“歷史投毒”（history poisoning）。這種攻擊方式指的是，原本看似無害的內容片段在多輪交互中逐步累積，最終拼接成一條完整的惡意指令。

所謂“蜜罐動作”，本質上是一種用于誘捕惡意意圖的安全陷阱，即 Agent 在任何正常業務場景下都不應選擇的合成動作。

這些動作對應的是一些不會真正執行任何操作的虛擬工具。它們并非用于完成實際任務，而是作為安全信號存在，其工具描述被刻意設計成能夠暴露可疑行為。

在提示中出現的可疑行為包括對系統內部機制的元層級探測、異常的數據提取嘗試，以及試圖誘導模型泄露系統提示（system prompt）的操縱行為等。如果 LLM 在動作映射階段選擇了其中一個蜜罐動作，通常就意味著存在明顯的異常或越界行為。

Rabin 指出，真正的安全風險并不主要來自用戶輸入，而是來自外部 API 或數據庫的返回結果。針對這一問題，團隊引入了指令檢測器作為關鍵防護手段。

這種檢測已經不再是傳統意義上對“惡意內容”的搜索，也并非基于關鍵詞、文本毒性或策略違規的判斷，而是聚焦于識別文本中所蘊含的意圖、行為模式以及指令在結構層面的特征。

指令檢測器本身是基于 LLM 構建的“裁判模型”。在任何外部數據被送入主模型之前，檢測器都會對其進行審查，并被明確要求識別任何形式的指令，無論其表現得多么直白或隱蔽，從而使系統能夠在第一時間阻斷可疑數據。

此外，時間也被證明是一種重要的攻擊向量。早期響應中零散存在的惡意指令片段，可能會在后續交互中被重新組合，最終形成一條完整指令。這種現象被稱為“歷史投毒”。

示意圖展示了一個典型案例：LLM 被要求分別獲取三段數據，單獨來看，這些數據完全無害；但合并在一起后，內容實際拼成了一條指令，要求系統停止處理并返回特定結果。

為防止歷史投毒，所有歷史 API 響應都會與最新獲取的數據一并提交給指令檢測器，作為一個統一輸入進行分析。

Rabin 指出，歷史投毒并不是發生在數據進入系統的入口階段，而是發生在系統從歷史記錄中重建上下文的過程中。通過引入這一機制，即便對話歷史中隱藏著試圖干擾模型推理的細微線索，系統也能夠在模型受到影響之前及時發現異常。

上述所有步驟都會在同一條流水線中運行。一旦任意一個階段檢測到風險，請求就會在模型處理之前被直接攔截；只有通過全部校驗后，模型才會處理已經凈化過的數據。

Rabin 總結，這種方法的關鍵在于將 LLM 視為一個長期運行、跨多輪交互的工作流系統，而非一次性的請求響應組件。他在原文中對這一方案進行了更為深入的展開，對于關注 AI 安全問題的讀者而言，值得進一步閱讀。

https://www.infoq.com/news/2026/01/cyberark-agents-defenses/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。