先說結論：提示注入不是「AI 版 SQL Injection」，而是更麻煩的東西
如果你把提示注入想成「把惡意字串塞進模型，讓它做錯事」，這個理解沒有錯，但只說對了一半。
它真正可怕的地方，不在於攻擊者多會寫 prompt，而在於今天的大型語言模型，從根上就沒有一條像傳統系統那樣清楚的邊界，去分開「可信的指令」和「不可信的資料」。在資料庫世界，工程師知道要做參數化查詢；在作業系統世界，我們知道要做權限隔離；在瀏覽器世界，我們知道要處理不可信內容的沙箱。但到了 LLM，開發者的系統指令、使用者輸入、外部文件、網頁內容、Email、圖片文字、工具輸出，最後往往都被拼進同一段上下文裡。
模型看見的，不是「誰有權限說話」，而只是下一個 token 應該長成什麼樣。
這就是為什麼提示注入到 2026 年都還穩坐 OWASP LLM Top 10 的第一名。它不是一個被 patch 完就能關帳的 bug；更像是一種會隨著 AI 能力擴張而同步膨脹的結構性風險。
一、縱向分析：提示注入是怎麼從一個「怪現象」，長成 AI 系統的頭號安全問題
1. 在它被命名之前，問題其實已經存在了
提示注入不是在 2022 年才突然出現在世界上。真正更早發生的是：大型語言模型開始被拿來做「可被外部文字驅動的應用」時，脆弱性就已經埋好了。
早期的 GPT-3 應用有個很典型的開發方式：工程師先寫一段自然語言指令，再把使用者輸入用字串拼接進去。這種方法在產品上極其方便，因為你幾乎不用寫一堆規則，就能讓模型做摘要、翻譯、分類、改寫、客服回覆。
但它同時也把兩件本來應該被分開的東西放在一起：一個是「系統想讓模型做什麼」，另一個是「外部送進來的內容」。
在傳統軟體世界，這種把指令與資料混在一起的設計，是安全工程師一眼就會起雞皮疙瘩的事。只是當時生成式 AI 還在爆發前夜，多數人先注意到的是它會寫詩、會對話、會總結，而不是它也會被「說服」。
換句話說，提示注入一開始不是以「攻擊技術」的姿態出現的，而是作為一個讓人尷尬又著迷的現象： 為什麼只要多說幾句話，模型就會忘記自己原本要做什麼？
2. 2022：它先被觀察，再被命名，最後被學術化
2022 年秋天，是提示注入真正被看見的起點。那一年，安全研究者與開發者開始公開展示：只要在輸入裡加入類似「忽略之前的指示」這種語句，就能讓 GPT-3 類系統偏離原任務。
Simon Willison 在 2022 年 9 月對這類現象做了集中討論，並推廣了「prompt injection」這個說法，讓它從零散技巧變成一個可被命名、可被討論的漏洞類別。
同年 11 月，Fábio Perez 與 Ian Ribeiro 發表〈Ignore Previous Prompt: Attack Techniques for Language Models〉，這是第一批把提示注入正式寫成研究論文的工作之一。它不只是展示模型會被誘導，更重要的是替這個領域建立了兩個後來反覆被引用的基本分類：
- 目標劫持（goal hijacking）： 把模型從原任務拉去做別的事
- 提示洩漏（prompt leaking）： 讓模型吐出不該被看到的系統指令
這個節點非常重要，因為它把「社群玩梗」變成了「安全問題」。從這一刻起，提示注入不再只是大家拿 ChatGPT 類產品測邊界的花招，而是開始被視為：只要你把 LLM 嵌進真實業務流程，就可能要面對的風險。
但那時候，問題看起來還沒有那麼大。原因很簡單：大多數模型還只能「說」，不能真正「做」。
3. 2023：真正的轉折，不是 ChatGPT 爆紅，而是「間接提示注入」的出現
2023 年的關鍵轉折，不在於更多人知道 ChatGPT，而在於研究社群開始意識到：最危險的攻擊者，可能根本不需要直接跟模型對話。
Kai Greshake 等人在 2023 年提出「間接提示注入」這個框架後，整個問題的性質變了。如果攻擊者可以把惡意指令藏在網頁、文件、Email、知識庫、RAG 檢索結果裡，那麼攻擊入口就不再是聊天輸入框，而是整個外部世界。
這意味著什麼？ 意味著你不是在防一個惡意使用者，而是在防模型會讀到的一切內容。
這一年發生的另一件大事，是 Bing Chat／Sydney 的一連串公開事件。大家原本把它當成新一代搜尋與對話產品來看，但很快就發現：一旦模型有更長上下文、更強人格持續性、更複雜的系統提示，它也更容易暴露內部規則、偏離產品設計意圖、被外部文字牽著走。
Johann Rehberger 等研究者後來持續針對 Bing、Copilot、ChatGPT、Gemini 做的實測，基本上都在放大同一件事：一旦模型開始處理外部內容，提示注入就不再是「聊天安全」問題，而是「系統安全」問題。
也是從這時起，產業開始出現一種新的認知：RAG 不是 prompt injection 的解藥。 很多人原本以為，把知識做成檢索增強，模型就會「更聽資料」而不是「更聽胡話」。實際上，RAG 只是把更多不可信內容穩定送進上下文，讓攻擊面從一段對話變成一個知識管線。
4. 2024：從聊天問題升級成代理問題，風險開始有了「後果」
如果說 2022 到 2023 年，人們主要還在看見模型「說錯話」，那麼到了 2024 年，關注焦點已經明顯轉向：當模型能呼叫工具、讀寫檔案、存取記憶、觸發工作流之後，提示注入會造成什麼後果？
這一年，OWASP 將 Prompt Injection 放在 LLM 應用風險清單的最前面。這個排序很有象徵意義。它傳達的不是「這是最常見的攻擊技巧」，而是「這是最基礎、最會牽動其他風險的源頭型問題」。
一個被注入的模型，可能進一步造成敏感資料外洩、過度代理、錯誤輸出被下游系統執行、向量檢索被污染，甚至把整個流程變成攻擊跳板。
Johann Rehberger 在這個階段的研究尤其有代表性。他持續展示，提示注入不一定要當場發作，它可以是延遲的、間接的、跨回合的，甚至可以利用記憶功能留下持久影響。這讓產業第一次大規模意識到：如果模型有 memory，它就不只是被騙一次，而是可能被種下長期偏差。
這也是為什麼 2024 年之後，安全社群開始不滿足於「寫更強的 system prompt」這種做法。因為問題已經很清楚：靠自然語言去要求模型「請不要被別的自然語言騙」，這件事本身就很不穩。
5. 2025：產業終於承認，這不是靠幾句護欄提示就能解掉的事
2025 年，提示注入研究進入一個成熟但也更現實的階段。業界終於比較少再說「我們有個模型防禦技巧可以解決它」，而開始轉向兩種更務實的方向：
第一種是承認殘餘風險。 像 OpenAI、Anthropic、Microsoft、Google DeepMind 都在 2025 年陸續公開談 prompt injection，而且措辭越來越一致：這是一個前沿安全挑戰，當代理系統能瀏覽、讀郵件、操作工具、代表使用者行動時，風險不會下降，只會上升。
英國 NCSC 在 2025 年底甚至明確提出：**不要把 prompt injection 當成 SQL injection 的翻版，它可能永遠無法像 SQL injection 那樣被「徹底修掉」。**這句話很重，但它說中了核心。
第二種是從模型內部對抗，轉向系統外部設計。 最具代表性的，是 Google 與 DeepMind 提出的 CaMeL。它的思想很像是在說：既然我們不能期待模型天然分清楚指令與資料，那就不要讓它自己掌握真正的控制流。它把「能做什麼」與「能看到什麼」拆開，用能力約束、資料流追蹤、受限執行的方式，把 LLM 從主控者降成一個參與者。這是提示注入防禦史上很重要的分水嶺，因為它不再幻想靠更好的提示詞讓模型變安全，而是把安全責任移回架構設計。
同年還有兩個標誌性事件，讓「提示注入已進入真實世界」這件事徹底坐實：
- **Google DeepMind 對 Gemini 抵禦間接提示注入的系統化研究。**反映出主流模型供應商已不再只是被動修洞，而是開始做持續、對抗式、近似紅隊化的自動評估。
- **Microsoft 365 Copilot 的 EchoLeak（CVE-2025-32711）。**這起事件之所以震撼，不只是因為它發生在企業生產環境，更因為它被描述為一種「零點擊」式的 AI 漏洞案例：攻擊者只要把惡意內容送進系統會檢索到的地方，之後使用者在正常問問題時，Copilot 就可能把本不該外送的資料帶出去。
從安全史的角度看，這非常重要。它代表 prompt injection 不再只是「模型被哄騙輸出奇怪內容」，而是開始具有傳統資安漏洞會有的屬性：可分配 CVE、可評估 CVSS、可進入企業風險治理流程。
6. 2025 下半年到 2026：研究開始變成熟，結論也變得更殘酷
2025 年 10 月那篇由 OpenAI、Anthropic、Google DeepMind 等研究者共同參與的論文〈The Attacker Moves Second〉，幾乎可以視為這一輪研究的里程碑。
它最刺耳、也最重要的結論是：很多看起來有效的防禦，只是因為評估太弱。 一旦攻擊者會根據你的防禦策略調整招式，也就是做「自適應攻擊」，不少宣稱很強的方案，成功率會大幅上升，甚至被攻破。
這篇研究的真正意義，不是告訴大家「所有防禦都沒用」，而是把防禦評估的門檻拉高。從此之後，你不能只拿幾組固定 payload 擋住，就宣稱自己有 robust defense。你得假設攻擊者會看懂你的設計，然後故意繞過它。
到了 2026 年，OWASP AISVS 等實務指南開始把這種認知制度化：
- 外部輸入、工具輸出、檢索內容、記憶讀寫、代理間訊息，都必須預設為不可信；
- 單靠模型對齊或 system prompt 無法視為充分防護；
- 真正可行的只剩下分層防禦、最小權限、人工確認、資料與控制流隔離、持續紅隊測試。
走到這一步，提示注入的故事其實已經很清楚了：它不是一個從 0 到 1 被發明出來的攻擊，而是一個在 LLM 應用從聊天走向代理的過程中，被逐步放大、最後無法再被忽視的結構性問題。
二、橫向分析：當前主流防禦路線，究竟誰在解什麼問題？
先判斷競品場景
「提示注入與防範」本身不是一家公司，也不是單一產品，因此它不適合用傳統「A 對 B 對 C」的產品競品方式比較。更準確的說法是：當前沒有一個公認可徹底解決 prompt injection 的單一路線，但已經出現幾條主流防禦範式，它們彼此競爭、互補，也各自暴露盲點。
以下我把今天最有代表性的五條路線拆開看：
- 提示工程型防禦
- 檢測與過濾型防禦
- 架構隔離型防禦
- 權限與流程治理型防禦
- 評估與紅隊型防禦
1. 提示工程型防禦：最便宜、最先上線，也最容易讓人高估
這一路線是大家最早採用的：在 system prompt 裡明確寫規則、重申優先級、標記不可信內容、提醒模型不得執行文件中的指令，甚至用 prompt sandwich、spotlighting、資料標記等技巧，盡量讓模型知道「哪一段是指令、哪一段是資料」。
它會流行很正常，因為成本低、導入快、幾乎不用改整體架構。Microsoft 的 Spotlighting、不少 guardrail 產品、還有很多企業內部 Copilot 實作，第一層幾乎都是從這裡開始。使用者與開發團隊喜歡它的真實理由，是它很符合軟體交付現場的節奏：需求來了，先加幾條規則；出現一個繞過案例，再補幾條規則；像在維護黑名單與 prompt policy 的混合體。
問題也正好在這裡。 這條路線最大的短板不是完全沒效，而是容易對已知攻擊有效，對未知攻擊脆弱。尤其面對間接提示注入、語意變形、多輪對話、延遲觸發、跨工具鏈路時，單靠文字層規則很容易失守。《The Attacker Moves Second》之所以讓人警醒，就是因為它直接證明：很多提示工程型防禦，在靜態 benchmark 上看起來漂亮，一遇到自適應攻擊就垮得很快。
所以它在生態位上的角色，比較像「必要但不充分的第一層」。沒有它，系統通常更脆；只有它，系統往往只是把危險包裝得更像安全。
2. 檢測與過濾型防禦：看起來像傳統資安，但天花板也很明顯
第二條路線，是把 prompt injection 當成一種可被辨識的攻擊模式，於是做分類器、過濾器、tripwire、內容檢查、tool-call 檢查、輸出檢查。OpenAI 的 guardrails、Microsoft Prompt Shields、各類企業安全產品，基本都屬於這一脈。
它的優勢在於工程上很容易被接受。安全團隊熟悉這套語言：偵測、告警、阻擋、關聯分析、SOC 可視化、XDR 串接。在企業治理層面，這條路線很有吸引力，因為它不像純 prompt engineering 那樣「全靠模型自己懂」，也不像架構改造那樣昂貴。它更像是在既有 AI 系統上加一層可觀測、可營運、可稽核的安全控制面。使用者的真實口碑也通常不差，因為它能擋住大量粗糙、重複、低成本的攻擊。
但安全研究者最常吐槽的，也正是這類方案：它們容易被評估高估，也容易被資料集綁架。 原因很直接。如果分類器訓練的是已知樣式，而攻擊者可以自由換語言、換話術、換格式、拆分 payload、藏在圖片或文件結構裡，那麼檢測模型的泛化能力就會面臨很大壓力。Microsoft 自己也承認，真正的防禦不能只停在檢測；一旦注入成功，還需要下游影響控制。這其實已經等於承認：檢測層重要，但它不該被視為最後一道門。
所以這一路線的最好位置，不是「神盾」，而是「雷達」。它適合提高可見性、降低大宗低階攻擊的命中率，但很難單獨扛住高價值、有針對性的攻擊者。
3. 架構隔離型防禦：最有機會真正降風險，但也最難導入
如果提示注入的根本問題，是模型分不清資料與指令，那最直接的做法就不是再要求模型分清楚，而是把系統設計成即使模型搞混，也不容易造成嚴重後果。Google DeepMind 的 CaMeL，是目前這條路線最具代表性的方案。
它背後的理念很像經典安全工程：控制流完整性、能力限制、資訊流約束、最小權限。核心思想很簡單：
- 讓 LLM 負責理解與規劃，但不要讓它直接決定高風險動作；
- 讓不可信資料只能進入隔離區；
- 讓每一份資料都帶著來源與可用範圍；
- 讓工具呼叫與敏感資訊外流都經過明確政策。
這種做法在工程師眼中很「像正道」，因為它終於把安全責任從文案層搬回系統層。但它也是最難推動的一條路，因為它幾乎意味著：你不能再把 LLM 當萬能 orchestrator，很多既有 agent 設計都要重寫。
使用者真實感受也會很分裂。安全導向團隊通常會很喜歡，因為它給了系統可證明、可推理的邊界。產品導向團隊則常覺得它太重、太慢、太限制代理的自由度，導致「AI 沒有想像中聰明」。這其實就是提示注入防禦最現實的矛盾：越自由的 agent，越難安全；越安全的 agent，越不像大家在 demo 裡想像的那種全能助手。
如果問今天哪條路線最可能成為長期主流，我會押這條。不是因為它已經成熟，而是因為它最符合 2025 之後逐漸形成的產業共識：prompt injection 不是主要靠模型內部訓練修掉，而是要靠外部架構把傷害面縮小。
4. 權限與流程治理型防禦：它不帥，但往往最有用
這條路線不太容易在論文標題裡發光，卻是企業真正能落地的主幹。它包含的其實是很多看起來「不 AI」的東西：最小權限、工具白名單、資料分級、敏感操作需人工確認、外發內容審批、DLP、審計紀錄、會話隔離、fresh context、權責切分。
Meta 在 2025 年提出的「Agents Rule of Two」很能代表這種思路。它不是在問你能不能阻止 prompt injection，而是在問：即使注入成功，這個 agent 是否還有能力造成高衝擊後果？ 如果一個 agent 同時具備三件事——可處理不可信輸入、可存取敏感資料、可對外溝通或改變外部狀態——那它就是高危組合。
這個框架之所以受到重視，是因為它從「如何完全阻擋」退了一步，轉向「如何避免高後果組合」。這條路線的使用者口碑通常來自兩件事：一是它真的有效；二是它跟既有資安治理體系相容。缺點當然也很明顯：體驗常常變差。你想做全自動代理，它偏要你人工確認；你想讓 Copilot 幫你順手寄出東西，它偏要審批；你想讓 AI 自主決策，它偏偏把權限拆碎。但如果把產品從 demo 搬到金融、醫療、政府、大型企業，這些「不順手」常常才是代價最小的選擇。
5. 評估與紅隊型防禦：它不是防線本身，卻決定你是不是在自欺欺人
最後一條路線，是持續對抗式評估。它的重要性在 2025 年之後急速上升，原因很簡單：提示注入不像靜態漏洞，它更像一場互相學習的攻防遊戲。今天有效的防禦，明天可能就被換一種說法繞過。
Anthropic 的挑戰賽、Google DeepMind 對 Gemini 的持續自動化對抗測試、OpenAI 對 prompt injection 的公開安全說明，還有 2025 年那篇自適應攻擊研究，共同強化了一個觀念：防禦不是發布時的一個功能，而是營運中的一個流程。
這條路線的優勢，是它最誠實。它不承諾你已經安全，而是幫你不斷發現哪裡其實不安全。對成熟團隊來說，這幾乎是必備能力；對預算有限、組織尚未建立 AI 安全節奏的團隊來說，這又往往是最先被省掉的部分。但如果沒有它，前面所有防禦都可能只是紙上防禦。提示注入這個領域近兩年的一個殘酷教訓就是：很多控制項不是完全沒用，而是它們只在「別人沒認真打你」的時候看起來有用。
三、趨勢判斷：提示注入會往哪裡走？
從今天回頭看，提示注入的發展方向已經非常清楚。
第一，它會從文字問題，繼續擴大成代理系統問題。 隨著模型擁有更多工具、記憶、跨系統操作能力，prompt injection 的價值只會上升。過去它常常造成的是內容偏移、規則繞過、系統提示洩漏；未來更值得擔心的是：資料外洩、未授權操作、工作流污染、持久記憶污染、多代理橫向擴散。
第二，防禦重心會從「讓模型更聰明」轉向「讓系統更保守」。 從 2022 到 2024，很多人直覺是：只要模型更懂規則、對齊更好、提示寫更精準，就能擋住。到 2025、2026，主流結論逐漸轉成：模型強化有幫助，但真正能顯著降風險的，是架構隔離、最小權限、能力切分、人工確認與可觀測性。
第三，企業會越來越把 prompt injection 納入正式風險治理，而不是模型 QA。 EchoLeak 這類案例的意義，不只是新聞性，而是它把 prompt injection 拉進了傳統企業安全語境。當它開始有 CVE、CVSS、修補說明、供應商安全公告，它就不再只是 AI 團隊的「模型調整議題」，而是資安、法遵、風控都必須面對的治理對象。
第四，「沒有萬靈丹」會成為常識。 這可能是未來兩三年最重要、也最不討喜的共識。不會有一個神奇分類器、神奇 system prompt、神奇防火牆，讓 prompt injection 從此消失。真正成熟的組織，會把它當成一個需要被持續管理、持續演練、持續限縮爆炸半徑的長期風險。
四、橫縱交匯：提示注入現在站在什麼位置，未來又會把 AI 帶到哪裡？
如果把縱向歷史和橫向格局疊在一起看，提示注入其實揭露了一個更大的事實：我們正在把一種本質上沒有權限邊界概念的技術，接上越來越多有真實權限後果的系統。
這就是為什麼它從 2022 年看起來像個「有趣的奇技淫巧」，到 2026 年已經變成企業 AI 安全治理的主軸之一。問題沒有變簡單，是因為 LLM 的角色變重了。模型一旦從聊天工具變成會讀你的文件、替你搜資料、代表你做事、替你記住偏好、串你的辦公系統，那麼 prompt injection 就不再只是「模型講了不該講的話」，而是「它會不會拿著你的權限做不該做的事」。
這也說明了一件很關鍵的判斷：提示注入的未來，不會主要由攻擊技巧決定，而會由 AI 產品設計哲學決定。 如果產業繼續迷戀「一個萬能代理接所有資料與工具」的敘事，那 prompt injection 只會變成更常見、更高價值、也更難補救的攻擊面。
如果產業接受「能力必須分層、資料必須分級、動作必須審批、上下文必須刷新、模型不能獨掌控制權」這些看似保守的原則，那 prompt injection 依舊存在，但它造成的後果會被壓到可治理範圍內。
所以，對 prompt injection 最準確的總結，不是「它能不能被消滅」，而是： 它正在迫使 AI 產業補上自己早期高速成長時跳過的那堂課：安全邊界。 而這堂課的代價，正由每一個想把 LLM 變成企業級代理的人，逐步承擔。
資料來源
以下依主題整理，供文末統一查核與延伸閱讀：
一、起源與早期研究
- Simon Willison, Prompt injection（系列文章，2022 起） https://simonwillison.net/series/prompt-injection/
- Fábio Perez, Ian Ribeiro, Ignore Previous Prompt: Attack Techniques For Language Models（arXiv:2211.09527, 2022） https://arxiv.org/abs/2211.09527
二、間接提示注入與攻擊面擴張
- OWASP, Prompt Injection https://owasp.org/www-community/attacks/PromptInjection
- OWASP, Top 10 for LLM Applications 2025 https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf
- Johann Rehberger, Hacking Gemini's Memory with Prompt Injection and Delayed Tool Invocation（2025） https://embracethered.com/blog/posts/2025/gemini-memory-persistence-prompt-injection/
三、供應商與研究機構的防禦觀點
- OpenAI, Understanding prompt injections: a frontier security challenge（2025） https://openai.com/index/prompt-injections/
- Anthropic, Mitigating the risk of prompt injections in browser use（2025） https://www.anthropic.com/research/prompt-injection-defenses
- Microsoft Security Response Center, How Microsoft defends against indirect prompt injection attacks（2025） https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks
- Google DeepMind, Lessons from Defending Gemini Against Indirect Prompt Injections（2025） https://storage.googleapis.com/deepmind-media/Security%20and%20Privacy/Gemini_Security_Paper.pdf
- Google / DeepMind / ETH Zurich, Defeating Prompt Injections by Design（CaMeL, arXiv:2503.18813, 2025） https://arxiv.org/pdf/2503.18813
四、真實世界事件與治理框架
- NVD, CVE-2025-32711（Microsoft 365 Copilot AI command injection） https://nvd.nist.gov/vuln/detail/CVE-2025-32711
- Pavan Reddy, Aditya Sanjay Gujral, EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System（arXiv:2509.10540, 2025） https://arxiv.org/abs/2509.10540
- UK NCSC, Prompt injection is not SQL injection (it may be worse)（2025） https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
- Meta AI（轉引與彙整可參考），Agents Rule of Two: A Practical Approach to AI Agent Security（2025） 可參考整理：https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/
五、最新防禦評估趨勢
- Milad Nasr 等，The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections（arXiv:2510.09023, 2025） https://arxiv.org/abs/2510.09023
- OWASP AISVS, Prompt Injection Defense（2026 研究更新） https://github.com/OWASP/AISVS/blob/main/wiki/C02-01-Prompt-Injection-Defense.md
