Prompt Injection（提示注入）是攻擊者利用文字、文件或外部資料中的指令，誘導生成式 AI 忽略原本規則、改變任務，甚至誤用它可存取的資料與工具。它不是把程式碼塞進資料庫，而是利用大型語言模型同時把「指令」與「資料」當成文字理解的特性，讓不可信內容影響決策。
Prompt Injection 和傳統注入攻擊有什麼不同？
SQL Injection、Command Injection 通常利用明確的語法邊界與程式漏洞；Prompt Injection 面對的卻是機率式模型。模型可能看得懂一段文字，卻不一定能可靠判斷它是系統規則、使用者需求，還是文件裡刻意埋入的惡意指示。因此，單靠一句「不要違反規則」無法形成真正的安全邊界。
OWASP LLM01:2025 將 Prompt Injection 列為生成式 AI 的主要風險，並區分直接與間接兩種來源。NIST AI 100-2 E2025 也以對抗式機器學習分類說明提示注入與相關緩解思路。
直接與間接 Prompt Injection
直接 Prompt Injection
攻擊文字由使用者直接輸入聊天框，目的是要求 AI 改變既定角色、略過限制，或執行原本不該執行的動作。企業若只把模型接到一般問答，影響可能是錯誤回答；一旦模型能寄信、查客戶資料或呼叫系統，風險就會放大。
間接 Prompt Injection
惡意指令藏在 AI 會讀取的外部內容，例如網頁、PDF、Email、工單、共享文件或 RAG 知識庫。使用者可能只是請 AI 摘要一份文件，模型卻把文件中的隱藏指示當成任務的一部分。這類攻擊更難察覺，因為操作者未必看過原始內容。
企業最常遇到的四個攻擊面
- 文件與網頁摘要：不可信內容可能試圖改寫摘要目標或要求揭露其他資料。
- RAG 知識庫：被上傳或同步進來的文件，可能在檢索後影響模型回答。
- Email 與客服工單：外部寄件者可把指令藏在正常業務內容中。
- AI Agent：當模型具有檔案、郵件、資料庫或 API 權限，錯誤判斷可能變成真實動作。
因此，企業設計 AI 架構時，應把模型視為「可能被不可信內容影響的決策元件」，而不是永遠服從系統提示的確定性程式。可參考 AiLab 的平台架構，先把資料、模型與工具權限分層。
企業情境：摘要供應商文件為何也有風險？
假設採購部門讓 AI 讀取供應商提案，並自動整理價格與風險。如果提案文件含有要求模型忽略評分規則、隱藏特定缺點或存取其他文件的文字，模型可能產生偏誤結果。安全設計不應只檢查員工輸入，而要把供應商文件視為不可信資料，禁止摘要任務直接取得其他資料或執行採購動作。
Prompt Injection 的六層防護
- 縮小任務：為每個 AI 功能定義單一目的，避免一個提示同時負責讀取、判斷與執行。
- 區分可信度：明確標記系統指令、使用者輸入、外部文件與工具結果，不因來源看似正式就自動信任。
- 最小權限：模型只取得完成任務所需的資料與唯讀工具；高風險操作使用獨立服務帳號與短效授權。
- 人工核准：寄送郵件、刪除檔案、付款、修改帳號或對外發布前，要求人員確認完整內容與目的地。
- 輸入與輸出檢查：偵測異常指令、敏感資料、未知連結與超出任務範圍的回答，但不把單一過濾器當成萬靈丹。
- 持續測試與監控：保留去敏感化日誌，測試直接與間接情境，追蹤模型、知識庫及工具更新後的行為變化。
哪些做法容易形成錯誤安全感？
第一，只把系統提示藏起來。提示內容不公開可以降低部分探測，但不能防止模型受到外部資料影響。第二，只維護一份關鍵字黑名單。攻擊文字可以換句話說、跨語言或分散在多段內容，過濾器只能是其中一層。第三，讓同一個 AI 同時讀取機密資料又擁有對外工具，卻相信模型會自行判斷界線。真正的隔離必須由應用程式、身份權限與工具閘道執行。
此外，輸出看起來合理不代表流程安全。測試應觀察模型實際查了哪些資料、呼叫哪些工具、帶出哪些參數，而不只評估最後文字。企業也應為每次高風險動作保留可稽核的核准者、目的地與結果。
這些控制也要隨模型、Prompt、資料來源與工具版本更新重新驗證，不能只在首次上線時測一次。
上線前檢查表
- 外部文件是否與系統指令分開處理？
- 模型是否能讀取超出目前使用者權限的資料？
- 高風險工具是否預設唯讀並要求人工核准？
- 輸出是否會在寄送、儲存或執行前再次檢查？
- 是否有測試間接 Prompt Injection 與權限濫用？
- 事件發生時，能否停用工具並追查受影響資料？
結論：Prompt Injection 不能只靠更長的提示解決
Prompt Injection 的核心問題是信任與權限。企業需要把不可信內容隔離、讓模型權限最小化、把重要動作交由確定性程式與人工核准，並持續測試。若正在規劃企業知識庫或 Agent，可先從 AiLab 的解決方案評估資料邊界與控制點。