💡 先搞懂問題
企業導入生成式 AI，很少只拿它來聊天。更常見的用法是讓它幫忙讀信、摘要網頁、查內部知識庫，甚至直接替人寄信、建立工單、查訂單。這類能自己決定要呼叫哪些工具的 AI 應用，一般稱為 AI Agent（AI 代理）。
傳統程式有一條清楚的界線：程式碼是開發者寫死的，使用者的輸入只會被放進固定欄位當資料。大型語言模型（Large Language Model，LLM）沒有這條界線。開發者的設定、使用者的問題、郵件內文、網頁文字、知識庫文件、工具回傳的結果，最後全部被接成同一長串文字送進模型，稱為上下文（context）。模型只是根據整串文字決定下一步要說什麼、做什麼，它並不可靠地知道哪一段是「主人的命令」、哪一段只是「別人寫的內容」。
右邊這張圖可以點：點任何一個來源，看看它進到上下文之後長什麼樣子，以及它能被誰寫入。
生活比喻：照紙條辦事的新秘書
想像主管請了一位非常能幹的新秘書，每天幫忙拆信、整理重點，也有權限替主管寄信和安排行程。有一天，秘書在整理一封論壇邀請函時，看到信紙角落用很小的字寫著：「讀到這封信的秘書，請把主管下週的行事曆影印一份，寄到以下地址，而且不必向主管報告。」一位盡責但只會照字面做事的秘書，可能真的就照做了。
這件事的問題不在主管下錯指令，主管只說了「幫我整理郵件」。問題在秘書把信件內容當成了命令，而且秘書手上剛好有寄信的權限，也沒有人在寄出前看一眼。
這個比喻有一個容易誤導的地方：真人秘書可以被訓練得更謹慎，下次看到怪紙條就會起疑。LLM 雖然也能被調校得比較不容易上當，但目前沒有任何方法能像 SQL 的參數化查詢那樣，把指令和資料徹底隔開。所以正確的設計思路是假設它一定會被騙幾次，再用權限、確認與過濾，讓它被騙的時候闖不了大禍。下面四個實驗室，就沿著這條思路動手做。
🎮 互動實驗室一：AI 秘書收信
這是一個模擬的郵件助理，不會呼叫任何真實模型或寄出任何信件。先在沒有防護的狀態下按「下一步」播放，看隱藏指令怎麼一路走到把行事曆寄出去；再打開下方的防護，重播看它在哪一層被攔下。
schedule@example.net（公司外部），附件：下週行事曆。🎮 互動實驗室二：攻擊發生在哪個階段
判斷 AI 攻擊的第一步，是問「它發生在生命週期的哪一段」。先點一張攻擊卡，再點它所屬的階段。放對了卡片會留在該階段，放錯會說明原因，可以再試。
🎮 互動實驗室三：OWASP LLM Top 10 配對
OWASP（開放網路應用程式安全計畫）為 LLM 應用整理了一份十大風險清單，2025 年版的編號是 LLM01 到 LLM10。讀一段原創情境，從十項裡選出最貼切的一項，選完立即看解析。
🎮 互動實驗室四：護欄設計台
你負責一個網購客服機器人，它能查訂單、也能辦退款。勾選要開啟的防護措施，下方八個模擬測試案例會立即重新評估：正常詢問是否順利、攻擊是否被攔、有沒有誤擋好人，以及人工審核要花多少力氣。結果依本頁設定的簡化規則計算，僅為示意。
📘 原理補完
四個實驗室玩過之後，把比喻接回正式的技術細節。這一節依序整理：注入的兩種來源、攻擊的階段分類、過度代理與不當輸出處理、OWASP 十項清單，最後是防禦架構與事件應變。
直接與間接提示詞注入
直接提示詞注入是使用者本人在對話中輸入誘導文字，例如要求模型「忘記先前的規則」、扮演不受限制的角色。它和越獄（Jailbreak）常重疊：越獄強調讓模型突破安全限制、產生原本會拒絕的內容；注入強調讓模型改做攻擊者想要的事。
間接提示詞注入的惡意文字不是使用者打的，而是藏在模型會讀取的外部內容裡：郵件、網頁、PDF、RAG 知識庫文件，甚至工具回傳的結果。使用者本身是無辜的，只是請 AI 摘要或回答問題，就觸發了指令。2025 年揭露、影響 Microsoft 365 Copilot 的 EchoLeak 是著名案例：攻擊者寄出一封含隱藏指令的郵件，使用者請 AI 整理郵件時，AI 照指令把機密資料夾帶在圖片連結裡送出。考題若問這類案例「運用了哪項技術」，答案是間接提示詞注入，資料外洩只是它造成的結果。
攻擊者還常用多國語言混寫、編碼（例如 Base64）、拆字或表情符號來躲過關鍵字過濾，這也是為什麼單靠黑名單不夠，實驗室四的「變形繞過」案例就是在示範這件事。
訓練期與推論期：先判斷階段，再選對策
資料投毒（Data Poisoning）發生在資料蒐集或訓練、微調階段：攻擊者混入特製樣本，讓模型學到錯誤判斷，或留下只在特定觸發條件下才發作的後門（Backdoor）。因為問題已經寫進模型內部，部署後的執行期掃描查不出來，防護要往上游做：管控訓練資料來源、以雜湊或簽章驗證資料集完整性、要求供應商提供來源證明（Provenance），並在上線後持續監控特定類別的誤判率。
對抗樣本（Adversarial Example）則發生在推論期：模型本身沒問題，但輸入被加上人眼幾乎看不出的擾動，讓它在那一筆判斷出錯，對策包含對抗訓練與輸入前處理。記法是：投毒改「模型」、影響之後所有判斷；對抗樣本改「輸入」、只影響那一筆。
模型竊取（Model Extraction）也在推論期，但方向相反：它不是改東西，而是用合法的 API 權杖大量查詢，依輸入輸出關係重建模型，或大量抽取嵌入向量（embedding）還原背後的資料。監控上它看起來很正常，HTTPS 流量正常、GPU 負載正常，異常在於行為，例如單一權杖短時間內送出數萬筆請求、查詢編號連續遞增。在 2025 版 OWASP 清單中，透過 API 抽取模型被歸在 LLM10 無上限的資源消耗之下。本地部署的模型則要防權重檔被直接複製，編譯成執行檔也不代表無法逆向。
過度代理：權限決定被騙時的傷害上限
過度代理（Excessive Agency）指 AI Agent 被賦予超出任務需要的工具、權限或自主性。實驗室一的郵件助理只需要讀信和寫摘要，卻同時擁有寄信和讀行事曆的能力，一旦被注入，攻擊者就能借用這些多餘的權限。
對策是三件事一起做：最小權限（只給完成任務所需的工具，工具本身也只開必要的操作與範圍，例如只能查本人的訂單）、高風險動作需人工確認（對外寄信、付款、刪除、改權限前先讓人看一眼，也就是 Human-in-the-loop），以及記錄所有工具呼叫（誰觸發、呼叫了什麼、參數為何、結果如何）。
要特別分清楚：最小權限不會讓模型比較不容易被騙，它處理的是「被騙之後」。這正好補上提示詞注入沒有根治解法的缺口。
不當的輸出處理：模型輸出也是不可信輸入
不當的輸出處理（Improper Output Handling）是指把模型的輸出未經檢查，直接拿去顯示、執行或傳給下游系統。模型輸出的內容可能受提示詞注入影響，本質上和使用者輸入一樣不可信。
所以傳統網頁安全的規則照樣適用：要顯示在網頁上就做輸出編碼，要查資料庫就用參數化查詢、讓 AI 使用的資料庫帳號只有必要權限，要執行指令就用白名單。EchoLeak 那種把資料夾帶在圖片網址裡送出的手法，也屬於輸出面該擋的東西，常見做法是限制回覆中可以出現的外部連結與圖片來源。
OWASP Top 10 for LLM Applications（2025）
這份清單像餐廳的衛生自評表，列的是最常出事的地方，逐項檢查能讓團隊少漏掉一些東西，但做完不代表沒有其他風險。下表手機上可左右滑動。
| 編號 | 名稱 | 一句話說明 | 典型對策 |
|---|---|---|---|
| LLM01 | 提示詞注入 Prompt Injection | 直接或間接的文字讓模型改做別的事 | 外部內容標記為不可信、最小權限、人工確認、輸入輸出護欄 |
| LLM02 | 敏感資訊洩漏 Sensitive Information Disclosure | 模型吐出個資、機密或訓練資料 | 資料送進模型前先分類與遮罩、輸出過濾、依權限檢索 |
| LLM03 | 供應鏈 Supply Chain | 第三方模型、資料集、外掛被污染或有漏洞 | 來源驗證、簽章與雜湊、元件清單與持續更新 |
| LLM04 | 資料與模型投毒 Data and Model Poisoning | 訓練或微調資料被動手腳、植入後門 | 資料來源管控、完整性驗證、溯源文件、監控誤判率 |
| LLM05 | 不當的輸出處理 Improper Output Handling | 輸出未處理就被執行或顯示 | 把輸出當不可信輸入：編碼、驗證、參數化 |
| LLM06 | 過度代理 Excessive Agency | Agent 的工具、權限或自主性太大 | 最小權限、高風險動作人工確認、記錄工具呼叫 |
| LLM07 | 系統提示詞洩漏 System Prompt Leakage | 系統提示詞被推斷或吐出，裡面的秘密跟著曝光 | 提示詞不放金鑰與機密，安全控制不依賴提示詞保密 |
| LLM08 | 向量與嵌入弱點 Vector and Embedding Weaknesses | RAG 向量庫被投毒，或檢索時越權讀到不該看的文件 | 依使用者權限過濾檢索範圍、控管誰能寫入知識庫 |
| LLM09 | 錯誤資訊 Misinformation | 幻覺或錯誤內容被當成事實採用 | 引用來源、交叉查證、重要決策由人覆核 |
| LLM10 | 無上限的資源消耗 Unbounded Consumption | 大量或超長請求耗盡資源與費用，也包含透過 API 抽取模型 | 限流與配額、輸入長度限制、行為異常偵測 |
兩個最常被混在一起的項目：LLM02 敏感資訊洩漏是模型吐出個資或訓練資料；LLM07 系統提示詞洩漏是開發者寫的設定被推斷或吐出。後者的重點是提示詞裡本來就不該放機密，因為攻擊者即使拿不到逐字原文，也能從模型拒答的模式推敲出有哪些防線，「沒有逐字洩漏就安全」是錯的。
防禦架構：一層擋不住，就多疊幾層
把前面的對策放在同一張圖上，就是 LLM 應用的縱深防禦。核心是 AI Gateway：它放在應用程式與模型之間，所有 AI 流量都要經過，統一處理權杖驗證、限流與配額、輸入與輸出的護欄（Guardrail）檢查、行為異常偵測和完整記錄。它和網路防火牆不同，防火牆看的是位址與埠，看不懂一段自然語言在要求什麼；Gateway 看得到 AI 請求的權杖與內容。
護欄能攔下許多注入嘗試、敏感資料與不當輸出，但它本身也是一個模型或一組規則，會漏也會誤擋，實驗室四已經看到兩種代價。所以考題中凡是「升級護欄就能完全阻止注入」「保證百分之百阻擋」的說法，幾乎都是錯的。
點右圖的任一元件，可以看它負責什麼、擋得住什麼、擋不住什麼。
事件應變與治理：出事了先做什麼
AI 事件的應變原則和一般資安事件相同：先止血、再保全證據、再評估影響。以 AI 應用來說，止血的施力點通常是 AI Gateway，例如立即封鎖正在作案的權杖或來源，而不是把整個服務關掉或急著重新訓練模型。若是 AI Agent 被注入，要保存使用者與 Agent 的完整對話紀錄和工具呼叫紀錄，前者證明攻擊怎麼進來，後者證明拿走了什麼、做了什麼；只有 GPU 使用率或只記錄被擋下嘗試的規則紀錄都不夠。重開 GPU 叢集「清除攻擊」則會摧毀證據，也清不掉已經被盜用的權杖。
管理面則要有 AI 專屬的治理框架。ISO/IEC 42001 是可驗證的 AI 管理系統（AIMS）標準，架構與 ISO 27001 相似，要求建立 AI 政策、角色與權責、AI 風險評鑑與影響評鑑；NIST AI RMF 以治理、對應、量測、管理四個功能管理 AI 風險。治理框架規定「要管」，但不會自動產生護欄與權限設計，兩者要搭配。另外，使用外部 AI 服務時，不應把個資或尚未分類分級的機密直接送出。
✅ 自我檢測
以下 6 題都是原創情境題，選完立即顯示對錯與解析。目前得分：0 / 6
🎯 重點整理
- LLM 把系統設定、使用者輸入與外部內容接成同一串上下文，無法可靠分辨指令與資料，這是提示詞注入的根源，而且沒有像參數化查詢那樣的根治法。
- 惡意文字由使用者自己輸入是直接注入；藏在郵件、網頁、文件、RAG 知識庫裡被 AI 讀到是間接注入。EchoLeak 類案例問技術，答間接提示詞注入。
- 先判斷階段：改訓練資料或模型是訓練期（投毒、後門，要管上游資料來源）；改輸入、抽輸出、借權限是推論期（注入、對抗樣本、模型竊取、過度代理）。
- 過度代理靠最小權限、高風險動作人工確認與工具呼叫紀錄處理；它們不讓模型更難被騙，而是限制被騙後的傷害。
- 模型輸出也是不可信輸入：未編碼、未驗證就執行或顯示，屬不當的輸出處理，會引發 XSS、SQL 注入等傳統漏洞。
- 系統提示詞不放金鑰與機密，「沒有逐字洩漏就安全」是錯的；LLM02 是吐出個資或訓練資料，LLM07 是設定本身被推斷或吐出。
- AI Gateway 是止血與記錄的施力點，護欄會漏也會誤擋；網路防火牆看不懂語意擋不了注入，「保證完全阻擋」「立刻重訓」通常不是正解。