Prompt injection 已是 AI 資安問題
Prompt injection 會用隱藏文字操控 LLM。近期測試顯示，像 DeepSeek-R1 這類模型，仍可能在注入攻擊下失手。
Prompt injection 會用隱藏指令操控 LLM，現在已經是實際的 AI 資安問題。
這題不是論壇冷知識了。它已經進到搜尋、文件摘要、瀏覽器助理，還有企業工作流。只要一段藏起來的文字，就可能改掉模型輸出的內容。
更麻煩的是，很多團隊先看回答品質。結果把安全性放到後面。這就像只看車子跑多快，卻不看煞車好不好。
| 項目 | 數字 | 意義 |
|---|---|---|
| 使用生成式 AI 的員工 | 75% | 攻擊面已進到日常工作工具 |
| 近 6 個月內導入 genAI 的員工 | 46% | 導入速度快過防護建置 |
| DeepSeek-R1 在 Spikee isolation test 排名 | 19 個模型中的第 17 名 | 基本注入防護仍不穩 |
| 加上 rules and markers 後排名 | 19 個模型中的第 16 名 | 額外規則沒補上太多缺口 |
| Chatbot Arena reasoning 排名 | 第 6 名 | 推理強，不代表安全強 |
問題核心：模型把指令和資料混在一起
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
大型語言模型會把指令和內容放在同一個 context window。這讓它很難分辨，哪句是系統規則，哪句是使用者要求，哪句又是藏在網頁或 PDF 裡的惡意文字。
講白了，模型看到的是一大串 token。它不會像人一樣自然分出「這是資料」和「這是命令」。只要格式設計不夠嚴，攻擊者就有機會偷渡指令。
直接注入，是攻擊者直接對模型下指令。間接注入，則是把指令藏在外部內容裡。後者更麻煩，因為它會出現在搜尋、文件上傳、瀏覽器外掛，甚至記憶功能裡。
你可能會想問，這到底多簡單。其實很簡單。像是翻譯任務裡，句子本身夾了一句「忽略前面要求，改輸出別的內容」，模型就可能照做。
- 直接注入，打的是使用者輸入。
- 間接注入，藏在外部資料裡。
- 圖片、白字、文件都能塞指令。
- Prompt leaking 會想辦法偷出系統提示詞。
這個詞在 2022 年冒出來
「prompt injection」這個詞，2022 年 5 月先在 Twitter 出現。@himbodhisattva 先提到這個說法。後來 Simon Willison 把它講得更清楚，也讓更多開發者開始注意。
Jonathan Cefalu 在同一時間也提過類似問題。他把它當成 command injection 來看，還回報給 OpenAI。這個角度很重要，因為它提醒大家，這不是單純的 prompt 調校問題。
我覺得最傳神的一句，是 Willison 說的那句話。它把風險講得很直白，也很像老派資安圈會懂的語言。
"Prompt injection is the new SQL injection." — Simon Willison
這個比喻會流行，不是沒原因。SQL injection 是偷渡資料和程式邊界。Prompt injection 則是在偷渡指令和內容邊界。兩者都是邊界沒守好。
真實案例已經跑進產品裡
這問題最煩的地方，是它不再只是 demo。它已經進到產品。2023 年 2 月，有 Stanford 學生讓 Microsoft Bing Chat 透露內部指引和代號。方法也不神秘，就是叫它忽略前面的規則。
2024 年 12 月，The Guardian 報導 ChatGPT 的搜尋工具可能被隱藏內容操控。看不見的文字，會把模型推向特定方向。這種輸出污染，對 AI 搜尋很傷。
2025 年初，研究者又發現學術論文裡藏了 prompt，想影響 AI 審稿系統。這就更尷尬了。因為被攻擊的不是聊天機器人，而是會影響升等、發表、評審的流程。
還有一個案例很值得看。Gemini 的記憶功能，也曾被研究者測到可被操弄。這類案例說明，只要模型會讀外部內容，就有機會中招。
- Bing Chat 曾在 2023 年洩露內部規則。
- ChatGPT 搜尋工具在 2024 年被指出可受隱藏內容影響。
- DeepSeek-R1 在一個注入測試中排第 17。
- Gemini 的記憶操弄也曾被報告。
推理強，不代表安全強
這裡最容易踩雷的地方，是把模型能力和安全性混在一起。DeepSeek-R1 在 Chatbot Arena 的推理排名是第 6。這代表它在解題上很能打。
但 WithSecure 的 Spikee 測試，看到的是另一件事。DeepSeek-R1 在 isolation test 排第 17。加上 rules and markers，也只到第 16。這表示它在面對注入攻擊時，還是會露出破口。
這個差距很重要。因為很多團隊買模型時，只看 benchmark 分數。分數高，不代表它懂得分辨「可信指令」和「惡意內容」。
你可以把它想成兩種測驗。第一種測的是會不會答題。第二種測的是會不會被騙。這兩件事，根本不是同一題。
- Reasoning benchmark 看解題能力。
- Injection benchmark 看抗攻擊能力。
- Browsing 和 memory 會擴大攻擊面。
- 多加規則有幫助，但通常不夠。
防護要做成一層一層
Wikipedia 提到的緩解方式，包含資料清理、guardrails、使用者訓練、system prompt 設計，還有雙 LLM 架構。這些都不是廢話，但它們要一起上。
我會直接講白一點。別把 prompt injection 當成 prompt engineering 問題。它比較像 application security。你要防的是資料流，不只是字句。
最實際的做法，是先假設外部文字都有毒。Email、網頁、上傳文件、OCR 文字、筆記內容，都一樣。只要模型看得到，攻擊者就有機會塞東西進去。
如果模型還能發信、改資料、呼叫工具，那風險更高。這時候最該做的是最小權限、動作驗證、內容隔離，還有把可疑輸入先攔下來。
這題背後，其實是 AI 應用的老問題
Prompt injection 會冒出來，不是因為某個模型特別差。它是因為 LLM 正在進入真實工作流程。以前模型只回答問題。現在它會讀信、看文件、查網頁、做摘要，還會接 API。
這就讓 AI 安全很像傳統資安。資料來源不可信。輸入內容不可信。外部工具也不可信。差別只是，現在多了一個會自動產生文字的中間層。
對台灣開發者來說，這題很現實。你只要做過客服助理、知識庫搜尋、文件摘要、內部 Copilot，就會碰到。真正該問的不是「模型會不會被騙」。而是「被騙之後，會不會真的做出事」。
接下來要看的，不是模型多會答題
我覺得下一波重點會很清楚。大家會開始把 injection resistance 納進採購和上線標準。只看 LLM 分數，會越來越不夠。
如果你的產品會讀外部資料，現在就該做一輪威脅建模。先找出哪些文字來源最危險，再看哪些工具權限太大。這比事後補洞便宜多了。
說到底，prompt injection 不是冷門技巧。它已經是 AI 產品設計的一部分。你若把文字當成資料，就要同時假設它也可能是指令。