Agent Data Injection (ADI)

資料來源#

• Agent Data Injection Attacks are Realistic Threats to AI Agents
• Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents
• GhostJacking Attacks: Half of the Fortune 500 Run These Tools. Getting Blocked by the Firewall Was the Way to Take Over Their AI Agents
• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents
• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking

摘要#

Choi、Kim、Kang、Jeong、Xing 與 Lee（Seoul National University / UIUC / Largosoft，arXiv 2607.05120，2026 年 7 月）提出 Agent Data Injection (ADI)，一種新型的間接提示注入（IPI）。廣為研究的 IPI 類型是指令注入：攻擊者控制的不可信資料被誤認為指令，於是代理程式放棄使用者的任務，改為執行攻擊者的要求。如今許多防禦會透過強制設定指令↔資料邊界來阻止這種情況。ADI 利用的是另一個更細微、同樣被這些防禦忽略的邊界：代理程式資料本身內部的可信與不可信資料缺乏隔離。ADI 讓不可信資料被誤認為可信資料，而非指令——也就是模型賴以定位的安全關鍵中繼資料，例如留言作者／角色、電子郵件的 sender、Web UI 元素識別碼，或工具呼叫／回應歷史。代理程式仍會執行使用者原本要它做的任務，但使用的是攻擊者偽造的中繼資料。

這個區別正是核心（論文圖 3）。指令注入會讓 LLM 遵循攻擊者的指令；ADI 則讓 LLM 依照使用者的指令處理攻擊者的資料。現有防禦的設計目標，是避免注入資料被讀成指令，並非避免它被讀成可信資料，因此面對 ADI 時大多失效：對抗最先進代理程式防禦時，指令注入的攻擊成功率接近零（0.0–0.7%），ADI 對相同防禦的成功率卻最高達 50%。這是 empirical 研究，包含真實且負責任揭露的漏洞利用（Anthropic、OpenAI 與 Google 已確認；Nanobrowser 未回覆）。

機制：機率式分隔符注入#

代理程式資料（JSON、Markdown、XML、自訂標籤格式）由分隔符組織，分隔三個層級——工具呼叫區塊、物件與欄位——也因此分隔可信與不可信的值。機率式分隔符注入會在不可信欄位中插入類似分隔符的字元序列，使 LLM 所理解的資料結構與工具所理解的結構產生差異。工具將注入序列視為一般文字；LLM 卻將其誤讀為結構邊界，於是攻擊者負載的一部分被認為是新的可信欄位／物件／工具區塊。

「機率式」一詞是這裡的關鍵，也是論文最核心的新意。傳統分隔符攻擊（SQL injection、XSS）針對的是確定性剖析器，只有使用完全一致的分隔符（真正的 ' 或 <script>）才會成功。LLM 會以機率方式解讀資料，因此即使分隔符不精確、對剖析器無效，也能奏效：跳脫的雙引號 \"——JSON 剖析器會將其保留為字面文字——仍可能被機率性地讀成結構引號（圖 4：電子郵件 body 中含有 \"sender\": \"alice@gmail.com\"，偽造出第二封冒充 alice 的電子郵件物件）。攻擊不依賴特定分隔符：視覺相似的引號（'）或任意字元（$、()），在 JSON 上仍可達到 35.8–43.3% ASR。假物件的結構一致性最重要——完整的假物件（31.3–43.3%）勝過格式錯誤的物件（11.8–20.0%）。這是首次系統性刻畫 LLM 對不精確分隔符的誤讀。

真實代理程式上的三種可行攻擊（§4）#

每種攻擊都濫用不同類型的可信資料。全部已在正式推出的產品上獲得確認；使用者核准對話框並未阻止攻擊，因為代理程式呈現的自身推理也是建基於這種誤讀，因此會強化攻擊者的錯誤說法（例如：「依維護者建議安裝 starship-auth」）。

1. 透過元素 ID 注入任意點擊（網頁代理程式）。 精心製作的產品評論會注入假的按鈕 button "Read More" [ref_3]，重複使用真實 Buy Now 按鈕的識別碼（ID 按順序以可預測方式指派）。代理程式仍在摘要評論，卻「點擊 Read More」——實際解析到 Buy Now，於是完成購買。已在 Claude in Chrome、Antigravity、Nanobrowser 確認。類似 XSS：任何有使用者生成內容的網站都可能成為攻擊面。ChatGPT Atlas 不受影響，因為它使用執行階段隨機化 nonce（ref_4af2b1c9），攻擊者無法預測——這是隨機化防禦。
2. 透過來源注入遠端程式碼執行（程式碼代理程式）。 GitHub issue 留言注入假的留言物件，並偽造維護者作者／角色，藉此建議惡意 shell 命令。使用者要求代理程式「套用維護者的修正」；代理程式將注入留言錯誤歸因給維護者，並執行命令（pip install starship-auth）。已透過 gh CLI 與 GitHub MCP server，在 Claude Code、Codex、Gemini CLI 上確認，涵蓋 JSON 和純文字格式。
3. 透過工具呼叫／回應注入發動供應鏈攻擊（程式碼代理程式）。 惡意 PR 的描述注入假的工具呼叫區塊——對 Claude Code 而言，是偽造 <function_calls>／<function_results> 標籤——捏造 read_pr_commit 結果，顯示一個無害的差異內容。代理程式「審查」偽造的提交，判定 PR 安全並合併，但實際提交包含 XSS 負載。這種攻擊偽造整段工具執行歷史，因此能捏造任何工具輸出（驗證結果、價格比較）。已在 Claude Code、Codex、Gemini CLI 確認。

其他已確認的變體（§C）：偽造電子郵件寄件者（ChatGPT、Claude）與 Slack 來源注入（Claude Code + Slack MCP，偽造頻道管理員訊息）。攻擊者只需知道資料格式；可透過閱讀開源程式碼、觀察呈現後的工具輸出、逆向分析本機用戶端，或誘使伺服器端模型洩漏格式來取得。

防禦為何失效（§5–6，表 1–2，圖 9–10）#

研究以現成 LLM（GPT-5.2、GPT-5-mini、Claude Opus 4.5、Claude Sonnet 4.5、Gemini 3 Pro/Flash）及擴充版 AgentDojo 代理程式基準測試（GPT-5.2，新增 108 種 ADI 攻擊）進行評估。現成模型的基準 ASR：JSON 上為 31.3–43.3%，網頁 DOM 上為 33.3–100%，且良性效用很高。對抗防禦時（AgentDojo，基準 ASR 49.1%）：

• 模型強化（指令／資料分離訓練）——無法保護資料內部；這正是指令注入降至約 0%，ADI 卻仍毫無阻礙的原因。
• 輸入防護（Llama Prompt Guard 2）——ASR 50.0%；108 個 ADI 負載中偵測到 0 個（它們不含「忽略先前指令」等模式，只像合理資料），相較之下可偵測 34.9% 的指令注入嘗試。
• 輸出防護（LlamaFirewall AlignmentCheck）——45.4%；無效，因為代理程式的行動仍符合使用者提示——只有底層資料遭到竄改。
• 先規劃再執行（IsolateGPT）——40.7%；計畫未被破壞，但執行器步驟仍會使用遭污染的資料。
• 代理程式沙箱（Progent、以符號式逐次呼叫規則實作的 Least Agency）——22.2%；只有在政策限制遭竄改的參數時，才會擋下攻擊。
• 雙 LLM（沒有政策的 CaMeL）——25.0%；分隔符注入會騙過負責隔離的 LLM，讓它擷取攻擊者的值。
• 資料流追蹤（CaMeL）——一般模式 23.1%（作者找到並回報一個污點傳播實作錯誤：隔離 LLM 擷取變數時會遺失標籤）；Strict 為 0%——唯一能完全阻止 ADI 的防禦，但效用成本很高（86.5% → 36.5%）。
• 隨機化（nonce 欄位名稱／元素 ID）——效用為 83.3% 時，ASR 為 28.7%；成本低，安全性接近 Progent，且不需政策 LLM，但只適用鍵值格式（JSON、DOM），不適用非結構化 Markdown。
• 清理（從不可信欄位移除類似分隔符的字元）——可降低 ASR，但會造成大幅效用下降，因為不可信欄位通常確實需要包含 URL、檔案路徑與結構化文字；不切實際。

論文的結論是：現有代理程式缺乏細緻的信任模型。正確的來源／資料流追蹤（CaMeL Strict）是唯一完整的解法，但代價高昂；持久有效的建議是在代理程式脈絡內部隔離可信與不可信資料，並在模型外強制執行。

為何這讓「持久特性還是訓練缺口？」的問題更明確#

Agentic Prompt Injection 留下了一個開放問題：「LLM 無法區分資訊與指令」究竟是持久的架構特性，還是可透過訓練彌補的缺口。ADI 強力支持持久特性的解讀，但也帶來一個轉折：指令↔資料邊界看起來確實可以封閉（模型強化能讓指令注入降至約 0%），但封閉這個邊界，只會把攻擊移到下一個更細的邊界。根本原因是 LLM 對結構分隔符採取機率式解讀——這是架構層面的事實，不是訓練缺口——因此任何攻擊者能模仿的邊界（指令／資料，接著是可信／不可信，往後或許還有更細的邊界）都會保持漏洞。你可以訓練模型遵守某一種分隔符，但無法透過訓練徹底消除對一般不精確分隔符的機率式誤讀。這個補救方向與帶外文獻一致：停止試圖在模型內部修正問題，改在模型外以確定性方式強制資料隔離。

延伸閱讀#

• Agentic Prompt Injection — ADI 是與指令注入並列的第二種 IPI 類型；該頁提出的開放問題（「持久特性還是訓練缺口？」）正是 ADI 讓它更明確的問題

• Out-of-Band Prompt-Injection Defense — 回應 ADI 的防禦類型：只有 CaMeL Strict（確定性資料流追蹤、來源標籤）能完全阻止它；ADI 提供獨立的對抗性證據，檢驗 CaMeL／Progent／雙 LLM 面對資料內部攻擊（而非指令注入）的表現。該頁也完整介紹 APPA（Archestra AI，empirical），直接回應本頁上方「效用崩跌」問題的候選解法——分支到隔離的子軌跡，而非污染父軌跡——包括它正式證明了什麼（父標籤保留、依呼叫範圍釋出）以及其安全性實際仰賴什麼（宣告的工具契約與經主張的清理轉換，兩者都位於其 TCB 內，也都是自身兩個殘餘漏洞所在之處）

• Task-Specification Effects in Prompt Injection (AutoDojo) — 同系列攻擊論文（AutoDojo，Ma 等人，2026）：兩者都顯示靜態評估會高估 IPI 防禦，且透過相互呼應的機制達成——ADI 透過分隔符注入偽造可信資料；AutoDojo 的開放式動作注入則會被讀成資料而非指令。這是兩條繞過只偵測類指令文字的過濾器的途徑，也都指出應以帶外方式強制限制行動／資料，作為解方

• Zero Trust for AI Agents — ADI 偽造零信任控制所仰賴的可信錨點（來源中繼資料、工具歷史）；這是指令注入防禦會漏掉的具體 Phase-4／輸入驗證威脅（hub）

• Least Agency — Progent（在工具呼叫邊界落實最低代理權限）將 ADI 降至 22.2%，但無法消除它——限制工具能做什麼，只在政策限制遭竄改的參數時有幫助

• Capability Gating Is Not Authorization — ADI 所利用的授權層，也有一個共同的殘餘問題：ScopeGate 的逐次呼叫值 authz 閘門會阻止值重新導向（例如型別正確但未獲授權的 account），但 ADI 的整套手法是偽造代理程式有正當理由採取行動的資料（偽造作者、捏造工具結果）——雖符合值政策，仍會造成傷害；這與 Progent 仍會遭遇的同類攻擊（22.2%）一致。值閘門能封鎖重新導向，卻不能防止合法資料遭竄改；只有來源／資料流追蹤能做到。該頁也介紹了回應 ADI 偽造權限面向的通道分離解法及其量測結果：NetInjectBench 的強攻擊集合（arXiv 2607.10490，empirical）從設計上就符合 ADI 的型態——偽造核准、假造票務系統與監控核准、投毒操作手冊與知識庫更新、偽造供應商與安全權限聲明，全部以一般操作資料而非指令呈現——且在未設防代理程式上的效果勝過直接指令注入（不安全行動率 97.50% vs 67.50%）。它降至 0.00%，並非因為偽造內容被偵測到，而是因為授權事實根本不是從該資料來源取得的：核准狀態、維護時段、核准的裝置／修補程式與變更請求 ID，都存在攻擊者無法寫入文字的紀錄中。這就是本頁結論的結構形式——偽造的可信資料無法以資料本身擊敗，因此不要從攻擊者能寫入的通道取得權限。限制也與本頁的殘餘問題一致：這種方式能奏效，是因為網路作業恰巧保存一份權威的帶外紀錄，記載確切爭議事實；偽造留言作者或捏造工具結果並沒有這種紀錄

• Off-Host, Identity-Bound Authorization — 對 ADI 來源偽造的局部防線，以及相同的殘餘問題：aiAuthZ 的逐訊息 HMAC 身分驗證會以密碼學方式驗證人類寄件者，所以當偽造主體不同於目前使用者時，就能阻止 ADI 的來源注入 RCE（偽造 GitHub 留言中的維護者作者）——訊息內文可以聲稱具有維護者權限，但綁定的身分不會賦予這種權限。若偽造資料（捏造的工具呼叫結果、範圍內的值）是以目前使用者自身權限執行，則無法提供幫助——這只受參數／頻率政策限制，正是只有正確資料流追蹤（CaMeL Strict）才能完全封閉的合法資料遭竄改類型。請注意，aiAuthZ 驗證的是人類訊息，而非 ADI 偽造的脈絡內工具歷史，因此同一主體下捏造工具結果的攻擊仍可通過（單一作者預印本）

• Memory and Context Poisoning — 工具呼叫與回應注入會捏造代理程式脈絡內的執行歷史，使模型對自己已執行的操作產生錯誤記憶——是單回合的投毒類比。該頁也為下方的非結構化格式問題提供損害估算：CLAUDE.md / AGENTS.md / behaviors.md 正是無法附加 nonce 的散文格式；Bad Memory（UW，arXiv 2607.14611，empirical）量測了在其中植入規則的攻擊，在目前四種模型、正式推出的 Claude Code 與 Codex 上，ASR 為 0–100%。它提出的補救方式不是修正分隔符，而是在記憶體階層採用政策層級（低信任知識檔案可提供事實，但不能覆寫安全規則）——這是權限層面的解法，而非結構邊界解法；該論文沒有評估此方案。該頁的第二個來源是 GhostWriter（NMSU，arXiv 2607.06595，empirical），目前最接近 ADI 型態的持久記憶攻擊：其描述式負載以禮貌口吻陳述錯誤事實（同事的「新」電子郵件地址，與真正的期限變更和聯絡資料更新郵件在同一通道抵達），而非下達指令——所有以指令為中心的偵測器都會漏掉，DataFilter 的偵測率為 0%，PromptArmor 則從直接指令措辭下的 85% 降至描述式措辭下的 6%，因為這些裁判唯一掌握的訊號就是語氣。其啟動特徵是有所變化，而非一概較弱：描述式負載在敏感資訊外洩和隱密外傳上與直接指令相當，只在提高權限範圍方面較弱；禮貌地要求略過使用者審查規則，讀起來像可選指引 同一通道上的稀釋效果量測（2026-09-02）： PipePoison（Zang 等人，arXiv 2609.00523，empirical）正是透過這個介面傳送負載——預設三個項目的外部工具回傳——也是語料中首個掃描項目數量的來源。回傳項目從一個增加到十個時，寫入成功率由 75–83% 降至 52–61%，端對端攻擊利用率則從 71–76% 降至 47–52%。因此，注入項目在工具回傳中所占的比例確實是值得關注的參數：稀釋 10 倍，端對端成功率約減少 25 個百分點；而且效果是衰減而非消失——與本頁的分隔符機率呈現相同形態，原因也相近：攻擊者項目與周遭項目之間沒有結構隔離，因此擠入更多項目只會降低它勝出的機率。

• Non-Malleable Memory Authority (TMA-NM) — 持久記憶體的對應案例：ADI 的工具呼叫／回應注入（偽造脈絡內工具歷史）與可信工具回聲，是 TMA-NM L-b 可信工具回聲洗白通道的單工作階段類比，兩者最後都指向相同的完整解方——正確的來源／資料流追蹤（ADI 的CaMeL Strict；TMA-NM 在呼叫邊界確認來源）。TMA-NM 是本頁所指代理程式缺乏細緻可信／不可信資料模型的跨工作階段版本 第二個接觸點（2026-09-02）： 移除偵測器可能依據的最後一個線索，就抵達本頁論證的終點。 ADI 的貢獻在於揭示負載無須包含任何指令——攻擊者內容只要被讀成可信資料，就能擊敗只分離指令和資料的防禦。Karunanidhi 移除了最後一點結構：負載不是偽造中繼資料、不是跳脫分隔符，也不是捏造工具結果——它是一般對話句子，唯一的問題是其中的數字錯了，而且是透過預期介面、在正確信任標籤下寫入。同一論文中，一個四階段寫入篩選器在間接注入上的召回率為 0.832，卻拒絕了其中 360 個案例的 0 個；其理由正是本頁一直探討的分類主張：文字內容掃描器無法取得「虛假」這項特性，因為能偵測它的階段必須已經知道答案。這與本頁的分隔符發現相同——防禦檢查產物，但竄改並不在產物結構中——只是如今連可供檢查的產物都不復存在。另一半也同樣成立：ADI 的殘餘問題是 CaMeL Strict 透過追蹤來源而非閱讀內容勝出；Karunanidhi 則量測了來源已正確追蹤、卻只以分數而非限制表示時會發生什麼事

• Impossible, Not Tedious (Design Test) — 使用者確認對話框是一種會失效的摩擦控制（代理程式推理會強化攻擊者的說法）；nonce 隨機化（ChatGPT Atlas）才是有效的移除能力控制

• Agent Supply Chain Risk — ADI 的工具呼叫注入漏洞利用就是供應鏈攻擊：透過偽造無害提交的工具回應來合併惡意 PR，真正提交內容卻從未經過審查

• MCP Tool Poisoning — 針對代理程式的同系列偽造可信脈絡攻擊，位於不同平面：ADI 透過機率式分隔符注入偽造可信資料（留言作者、捏造工具結果），使代理程式依攻擊者資料行動；ShareLock 偽造工具中繼資料（MCP 描述／tool_id／checksum），讓代理程式重新組合攻擊者的指令。兩者都利用模型對不該信任的脈絡具有結構性信任——ADI 位於資料平面，ShareLock 位於工具能力平面——也都能溜過只搜尋類指令文字的內容偵測防禦。Agentjacking（Tenet Security，case-study），該頁記錄的實地 MCP 案例，可能就是這種攻擊的真實事件——透過 MCP 傳遞、帶有 ADI 特徵的偽造攻擊：攻擊者注入假的 Sentry 錯誤事件，由合法 Sentry MCP server 轉送，程式碼代理程式便將其讀成可信診斷資料（假的 ## Resolution 在結構上與 Sentry 自己的範本完全相同）。從機制來看，它跨越兩種類型——偽造內容會解析成可執行命令（npx …），因此在負載層面帶有 IPI 特徵，在信任層面則帶有 ADI 特徵（不可信資料被洗成可信工具輸出），並以純文字格式仿造，而非機率式分隔符注入。這是供應商回報、未經量測的近親案例，對照本頁 empirical PoC，也印證核心發現：提示層強化（「忽略不可信資料」）無法阻止資料內部的偽造

• Agent Harness Engineering — 代理程式的資料格式與工具呼叫分隔符（Claude Code 的 <function_calls>／<function_results>、Codex 的換行分隔、Gemini CLI 的 <ctrl46>）是 harness 設計的攻擊面；其可預測性／可模仿性也是 harness 的安全屬性

• Internal Signatures of Misalignment / White-Box Activation Monitoring — 一個可能的盲點：白箱注入偵測器會在負載看起來有敵意（fake、injection）時觸發，但 ADI 負載刻意偽裝成一般可信資料，因此可能完全沒有這類特徵

• The Assistant Persona in the Workspace — 延伸更深層的論點（「LLM 無法明確區分資訊和指令」）：模型也無法區分可信與不可信資料，因為兩種邊界都只是由模型以機率方式解讀的分隔符

• Claude Code — 展示 RCE 與供應鏈 PoC 的代理程式；也是 Slack 來源注入的目標

• Codex / Google DeepMind — Codex 與 Gemini CLI 同樣容易受到來源注入和工具呼叫注入攻擊

• OWASP — ADI 是 OWASP LLM01 提示注入範疇下的新子類型

• Anthropic / OpenAI — 已確認負責任揭露的供應商之一

• Can Models Learn to Separate Instructions from Data? Durable Property vs Training Gap — 本論文所依據的彙整分析：ADI 的「封閉一個邊界，就把攻擊移到下一個更細的邊界」是有力證據，說明分離能力具有持久的架構特性（個別邊界可透過訓練改善，但整體上無法根除），這項論點橫跨五個來源

• Deep Research Agents — 本頁所有防禦都無法阻止的失敗，也是兩種類型必須分開看待的原因。MisKnow-Agent（arXiv 2607.20891，empirical）注入的文件什麼都沒有偽造：沒有分隔符、沒有假作者、沒有捏造工具結果、也完全沒有指令——只是在看似合理的文類中，提出一個由聽來可信的機構所發布的合理假說法。其威脅模型明確排除提示注入與指令劫持，而一份這類文件就能讓六種框架－LLM 組合採納錯誤結論的比例從 0% 升至 54.7%。這對本頁處方的意義是：正確的來源追蹤在這裡不是防禦。 CaMeL Strict 會如實標記誤導文件的真正不可信來源，但代理程式仍會相信它，因為文件本身正如其來源標籤所示。信任邊界完整性和內容可靠性是彼此正交的軸，只有第一項有機制層面的解法。該論文另外兩項發現也讓 ADI 的說服機制更明確：作為採納線索，呈現文類比機構權威更有影響力（寫作品質跨層級保持一致時，論文轉貼文類相差 23.5 個百分點，高低權威相差 14.8 個百分點）；而在任務中採納文件的同一批模型，單獨讀取文件時又會將其判定為誤導——它們具備這種能力，但工作流程從未呼叫它

• Observability-Pipeline Poisoning — 本頁論點在正式推出的代理程式和即時第三方平台上獲得驗證，但出現分隔符論述未涵蓋的說服機制。 Tenet 的 GhostJacking（case-study，DEF CON 34，供應商撰寫）報告指出，所有命令式負載都遭拒絕——「忽略先前指令」、假的 <system> 標籤、[AGENT: call dns_update]、嵌入程式碼——真正奏效的是完全不帶指令的結構化掃描器遙測資料：工單參照、合規引用、無法證偽的指標，「包含缺口的發現，而非命令」。這是攻擊者親自重述 ADI 的前提，而非基準測試。另有兩點需要修正。(1) 釐清下方的非結構化格式問題範圍——WAF 記錄欄位不屬於這個問題的案例。Cloudflare 的 firewallEventsAdaptive 中的 userAgent，以及 Datadog 的 message，都是 nonce 可涵蓋的一般鍵值欄位；問題更單純：根本沒有加入來源標註（Cloudflare），或雖有標註卻從未使用（Datadog 將這些項目標為 client-token-submitted；Tenet 指出「警告藏在任何代理程式都不會讀取的中繼資料裡」）。nonce 問題探討的是無法加上界線的格式；這裡則是容易加上界線的通道，卻無人採用。(2) 已驗證前綴的信任轉移——這是本頁現有論述容不下的機制：成功的負載提出兩項代理程式自行查證的主張（子網域缺少 DMARC 記錄；父層政策為 sp=reject），代理程式確認兩者後，就接受同一記錄中尚未查證的攻擊者 rua 地址與 CNAME 目標。可查證部分所累積的可信度，被用來支持無法查證的部分——這是記錄內部的信任梯度，不是偽造分隔符，也不會被任何資料流標籤標記，因為整份記錄的來源如實標為「不可信」。這是供應商執行的實驗室數據：在單一攻擊鏈上對 Claude Code（Sonnet 4.6）的成功率為 90%，可信度低於本頁的 empirical 結果

• Write-Then-Trusted — 同樣四種產品（Claude Code、Codex、Gemini CLI、Antigravity）在相鄰且互為鏡像的邊界失守。ADI 會污染代理程式脈絡內部的資料，讓代理程式依偽造的可信值行動；write-then-trusted 則讓代理程式在脈絡外部輸出檔案，之後由未沙箱化的主機元件將其視為可信設定（Pillar Security，case-study；Cursor 的 .claude hook 設定涉及 CVE-2026-48124）。兩者都是工具呼叫閘門看不到的信任邊界失效——一種發生在代理程式上游，一種發生在下游——原則上都可由同一項缺失能力解決：讓來源資訊隨產物一併傳遞

• Self-Propagating Prompt Injection (AI Worms) — 單次注入已經延伸到另一個方向，也能與本頁形成清楚對照。ADI 往更細處延伸（資料內部以不精確分隔符偽造的邊界）；Måløy 的 Copilot for Word 蠕蟲（case-study、MSRC、協調處理 144 天）則往更長處延伸——負載的第二個指令要求將自身複製到助理輸出，因此每份生成文件都成為新的載體，即使原始惡意文件已不存在，第二階段仍會觸發。負載本身是一般指令注入，只有自我複製步驟具有新意；它在此補充的是下方非結構化格式問題的直接實例（Word 文件中以白字白底藏起負載，Copilot 在模型讀取前將其移除——沒有分隔符可設界線，也沒有欄位可加入 nonce），以及一項正式產品案例，說明升級模型無法修復整個攻擊類別：Microsoft 的第二次修補方式是升級至 GPT-5.5，隔天攻擊便在 GPT-5.6 上重現

• Guarantees That Degrade at Deployment: Action-Space Soundness, Admissibility Without Effect, and a Vendor-Coupled Security Framework — 本頁是反駁某項 Pro-tip 的案例：Zero Trust for AI Agents 將 Claude Code 作為 Phase-4 輸入驗證控制的參考實作，但此處的可行 RCE 恰好也發生在相同實作上（另外還有 Codex CLI 與 Gemini CLI），因此這項彙整會將 Pro-tip 視為控制措施已推出的證據，而非控制措施有效的證據

• Agent Epistemic Vigilance — 直接量測「有限接觸剝削型寄件者或抵禦其攻擊的能力」。一位大多數報告為真、卻帶有攸關決策謊言的同伴，是偽裝成可信資料之負載的多代理程式版本；失效原因也相同：代理程式沒有降低特定來源可信度的機制，只會閱讀內容

開放問題#

• 完整防禦（CaMeL Strict）會造成約 50 個百分點的效用損失。是否有細緻的可信／不可信資料隔離方案，能在不讓確定性流程追蹤造成效用崩跌的情況下阻止 ADI——還是說這項取捨無法避免？已有部分答案： APPA（Kravchenko 等人、Archestra AI、arXiv 2607.24625，empirical）已解答「取捨是否無法避免」這一半，並讓「能否阻止 ADI」這一半維持開放。其發現是診斷結果：效用崩跌並非確定性資料流追蹤本身的固有屬性，而是將污點回溯性地傳入單一整體脈絡造成的。一旦 harness 能建立分支，受限制的讀取就會進入可丟棄的子軌跡，其標籤降級不會影響父軌跡，父軌跡的下游工具也能繼續使用——ASR 從 31–50% 降至 0–7%，代價是 0–26 個百分點的情節，而非約 50 個百分點；在量測中能力最強的模型 GPT-5.6 Luna 上，對比未強制執行時的 92%，可達到 95% 效用、2% ASR，也就是完全沒有成本。標籤擴散是資料模型造成的產物，不是定律。此結果仍不足以結束問題，原因依嚴重程度排列如下：(1) 從未實際執行 CaMeL Strict——它只出現在比較表中，其他地方都未測試；唯一實際執行的基準是 Fides，作者自己也承認它與 APPA 在功能上不等價，而且在四種模型上的 ASR 都固定為 12/42（這是政策表達能力不匹配，並非防禦被突破）。約 50 個百分點的效用損失遭到繞過，並未被推翻。(2) 也從未用 ADI 對其進行測試。 APPA 的威脅模型關注來源與接收端之間的流程；正確宣告的契約確實應該將偽造留言作者標示為不可信來源，這正是所需的形式——但論文自身的殘餘漏洞（hide-secret-in-status，在獲授權的傳送過程中，將權杖偷偷送給合法讀取者）正是 ADI 利用的資料流；作者也明確指出，接收端集合上的標籤代數並未主張能對獲授權傳送內容進行內容隔離。(3) 這是供應商撰寫、針對量身打造的基準測試進行的設計研究，其中大部分分支改善集中在那些被宣告為沒有分支便無法取勝的情境；同一系統在第三方基準測試（AgentDojo）上會損失 21–30 個百分點，其中四分之三來自 harness 中介開銷。因此，剩下的問題比原先更聚焦明確：在同一份 ADI 語料上執行 CaMeL Strict 與具備分支隔離功能的引擎。
• 隨機化對鍵值格式成本低、效果好，但對非結構化格式（Markdown、散文式工具輸出）毫無用處。無法附加 nonce 的格式由什麼保護？（範圍說明，2026-09-02：*即使觀測日誌欄位看起來像符合條件，也不在本問題範圍內——請見 Observability-Pipeline Poisoning。它們是 nonce 可及的鍵值欄位；只是完全沒有標籤，或標籤無人讀取。本問題應聚焦於無法設界線的格式，而非僅僅沒有設界線的通道。） *（Rehberger 的 macOS Terminal 攻擊鏈（case-study）讓問題更明確，但還沒有答案：補救方式是在呈現邊界預設編碼控制字元**，只有明確選擇才輸出原始內容；這種方式不需 nonce 就能控制非結構化文字，因為它讓攻擊者位元組在解讀時不再具有結構性，而非在撰寫時替它們加上界線。但它保護的是接收端，而非來源：它保護呈現器不受代理程式輸出影響；本問題問的則是如何保護代理程式不受非結構化輸入影響。值得測試的推廣方式是，同樣做法能否用於輸入端——在模型讀取不可信散文前，移除或跳脫會承載結構的序列，進行標準化解碼——這與論文自己的清理項目接近，而該項在此量測出高昂的效用成本。因此，目前解答空間有兩種明確方式（隔離邊界；中和位元組），但都還沒有可低成本處理非結構化輸入的方案。） （直接案例，仍非解答：Måløy 的 Copilot for Word 漏洞揭露（case-study，2026-07-28）是正式推出產品中最糟糕的情況——.docx 附件中完全沒有鍵值結構，隱藏方式不是分隔符，而是Copilot 在文字送達模型前移除的視覺格式，因此模型讀到的內容嚴格多於使用者看到的內容。兩種緩解方式都未能消除這個攻擊類別，且在文章發布時攻擊仍可重現。不過，它指出了解答空間中原本缺少的第三種方式：在輸入時強制視覺一致性——只將可見呈現內容提供給模型——這是將「中和位元組」從呈現邊界移至讀取邊界，而且是確定性、非 LLM 的方法。尚未有人測試，且只處理隱藏這一部分；可見的指令仍可注入。）
• ADI 在 GPT-5.2 級別的代理程式上獲得展示。前沿模型的進步會降低對機率式分隔符的易感性嗎？還是能力提升後仍會誤讀分隔符（表示這是持久的架構特性，而非能隨規模擴大而消除的缺口）？已有部分答案：Can Models Learn to Separate Instructions from Data? Durable Property vs Training Gap 指出能力提升確實會降低個別邊界的易感性（強化訓練使指令注入降至約 0%；較新的模型對未設防的靜態注入也更具抵抗力），因此預期它也會降低可信／不可信資料的 ASR——但面對自適應攻擊者永遠不會降至明確的零，而且分隔符誤讀的機制不會因模型改進而消失。最新模型在可信資料邊界上的直接測試仍未進行——本問題要求的量測仍待解答。
• 鑑於 ADI 負載經過設計，會被讀成可信資料而非攻擊，內部／白箱監控器能否偵測到它？（尚未測試；呼應延伸閱讀中提出的矛盾。）

資料來源#

• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents — Zang、J. Wang、Chen、Meng、L. Wang、Gao、Z. Li 與 Guo（Shandong University），Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning in LLM Agents，arXiv 2609.00523 v1，2026-09-01，empirical，無 COI。此處僅引用第 4.1 節（工具回傳傳遞通道，預設三個項目）與第 4.4.3 節及圖 10（工具回傳數量從 1 增至 10 的稀釋掃描），數據取自內文。Memory and Context Poisoning 收錄完整分析

• Agentic Permissions Policy Algebra for Taint Confinement in LLM Agents — Kravchenko、Liventsev、Konstantinov、Iskhakov 與 Kukuy（Archestra AI，標記為供應商 COI），arXiv 2607.24625，2026-07-27，empirical。此處僅引用效用崩跌問題：§6–§7（以分支限制污點；bench-corp 表 3、APPA 對比 --max-forks 0 的因果實驗組、AgentDojo 負面結果及其成本拆分）與 §7–§8（兩項殘餘漏洞與 TCB 邊界）。Out-of-Band Prompt-Injection Defense 收錄完整分析，並附有對原始表 3 的剖析警告

• Agent Data Injection Attacks are Realistic Threats to AI Agents — Choi、Kim、Kang、Jeong、Xing 與 Lee（SNU / UIUC / Largosoft），arXiv 2607.05120，2026 年 7 月，empirical。§3（威脅模型、ADI 形式化 D=(D_T,D_U)、機率式分隔符注入）；§4（在 Claude in Chrome、Antigravity、Nanobrowser、Claude Code、Codex、Gemini CLI 上進行元素 ID／來源／工具呼叫注入 PoC）；§5（防禦分析，表 1）；§6（LLM ASR 表 2–3、AgentDojo 代理程式評估圖 9–10）；§C（電子郵件／Slack 變體）；§D（格式還原）；§E（PoC 執行軌跡）

• GhostJacking Attacks: Half of the Fortune 500 Run These Tools. Getting Blocked by the Firewall Was the Way to Take Over Their AI Agents — Sternberg、Poran 與 Bobrov（Tenet Threat Labs），GhostJacking Attacks，2026-08-09，DEF CON 34 主場議程，case-study（供應商撰寫，內文已處理 COI）。此處僅引用 Cloudflare 攻擊鏈中遭拒絕的命令式負載與遭接受的遙測資料對比，以及包含兩項真實錨點主張的負載。Observability-Pipeline Poisoning 收錄完整分析

• Utility Under Attack: Agent Memory Poisoning and the Limits of Content Screening and Provenance Ranking — Arulnidhi Karunanidhi（Quantify Labs Ltd，論文中未聲明 COI），Utility Under Attack，arXiv 2608.21230 v1，2026-08-21，empirical。此處僅引用 §2.4 與清單 1–2（無負載攻擊與可由結構偵測的注入項目對照）及 §6.2 的 360 個案例中零個遭篩除結果。Memory and Context Poisoning 收錄完整分析