MITRE ATT&CK v20 納入提示注入：企業 AI 代理的防線要重畫

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-14

MITRE ATT&CK v20 把多種針對 AI 系統的攻擊行為納入分類，包括直接提示注入、間接提示注入，以及操控企業 AI agent 外洩資料的手法。iThome 報道指出，這次更新反映攻擊者的焦點正由「用 AI 協助攻擊」擴展至操縱模型、檢索內容與具備行動能力的代理流程。對已讓 LLM 讀取內部知識庫、電郵、工單或連接企業系統的團隊而言，這是一套更貼近實際部署風險的共同語言。

不過，ATT&CK 是用來描述對手行為及協助防禦對照的框架，並不會自動替企業封鎖 prompt 攻擊。企業若只在聊天介面加上「不要洩漏資料」等規則，未必足以處理模型從外部網頁、文件或電郵接收內容後被誘導執行操作的情況。真正受影響的是把 AI 視為工作流程一環、並授予它搜尋、讀取、寫入或調用工具權限的開發及資安團隊。

提示注入由輸入問題變成工作流程問題

iThome 報道指，v20 新增直接提示注入（Direct Prompt Injection，T1699）與間接提示注入（Indirect Prompt Injection，T1698）。前者是攻擊者直接向大型語言模型輸入惡意指令；後者則把指令藏進模型將會處理的外部內容，例如可被讀取的網頁或文件。兩者的分別看似只是內容從哪裏進入，對防禦設計卻有很大差異。

直接提示注入可在使用者與模型互動時出現，因此介面層的輸入限制、風險偵測和高風險操作覆核都有作用。間接提示注入則跨越了內容擷取、檢索增強生成、模型推理及工具調用等環節：原本被系統當作「資料」的句子，可能嘗試被模型理解成「指令」。若 AI agent 可按照模型輸出自行開啟連結、搜尋資料庫或提交工作項目，單純檢查使用者最初輸入已不夠。

這帶來一項實務取捨。讓 agent 廣泛存取資料和工具，確實能減少人手轉換系統的成本；但每增加一個資料來源或可執行動作，也會增加受不可信內容影響的機會。這不是說企業不應採用代理工作流，而是權限模型要與使用情境一同設計：閱讀公開資料的研究助理，與能修改客戶紀錄或發送訊息的 agent，不能採用相同的信任假設。

資料外洩風險取決於 agent 有多少權限

iThome 指出，AI 輔助資料外洩（AI-Enabled Exfiltration，T1700）針對攻擊者操控企業 AI agent 洩露資料的情境。這項分類的價值，在於把討論由模型會否「答錯」轉向一個更直接的問題：當模型被操縱後，它有能力接觸甚麼資料，又可以把資料帶到哪裏？

從防守角度推論，企業應把 agent 視作具備身份和權限的軟件元件，而非只是一個對話功能。它連接的知識庫、雲端儲存空間、客戶管理系統及內部 API，應按任務採用最小權限；涉及匯出、寄送、修改或跨系統傳遞資料的動作，宜要求明確授權或人手確認。敏感資料亦不應因為可被檢索，就預設可被任何對話或工作流程帶走。

偵測方面，記錄亦要覆蓋 agent 的完整鏈路：它讀取了哪一份內容、使用了甚麼工具、向何處傳送結果，以及由哪個使用者或服務身份觸發。這些紀錄不保證能阻止攻擊，但可讓資安團隊在出現異常工具調用、非預期的大量查詢或跨領域資料存取時追查原因。若日誌只保留最終聊天答案，事後很難分辨問題源自原始內容、模型判斷，還是後端權限設定。

搜尋結果與自動防禦也成為攻擊面

除了新增獨立技術，iThome 報道稱，MITRE 亦在既有分類加入 AI 結果污染（AI Result Poisoning，T1608.007）及干擾自主防禦（Impair Autonomous Defenses，T1685.007）兩項子技術。前者描述攻擊者操縱網頁內容，藉此影響 AI 搜尋引擎與 AI 助理推薦的結果；後者涵蓋干擾 AI 輔助惡意程式分析及攻擊活動分析的手法。

AI 結果污染提醒團隊，模型引用或摘要到的內容不會天然可靠。當企業把 AI 搜尋、外部情報摘要或自動推薦接入決策流程，結果應保留來源脈絡，並為高影響決定加入可核實的引用與人工覆核。重點不是要求每條答案都由人逐字重寫，而是按風險分級：涉及付款、帳戶、供應商、程式碼部署或保安處置的建議，驗證門檻應高於一般內部問答。

至於 AI 輔助防禦工具，本身也需要被視作可能受干擾的分析環節。若安全營運中心用模型整理告警、歸納惡意程式行為或協助分流事件，就應保留原始遙測資料及既有規則作交叉比對，避免單一模型結論直接決定封鎖、放行或關閉事件。這會增加設計和營運成本，但能減少有人藉輸入內容或分析盲點影響自動化判斷的風險。

用 ATT&CK 對照開發與保安控制

iThome 亦提到，v20 新增竊取應用程式專用密碼（T1697）及反自動化機制規避（T1696），並擴充軟件供應鏈入侵的情境，把 IDE 和程式開發 agent 的設定檔納入考量。這意味着 AI coding 與開發自動化雖可提升速度，其本機設定、憑證和代理權限同樣是保安盤點的一部分，不能只把注意力放在雲端模型供應商。

一個可行的下一步，是由開發、資料治理及資安人員共同列出每個 AI 工作流程的資料來源、可用工具、服務身份、輸出目的地和人手批准點，再把上述 ATT&CK 技術映射到測試案例與監控規則。先從能讀取敏感資料或具備寫入權限的 agent 做起，通常比一次過為所有聊天功能建立繁重管制更實際。接下來值得觀察的是，企業會否把這些 AI 攻擊分類轉化為日常紅隊測試、採購要求及事故應變流程，而不只停留在框架更新的認知層面。