兩年前，你的團隊交付的是軟體。如今，他們交付的是兩種類型的產品，一種是大部分由 AI 生成的軟體，另一種則是團隊自己打造的 AI 系統：包括模型（Model）、Agents、以及具備推理與執行能力的功能模組。多數資安計畫仍只聚焦於前者，卻幾乎忽略了後者。
這個落差並非源於工具不足，而是分類方式本身出了問題。而整個產業目前對 AI Security（AI 安全）的分類方式，正在讓這個問題變得更加嚴重。
打開任何一家廠商的網頁，就會發現 AI Security 都是依照 AI 所在的位置來劃分的：在編輯器中的 AI、在 CI/CD 流程（pipeline）中的 AI、在模型層（Model Layer）的 AI、在 SOC（Security Operations Center，安全維運中心） 中的 AI。每一個類別都有專屬的產品、專屬的縮寫，也有專屬的推銷話術。
但問題在於，AI 已經無所不在。當分類依據「AI 在哪裡」，而 AI 本身又同時存在於所有環境時，這些分類自然會互相重疊，導致不同工具其實在解決同一類問題。表面上看似做到了完整涵蓋，實際上卻是一團混亂。採購者也難以分辨各產品之間的界線，因為分類的依據是技術位置，而非風險。
其實，可以換一個更合理的分類方式。
只要把問題重新聚焦在「保護的對象」，整個問題就能收斂成兩個答案，而且只有兩個。
第一種，是保護你所交付的軟體。第二種，是保護你所打造的 AI 。兩者面對的是不同的保護對象、不同的風險模式（Failure modes），在同一家公司內負責採購的也是不同部門。而在這兩者之上，都需要有一個獨立的安全層。
如今，軟體程式碼中有越來越高的比例是由 AI 所撰寫。然而，資安風險的核心，依然在於「應用程式」本身。不論是人類寫的，或是模型生成的，漏洞就是漏洞。可被利用的程式碼、不安全的第三方依賴套件、開源授權合規風險、架構缺陷。風險類別並沒有改變，真正改變的是風險產生的數量與速度。
數據相當驚人，截至 2025 年年中，在相關研究所涵蓋的 Code repository 中，AI 生成的程式碼每月新增超過 10,000 個安全弱點，相較於六個月前成長了 10 倍。CVSS 7.0 以上的高風險漏洞，出現在 AI 生成程式碼中的機率，更是人工撰寫程式碼的 2.5 倍。AI 並沒有創造新的漏洞類型，而是把既有漏洞「工業化（Industrialize）」（※具有規模化、自動化、大量複製的含意）。
本質上，這仍然屬於應用程式安全（Application Security）的範疇，只是規模已經擴展到 Agentic 時代。此外，本系列前幾篇文章中所提出的兩個核心論點，在這裡同樣適用：第一，撰寫程式碼的系統，不應同時負責驗證自己寫出的程式碼，因此安全驗證必須來自生成工具外的獨立層。第二，這種安全驗證必須持續涵蓋整個企業的軟體資產，而非只針對最新一批 AI 生成的程式碼，因為企業絕大多數的資安風險，往往來自於多年累積、並非單一模型撰寫，且已沒有人能完全理解的老舊既有程式碼。
這個問題本身其實早已被理解，市場也已有明確定義。但 AI 正讓它面臨前所未有的壓力。
第二個保護對象則是全新的領域，而且目前絕大多數企業的資安計畫對此毫無防備。
現在，你的團隊正在交付的是 AI 系統：一個擁有工具存取權的客服代理（Support Agent）、一個使用企業專有資料微調的模型、一個能接收指令並執行動作的功能模組。這些本身就已經是獨立的產品，單純掃描其原始碼，幾乎無法判斷它們是否真正安全。
它們的失效模式在本質上完全不同。譬如已被列為 OWASP LLM Top 10 第一名的提示詞注入（Prompt Injection）、能繞過系統防護的越獄（Jailbreak）、可能改變行為的訓練資料或模型污染（Training Data and Model Poisoning）、工具被誤用執行不該發生的操作，以及那些在測試中表現完美，卻在對抗性壓力（Adversarial Pressure）下崩潰的 Agent。這些問題無法透過閱讀程式碼發現，必須在攻擊者動手之前，以攻擊者的角度測試 AI 系統。
間接提示詞注入（Indirect Prompt Injection）目前已占 LLM 攻擊的 55% 以上，依模型設定不同，這類攻擊的成功率介於 50% 至 84% 之間。然而，目前只有 24% 的企業設有專責的 AI 安全治理團隊，這代表絕大多數 AI 系統，都是在沒有經過系統化對抗性測試（Adversarial Testing）的情況下上線。
在這個領域，「獨立性」的重要性比任何地方都更高。AI 系統不可能對自己進行可信的紅隊（Red Team）演練，就像它無法客觀評估自己的回答一樣。基礎模型供應商也無法替你完成這件事，因為他們打造的是模型本身，而不是你在特定環境中的部署，他們更不會針對你在特定環境中的 Agent 發動量身打造的攻擊測試。唯一可信的方法，就是來自系統外部的對抗性測試。
很多人會直覺認為，既然是兩種問題，就應該購買兩套不同的工具。但這其實只是把依 AI 所在位置分類的這種錯誤，再往上一層複製了一次。這並不是兩個產品，而是一項共同的安全使命，應用在兩個不同的保護對象上。而無論是哪一種，獨立性的理由相同、經濟效益與成本的考量也完全相同。前沿模型不能同時是「生成者」又是「可信的驗證者」，就和它無法同時扮演「AI 系統」與自己的「紅隊演練者」是同樣的道理。真正讓這層安全機制具備一致性的，並不是它所檢測的技術，而是「立場」——獨立、對任何建置出該系統的技術都保持中立，並且正因位於系統之外，才值得信任。
這就是獨立安全層存在的核心意義：它不在乎程式碼是誰寫的，也不關心模型是由哪個實驗室訓練的。它同時驗證兩者，因為「驗證」才是它真正的職責，而這項工作的本質，不會因為創造風險的工具不同而改變。
AI 改變了你的團隊所交付的內容，也緊接著改變了你必須保護的對象。能夠保持清晰思考與理智的企業，不會是那些擁有最多 AI 標籤產品的企業，而是那些能夠毫不遲疑回答一個簡單問題的企業：我們真正要保護的是什麼？又該信任誰來驗證它？
答案只有兩個。我們保護你交付的軟體，也保護你打造的 AI 系統。而這兩者，都需要同一個獨立的安全驗證層。
若對 Mend.io 有興趣歡迎留下資訊，將會有專人與您聯繫 ➤ https://www.gss.com.tw/mend-io