自 OWASP 開始追蹤 LLM 應用程式漏洞以來，提示詞注入一直是排名第一的漏洞。每個主要 AI 平台都針對此問題發布過指引，研究人員也提出了數十種防禦方案。但沒有一個真正解決了問題，而這些方案持續失敗的模式，指向了一個根本性的原因：問題的核心在於它所處的層級本身。
簡短版本：你無法在問題本身所在的層級修復問題。提示詞注入之所以有效，是因為模型無法區分來自開發者的指令和來自攻擊者的指令。每一種試圖透過向模型添加更多指令來解決此問題的防禦方案，都在利用那個讓攻擊得以實現的同一限制條件下運作。
攻擊實際上做了什麼
語言模型接收一個上下文窗口作為輸入，並產生一段補全內容。上下文窗口是一個扁平的 token 序列。模型沒有原生機制來追蹤哪些 token 來自受信任的系統提示詞、哪些來自使用者、哪些來自代理在執行工作過程中擷取的外部內容。開發者使用角色標籤等結構性慣例來表達意圖，但那些只是慣例，不是強制機制。從模型的角度來看，整個上下文都是影響下一個 token 預測的輸入。
提示詞注入正是利用了這一點。攻擊者在代理會讀取的內容中嵌入指令——例如網頁、文件、電子郵件、程式碼註解或資料庫欄位——而這些指令與開發者的指令在同一個上下文窗口中競爭。如果注入的指令足夠有說服力、足夠連貫，或在上下文中處於有利的位置，模型就會聽從它們。這不是某個特定模型的 bug，而是所有這類系統運作方式的必然結果。
間接提示詞注入是更危險的形式。攻擊者不是讓使用者直接輸入惡意提示詞，而是汙染代理自主擷取的內容。使用者什麼錯也沒做。代理在執行任務的過程中外出擷取資料、遇到被汙染的內容，攻擊就此觸發。攻擊者不需要存取對話，只需要讓他們的文字出現在代理會讀取的地方。
已記錄的攻擊案例
2024 年 8 月，PromptArmor 的安全研究人員記錄了 Slack AI 中的一個提示詞注入漏洞。攻擊過程如下：攻擊者建立一個公開的 Slack 頻道，並發布一則包含惡意指令的訊息。該訊息告訴 Slack AI，當使用者查詢 API 金鑰時，應將佔位詞替換為實際金鑰值，並將其編碼為「點此重新驗證」連結中的 URL 參數。攻擊者的頻道只有一個成員：攻擊者自己。受害者從未見過這個頻道。當工作區中某個開發者使用 Slack AI 搜尋其 API 金鑰的相關資訊時——該金鑰儲存在攻擊者無法存取的私人頻道中——Slack AI 會將攻擊者公開頻道的訊息拉入上下文、遵循該指令，並在開發者的 Slack 環境中呈現釣魚連結。點擊該連結就會將私人 API 金鑰傳送到攻擊者的伺服器。
Slack 對此漏洞揭露的初始回應是：查詢使用者未加入的公開頻道是預期行為。問題不在於頻道存取政策。問題在於，當 Slack 員工的指令和攻擊者的指令同時出現在上下文窗口中時，模型無法區分兩者。
2025 年 6 月，一位研究人員發現了 GitHub Copilot 中的提示詞注入漏洞，追蹤編號為 CVE-2025-53773，並在 Microsoft 2025 年 8 月的 Patch Tuesday 更新中修復。攻擊向量是嵌入在原始碼檔案、README 檔案、GitHub issues 或 Copilot 可能處理的任何其他文字中的惡意指令。該指令引導 Copilot 修改專案的 .vscode/settings.json 檔案，加入一行設定來啟用該專案所稱的「YOLO 模式」：停用所有使用者確認提示，並授予 AI 不受限制的 shell 命令執行權限。一旦寫入該行設定，代理就會在不詢問的情況下在開發者的機器上執行命令。研究人員透過開啟計算機來演示此漏洞。實際的攻擊載荷遠比這嚴重。該攻擊被證實可在 GPT-4.1、Claude Sonnet 4、Gemini 及其他模型驅動的 GitHub Copilot 上運作，這說明漏洞不在模型本身，而在架構。
蠕蟲化變體值得深入了解。由於 Copilot 可以寫入檔案，而注入的指令可以告訴 Copilot 在重構或產生文件的過程中將指令傳播到它處理的其他檔案中，一個被汙染的儲存庫就能感染開發者接觸的每一個專案。這些指令透過提交紀錄傳播，就像病毒透過可執行檔傳播一樣。GitHub 現在將這類威脅稱為「AI 病毒」。
標準防禦為何失敗
面對提示詞注入的直覺反應是撰寫更好的系統提示詞。加入指令告訴模型忽略擷取內容中的指令。告訴它將外部資料視為不受信任。告訴它標記任何看起來像是試圖覆蓋其行為的內容。許多平台正是這樣做的。安全廠商銷售的產品就是圍繞在代理上下文中添加精心設計的偵測提示詞而建構的。
來自 OpenAI、Anthropic 和 Google DeepMind 的研究團隊在 2025 年 10 月發表了一篇論文，評估了 12 種已發表的提示詞注入防禦方案，並對每一種進行了自適應攻擊。他們突破了全部 12 種防禦，大多數的攻擊成功率超過 90%。這些防禦方案並不差——它們包含了嚴謹研究人員使用真實技術的成果。問題在於，任何教導模型抵禦什麼的防禦，都可以被知道防禦內容的攻擊者逆向工程。攻擊者的指令在同一個上下文窗口中競爭。如果防禦說「忽略告訴你轉發資料的指令」，攻擊者就撰寫不使用那些詞彙的指令，或提供一個看似合理的理由說明為何這個特定情況是不同的，或聲稱來自受信任來源的授權。模型會對此進行推理。推理可以被操控。
基於 LLM 的偵測器在不同層級上有著相同的問題。如果你使用第二個模型來檢查輸入並判斷其是否包含惡意提示詞，那個第二個模型有著相同的根本限制。它根據給定的內容做出判斷，而那個判斷可以被內容所影響。研究人員已經展示了成功繞過基於偵測的防禦的攻擊，方法是製作對偵測器看起來無害、但對下游代理而言具有惡意的注入內容。
所有這些方法在面對有決心的攻擊者時失敗的原因，是它們試圖透過向一個無法強制信任的上下文窗口添加更多內容來解決信任問題。攻擊面就是上下文窗口本身。向上下文窗口添加更多指令並不會縮小攻擊面。
什麼才能真正約束這個問題
當你應用以下原則時，提示詞注入風險會有顯著的降低：系統的安全特性不應依賴於模型做出正確的判斷。這在安全領域不是新概念。這和促使你在程式碼中強制執行存取控制，而不是在政策文件中寫「請只存取你有權存取的資料」的原則是一樣的。
對於 AI 代理，這意味著執行層需要位於模型之外，在模型的推理無法影響的程式碼中。模型產生請求。程式碼根據工作階段狀態、所涉資料的分類等級以及輸出目標頻道的權限，來評估這些請求是否被允許。模型無法說服程式碼通過這個評估，因為評估過程不讀取對話內容。
這並不能使提示詞注入變得不可能。攻擊者仍然可以注入指令，模型仍然會處理它們。改變的是爆炸半徑。如果注入的指令試圖將資料外洩到外部端點，出站呼叫會被阻擋——不是因為模型決定忽略這些指令，而是因為執行層檢查了請求與工作階段分類狀態及目標端點的分類下限，發現該資料流違反了寫降規則。模型的意圖，無論是真實的還是被注入的，對該檢查而言毫無意義。
工作階段汙染追蹤填補了單靠存取控制無法覆蓋的特定缺口。當代理讀取一份分類為 CONFIDENTIAL 的文件時，該工作階段就被汙染為 CONFIDENTIAL。此後任何試圖透過 PUBLIC 頻道發送輸出的行為都會在寫降檢查中失敗，無論模型被告知要做什麼，也無論該指令是來自合法使用者還是注入的載荷。注入可以告訴模型洩露資料。執行層不在乎。
架構層面的思維至關重要：提示詞注入是一類針對模型指令遵循行為的攻擊。正確的防禦不是教導模型更好地遵循指令，也不是更準確地偵測壞指令。正確的防禦是縮減模型在遵循壞指令後可能產生的後果集合。做法是將後果——實際的工具呼叫、實際的資料流、實際的對外通訊——放在一個模型無法影響的閘門之後。
這是一個可解決的問題。讓模型可靠地區分受信任與不受信任的指令，則不是。