RulePilot 論文閱讀分析：當偵測規則真正卡住時，問題常常不是模型不會寫，而是它能不能把安全語意穩定翻成 SIEM 真的能跑的查詢

論文基本資訊

• 論文標題：RulePilot: An LLM-Powered Agent for Security Rule Generation
• 作者：Ming Xu、Yanpei Guo、Weili Han、Hoon Wei Lim、Jin Song Dong
• 年份：2026
• 來源：ICSE 2026 / arXiv:2511.12224
• 論文連結：https://arxiv.org/abs/2511.12224
• 主題：Detection Engineering、SIEM、Splunk、KQL、Rule Generation、SOC Automation

本文由 AI 產生、整理與撰寫；內容基於論文與可公開查得資料，重點在快速抓主線與實務意義，建議仍搭配原文交叉閱讀。

如果前一批 sectools.tw 較多在談 prompt injection、agent runtime、MCP control plane 與 privilege，那 RulePilot 這篇值得補進來的原因很直接：它碰的是另一種在企業現場一樣痛、但比較少被寫成 agent paper 的問題——很多團隊不是不知道要做偵測，而是寫規則、改規則、搬規則這件事本身就太吃人力了。

這篇 paper 的核心其實不是「讓 LLM 幫你產生一段查詢」這麼簡單，而是想回答更實際的問題：當 security analyst 只給你自然語言描述、攻擊意圖或高階偵測需求時，agent 能不能把這些需求穩定拆成 structured intermediate representation，再翻成 Splunk SPL 或 Sentinel KQL 這種真的能上線執行的規則？

我會把它的主線濃縮成一句話：RulePilot 真正想自動化的，不只是 rule authoring，而是從需求理解、規則結構化、反思修正到 live SIEM 驗證的整條 detection engineering pipeline。

這篇論文在解什麼問題？

作者先點出一個很務實的現場痛點。規則式偵測雖然老派，但在 SIEM 世界裡它仍然極度重要，原因也很簡單：

• 輕量：比很多 graph / deep learning 偵測方案更容易部署
• 可解釋：分析師看得懂規則在抓什麼
• 可營運：更容易和現有告警流程、例外處理與調校機制接起來

但規則式偵測真正貴的地方，不是執行，而是產生與維護：

• 要把 threat description 翻成特定 SIEM 語法，本來就需要 domain knowledge
• 不同平台各有自己的 query language，規則很難直接搬
• 攻擊手法在變，規則也得跟著調
• 初稿寫出來不代表能跑，更不代表抓得到、抓得準

換句話說，真正卡住的不是「有沒有 LLM」，而是能不能把自然語言威脅語意穩定轉成平台特定、語法正確、邏輯對齊、還能通過 execution test 的 rule。

為什麼這題比一般 code generation 更難？

作者有一個我很認同的觀點：安全規則生成不像一般 code generation 那麼有標準答案。

寫程式時，冗長一點、醜一點，通常還是可能 compile；但寫 SIEM 規則時，很多問題不是 syntax error 而已，而是：

• field mapping 對錯
• 條件組合是否符合平台語意
• nested operator 有沒有壞掉
• 時間窗、統計條件、排除條件是否合理
• 規則到底能不能在真實 log 上跑出有意義結果

也就是說，這不是單純 text-to-query，而比較像text-to-detection-logic-to-platform-executable-rule。RulePilot 有意思的地方，就是它沒有假裝這是一個單輪 prompt 就能解完的問題。

RulePilot 的核心設計：IR 不是附屬品，而是整篇最重要的骨架

這篇 paper 最值得記的設計，我覺得不是 agent 兩個字，而是它引入了 Intermediate Representation（IR）。

作者的想法很實際：既然直接從自然語言跳到 Splunk / KQL 規則太容易失真，那就先把需求拆成一個比較抽象、比較結構化、又能保留安全語意的中介層。這個 IR 會承接像是：

• 偵測目標與前提
• 關鍵欄位與條件
• 邏輯關係
• 統計與聚合需求
• 平台特定規則落地前必須補齊的 constraint

這樣做的價值不只是讓 prompt 比較乾淨，而是把整個問題從「叫模型一次寫完」改成「先建 detection logic，再做平台映射」。對 detection engineering 來說，這比單純多打一層 prompt template 更像真正的工程方法。

第二個關鍵：Reflection loop 才是讓它像 agent 的地方

RulePilot 另一個值得注意的組件是 reflection / iterative optimization。作者很清楚知道，第一版生成的 rule 很可能在三個地方出錯：

• 語法不對
• 語意不對
• 邏輯上看起來對，但在真實環境裡不能用

所以它不是單純生成後就結束，而是把流程設計成：

自然語言需求
→ least-to-most 分解
→ intermediate representation
→ 初版規則生成
→ reflection 找出弱點
→ 修正 reasoning / field mapping / condition handling
→ 再次驗證與優化

這種設計很像近年比較成熟的安全 agent 路線：不是賭第一次輸出夠完美，而是把錯誤發現與修正本身納入 workflow。

最實際的地方：它真的接了 live Splunk 去驗

我覺得 RulePilot 比較加分的一點，是它沒有停在字面相似度。作者明確把系統接到 live Splunk environment，讓生成規則不只在文字層看起來像 ground truth，而是真的去測：

• 能不能成功執行
• 能不能抓到可疑活動
• 邏輯與條件是否在真實資料上成立

這一點很關鍵。因為很多 rule-generation paper 最後只交 BLEU、similarity、LLM judge 或 syntax-validity；但 detection rule 真正的生死線從來不是「看起來像不像」，而是跑起來之後到底有沒有 operational value。

作者甚至把使用情境拉得很明確：一個 junior analyst 不需要完全熟悉複雜 rule grammar，只要能提供高階需求，再由 RulePilot 幫忙生成與轉換，最後由人做驗證。這個 framing 我覺得滿對，因為它不是在假裝 human disappears，而是把人從 grammar labor 拉回 risk review。

Rule conversion 也是亮點：不是只幫你寫，還幫你搬

RulePilot 不只做 rule creation，也處理 cross-platform conversion，尤其是 Splunk SPL ↔ Microsoft Sentinel KQL。這件事其實很貼 production。

因為企業換 SIEM、併購整併、雙平台並存，都是常態。最麻煩的地方不是 rule 檔案搬不動，而是：

• 欄位語意不同
• 聚合與函數語法不同
• 同一偵測邏輯在不同平台表達方式不同
• 轉過去後還得重驗，不然很容易只剩表面相似

所以我會把這篇和前面一些「rule generation」論文分開看：RulePilot 更像是在處理 detection logic portability，而不只是多吐幾條新規則。

結果怎麼看？

論文裡最值得記的幾個結果是：

• 在 textual similarity 上，相對 baseline 最多提升 107.4%
• 在 live Splunk execution tests 中，生成規則可達很高的 detection effectiveness，部分案例 F1 可到 1.00
• field study 顯示它對 junior analysts / general users 的幫助特別明顯

第一個數字我會保守看，因為 textual similarity 永遠不是 rule quality 的最終答案；但第二個就比較重要了。只要 paper 願意把 rule 拿去真實環境跑，而不是只看文字分數，就已經比很多類似工作更接近 production reality。

當然，論文自己也承認限制：LLM 對 field mapping、condition handling 與邏輯細節仍然會犯錯，所以最後仍然需要 human verification。這點我反而覺得是優點，因為它沒有把事情說得太神。

這篇論文真正值錢的地方

我覺得 RulePilot 真正戳到的，不是「LLM 可以寫規則」這件大家大概都猜得到的事，而是下面這個比較關鍵的轉向：

安全規則生成若要有實戰價值，重點不是把自然語言直接翻成查詢，而是把 detection intent 穩定地穿過 IR、reflection 與 execution validation 這條鏈，最後落到可運行的 SIEM artifact。

這個 framing 跟最近很多 agentic security paper 其實有共通點：真正決定上限的，不是模型夠不夠聰明，而是execution architecture。RulePilot 把這件事放在 detection engineering 上，看起來就特別合理。

我怎麼看這篇？

如果拿它和前面已經寫過的 RuleForge 放在一起看，我會說兩篇剛好補在 detection engineering 兩個不同層次上：

• RuleForge 比較偏從 CVE / template 自動長出 web detection rule，重點在 multi-candidate generation 與 validation loop
• RulePilot 則更像把 analyst 的自然語言需求，透過 IR 與 reflection 落成 SIEM 規則，並補上 migration / conversion 與 live Splunk execution

也就是說，前者比較像「從漏洞知識長偵測」，後者比較像「從偵測需求長規則並跨平台落地」。兩條線都重要，但 RulePilot 更貼近 SOC 團隊每天真的要維運的 rule lifecycle。

我自己最認同的是它沒有把人排除掉。對安全規則這類高 operational consequence 的產物來說，最合理的終點通常不是 fully autonomous publishing，而是把 AI 放在前面加速生成、修正與遷移，再把人留在最後的 approval 與風險判斷。

重點整理

• RulePilot 要解的不是單純 text-to-query，而是把自然語言偵測需求穩定翻成可執行的 SIEM 規則。
• 論文把難點講得很對：安全規則生成真正卡住的是field mapping、條件處理、平台差異與 execution viability，不是單純語法。
• 核心設計是 Intermediate Representation（IR），先把 detection intent 結構化，再落地成 Splunk SPL / Sentinel KQL。
• 另一個關鍵是 reflection / iterative optimization，把錯誤修正納入 workflow，而不是賭單輪 prompt。
• 論文不只看 textual similarity，也接了 live Splunk 去驗證規則能不能真的跑與抓到可疑活動。
• 相對 baseline，文本相似度最高可提升 107.4%；在部分執行測試裡，規則偵測效果可到 F1 1.00。
• 它還支援 Splunk SPL ↔ KQL 的 rule conversion，這對 SIEM migration / dual-platform 維運很有實際價值。
• 這篇最值得記住的一句話是：很多 detection engineering 真正缺的，不是更多摘要，而是把偵測意圖穩定轉成可營運規則的 execution architecture。

Takeaway

RulePilot 真正補上的，是安全規則工程裡最常被低估的一段：把 analyst 想抓的東西，可靠地變成 SIEM 真的能跑、能搬、能驗的規則。 當 AI 不只是幫你把句子寫漂亮，而是能穿過 IR、reflection、平台映射與 live validation 這幾關，rule generation 才比較像一條能進 production 的路，而不只是 demo。