OWASP 2026 年 LLM Top 10，多數人可能忽略的關鍵轉變
OWASP GenAI Security Project 發布 2026 年 LLM 應用程式十大清單（Top 10 for LLM Applications）。提示詞注入（Prompt Injection）仍位居第一，敏感資訊洩露（Sensitive Information Disclosure）也依然排名第二。單從排名來看，似乎與過去沒有太大的變化。
但真正的改變，其實不在排名上。專案負責人在一開始就提出一個重要觀念：不要再試圖打造一個「永遠不會被欺騙的模型」，而應該把重點放在模型周圍的系統設計。如此一來，即使模型遭到欺騙，也不至於讓重要的系統或資產受到影響。
這代表資安工作的重點正在改變。過去兩年，產業大多把心力放在如何優化模型；而這份清單傳達的訊息則是：現在更重要的，是建立有效的風險控制與隔離機制（Containment）。換句話說，目標不再只是追求完美的事前防禦，而是思考如何控制事件發生後的影響範圍（blast radius）。
而這項轉變，也進一步帶出一值得深入思考的問題，接下來在文章中討論。
這是 OWASP 首次將實際事件數據納入風險排序。資安人員投票仍占整體權重的 75%，另外 25% 則來自 6,639 起真實事件，資料來源包括公開漏洞資料庫以及 AI 危害事件資料庫。 而這 25% 的數據權重，對 Misinformation 這項風險的排名影響最大 。資安人員投票將 Misinformation 排在相對後面，但實際事件紀錄卻將其推向前段，最終使 Misinformation 的排名上升兩名。
這項落差本身就是值得關注的發現。
資安風險評估長期較聚焦於「攻擊者驅動」的威脅，例如提示詞注入、資訊洩露或資料投毒。然而，實際事件紀錄顯示，一些代價高昂的失敗案例，甚至沒有攻擊者參與。 問題可能只是模型講錯了，而下游系統信以為真、照單全收。 專案負責人也進一步說明，為什麼這類問題已經不只是「內容是否正確」，而是上升至系統層級的安全風險。
現今的模型輸出可能觸發工具呼叫（Tool Calls）、產生程式碼、推斷系統狀態、授權執行動作，甚至協調多個 AI Agent 之間的工作。一旦流程上游產生錯誤輸出，錯誤便不會只停留在文字內容，而可能進一步轉化為系統真正執行的決策。
過度代理權限（Excessive Agency）上升至第三名，而在這項風險上，資安人員投票與實際事件數據呈現一致趨勢：隨著 Agentic AI 部署增加，實際損害也逐漸集中於模型能夠採取的行動。另一方面，無限制資源消耗（Unbounded Consumption）依資安人員評分上升四個名次。資源與成本耗盡不再只是紙上談兵，而是看得到、算得出，甚至反映在帳單上的問題。
將這兩項風險放在一起觀察，可以看出相當明確的趨勢。目前影響較大的 AI 失敗，已不只是產生錯誤或不適當的輸出，而是系統實際執行了動作，或產生了實際的資源與成本支出。
好消息是，這些防護方式大多並不是全新的資安概念。最小權限（Least Privilege）、限制使用範圍並縮短有效期限的存取憑證、速率與支出限制，以及針對不可逆操作加入人工審核，都是 AppSec 多年來已經熟悉的基本控制措施，也同樣適用於 AI 系統。
然而，要落實這些控制措施，仍存在一項重要前提。若無法掌握企業環境中究竟有哪些 AI 元件，就難以正確設定其權限範圍。目前仍有許多企業缺乏完整、可信的 AI 資產清單，因而無法清楚掌握哪些 AI 元件具有執行動作的能力、可以存取哪些系統，以及這些元件由哪些團隊建立與部署。
System Prompt Leakage（系統提示詞洩露）更名為 Hidden Context Exposure（隱藏上下文暴露）。 Prompt Injection（提示詞注入）的範圍進一步納入隱藏於圖片、音訊等內容中的跨模態攻擊（Cross-modal Attacks）。Data and Model Poisoning（資料與模型投毒）則納入針對模型微調（Fine-tuning）的破壞行為。而 Output Handling（輸出處理）從第五名下降至第十名，但涵蓋的風險範圍反而進一步擴大。
OWASP 選擇整併既有類別，而非持續增加新的風險分類。相較於排名變化，更值得關注的是這些風險類別整併的方向：真正重要的安全邊界，已不再只是 Prompt 本身，而是模型所接收到的整體上下文（Context）。任何能夠進入模型 Context Window 的資訊，都應被視為不可信任的輸入，無論資訊是透過文字、圖片、音訊或其他格式進入，也無論內容來源為何。
2026 年版 OWASP 對於適用範圍有相當清楚的界定。Top 10 for LLM Applications所整理的是 LLM 作為應用程式其中一個元件時所面臨的安全風險。當模型從單純的「應用程式元件」進一步成為能夠採取行動的「執行者」，例如可以呼叫工具、跨 Session 保留記憶，並能對下游系統產生實際影響時，安全風險的評估範圍便需要進一步延伸至 Agentic Top 10。
因此，AI 資產盤點不應依照清單分類，而應以各項 AI 元件具備的能力為基礎，並針對每一項 AI 元件確認以下三個問題：
這三項資訊有助於判斷應參考哪一份風險清單、可能造成多大的影響範圍，以及風險控制與隔離機制應部署在哪裡。
然而，若缺乏完整的 AI 資產發現與盤點，上述問題便難以得到明確答案。 因此，資產盤點應走在安全控制之前，而不是在控制措施建立之後才進行補充。
首先，進行完整盤點。盤點企業中的模型、AI Agent、MCP Server（Model Context Protocol Server）、具有程式碼儲存庫寫入權限的 Coding Assistant，以及那些由內部團隊自行建立、卻沒有通知資安團隊的 AI 元件。 如果連控制範圍都無法界定，那麼所謂的隔離策略，就只是簡報上的概念，而不是真正的安全控制。
其次，依照能力邊界進行分類，而非按照供應商或元件所屬的 OWASP 清單分類。 將 AI 建議的修復方式一律視為尚未驗證的輸入，包括來自企業自己所使用工具的建議。除非能夠確認修復方向正確，否則不要直接把這些修復建議交給自動化修補 Agent 執行。
建立能夠偵測「無聲失敗（silent failure）」的監控機制。驗收標準不應只看「原本的漏洞是否已無法重現」，更要確認「真正存在漏洞的攻擊路徑是否已經消失」。
建立屬於自己的基準數據。使用企業自身程式碼中已經修復過的漏洞進行基準測試（Benchmark），取得實際數據，而不是拿其他企業或市場上的平均值作為安全規劃依據。
「應在模型周圍建立足夠的安全機制，確保即使模型發生錯誤，也不會導致重要系統或資產受到破壞。」沿著這項原則進一步思考，便會產生一個更根本的結構性問題：模型周圍的安全機制，應由誰負責建立與驗證？
答案不應該是模型本身。單一元件無法獨立界定並限制自身可能造成的影響範圍。同樣地，答案也不應該是提供該模型的供應商——因為若輸出仍由相同模型家族進行檢查。 同樣地，若模型產生的輸出仍由相同模型家族進行檢查，並依賴相同或相近的模型機制進行判斷，內容產生端與驗證端便可能共享相同的盲點。
這並非模型能力高低的問題。前沿 AI 模型仍在快速進步，現階段容易發生的錯誤，未來可能隨著模型能力提升而逐漸減少。然而，此處所涉及的是系統結構問題，而結構本身並不會隨著下一次模型版本更新而自然改善。產出者不能同時也是唯一的驗證者。
Mend.io 不負責替你生成應用程式碼；我們負責驗證它，也驗證 AI Assistant 所生成的程式碼，不論它來自哪一套工具或模型。
目前 Mend 平台已提供多項相關能力，包括透過 Discovery 與 AI-BOM 掌握企業環境中的模型、AI Agent 與其他 AI 元件；進行模型風險與 Agent 設定風險掃描；System Prompt 強化；Red Teaming；以及可直接部署於應用程式內或透過 Proxy 執行的 Runtime Protection。同時，也可針對程式碼本身執行 SCA（軟體組成分析）、SAST（靜態應用程式安全測試）、Container 與 IaC（基礎設施即程式碼）掃描。
模型終究可能出錯或被欺騙；真正決定後果有多大的，是你在模型周圍建立了什麼樣的安全機制。模型可能被欺騙，但真正決定風險是否擴大的關鍵，在於模型周圍建立了哪些安全機制。
資料來源：OWASP GenAI Security Project、Top 10 for LLM Applications 2026，以及 Top 10 for Agentic Applications 2026。
若對 Mend.io 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/mend-io