CritBench 論文閱讀分析：當 LLM Agent 開始碰 IEC 61850 數位變電站，舊的資安 benchmark 就不夠了
論文基本資訊
- 論文標題：CritBench: A Framework for Evaluating Cybersecurity Capabilities of Large Language Models in IEC 61850 Digital Substation Environments
- 作者：Gustav Keppler、Moritz Gstür、Veit Hagenmeyer
- 年份：2026
- 來源：arXiv:2604.06019
- 論文連結：https://arxiv.org/abs/2604.06019
- DOI：10.48550/arXiv.2604.06019
- 主題：Operational Technology、IEC 61850、Digital Substation、LLM Agent、Benchmark、ICS Security、Critical Infrastructure
如果最近幾篇文章一路在談 SOC workflow、incident response orchestration、agent guardrail、system prompt attack surface，那接下來很自然會遇到另一個更少人真的碰進去、但風險可能更高的問題：當 LLM agent 不再待在一般 IT 環境，而是開始接觸 OT / ICS / critical infrastructure，現有 benchmark 還夠不夠用？
CritBench 這篇論文的價值，就在它把這個問題硬生生拉出來。作者的核心批評很直接：現在多數資安 AI benchmark，無論是 CTF、web exploitation、code security 還是一般 cyber QA，本質上都還是站在 enterprise IT 的地板上思考。可是真實世界裡，像 IEC 61850 digital substation 這種 OT 環境，風險模型、協定語言、操作限制、以及失敗代價，全都不是同一個層級。
所以這篇 paper 真正要問的不是「模型懂不懂資安」，而是更具體的一句話：
當 agent 被放進數位變電站這種 industrial protocol environment，它到底還能不能穩定完成 reconnaissance、protocol understanding，甚至 live interaction 與 state manipulation？
這篇論文想補的洞：現有 benchmark 大多測 IT，不太測 OT
作者認為，當前很多 LLM cyber benchmark 的共同盲點，不是沒有技術深度，而是環境假設太單一。它們通常預設：
- 目標是標準 Linux / web / application stack
- 錯誤訊號清楚、可回饋、甚至很「developer-friendly」
- 任務邏輯偏向一般 IT 世界熟悉的 enumeration、 exploitation、 patching 或 CTF 解題
但 OT 完全不是這個宇宙。Digital substation 這類環境更在意的是：
- availability 而不只是 confidentiality
- physical safety 而不只是資料完整性
- specialized industrial protocols，像 MMS、GOOSE、SV、IEC 60870-5-104
- 低容錯的連續系統操作，而不是隨便試錯的 web app sandbox
這也是 CritBench 想補的真正缺口：如果 agent 評測只停在 IT benchmark，我們其實還不知道它面對 critical infrastructure 時到底行不行，或者危不危險。
CritBench 在做什麼：把 benchmark 搬進 IEC 61850 digital substation
這篇論文提出的是一個專門面向 IEC 61850 digital substation 的 benchmark framework。它不是只有一組題目而已，而是把整個評測拆成三個部分：
- task specification：每題定義目標、環境、限制、成功條件
- execution environment：讓 agent 在隔離環境中與工具、檔案、虛擬裝置互動
- host-side evaluation：從答案字串與最終系統狀態驗證是否真的完成任務
論文一共建立了 81 個 domain-specific tasks，覆蓋三大類情境：
- 30 個 static configuration analysis tasks
- 30 個 network traffic analysis tasks
- 21 個 dynamic live interaction tasks
這個設計很關鍵，因為它不是只測模型會不會背 IEC 61850 術語，而是一路往上推到：
- 會不會解析真實 SCD / CID 類型配置
- 會不會從 PCAP 裡重建 protocol-level intelligence
- 會不會在 live VM / containerized IED 環境裡，真的透過協定改變系統狀態
任務怎麼分：從看懂檔案，到碰活系統
1. Static configuration analysis
第一類任務聚焦在 SCD files 等 IEC 61850 配置描述檔。這些 XML 檔不是普通設定檔，而是 digital substation 的拓樸與控制語意本體。agent 得做的事情包括：
- 解析 voltage levels、bays、primary equipment
- 找出 logical nodes 與 protection functions
- 辨識 VLAN、GOOSE multicast MAC、dual-homed relay 等網路結構
- 比對多個版本，找出 revision anomaly 或未授權設備變動
這類任務看似靜態，但其實很能測出一件事：模型是不是只會講 OT 名詞，還是真的能把 structured industrial configuration 讀懂。
2. Network traffic analysis
第二類是被動流量分析。作者讓 agent 從 PCAP 中抽取 IEC 61850 與相關協定的 intelligence，包括：
- Sampled Value 的同步狀態與資料打包特徵
- GOOSE 的 configuration revision anomaly 與 time-allowed-to-live 異常
- MMS data model reconstruction
- 跨 protocol 追蹤同一裝置的 UID、IP 與 role mapping
這一段很有意思，因為它讓 benchmark 不只是在測「會不會封包分析」，而是在測模型能不能把 process bus 與 station bus 裡分散的訊號，重建成對 OT operator 有意義的判讀。
3. Dynamic system interaction
第三類任務才是這篇論文真正把壓力拉高的地方：動態互動。Agent 不再只是看檔案、看封包，而是要對 containerized IED environment 主動下手。
這個環境包含：
- 基於 libIEC61850 的 MMS / GOOSE server
- IEC 60870-5-104 server
- 一個 out-of-band state API，專門記錄裝置內部狀態是否真的被改變
這表示成功條件不是 agent 說自己做到了，而是 host 端真的能驗證：
- breaker 是否被切換
- setpoint 是否被覆寫
- IED 內部狀態是否真的進入目標狀態
到這一步，benchmark 才真正從「知識問答」變成可驗證的 cyber-physical interaction evaluation。
CritLayer：這篇論文最值得注意的地方之一
CritBench 不只丟一堆 OT 任務給模型裸跑，作者還設計了一套 domain-specific scaffold，叫做 CritLayer。
CritLayer 可以理解成一層專為 digital substation interaction 設計的工具註冊表。它把複雜的 industrial protocol 操作，包裝成 agent 可以呼叫的工具，例如：
- packet analysis utilities
- MMS read / write functions
- GOOSE injection tools
- IEC 60870-5-104 client operations
這一點非常關鍵，因為它揭露了一個最近 agentic security 論文反覆出現的結論：很多時候，限制 agent 的不是它完全不懂，而是它沒有足夠貼近任務語言的工具層。
對 OT 這種高度專用環境尤其如此。模型也許知道 IEC 61850 的名詞，但如果沒有一個能把協定操作抽象成可控工具呼叫的中介層，它很難在 live system interaction 裡穩定成功。
評估方式很務實：不只看文字答案，也看系統狀態
CritBench 的評估設計也比很多 benchmark 更成熟。作者把驗證方式拆成三種：
- Textual evaluation：比對字串、substring、regex
- State verification：直接檢查 IED 內部狀態有沒有改變
- Multi-check：混合答案文本與系統狀態，給部分分數
這個設計的重要性在於：在 OT / ICS 任務裡，agent 說對不代表做對；真正有意義的是 system state 到底有沒有被正確地改變。
這也是我很喜歡這篇論文的一點。它沒有把評測退化成「像不像對的回答」，而是努力往operational truth 靠攏。
實驗結果：模型在靜態任務還不錯，一進動態互動就掉下去
作者評測了五個模型，包含 OpenAI GPT-5 系列與開放權重模型。整體結果裡最值得記住的幾個數字是：
- GPT-5.1 整體最高，準確率 86.4%
- Qwen3.5 397B A17 達 76.6%
- GPT-5 nano 只有 43.3%
光看這三個數字，好像會讓人覺得「那其實還不錯啊」。但真正重要的是作者的 breakdown：模型在 static structured-file analysis 與單步 network enumeration 還算穩，真正掉分的地方是 dynamic tasks。
也就是說，問題不在模型完全不懂 IEC 61850 terminology；相反地，作者明確指出，這些模型其實展現出某種internalized protocol knowledge。真正的瓶頸是：
- 持續多步驟推理
- 狀態追蹤
- 跨工具／跨觀察的 sequential interaction
- 在 live system 上維持正確操作上下文
這個結果非常像我們在 SOC agent、IR copilot、code agent 甚至 offensive benchmark 上一再看到的模式：模型最容易失手的地方，不是第一步認知，而是長鏈條執行。
這篇論文最重要的結論：不是不知道，而是做不穩
CritBench 最有研究價值的地方，是它把失敗點說得很清楚。作者沒有把結論寫成「模型不懂 OT」，而是更精準地指出：
現階段模型對 IEC 61850 名詞、資料結構、甚至部分 protocol semantics 並非完全陌生；真正卡住的是缺乏穩定完成動態互動所需的 sequential reasoning 與 state tracking。
這個差異很重要。因為它意味著未來若要讓 LLM agent 真正碰 OT / ICS，不一定只是繼續灌更多領域知識，而更可能需要：
- 更好的 domain-specific tooling
- 更穩定的 memory / state representation
- 更嚴格的 action validation 與 rollback 機制
- 更低風險的 execution sandbox 與 supervision layer
也就是說，OT agent 的難題本質上是 systems engineering problem，不只是 language understanding problem。
它和最近幾篇論文的關係在哪？
如果把 CritBench 放進最近這串文章脈絡裡，它的位置其實很漂亮。
- 它不像 SIABench、IRCopilot 那樣聚焦 SOC / IR 工作流。
- 它不像 AgentDoG、AIR、Clawed and Dangerous 那樣主要談 safety / governance。
- 它也不像 SEC-bench 站在 AppSec / repository security engineering 的路線。
CritBench 真正補上的，是 critical infrastructure / OT benchmark 這塊缺口。它把 agent evaluation 從一般 IT 場景延伸到更高風險、更多專有協定、也更少容錯的 industrial environment。
所以這篇 paper 最值得記住的一點不是「又多一個 benchmark」，而是：
它提醒我們，當 AI agent 開始碰到電力系統、變電站、工控協定時，不能再拿 web / CTF / Linux 類 benchmark 當作能力代理變數。
對產業的意義：OT 不是把 IT benchmark 放大就好
這篇論文對實務界最大的提醒，我認為有三個。
1. 不要把 IT world 的成功經驗直接外推到 OT
模型在 web security、code agent、CTF 甚至一般 SOC 任務上有進展，不等於它已經能安全碰 OT。OT 的 interaction grammar、風險邏輯與可接受失敗成本都不同。
2. Tool scaffold 不是加分題，而是必要條件
CritLayer 的結果很清楚：在 industrial protocol environment 裡，沒有貼近任務語言的工具層，agent 很難穩定做事。這意味著未來任何想在 OT 佈署 AI agent 的系統，tool design 本身就是安全與可用性的核心。
3. 真正要防的不是模型完全不懂，而是半懂半會地操作活系統
這可能是最可怕的一點。因為從論文結果看來，模型不是零分，而是足以讓你誤以為它可以做更多。這種情況在高風險環境裡反而更危險：它看起來懂、也能做幾步，但一旦進到長鏈條互動，就可能在錯誤狀態上繼續推理，最後把系統帶進不該去的地方。
這篇論文的限制也值得一起看
當然，CritBench 也有侷限。
- 第一，它聚焦的是 IEC 61850 digital substation，不等於涵蓋全部 OT / ICS 場景。
- 第二，雖然已比一般 benchmark 更接近現場，但仍是可控、可隔離的研究環境。
- 第三，它主要衡量 capability，不直接等於完整風險評估；真實部署還牽涉政策、權限、監控與 fail-safe 設計。
- 第四，若後續能加入更細的 trajectory failure analysis，會更能拆出 agent 是卡在 planning、memory、tool selection 還是 protocol semantics。
不過這些限制不會削弱它的重要性。相反地，正因為這塊領域太少 benchmark，CritBench 才顯得特別關鍵。
總結
CritBench: A Framework for Evaluating Cybersecurity Capabilities of Large Language Models in IEC 61850 Digital Substation Environments 是一篇很值得接在最近這串 agentic security / benchmark / critical infrastructure 脈絡後面的論文。它最大的貢獻，不只是又做了一套新評測，而是把問題從一般 IT 世界推進到 OT / ICS 現場：當 agent 開始碰變電站與工控協定，我們終於有比較像樣的方式去量它到底會什麼、又卡在哪裡。
如果要把這篇 paper 濃縮成一句話，我會這樣說：
CritBench 告訴我們，LLM agent 在 OT 裡最危險的地方不是完全無知，而是它已經懂到足以開始操作，卻還不夠穩到能安全地把動態互動做完。
而這也正是 critical infrastructure 場景最需要被誠實量測的地方。
本文由 AI 產生、整理與撰寫。