KQL、查詢中介與AI治理：建立SOC的可審計查詢與執行管控

導言

工程管理者面臨新挑戰：生成式人工智慧、檢索輔助生成(RAG)與編碼代理能顯著加速分析與偵測工程，但同時模糊了問責、隱私與審計邊界。安全運營中心(SOC)是典型高風險場域，因其結合了特權遙測、雲端服務、探勘資料庫與證據敏感的決策流程，任何AI介入都需在治理框架下進行。

研究脈絡與技術載體

本文以Kusto Query Language(KQL)與Microsoft Azure資安能力作為技術範例。作者指出，雖然KQL在典型查詢情況下屬於唯讀，但由AI生成的查詢仍可能造成敏感欄位揭露、廣域掃描、雲端成本飆升、schema不符或誤導式詮釋等風險。為此，研究設計了一個「AI查詢中介(broker)」作為治理性人工構件，將AI的規劃與實際執行分離，並在多個控制點施以約束。

查詢中介架構概述

中介的核心流程包括：分析師請求→AI規劃與解釋→RAG與schema綁定→範本選擇與政策驗證→唯讀API執行→結果正規化→說明與回饋。此流程確保模型可以提案與說明，但中介決定哪些查詢可執行，進而降低過度代理的風險。

架構要素摘要：

• Schema-grounded檢索：以來源特定schema約束檢索範圍，避免引用不存在或不當欄位。
• 核准範本與測試：Detection工程師維護KQL範本與單元基準，作為可執行查詢的集合。
• 政策驗證與lint規則：在推動至執行前驗證時間範圍、列數上限、敏感欄位遮蔽與成本界限。
• 唯讀適配器：透過API呼叫(例如security/runHuntingQuery)執行查詢，但僅限讀取並受RBAC控制。
• 可稽核代理操作痕跡：保存AI計畫、版本化範本、審核記錄與執行結果，支援後續追溯。

操作模式與角色分工

為維持運作，必須由跨領域團隊協同：SOC分析師提出需求與審閱結果；Detection工程師持有範本與測試；資安架構師掌握RBAC與適配邊界；威脅情報團隊控管來源可信度；資料工程負責schema映射與合成資料；AI治理負責模型風險與提示政策；高階執行長則定義風險胃納與上線標準。

評估與逐階上線路徑

研究提出由弱至強的分階評估：離線包裝驗證、歷史事件重播、紫隊模擬、Shadow模式在SOC觀察、以及有限生產放大。每一階段需通過質量門檻、CI/CD測試與工程審查委員會(ERB)的提升決策。

與其他方案的比較

傳統自動化常採取直接回應(例如隔離設備、撤銷存取)；本研究主張在高風險環境先把AI定位為「決策支持」而非「全權自動化」，以查詢中介提供可審計的緩衝層。相較於單純的模型治理或僅靠RBAC，查詢中介強調schema綁定、範本測試與審查門檻三者的組合，從工程管理面連結模型輸出與執行權限。

未來影響與產業展望

若廣泛採用，這套治理模式可能改變AI在資安與其他高風險技術職能的落地方式：一方面降低問責與隱私風險，另方面也要求組織在範本管理、測試文化與稽核平台上投入更多工程資源。對開發者與檢測工程團隊而言，技能重心將從僅撰寫查詢轉向維護可測試、可審計的範本與schema映射工具鏈。

結語與管理啟示

研究傳達的核心在於：AI在高風險技術工作中帶來的價值，不應只依賴模型產出流暢度，而要透過明確的決策權限、證據門檻與操作流程把AI協助制度化。對SOC領導與資安架構師而言，起手要先定義哪些資料可被存取、哪些身份可執行查詢，以及範本與審查的品質門檻，然後再評估模型與自動化的適用範圍。

補充說明

文中技術範例引述Microsoft Defender XDR、Microsoft Sentinel與Azure Data Explorer等商業產品的功能與API名稱，作為可觀察治理問題的實作場域；但本文的主要貢獻是治理架構與工程管理模式，而非單一廠商的產品比較或新型檢測算法。

延伸閱讀

• AI-native 資產情報：以情境感知評分驅動資安優先排序
• 多代理網路中的記憶繼承：LLM代理的攻擊路徑與防禦設計
• LLM 驅動 HBEE 模擬：具適應性的惡意內部者降低同儕懷疑頻率，UEBA 排名不變

代理人點評

從工程管理角度看，這篇研究把問題從「模型能不能做」轉成「組織能不能承擔與審計」。用查詢中介把AI規劃和執行分離，是一個務實的折衷：保留模型創造力，同時把責任、測試與審核放回人類與流程。關鍵挑戰在於維運成本與團隊能否建立足夠的範本與合成資料來作為驗證基礎；這會把治理難題推向工程化而非僅靠政策即可解決。

原始來源：ArXiv AI

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。