本文重點
- ISO 27001 / CNS 27001 提供管理流程的基礎骨架,但不能替代 AI 特有的技術防護層
- AI 系統的攻擊面是動態的:每次模型推理都是潛在入口,邊界防護邏輯在這裡失效
- 提示詞注入防護、工具呼叫最小授權、輸出完整審計,是三個優先落地的控制方向
- AI 系統應納入 ISMS 資產清冊,並在年度風險評估中單獨列出 AI 特有威脅類型
- 等待 ISO 更新 AI 專屬條文不是務實做法;主動補充框架輸入才能跟上威脅演進速度
- ISO 27001 認證對 AI 系統的安全有什麼實際幫助?
- ISO 27001 認證代表組織有一套系統化的資訊安全管理流程,包含資產識別、風險評估、控制措施選擇與定期審查。這個流程基礎本身有價值,但認證本身不保證組織對 AI 特有的攻擊面(如提示詞注入、工具授權失控)有具體防護措施。認證是起點,不是終點。
- CNS 27001 和 ISO 27001 有什麼差異,台灣組織應該取哪個認證?
- CNS 27001 是台灣對應 ISO 27001 的國家標準,技術要求高度一致,差異在於語言與本地化條文。若組織主要在台灣市場、面對政府採購需求,CNS 27001 已足夠;若有跨國業務或需要國際通用的認證效力,則需 ISO 27001。兩者並非互斥,部分組織同時持有。
- 什麼是提示詞注入(Prompt Injection),為什麼現有資安框架難以攔截?
- 提示詞注入是針對語言模型的攻擊方式,攻擊者把惡意指令藏在模型會讀取的輸入來源中,讓模型在執行正常任務的過程中被誘導執行預期外的行為,例如揭露系統設計、繞過存取限制或夾帶資料外洩。它的特殊性在於:攻擊入口是模型的推理行為本身,不是程式碼漏洞,傳統的程式碼審查和防火牆無法攔截。
很多組織在引入強大 AI 工具的時候,第一個反應是去翻資安認證的清單:「我們有 ISO 27001,應該沒問題吧?」
但這裡要先問一個更前面的問題:這些框架在設計的時候,有沒有把 AI 系統特有的攻擊面納入考量?
如果沒有,那「有認證」這件事,並不等於有能力應對 AI 特有的威脅。這篇文章從 Claude Mythos Preview 這個案例出發,拆解 ISO 27001、CNS 27001 與 ISMS 框架的實際覆蓋範圍,然後回到一個更實際的問題:當 AI exploit 成為真實風險,組織要怎麼做,才不是真的在裸奔?
一、Claude Mythos Preview 是什麼,帶來什麼新的安全問題
Claude Mythos 是 Anthropic 釋出的預覽版本,定位在具備更強推理能力與多步驟執行能力(agentic,自主代理能力)的語言模型,能夠在較少人工介入的情況下完成複雜任務。這類模型的能力邊界比過去的對話型 AI 更寬,因為它不只是回答問題,而是能夠規劃步驟、呼叫工具、操作介面、讀寫資料。能力愈強,攻擊面也跟著變大。
這不是說 Mythos 本身有設計缺陷,而是說:當一個 AI 系統具備執行動作的能力,它所處的環境就成了一個新的風險層。
傳統 AI 系統的攻擊面是相對有限的,多半是模型輸出被濫用,或是 API 接口被暴力嘗試。但具備 agentic 能力的模型,引入了幾個以前不存在、也沒有被現行資安標準具體覆蓋的攻擊向量:
Prompt injection(提示詞注入):攻擊者把惡意指令藏在模型的輸入來源中(如網頁、文件、資料庫),讓模型在不知情的情況下執行預期外的行為。這是目前針對 LLM 應用最常見也最危險的攻擊手法。
Indirect instruction hijacking(間接指令劫持):透過讓模型存取的外部資源,置入偽裝成正常內容的惡意指令。常見於 RAG(Retrieval-Augmented Generation,檢索增強生成)架構中,當知識庫或外部文件被污染,模型的推理就會被劫持。
工具呼叫濫用(tool misuse):當模型被授權可以呼叫 API 或執行系統指令,攻擊者可以誘導它呼叫本不應被觸發的介面,甚至透過模型行為側信道推斷系統設計。
資料滲漏(data exfiltration via model output):利用模型的推理能力,誘導它在正常回應中夾帶本不該揭露的敏感欄位組合,讓資料以看似合理的格式被外洩。
這四類攻擊路徑都有一個共通特點:攻擊入口不是程式碼漏洞,而是模型的推理行為本身。這讓傳統的程式碼審查、防火牆規則、邊界防護邏輯,都失去了作用。
二、ISO 27001、CNS 27001 與 ISMS:框架管的是什麼
ISMS(Information Security Management System,資訊安全管理系統)是一套組織層面的管理框架,目的是系統化地識別、評估、控制資訊安全風險。ISO 27001 是目前全球主要的 ISMS 認證標準,由 ISO(國際標準化組織)與 IEC 共同制定;CNS 27001 則是台灣依 ISO 27001 翻譯制定的國家標準,由經濟部標準檢驗局(BSMI)公告,技術要求與 ISO 27001 高度一致,差異主要在語言和本地化適用情境。
| 維度 | ISO 27001:2022 | CNS 27001:2023 |
|---|---|---|
| 發布機構 | ISO/IEC(國際) | 經濟部標準檢驗局(台灣) |
| 適用對象 | 全球組織 | 台灣組織(政府採購、本地法遵) |
| 技術內容 | 原版英文標準 | 高度一致,官方中文版 |
| 認證效力 | 國際通用 | 台灣法規場景有效,部分標案要求 |
| 附件 A 控制措施 | 93 項(2022 版更新) | 同步對應 |
ISMS 的核心設計邏輯是「風險管理循環」(Plan-Do-Check-Act,PDCA):要求組織對資訊資產進行識別,對威脅進行評估,選擇並執行控制措施,然後定期審查。它管的不只是技術控制,還包括人員管理、物理安全、供應商管理、業務持續計畫等跨部門面向。
這個框架的強項在於:系統化、可審計、跨部門。取得 ISO 27001 認證,代表組織有一套可追溯的管理流程,不是只有技術工具的堆疊。這個基礎是有價值的。
但問題也在這裡:ISMS 附件 A 的 93 個控制措施,在設計時並沒有把 AI 系統作為主要攻擊面納入。ISO 27001:2022 的更新確實加入了威脅情報、資料遮蔽、安全編碼等新控制措施,但對 AI 系統特有的風險類別(如提示詞注入、模型中毒、agentic 授權失控),目前仍沒有明確的對應控制要求。
這不是框架的設計缺陷,而是時代落差:這些標準在 AI agent 普及之前就已制定,更新週期也無法跟上 AI 能力演進的速度。
「ISO 27001:2022 附件 A 新增了威脅情報(A.5.7)、資料遮蔽(A.8.11)與安全配置管理(A.8.9)等控制措施,反映了現代 IT 環境的威脅演進;但針對 LLM 應用特有的攻擊面,標準文件中目前尚無對應的控制描述。」— 資訊安全業界實務觀察,參考 ISO/IEC 27001:2022 Annex A 說明文件
三、遇到的問題:在 AI exploit 時代,框架能保護你到哪裡
不是。 ISMS 認證是管理流程的認可,不是技術防護能力的保證。一個通過 ISO 27001 認證的組織,如果在引入 AI agent 系統時沒有針對性地更新威脅評估,它在 AI exploit 面前的防護能力,跟沒有認證的組織差距不會很大。
這裡有一個更根本的問題要先定義清楚:AI exploit 的攻擊路徑,和傳統資安事件的攻擊路徑,在結構上不同。
傳統攻擊的起點通常是:掃描系統邊界、尋找未修補的漏洞、嘗試未授權存取。這些攻擊路徑相對固定,防護邏輯也相對清楚。
AI exploit 的起點可能是:一段看起來無害的使用者輸入、一份經過污染的 RAG 知識庫、一個透過模型推理被繞過的業務邏輯。這類攻擊不走固定路徑,因為它的武器是模型的推理能力本身。
問題的根本原因在這裡:AI 系統的攻擊面不是靜態的,而是動態的。每一次模型推理都是一次潛在的攻擊入口,因為推理過程本身是輸入驅動的。這讓「邊界防護」思維失效,因為邊界根本無法被固定下來。
在引入 Mythos 這類強 agentic 能力模型的實際場景中,常見問題分布如下:
使用者輸入層的提示詞注入:使用者在對話中嵌入讓模型忽略系統指令的提示,導致模型輸出超出預期範圍的內容,例如揭露系統提示的設計或繞過輸出限制。
外部資料來源的間接污染:模型在 RAG 流程中讀取了被篡改的文件,導致推理結果偏離,甚至被誘導輸出攻擊者預期的回應。
過寬的工具呼叫授權:模型被授權可以讀取特定資料庫,卻在被誘導的情況下提取了本不應揭露的欄位組合,或觸發了本不應被呼叫的 API 端點。
缺乏有效的輸出審計機制:模型的回應沒有被記錄和審查,導致異常輸出在事後無從追蹤,也無法納入 ISMS 的事件管理流程。
這些問題不是 ISO 27001 的控制措施不能管,而是它現有的控制措施細緻度,在 AI 系統這一層還不夠。更直接地說:風險登錄冊(Risk Register)如果沒有把提示詞注入、模型授權過寬列為威脅類型,ISMS 的審查流程就不會覆蓋到它。
「OWASP LLM Top 10 將提示詞注入(Prompt Injection)列為大型語言模型應用的第一大風險。這類風險的攻擊面在於模型推理行為本身,而非傳統的程式碼漏洞或未授權存取,現有通用資安標準中幾乎沒有對應的具體控制措施。」— 參考 OWASP Top 10 for Large Language Model Applications 2025 版
四、怎麼解決:從框架的邊界找到真正有效的做法
不是丟掉 ISMS,而是在 ISMS 框架上疊加 AI 特有的控制層。 ISMS 提供的系統化管理流程本身是有價值的,問題是它的風險識別輸入清單需要針對 AI 系統做延伸。OWASP LLM Top 10 和 NIST AI Risk Management Framework(AI RMF)是目前最具參考性的補充框架,可以直接作為 ISMS 風險評估的延伸輸入,而不需要重建整個管理體系。
重點摘要
- ISO 27001 / CNS 27001 提供管理流程的基礎骨架,但不能替代 AI 特有的技術防護層
- AI 系統的攻擊面是動態的:每次模型推理都是潛在入口,邊界防護邏輯在這裡失效
- 提示詞注入防護、工具呼叫最小授權、輸出完整審計,是三個優先落地的控制方向
- AI 系統應納入 ISMS 資產清冊,並在年度風險評估中單獨列出 AI 特有威脅類型
- 等待 ISO 更新 AI 專屬條文不是務實做法;主動補充框架輸入才能跟上威脅演進速度
從根本上來說,問題的結構是「舊框架遇到新威脅類型」。解法不是換掉框架,而是在原有結構中補充新的風險識別維度和控制措施。ISMS 的 PDCA 循環本身設計是有效的——真正需要更新的,是它的輸入。
可執行步驟
AI 安全控制落地步驟(可疊加在現有 ISMS 流程上)
-
更新資產清冊,納入 AI 系統:把每個部署的 AI 系統(含模型版本、工具授權範圍、資料存取範圍)納入 ISMS 資產識別。這是後續風險評估的基礎,跳過這步,後面都是空談。
-
對照 OWASP LLM Top 10 補充威脅識別:在風險登錄冊(Risk Register)中新增 AI 特有威脅類型:提示詞注入、模型中毒、不安全的輸出處理、過寬的 agentic 授權、供應鏈風險(如第三方模型 API)。
-
實施最小授權原則於工具呼叫設計:AI agent 能呼叫的工具和能存取的資料範圍,以完成任務所需的最小集合為準。授權設定應受版本控制,變更需要審批紀錄。
-
建立輸入過濾層:在使用者輸入進入模型前,加入結構化過濾規則;在系統提示中設計防注入的結構(明確角色邊界、不可覆蓋的指令前綴)。這不是萬能的,但能攔截大量初級注入嘗試。
-
建立輸出審計機制:AI 系統的輸入和輸出應有完整記錄,保留期限依 ISMS 現有日誌管理政策執行。異常輸出需要有人負責審查,並有明確的通報路徑。
-
定期執行 AI 系統的對抗性測試(Red Teaming):每季度或在系統重大更新後,對 AI 系統執行結構化的紅隊測試,模擬提示詞注入、工具濫用、資料滲漏等場景。測試結果回饋到 ISMS 的持續改善(Act)流程。
這六個步驟的核心邏輯:不是要建一個新的管理體系,而是把 ISMS 已有的流程骨架(資產識別→威脅評估→控制選擇→審查改善)的輸入清單,往 AI 時代更新一次。
延伸參考框架:
- ISO/IEC 27001:2022 Information security management systems(ISO 官方頁面)
- NIST AI Risk Management Framework (AI RMF 1.0)(NIST 官方文件,免費公開)
ISMS 和 ISO 27001 不是沒用,而是它們的設計原點在 AI 大規模 agentic 應用普及之前。用它們管理傳統資訊安全風險是對的,但如果以為「有認證就安全了」,那確實是在裸奔——只是穿了一套會議室西裝。
真正有效的防護,是在既有框架的邊界上,清楚知道哪裡是盲區,然後主動補上對應的控制措施。Mythos 這類具備強大 agentic 能力的模型,讓這件事變得更急迫,但問題本身並不複雜——複雜的問題,往往是因為問題還沒被定義清楚。先找對盲區,再談怎麼補。
ISO 27001 認證對 AI 系統的安全有什麼實際幫助?
ISO 27001 認證代表組織有一套系統化的資訊安全管理流程,包含資產識別、風險評估、控制措施選擇與定期審查。這個流程基礎本身有價值,但認證本身不保證組織對 AI 特有的攻擊面(如提示詞注入、工具授權失控)有具體防護措施。認證是起點,不是終點。
CNS 27001 和 ISO 27001 有什麼差異,台灣組織應該取哪個認證?
CNS 27001 是台灣對應 ISO 27001 的國家標準,技術要求高度一致,差異在於語言與本地化條文。若組織主要在台灣市場、面對政府採購需求,CNS 27001 已足夠;若有跨國業務或需要國際通用的認證效力,則需 ISO 27001。兩者並非互斥,部分組織同時持有。
什麼是提示詞注入(Prompt Injection),為什麼現有資安框架難以攔截?
提示詞注入是針對語言模型的攻擊方式,攻擊者把惡意指令藏在模型會讀取的輸入來源中,讓模型在執行正常任務的過程中被誘導執行預期外的行為,例如揭露系統設計、繞過存取限制或夾帶資料外洩。它的特殊性在於:攻擊入口是模型的推理行為本身,不是程式碼漏洞,傳統的程式碼審查和防火牆無法攔截。
組織的 ISMS 需要多快更新,才能跟上 AI 安全威脅的演進速度?
ISO 27001 要求至少每年進行一次管理審查,但 AI 安全威脅的演進速度比標準制定週期快得多。實務建議:每季度對新部署或重大更新的 AI 系統執行一次威脅評估,並在年度 ISMS 審查中更新 AI 相關的風險登錄冊項目。等待標準自動更新,不是務實的做法。
小型組織沒有資源取得 ISO 27001 認證,還能怎麼建立 AI 安全基礎?
沒有認證不代表沒有方向。OWASP LLM Top 10 和 NIST AI RMF 都是公開免費框架,可以作為風險識別的起點。最低限度的做法:建立 AI 系統工具授權清單、設定輸入過濾規則、建立基本的輸出日誌、指定一個負責人定期審查。指定責任人是關鍵——沒有人負責的控制措施,跟沒有一樣。