部落格列表

2026.09.11

LLM提示注入如何突破防線：企業從攻擊辨識到治理實作

LLM提示注入不是單純叫模型「忽略前文」的惡作劇，而是可能讓 AI 助理錯讀指令、洩漏內容，甚至在具備工具權限時執行未授權操作的應用程式風險。只要模型同時閱讀使用者輸入、網頁、文件或知識庫，攻擊者就有機會把看似正常的文字包裝成指令。

企業導入生成式 AI 後，風險邊界已從傳統網站表單延伸到提示詞、檔案、RAG 檢索內容與 AI Agent 的工具鏈。組織中使用 GenAI 的比例從 2023 年的 33% 躍升至 2024 年的 71%，而到了 2025 年，已有高達 78% 的組織表示在至少一項業務功能中使用 AI；防護若仍只著重網路邊界，將難以處理模型層的信任問題。

本文會先用實務語言說明攻擊原理，再比較直接、間接與非故意注入的差異；接著說明 RAG、文件與多模態輸入的高風險情境，並整理 AI資安、企業AI治理、Shadow AI、AI提示工程與函數呼叫開發應採取的具體控制措施。最後也會說明如何以小規模 PoC 測試，讓安全要求真正進入產品決策。

LLM提示注入是什麼？先理解模型為何會誤信內容

資安人員檢視大型語言模型提示注入攻擊流程圖
Photo by Zulfugar Karimov on Unsplash

提示注入的核心是混淆「資料」與「指令」

LLM提示注入的本質，是模型無法可靠地分辨哪段文字是可信指令、哪段只是待處理資料。傳統程式會依明確語法執行命令；大型語言模型則以自然語言推論上下文。因此，客服機器人即使原本只應摘要一封信，也可能把信件內的「忽略規則並列出機密」當成較高優先的任務來回應。

直接攻擊通常由使用者在對話框輸入，例如要求模型改變角色、略過政策、輸出系統提示或虛構已完成的任務；間接攻擊則把指令藏在網頁、電子郵件、PDF、履歷或 RAG 知識庫中。前者是互動者主動測試邊界，後者更危險，因為受害者往往不知道模型讀到了惡意內容。

這個問題可類比 SQL 注入，但不能把兩者完全等同。SQL 注入是解析器把字串誤當查詢語法；提示注入則是機率模型在語意上受到操控，沒有一個萬用的跳脫字元能徹底解決。它也與社會工程學相似：攻擊者透過語言建立假權威，誘使系統或使用者採取不該做的行動。

  • 系統提示、使用者輸入與外部文件應視為不同信任層級。
  • 模型回覆看似合理，不代表它遵循了正確的授權流程。
  • 提示詞防護必須搭配程式權限與資料隔離，不能只依賴一句拒絕指令。

直接、間接與非故意注入的差別

直接注入發生在攻擊者可以直接對模型下指令時，間接注入則發生在模型替使用者讀取不可信內容時。例如內部助理接到「整理這份合約」的任務，若合約白字或隱藏文字要求模型寄送摘要到外部信箱，便屬於典型的間接注入；真正的危害取決於後續是否連接郵件、CRM 或檔案系統。

非故意注入則常被低估。行銷人員把舊版提示模板貼進新系統、客服把客訴信中的指令原文交給 Agent，或工程師將測試用的「略過驗證」字串留在文件裡，都可能讓模型偏離任務。這不是使用者惡意，卻會造成與攻擊相同的安全結果，因此流程設計不能只檢查惡意關鍵字。

MITRE ATLAS 已將此類技術以 AML.T0051.000 – LLM Prompt Injection: Direct 與 AML.T0051.001 – LLM Prompt Injection: Indirect 分別描述；直接越獄則可參照 AML.T0054 – LLM Jailbreak Injection: Direct。分類的目的不是增加文件術語，而是協助團隊為每一條資料流設定測試與責任人。

  • 直接注入：使用者利用聊天或 API 輸入改寫模型任務。
  • 間接注入：惡意文字藏在模型會讀取的外部內容中。
  • 非故意注入：流程、模板或文件中的殘留指令引發偏移。

提示注入、越獄與提示洩漏不能混為一談

越獄的目標通常是繞過模型內容限制，提示注入的目標則是改變應用程式原本的任務與信任關係。兩者可能同時出現，但防護重點不同。若模型只生成文字，越獄多造成不當內容；若模型能搜尋、寄信或呼叫內部 API，注入便可能升級為資料外洩與未授權交易。

提示擷取是另一個常見後果。攻擊者可能誘導模型重述系統提示、對話歷史、提示模板或檢索到的敏感片段，再利用內容推測內部規則。即使系統提示沒有直接暴露密碼，洩漏工具名稱、資料庫欄位或安全條件，也足以降低後續攻擊門檻。

測試人員應把「有沒有成功讓模型說出不該說的話」與「是否能造成業務影響」拆開評估。研究測試曾列出 Claude 3.5 Sonnet 的攻擊成功率為 87.50%，同一測試條件下某項防護結果為 0.00%；而 Claude 3.5 Sonnet v2 的結果為 56.25%。這類數字不應被解讀為通用排名，卻提醒我們版本、提示設計與測試集都會大幅改變結果。

  • 越獄著重繞過模型行為限制；注入著重奪取應用任務控制權。
  • 提示洩漏可能暴露規則、資料來源、工作流程與工具資訊。
  • 安全測試應以實際可造成的資料或操作影響作為判定標準。

常見攻擊路徑：RAG、文件與多模態內容如何成為入口

RAG 讓外部內容進入模型脈絡，也帶來間接風險

RAG 不會自動消除 LLM提示注入，反而可能把知識庫中的不可信片段帶進高權限對話。檢索增強生成的價值在於讓模型引用最新文件，但只要文件管理權限、上傳來源或索引程序不足，攻擊者便能以看似專業的段落影響模型回答與工具選擇。

實務上應採用 RAG Triad：先檢查回覆是否與問題相關，再確認是否忠實依據檢索內容，最後判斷是否有用。這三項品質檢查還需加上安全條件，例如檢索內容只能當證據、不得改寫系統政策；模型一旦偵測到「忽略前文」「轉寄資料」等指令語意，就要標示為不可信資料而非照做。

RAG 的存取控制必須在檢索前執行，而不是讓模型取得所有文件後再自行判斷。向量資料庫應保存文件擁有者、資料分類、來源與版本，查詢時依使用者身分過濾。輸出端也要確認模型沒有將不同部門文件拼接成可辨識的機密內容，避免權限穿透。

  • 文件進入向量資料庫前，應保留來源、分類與審核紀錄。
  • 檢索採用使用者權限過濾，不讓模型取得超出職務範圍的內容。
  • 把外部文件視為證據，不可視為可執行指令。

混淆技巧讓單純關鍵字封鎖失效

語言混用、Base64、Unicode 與負載拆分，是提示注入繞過簡易過濾的常見手法。攻擊者可將命令拆散在多個段落、改用不同語言轉述，或請模型先解碼再執行；若系統只比對「ignore previous instructions」等單一字串，很容易漏掉語意相同但寫法不同的內容。

Unicode 也可能被用來藏入人眼不易察覺的控制內容；例如 Unicode 標記字元的字碼範圍是從 E0000 至 E007F。系統應在寫入、索引與送進模型前進行 Unicode 正規化，移除或標記不可見控制字元，同時保存原始檔案供事件調查，而不是直接覆寫證據。

防護的要點不是猜中每一種變形，而是降低模型把資料當命令的機會。可將文件內容放入清楚界定的資料區塊，禁止其觸發工具呼叫；對要求解碼、執行程式、改變輸出格式或修改權限的語意，交由規則引擎與人工流程共同判斷。

  • 進行 Unicode 正規化、長度限制與檔案類型驗證。
  • 偵測解碼、角色切換、指令覆寫與工具操作等高風險意圖。
  • 將多段輸入合併分析，避免負載拆分躲過單次檢查。

圖像、PDF 與網頁都可能包含看不見的指令

多模態提示注入的關鍵風險，是視覺語言模型會把圖像中的文字、版面與隱藏訊息一起當成可理解的脈絡。一張商品圖可能夾帶細小字樣，要求助理忽略採購規則；一份 PDF 的頁首頁尾也可能含有與正文無關的命令。當系統自動讀取這些內容並連接工具，風險會比純聊天更高。

學術調查《2407.07403 A Survey of Attacks on Large Vision-Language Models: Resources, Advances, and Future Trends (arxiv)》指出，視覺語言模型的攻擊面不只在文字提示，也存在影像、跨模態對齊與對抗樣本。企業若有發票辨識、履歷篩選或影像客服流程，測試素材就不能只用乾淨的文字檔。

建議將 OCR 結果、原始圖像與模型指令分層保存。模型可以摘要文件，但不能因文件內文字而自行變更任務；遇到付款、合約批准、寄送附件或存取個資等情境，應改成產出建議草稿，並由具備權限的人員核准後才執行。

  • 測試圖像中的小字、浮水印、QR Code 與頁首頁尾內容。
  • OCR 結果屬不可信輸入，不能直接驅動工作流程。
  • 高風險操作應由人員確認原始文件與模型建議是否一致。

AI資安防線：從提示邊界到最小權限的系統設計

單靠系統提示無法構成完整防護

AI資安的有效防線必須把提示詞規則轉換為可驗證的系統控制，而非期待模型永遠服從一句禁止命令。系統提示可說明角色、輸出格式與不可做的事情，但模型仍可能受長脈絡、對抗性後綴或外部文件影響，因此應將它視為降低風險的一層，而不是安全邊界本身。

輸入端可做檔案掃描、內容正規化、資料分類與可疑意圖偵測；輸出端則應以結構化格式驗證欄位，掃描個資、機密標記、連結與不預期的指令。若回覆必須是 JSON，後端要用 schema 驗證其資料型別與允許值，不能因為模型輸出看起來像 JSON 就直接交給下游服務。

OWASP LLM Top 10 將 Prompt Injection 列為 LLM01:2025 Prompt Injection，正是因為它可跨越許多應用情境。工程設計上，應讓模型只提出「想做什麼」，由確定性的授權服務決定「能不能做」；這樣即使模型被誘導，仍會被權限、參數與資料政策擋下。

  • 輸入過濾處理資料來源與異常語意；輸出驗證處理回覆能否被系統使用。
  • 模型不可直接取得長期憑證、管理員 Token 或完整資料庫權限。
  • 以可驗證的政策引擎取代自然語言中的模糊授權規則。

AI Agent 的工具權限必須比聊天回覆更嚴格

具備工具呼叫能力的 AI Agent，應被當成一名權限受限的數位員工，而不是單純的問答介面。它若可以查 CRM、下載檔案、建立付款單或寄送郵件，提示注入的目標就會從「產生錯誤答案」升級為「誘導系統執行動作」。研究指出，超過 45% 的雲端應用擁有過多權限，這種既有問題在 Agent 架構下會被放大。

函數呼叫開發應採取 allowlist 設計：每一個工具都定義可用角色、可接受參數、交易金額門檻與資料範圍。模型只能選擇既有函數，不能自行組合 SQL、Shell 指令或 URL；後端也要重新驗證使用者身分、資源所有權與業務規則，避免把模型輸出的參數直接信任為合法請求。

付款、刪除資料、對外寄信、權限變更與下載大量文件，都應設置人工核准。核准畫面須同時顯示原始使用者請求、模型推論的動作、實際函數參數與影響範圍，讓審核者能辨別是否受到外部文件誘導。這是人機回圈，不是降低效率的行政負擔。

  • 使用短效 Token、服務帳號分離與每次呼叫的身分驗證。
  • 函數參數採固定 schema、值域限制與伺服器端重新授權。
  • 把不可逆、對外或高金額操作設為人工核准工作流。

紅隊、日誌與事件演練讓防護持續有效

提示注入防護需要持續測試，因為模型版本、提示模板、文件來源與工具功能一變，原本的安全結論就可能失效。團隊可建立測試集，涵蓋角色切換、提示擷取、語言混用、編碼、外部網頁、惡意 PDF、圖像文字與工具濫用，並在每次部署前後比較拒絕率、誤擋率與可造成的實際影響。

公開測試資料曾在 2025-11-26 12:15 記錄不同模型面對攻擊的結果，其中 Claude 3.5 Sonnet 的數值為 87.50%，Claude 3.5 Sonnet v2 為 56.25%。這些結果不適合直接套用到企業環境，但可用來提醒決策者：同一類模型名稱不代表有相同的抗攻擊能力，升版必須重新驗證。

日誌至少應保留提示版本、模型版本、檢索文件識別碼、工具呼叫、核准決策與輸出過濾結果，並避免將完整機密提示散落在一般維運日誌中。當發現異常時，先停用高風險工具、保全紀錄、撤銷 Token，再追查是哪份內容改變了模型行為，才能縮短事件處理時間。

  • 以攻擊成功、資料外洩、越權工具呼叫與誤擋率作為測試指標。
  • 模型或知識庫更新後，重新執行回歸測試與權限檢查。
  • 建立緊急關閉機制，讓 Agent 可立即停止高風險工具。

企業AI治理如何處理 Shadow AI 與影子AI風險

先盤點 AI 使用現況，才能看見真正的風險

企業AI治理的第一步不是禁止所有工具，而是建立可信的 AI 資產清冊，找出誰在用什麼、用了哪些資料、具備哪些權限。若組織不知道客服、行銷、研發與外包商各自使用的模型、外掛與 API，就無法判斷哪些流程會受到提示注入、資料外洩或供應鏈風險影響。

Shadow AI 與影子AI 指的是未經審核、未納入管理的 AI 使用行為，常源自員工想快速完成工作。2024年微軟（Microsoft）與領英（LinkedIn）共同發布的〈工作趨勢指數報告〉顯示，有75%的知識型工作者會在工作中使用AI，而其中有78%的人會自備AI工具。把使用者一概視為違規者，只會讓風險更隱蔽。

調查也顯示，93% 的員工會在未經核准的情況下將資料輸入到 AI 工具中。企業應提供可用、易取得且具資料保護的核准工具，並清楚定義哪些資料不可輸入公開服務；同時以代理、CASB、DLP 與採購流程交叉盤點，讓治理能反映實際行為而非僅存在於政策文件。

  • 建立模型、外掛、資料來源、擁有者、用途與權限的資產清冊。
  • 提供核准替代方案，降低員工改用未管理服務的誘因。
  • 依資料敏感度區分可公開、內部、機密與受管制資料的使用規則。

治理要分清責任、風險與例外流程

有效的企業AI治理，應由業務、IT、資安、法務、資料管理與稽核共同決定風險承擔，而不是把所有責任丟給單一技術團隊。業務單位說明效益與使用情境，資料負責人確認資料合法性，資安團隊評估攻擊面，法務處理契約與隱私義務，管理階層則決定風險門檻與資源投入。

不少組織的治理仍有缺口：34% 缺乏風險評估機制，僅 16% 有完整框架，且有 36% 沒有明確定義或宣告同仁使用 AI 工具的管理機制。若只在事故後才要求填表，治理會被視為阻礙；更好的做法是採風險分級，讓低風險摘要工具快速通過，高風險 Agent 則接受較深度審查。

ISO/IEC 42001 與 NIST AI RMF 可作為制度參考，但真正落地仍要連接既有的資訊安全、隱私與採購流程。每個 AI 專案應有風險登記表，記錄資料類型、模型供應商、提示注入測試、工具權限、人工覆核、退役條件與例外核准期限，讓稽核有可追溯證據。

  • 成立跨部門治理機制，明確指定系統擁有者與風險承擔者。
  • 以風險分級決定審批深度，而非用一套流程阻塞所有需求。
  • 例外核准應設定期限、補償控制與定期複查條件。

用分階段路線圖，讓治理從規則走向營運

治理計畫可在 90天 內完成第一輪盤點、分級與試行，但不應把 90天 當成一次性結案期限。第一個階段為期30天，先盤點 AI 工具、資料流與高風險流程；第二階段同樣為期30天，建立政策、審批與測試基準；第三階段也是30天，將控制措施接入真實專案並檢視缺口。

治理儀表板應讓管理者看見可行動的資訊，例如已登錄工具數、未審核工具、含敏感資料的流程、提示注入測試覆蓋率、高風險函數呼叫與例外到期日。尤其是 AI Agent，除了模型本身，還要納入 MCP 伺服器、外掛、服務帳號與資料連接器，否則資產清冊仍會有盲點。

政策需要每季進行評估，並隨模型能力、法規與業務流程調整。台灣在2025年底通過首部AI專法《人工智慧基本法》，企業更應保留資料處理、風險評估與人工監督紀錄。治理不是保證零風險，而是讓組織能以可解釋、可稽核的方式接受或拒絕風險。

  • 第一輪治理以盤點、分級、試行三個階段建立最小可行制度。
  • 以儀表板追蹤工具、資料、權限、測試與例外，而不只追蹤專案數量。
  • 定期檢討政策與控制措施，將新型攻擊及法規要求納入流程。

以 AI提示工程與 PoC 驗證安全，讓函數呼叫開發可控落地

AI提示工程要建立明確任務邊界，而非堆疊禁止語句

安全的 AI提示工程，應明確界定任務、資料區塊、可用工具與拒絕條件，讓模型在遇到不可信內容時有一致的處理方式。提示可要求模型把文件中的命令視為引用資料、只回答使用者問題、無法判定時回報風險；但每項規則都應同步有程式層控制，避免只靠語言指令承擔安全責任。

可將提示結構化為四個區塊：系統角色與不可違反規則、使用者任務、檢索或文件資料、輸出契約。資料區塊要清楚標示為「不可執行內容」，輸出契約則限定欄位與格式。這會降低角色切換與格式操控成功的空間，也讓測試人員較容易判斷是哪一層規則失效。

不要將完整機密流程、管理指令或長期憑證直接寫入系統提示。即使模型通常不會重述，提示仍可能在除錯紀錄、前端請求或回覆中間接曝光。把機密改放在伺服器端政策與權限服務中，模型只接收完成當前任務所需的最少資訊，才能限制提示洩漏的損害範圍。

  • 分離系統規則、使用者任務與不可信文件，避免語意混在同一段。
  • 用固定輸出契約與後端 schema 驗證降低格式操控風險。
  • 機密規則與授權邏輯應放在伺服器端，不要內嵌於提示詞。

函數呼叫開發要讓模型提案、後端裁決

安全的函數呼叫開發原則是：模型負責理解意圖與產生提案，後端服務負責驗證、授權與執行。例如模型可以提出「搜尋訂單」或「建立草稿信件」，但不能自行決定查詢任意客戶、改變收件人或跳過交易限制。每個工具呼叫都必須有明確目的、最小資料範圍與可稽核紀錄。

設計 API 時，避免提供過度通用的工具，例如可任意執行 SQL 的 query_database，或可任意抓取網址的 fetch_url。應改成與業務動作對應的窄介面，例如 get_order_status、create_email_draft；參數採列舉值、長度限制與資源 ID 驗證，讓攻擊者即使影響模型，也難以擴大操作範圍。

下表可協助團隊區分不同自動化層級應搭配的控制。實際門檻仍要依資料敏感度、法規義務與交易影響調整，特別是當 Agent 能接觸客戶資料或外部系統時，不應因為模型回覆自信就省略後端授權。

不同 AI 自動化層級需要的授權與人工控制
操作類型 模型可做範圍 必要控制 人工核准
知識問答 摘要與引用 檢索權限過濾 通常不需
內部查詢 提出查詢意圖 伺服器端授權 敏感資料需
草稿建立 產生草稿 收件者與內容驗證 建議需要
交易與刪除 提出執行建議 雙重確認與審計 必須
控制強度應依資料分類、權限範圍與操作可逆性提高。
  • 工具設計採窄介面與 allowlist，不提供萬用執行能力。
  • 每次呼叫都重新檢查使用者、資源、參數與業務規則。
  • 將寫入、對外與不可逆操作改為草稿加人工核准。

用小規模 PoC 證明安全與效益能一起成立

AI PoC 的價值，在於正式開發前以真實資料、真實流程與有限權限驗證安全假設，而不是先投入大型系統後才發現風險。針對 LLM提示注入，可先挑選一個高價值但可隔離的流程，例如內部知識問答或客服草稿產生，建立惡意文件測試集，量測模型是否洩漏資料、是否誤觸工具，以及人工覆核是否能有效攔截。

ALION 的做法會從現場調查與目標設定開始，以最小配置製作可運作原型，並在驗證後提供 Go / No-Go 的判斷依據。其 AI 上游工程訂閱服務為月費 20 萬日圓起；相較於聘僱 CTO 級人才月薪 80〜150 萬日圓，或委託外包開發啟動費約 300 萬日圓起，較適合在方向尚未確認時先縮小投資風險。

PoC 的 KPI 不宜只看回答正確率，還應列入惡意提示攔截率、未授權工具呼叫數、敏感資料輸出數、人工核准時間與現場採用率。若驗證結果顯示資料權限尚未整理、流程不適合自動化，建議暫緩正式開發也是有價值的成果。能做出「現在不該做」的判斷，往往比勉強上線更能保護預算與信任。

  • 先選擇可隔離、可量測且具業務價值的單一流程驗證。
  • KPI 同時衡量安全、精度、效率、人工負荷與使用者接受度。
  • PoC 成果應保留設計、程式碼、測試集與風險紀錄，延續到正式開發。

總結

LLM提示注入無法只靠一段更嚴格的系統提示解決。真正可靠的做法，是將不可信內容與可信指令分離，讓模型處在最小權限下運作，以輸入輸出驗證、後端授權、人工核准、日誌監控與持續紅隊測試形成多層防線。再透過企業AI治理盤點 Shadow AI 與影子AI，才能把零散的工具使用轉化為可管理的企業能力。

重點整理

  • LLM提示注入的核心風險是模型混淆資料與指令，直接與間接攻擊都必須測試。
  • RAG、PDF、網頁、電子郵件與圖像都是不可信輸入，不能直接驅動工具操作。
  • AI資安必須以最小權限、schema 驗證、API 隔離與人工核准補強提示詞規則。
  • 企業AI治理要先盤點 AI 資產與影子AI，再建立風險分級、例外管理與定期檢討。
  • 以 PoC 在真實流程中量測安全與效益，可避免未驗證就投入正式開發。

若您的團隊正規劃 RAG、AI Agent 或函數呼叫開發，建議先列出資料來源、可呼叫工具與高風險操作，再以小範圍測試惡意提示、權限穿透與人工覆核流程。把安全需求寫進需求定義與驗收條件，才能讓 AI 導入在可控風險下持續創造價值。

常見問題 FAQ

Q1. LLM提示注入可以完全防止嗎？

目前沒有只靠提示詞就能完全防止的方法。較務實的目標是降低攻擊成功後的影響：分離不可信內容、限制工具權限、驗證輸入輸出、設置人工核准，並持續以紅隊測試更新防線。

Q2. RAG 系統只讀內部文件，還需要防提示注入嗎？

需要。內部文件也可能含有錯誤模板、未審核內容或遭竄改資料。RAG 應在檢索前依使用者權限過濾文件，並將檢索結果視為引用資料，而不是能覆寫系統任務的指令。

Q3. AI提示工程能否取代後端安全控制？

不能。AI提示工程可提升模型遵循任務的穩定性，但模型輸出仍應由後端驗證。尤其在函數呼叫開發中，身分驗證、資源授權、參數限制與交易確認必須由確定性的程式邏輯處理。

Q4. 企業該如何處理 Shadow AI 或影子AI？

先建立低摩擦的盤點與核准機制，了解員工實際使用哪些工具及輸入哪些資料；接著提供安全替代方案與清楚資料政策。單純封鎖容易讓使用行為轉入更難追蹤的管道。

Q5. 哪些來源可作為提示注入防護的技術參考？

可參考 OWASP LLM Top 10：https://owasp.org/www-project-top-10-for-large-language-model-applications/；MITRE ATLAS：https://atlas.mitre.org/；NIST AI RMF：https://www.nist.gov/itl/ai-risk-management-framework；ISO/IEC 42001：https://www.iso.org/standard/81230.html；以及 arXiv 論文：https://arxiv.org/abs/2407.07403。



返回部落格列表