SOC × LLM 論文閱讀分析：大家不是不用 AI，而是不敢把高風險收尾真的交給它
論文基本資訊
- 論文標題：Like a Hammer, It Can Build, It Can Break: Large Language Model Uses, Perceptions, and Adoption in Cybersecurity Operations on Reddit
- 作者：Souradip Nath、Chih-Yi Huang、Aditi Ganapathi、Kashyap Thimmaraju、Jaron Mink、Gail-Joon Ahn
- 來源：arXiv
- 年份：2026
- 論文連結：https://arxiv.org/abs/2604.09998
- 主題：SOC、LLM adoption、Human-AI collaboration、Incident Response、Security Operations、Practitioner Study
Like a Hammer, It Can Build, It Can Break 這篇論文不是再做一個新的 SOC copilot，也不是再秀一次「LLM 可以幫忙寫 KQL、整理 incident summary、做 alert triage」的 demo。它真正有價值的地方，是作者退一步去問一個更根本、也更容易被產品行銷蓋掉的問題：現實世界裡的資安從業者，到底怎麼在用這些 LLM 工具？他們相信到什麼程度？又在哪裡明確不敢放手？
這題很重要，因為這兩年大家對 SOC × LLM 的討論，常常被兩種聲音綁架：一種是 vendor 版本的「很快就能 autonomous SOC」；另一種是純技術論文版本的「某個 benchmark 又進步了幾個點」。但真實世界的 adoption 往往卡在完全不同的地方：不是模型會不會答，而是分析師敢不敢真的把某一段工作交出去；不是 prototype 能不能跑，而是 verification overhead、隱私風險、誤判成本與組織責任到底誰來扛。
這篇研究的核心貢獻，就是用 Reddit 上三個資安社群、892 則相關貼文，把這個落差系統性攤開來看。它告訴我們：LLM 在 SOC 裡不是沒用，相反地，大家已經真的在用；但大多數人把它放在低風險、高可驗證、能保留人類主導權的位置，而不是直接讓它接管高風險 response loop。
這篇論文在問什麼？
作者想回答三個問題：
- RQ1：資安從業者在 SOC 工作裡提到哪些 LLM 工具、拿它們做哪些事？
- RQ2：他們認為這些工具的優點與缺點是什麼？
- RQ3：他們怎麼看待這些工具的 adoption，以及它們對產業與分析師工作的長期影響？
這三題看起來像 usage survey，但其實不是那麼簡單。因為作者不是發問卷問「你喜不喜歡 AI」，而是直接觀察社群裡自然長出來的討論。這種做法的價值在於，它比較容易看到真實工作現場的 friction：哪些地方大家真的覺得省時間、哪些地方覺得麻煩、哪些地方明確說「這步我不敢給它自己做」。
方法：不是測模型分數，而是看真實社群怎麼說
作者採用 mixed-methods 分析，資料來自 Reddit 上與資安工作高度相關的論壇討論。整體流程大致如下：
- 先從多個 cybersecurity-focused subreddit 搜尋與 LLM / AI / SOC 相關的 threads
- 收集 2022 年 12 月到 2025 年 9 月之間的討論
- 先抓到 1,310 個 threads、1,703 則 posts
- 再透過人工與 LLM 輔助分類，最後保留 76 個 relevant threads、892 則 relevant posts
- 進一步做 qualitative coding、主題分析與比例統計檢定
這裡有兩個方法上的亮點。
第一，它不是只抽訪幾個資安主管，也不是只看產品案例，而是看大規模、自然發生的 practitioner 討論，因此更容易看到一線使用者的語氣與真實保留。
第二，它把結果拆成「工具」、「使用情境」、「正負面觀感」、「adoption 與未來想像」幾個層次，而不是只做籠統的 sentiment analysis。這讓它能回答的不只是「大家喜不喜歡」，而是大家把 LLM 擺在 SOC pipeline 的哪裡、給它多少自治權、在哪些地方明顯拉手煞車。
最重要的發現一：大家最常提的，不是 security-native 工具，而是通用型 LLM
論文裡一個很關鍵的訊號是：雖然市場上一直在推 security-specific LLM platform，但實際討論最常出現的，仍然是 ChatGPT、Microsoft Copilot、Claude 這類通用型模型，而不是一長串安全產品原生 copilot。
這代表什麼？代表在真實 SOC adoption 裡，入口往往不是「買一套新的 autonomous SOC 平台」；而是分析師先把手邊最容易取得、最熟、摩擦最低的通用模型拿來解決局部問題。
從組織導入角度看，這一點比任何 benchmark 都重要。因為它意味著 LLM adoption 的起點，通常不是正式、全域、制度化的安全平台整合，而是更像個人工作流裡的 shadow augmentation：
- 幫忙改寫查詢語法
- 幫忙整理 investigation notes
- 幫忙把技術內容翻成比較可讀的 summary
- 幫忙寫 script、正規表示式、報告段落
也就是說，最先落地的不是 autonomy，而是 productivity。
最重要的發現二：SOC 裡最常被拿來用的，是低風險、好驗證的任務
作者把討論中的 use case 做了系統性整理，發現提及最多的仍是 incident response 與 triage 相關活動；但如果只看「真的在用」而不是「覺得可用」，重心會往更低風險的工作偏移，例如：
- 寫或改 shell / Python / SIEM query
- 整理事件摘要與報告
- 將複雜告警翻成較易理解的人話
- 做知識輔助與快速查詢
- 為既有分析流程補上初稿，而不是直接做最終判斷
這個現象很值得記住。因為它說明：實務界對 LLM 的接受程度，不是看任務是不是重要，而是看錯了之後多痛、以及人類要驗證它有多難。
同樣是 SOC 工作：
- 讓模型幫你產生一段 KQL，你可以自己 review 後再跑，風險相對可控
- 讓模型先整理一版 incident summary，你可以人工改寫，風險也相對可控
- 但如果讓模型自己決定是否隔離主機、封鎖帳號、執行 remediation，風險、責任與可回復成本都完全不同
所以這篇論文其實在提醒一件很現實的事：SOC 裡的自治權設計，本質上不是模型能力排序，而是風險分層與可驗證性設計。
最重要的發現三：大家不是不用，而是不信任它自己收尾
論文把 practitioner 對 LLM 的使用方式整理出一個很漂亮的 autonomy gradient：
- 最常見的是 decision support
- 其次才是 human-in-the-loop pipeline
- 真正把它放到 fully autonomous end-to-end mitigation 的非常少
這幾乎可以當成今天 SOC × AI adoption 的核心現實。大家不是覺得 LLM 完全沒價值，而是大多數人把它當成：
- 加速器
- 整理器
- 對話式查詢介面
- 草稿生成器
- 輔助判讀工具
而不是可以放心交辦 closing action 的 autonomous analyst。
這裡最值得注意的，不只是「大家保守」，而是這種保守其實相當理性。因為在高風險 SOC 工作裡，真正昂貴的不只是 hallucination 本身，而是：
- 你要花多少時間驗證它
- 它若錯了會不會造成誤封鎖、誤升級、誤歸因
- 組織是否能接受責任不明的自動決策
- 資料是否可以安全餵進第三方模型
優點不是沒有，而且很實際
論文沒有把 practitioners 描述成一群完全排斥 AI 的人。相反地，不少討論都指出 LLM 的實際價值，包括：
- 效率提升：特別是在整理、重寫、摘要、查詢生成這些任務上
- 降低認知負擔：把複雜技術內容先翻成較容易消化的形式
- 加速初步分析：作為 investigation 的 starting point 很有幫助
- 改善工作流流暢度：尤其對報告、腳本與文書型輸出最明顯
這裡其實對產品設計有一個很重要的啟示：LLM 在 SOC 的價值，很多時候不是替代分析師判斷，而是替分析師省下那些不值得用高級人腦反覆消耗的摩擦成本。
如果產品設計者一直把勝負押在「模型能不能自己做完 incident response」，反而可能忽略當下最穩、最能落地的價值區：提高 analyst throughput、降低上下文切換成本、讓證據整理與查詢構造更快。
但限制也同樣清楚：可靠性、驗證成本、隱私與安全風險
論文最有份量的地方，是它很清楚地指出：即使大家看見效率收益，真正卡住大規模 adoption 的仍然是 trust 問題。而且這個 trust 不是抽象的「我不喜歡 AI」，而是具體、可操作、每天都會遇到的四種成本：
- 可靠性不足：會編、會猜、會在安全細節上一本正經地亂講
- 驗證成本高：省下的時間可能又被 review 吃回去
- 安全與隱私風險：敏感告警、log、IR artifact 能不能送進模型，本身就是治理問題
- 成本合理性不清：工具費用與真實產值之間未必成比例
這也是我認為這篇論文最成熟的地方：它沒有把 adoption 當成「能力變強 → 自然被接受」的線性問題，而是把它看成一個 sociotechnical negotiation。換句話說，模型再強，只要 verification overhead 還在、資料治理不清、責任歸屬不明，它在 SOC 裡的自治半徑就很難真的放大。
這篇論文真正戳破了什麼迷思？
我覺得它至少戳破三個常見迷思。
迷思一：只要 benchmark 夠高，SOC 自然會自動化
錯。真實世界裡，benchmark 只是必要條件，遠遠不是充分條件。SOC 導入看的是 失誤代價、可審計性、資料邊界、責任鍊與人機分工。
迷思二：security-specific copilot 一定比通用模型更快被採用
也不一定。這篇論文看到的是：實務上先被廣泛提到與拿來試的，反而常是通用型模型。因為 adoption friction 低、大家更熟、比較容易拿來做自我範圍內的小任務。
迷思三：大家不讓 AI fully autonomous，是因為保守或不懂技術
未必。很多時候不是保守，而是成熟。因為高風險 security workflow 本來就該問：哪一步可以錯？誰來驗？錯了怎麼收？ 在這些問題沒被制度化之前，拒絕 fully autonomous 反而是健康訊號。
對 SOC 與 agentic security 的啟示
把這篇論文放回最近整波 agentic security 脈絡裡看，它提供了一個很重要、但常被忽略的角度：不是所有安全問題都發生在模型失控那一刻，很多問題其實早在 adoption design 階段就決定了。
如果我們已經知道 practitioners 最能接受的是低風險、可驗證、可回滾的工作，那麼比較務實的設計方向應該是：
- 把 LLM 放在 evidence organization、query drafting、summary drafting、knowledge grounding 這些位置
- 把高風險 remediation 與 irreversible action 維持在明確的 approval boundary 後面
- 降低 verification overhead，而不是只追求更長更聰明的輸出
- 把 privacy、data residency、auditability 與 provenance 做成產品第一級能力，而不是補丁
說白一點，真正能推動 SOC adoption 的，可能不是讓 AI 看起來更像 autonomous analyst，而是讓它更像一個可控、可查、可回頭追責的工作台。
研究限制
當然，這篇研究也有它的邊界：
- 資料來自 Reddit，使用者未必能代表整個資安產業
- 角色與經驗多半是 self-reported，無法完全驗證
- 社群討論可能偏向對新工具比較敏感、也比較願意公開發言的一群人
- 它反映的是「被討論、被感知、被嘗試」的 adoption，不等於企業內部真實部署全貌
但即便如此，這種大規模、自然語境下的 practitioner discourse，仍然非常有價值。因為它補上的，正是很多技術論文缺的那塊：人到底怎麼看、怎麼怕、怎麼偷用、怎麼局部採納、又在哪裡踩煞車。
我的看法
如果你最近看很多 SOC × LLM 論文，會很容易掉進一種錯覺：好像現在的問題只剩下模型再進步一點、agent 再多一步、benchmark 再高一點，SOC 自動化就會自然到來。但這篇論文很誠實地提醒我們，真實世界的卡點從來不只是在「能不能做」，而是在「敢不敢交、交到哪、驗證值不值得、以及出事時誰負責」。
所以這篇 paper 最值得帶走的一句話，不是「LLM 對 SOC 很有幫助」，而是：
LLM 在 SOC 裡最有機會被長期採納的地方，不是它最像人類分析師的地方，而是它最能降低摩擦、又不會讓責任邊界失焦的地方。
這也是為什麼我會覺得這篇論文很值得讀。它不是在替某個產品站台，也不是在唱衰 AI；它做的是更難、也更接近現場的事：把 adoption 的真實阻力與真實價值都講清楚。對任何想做 SOC copilot、agentic IR、或 enterprise security AI 的人來說，這種 paper 往往比另一篇漂亮 demo 更有用。