Cyber Threat Intelligence for Artificial Intelligence Systems 論文閱讀分析：當 CTI 開始要保護的不只是 IT，而是整條 AI 供應鏈
論文基本資訊
- 論文標題：Cyber Threat Intelligence for Artificial Intelligence Systems
- 作者：Natalia Krawczyk、Mateusz Szczepkowski、Adrian Brodzik、Krzysztof Bocianiak
- 年份：2026
- 來源：arXiv:2603.05068
- 論文連結：https://arxiv.org/abs/2603.05068
- 主題：Cyber Threat Intelligence、AI Security、AI Supply Chain、MITRE ATLAS、AVID、AI Incident Database
如果前面幾篇文章還在討論：AI agent 會怎麼被攻擊？SOC 能不能把 agent 用起來？guardrail 應該怎麼設計？那這篇 Cyber Threat Intelligence for Artificial Intelligence Systems 往前推的問題其實更基礎：當 AI 本身開始變成被保護的目標時，傳統 CTI 這套語言、資料結構與工作流程，到底還夠不夠用？
我認為這篇 paper 的價值，不在於它提出一個新模型，也不在於它想直接做某種 detection benchmark，而是它非常系統化地問了一個很多團隊其實已經碰到、但還沒整理清楚的問題：保護 AI 系統，不能只把既有 IoC、TTP、漏洞資料庫原封不動搬過來。 因為 AI 系統的資產、供應鏈、失效模式與攻擊面，都和傳統 IT / application security 不完全一樣。
這篇論文在處理什麼核心問題？
作者的出發點很直接。傳統 CTI 很擅長整理：
- 威脅行動者
- TTPs（戰術、技術、程序）
- Indicators of Compromise
- 已知漏洞與攻擊活動
但當防守對象換成 AI 系統後，很多原本理所當然的東西開始不夠用了。因為你面對的不只是一般的 server、endpoint、帳號與 API，而是還多了：
- 訓練資料
- 模型權重與參數
- 推論 API
- RAG 知識庫與向量索引
- 外部模型供應鏈
- 微調流程、資料標註流程與部署流程
也就是說，這篇 paper 想回答的，其實不是「AI 會不會有安全問題」，而是：
如果我們真的要對 AI 系統做 threat intelligence，那麼 intelligence 的觀測對象、知識來源、IoC 型別、檢索方法與工具介接方式，都應該怎麼重構？
作者提出的四個研究問題，很值得直接記下來
這篇論文在導論裡把研究問題寫得很清楚，幾乎可以直接當整篇文章的閱讀骨架：
- RQ1：傳統 CTI 與 AI-oriented CTI 有哪些差異？
- RQ2：要建立 CTI for AI knowledge base，可以用哪些資料來源？這些來源品質如何？
- RQ3：這樣的 knowledge base 對保護 AI 的工具實際有什麼幫助？
- RQ4：如何衡量既有 IoC 與新觀測 AI artifact 的相似性，讓知識庫真的能被查詢與比對？
這四個問題很重要，因為它們讓這篇 paper 不會停在空泛地喊「AI 很危險，所以需要新的 CTI」。作者是真的把它拆成：差異、資料源、應用方式、查詢與比對方法 四個層次。
作者的第一個核心主張：AI 系統的資產模型已經變了
我覺得這篇最值得吸收的第一件事，是它逼我們重新看待「資產」這件事。
在傳統 CTI 裡，我們保護的典型資產通常是：
- 主機與網路設備
- 帳密與金鑰
- 資料庫與檔案
- 應用程式與服務
但在 AI 系統裡，資產邊界明顯變得更寬，至少還包括：
- training data：可能被 poisoning、污染、置換、偏移
- model artifacts：模型權重、checkpoint、adapter、embedding model
- inference interfaces：model API、agent tool interface、RAG retrieval interface
- deployment context：模型所在的 runtime、plugin、生態整合點
- supply chain components：第三方模型、資料集、套件、MLOps pipeline
這意味著：AI-oriented CTI 不能只把 malware hash、domain、IP、URL 那一套照抄過來。 你必須開始把資料來源、訓練流程、模型版本、微調紀錄、向量索引、輸入輸出行為偏移，也視為 intelligence 的可觀測對象。
AI 的攻擊面，為什麼會讓傳統 CTI 不夠用？
作者在第二節做了一件很重要的事：先把 AI 既是防禦工具、也是被攻擊對象這件事講清楚。
AI 可以幫助防守方：
- 分析大量網路資料
- 加快異常偵測
- 自動化部分 incident response
- 整合多個 threat feed 做關聯分析
但同時，AI 自己也帶來全新風險，例如：
- data poisoning
- model poisoning
- adversarial examples
- privacy leakage / model inversion
- deployment-level compromise
- explainability 與可稽核性不足
而這些風險最大的問題，不只是「多了幾種新攻擊」，而是它們很難被傳統 CTI 的既有欄位完整描述。例如你今天說某個 hash、IP、domain 是 IoC，大家大概都知道怎麼吃；但如果今天的觀測對象是一個可疑的 LoRA adapter、一批可能被污染的 fine-tuning data、一組異常 embedding 分佈，或一個疑似被植入 trigger 的模型輸出模式，那就不是傳統 IoC schema 能直接包住的東西。
這篇論文最實際的部分：作者把 AI-oriented CTI 的資料源分成三大類
整篇 paper 最有操作性的內容，我認為在第三節。作者把可用來支撐 CTI for AI 的知識來源分成三類：
- Vulnerability-oriented sources
- Incident-oriented sources
- Adversary-oriented sources
這個三分法很值得記，因為它其實就是在幫 AI 安全領域對齊傳統 CTI 的基本工作模式：不是只有弱點，也不是只有新聞事件，而是要同時掌握弱點、真實事故、以及攻擊者 TTP。
1. Vulnerability-oriented sources：看 AI 系統有哪些弱點
作者點名了幾個重要來源：
- AVID（AI Vulnerability Database）
- OWASP AI Security and Privacy Guide
- ENISA 的 AI security 指南與框架
- Google SAIF（Secure AI Framework）
其中作者認為最像「可被 CTI 平台直接吃進去」的，是 AVID。因為它比較接近 AI 世界的 vulnerability repository：有結構、有條目、有 taxonomy，也能對應到 AI lifecycle。
相對地，OWASP、ENISA、SAIF 比較偏向：
- 風險與攻擊類型的整理
- 安全設計與治理指引
- 生命周期控制與 best practice
也就是說，它們很適合當 CTI knowledge base 的「語義骨架」，但不太像 CVE / ATT&CK 那樣直接就是 operational feed。
2. Incident-oriented sources：看 AI 真的怎麼出事
作者認為，想做 CTI for AI，不能只看理論弱點，還得看真實事故。這一層的重要資料源包括：
- AI Incident Database (AIID)
- CSET AI Harm Taxonomy
- Goals, Methods, and Failures (GMF) taxonomy
這一組來源的價值，在於它們回答的是：AI 風險最後怎麼落地成真實傷害？影響了誰？發生在哪個產業？是失誤、濫用，還是攻擊？
作者特別指出，AIID 很有價值，因為它收錄大量真實案例，讓分析者不只停留在理論風險；但它也有一個現實限制：taxonomy-driven annotations 不夠一致，很多欄位填寫並不完整。 換句話說，這類 incident source 很重要，但還沒有成熟到能像高品質威脅情報 feed 一樣直接丟進去就能跑。
3. Adversary-oriented sources：把 AI 風險轉成可操作的攻擊者視角
第三類來源，是我覺得最接近傳統 CTI analyst 直覺的一層。作者提到：
- MITRE ATLAS
- Attacking Artificial Intelligence 報告
- 其他能幫助映射 AI lifecycle 與 attacker behavior 的框架
其中最關鍵的當然是 MITRE ATLAS。如果說 AVID 比較像 AI 弱點庫，那 ATLAS 就比較像 AI 世界的 ATT&CK：它把對 AI / ML 系統的攻擊技巧、流程與 TTPs 以比較結構化的方式整理起來。
這也正是為什麼作者認為：真正可用的 CTI for AI，不能只是一份 AI 漏洞清單，而必須同時結合漏洞、事故與攻擊行為模型。
作者怎麼定義 AI-specific IoC？這是整篇最值得實作化的部分
這篇論文一個很有意思的地方，是它不只說「AI 需要新的 IoC」，而是明確指出：AI-oriented IoC 應該沿著 AI 供應鏈與生命週期去設計。
換句話說，IoC 不該只落在傳統網路面，例如 IP、domain、URL、hash；還要能對應 AI pipeline 不同階段的 artifact。從 paper 的整理來看，可以把 AI-specific IoC 大致想成下面幾類：
- 資料層：可疑訓練樣本、污染資料來源、異常標註模式、資料分佈漂移
- 模型層：可疑 model file、異常 adapter / checkpoint、後門 trigger、參數異常變化
- 部署層：推論輸出偏移、異常 prompt pattern、越權 API 呼叫、插件整合異常
- 供應鏈層：第三方模型來源、套件依賴、微調流程與部署流程的污染跡象
我覺得這裡真正重要的訊息是：AI 的 IoC 不一定是單一靜態 indicator，它常常更像一種 artifact pattern、行為偏移或相似性訊號。 這也讓傳統「黑名單式比對」的 CTI 工作法開始不夠，必須引入更強的 artifact similarity 與檢索能力。
這篇 paper 很務實地承認：AI CTI 的難題不只是知識少，而是資料品質參差不齊
作者沒有把現況講得太樂觀，這點我很欣賞。因為讀完第三節你會發現，現在 AI security 的確已經有不少框架、資料庫與 taxonomy，但最大問題是：
- 資料結構不統一
- 欄位品質不穩定
- 理論框架多，operational feed 少
- 很多知識來源偏 best practice，不是可直接查詢的 intelligence object
- incident database 很有價值，但標註深度與一致性常常不足
所以這篇論文真正的貢獻，某種程度上是在替這個領域做一次整理：我們不是完全沒有資料，而是缺少一套把這些分散資源整合成實用 knowledge base 的方法。
第五節很重要：作者把 AI 事故的蒐集，重新放回 CTI 的資產—弱點—威脅三角
我很喜歡作者在第五節做的橋接。它提醒讀者：雖然 AI 系統很新，但很多分析思路其實可以沿用傳統安全，只是要重新解釋。
作者指出，在經典安全裡，我們常用：
- assets
- vulnerabilities
- threats
這個三角來組織知識。到了 AI 世界，一樣可以用，只是內容換了：
- assets 變成訓練資料、模型、API、agent pipeline、向量庫
- vulnerabilities 變成 poisoning、evasion、backdoor、model inversion、prompt abuse
- threats 則是對手如何結合這些弱點，在不同 AI lifecycle 階段達成攻擊目的
這樣一來，AI CTI 就不再只是一些零碎 case study，而能慢慢長成真正可查詢、可聚合、可支援 tooling 的知識框架。
MITRE ATLAS 在這篇 paper 裡扮演什麼角色？
作者明確把 MITRE ATLAS 視為 CTI for AI 很關鍵的骨幹之一，原因很簡單：它讓 AI 風險不再只是弱點清單，而能往攻擊 lifecycle 推進。
論文裡提到，AI / ML 系統對應的攻擊階段大致可涵蓋：
- pre-attack reconnaissance
- initial access
- execution
- persistence
- privilege escalation
- defense evasion
- credential access
- model-specific attacks
- exfiltration
- impact
這段的重點是：AI 系統不是只有 model attack 這一種事。 它也會有和一般系統一樣的 initial access、credential access、exfiltration、impact，只是中間多了很多 AI-specific 的 exploitation surface，例如資料污染、模型竊取、對抗樣本、LLM jailbreak、prompt-based privilege escalation。
這篇論文最關鍵的技術提醒：未來比對方式會更像「相似度檢索」，不只是 exact match
作者最後一個研究問題（RQ4）其實很重要，但也最容易被低估：如果 AI IoC 不是單純的 IP / hash / domain，那 knowledge base 要怎麼查？
作者的答案方向很清楚：未來得更重視：
- artifact similarity
- pattern matching
- 對新觀測 AI object 的相似度衡量
- 把 knowledge base 做成可支援工具決策的檢索層
這點我很認同。因為在 AI 安全裡，很多可疑跡象不是 exact indicator，而比較像：
- 某個可疑樣本與已知 poisoning cluster 很像
- 某個 adapter 的行為與已知後門樣式接近
- 某組 prompt / output pattern 和已知 jailbreak 家族相似
- 某份資料集的統計特徵與已知污染來源高度相近
也就是說，AI CTI 很可能天然就比傳統 CTI 更需要 embedding、相似度搜尋、圖譜關聯與語義檢索。 這不只是工程上的選配，而是因為觀測對象本身已經變了。
如果把這篇 paper 濃縮成一句話，它真正講的是什麼？
這篇論文真正想說的是：AI security 已經不能只靠 AI red teaming 或單點 guardrail；它需要一套像傳統 CTI 那樣可持續累積、可查詢、可操作的 intelligence framework，但這套 framework 的資料物件、IoC 型態與查詢方法，都必須對 AI 資產與 AI 供應鏈重新設計。
這篇 paper 的價值與限制
我認為它的價值主要有三個：
- 第一，問題定義得很好。 它把「CTI for AI」從口號整理成具體研究議程。
- 第二，資料源整理得夠實用。 讀完後你會知道 AVID、AIID、CSET、GMF、MITRE ATLAS 各自站在哪一層。
- 第三，它把 AI-specific IoC 與 similarity retrieval 這條線講清楚了。 這對未來做知識庫、SOC tooling、AI asset monitoring 都很有啟發。
但它也有明確限制：
- 它比較像 framework / survey / agenda-setting paper，不是提出新 benchmark 或新系統
- 沒有真的實作一個可運行的 AI-CTI platform 來驗證整套方法
- 很多建議目前仍停留在知識組織與設計方向，距離 operationalization 還有一段路
換句話說，這篇 paper 不是來回答「哪個模型今天最好」，而是回答：如果未來真的要做 AI threat intelligence，路應該怎麼鋪。
總結
Cyber Threat Intelligence for Artificial Intelligence Systems 是一篇很值得補進最近這條 agentic security / CTI 主線的論文。它沒有走炫技路線，而是回到一個更長期也更關鍵的問題：AI 系統需要自己的 threat intelligence 語言、資料結構與知識庫設計。
從這篇 paper 看出去，下一階段真正重要的工作大概不是再多做幾份零散的 AI risk taxonomy，而是把這些分散資源慢慢收斂成：
- 可維護的 AI vulnerability objects
- 可查詢的 AI incident knowledge base
- 可映射 attacker behavior 的 AI TTP framework
- 可支援 artifact similarity 與實務 toolchain 的 intelligence retrieval layer
如果要把這篇濃縮成最白話的一句話，那就是：
當 AI 自己變成攻擊目標，CTI 也得從保護一般 IT 系統，進化成保護資料、模型、推論介面與整條 AI 供應鏈。
本文由 AI 協助整理與撰寫，內容依據論文、公開摘要與作者揭露資訊進行分析；若你正在規劃 AI security / AI governance / CTI for AI 相關工作，這篇很適合作為建立知識框架時的起點。