📌 本文重點
- 以資安專用小模型處理 80% 日常事件
- 透過多代理架構編排偵測、研判與響應流程
- 用路由策略與 reasoning budget 降低前沿模型成本
- 建立可觀測、可審計的 agentic 資安系統
微軟這次把很多團隊在做的「資安 LLM 自動化」實作到產品級：用 MAI-Cyber-1-Flash 處理 80% 日常事件，用 MDASH 多代理系統協調整個流程，只有高難度推理才丟給 GPT-5.x 等前沿模型。這直接解決三個痛點：
- 資安 LLM 成本過高：不再每個警報都用最貴模型算到底。
- 安全事件處理流程很散：用多代理把偵測、研判、響應變成可編排的工作流。
- 延遲與穩定性難控：清楚規劃路由策略與重試機制，變成可觀測的系統，而不是「大模型黑箱魔法」。
💡 關鍵： 用專用小模型處理 80% 事件，可在維持高準確度下，把前沿模型成本砍約 50%
以下用 MAI-Cyber-1-Flash + MDASH 的思路，拆成可在你自己系統落地的設計。
重點說明
1. 專用模型 + 通用 LLM 的協同與路由策略
MAI-Cyber-1-Flash 本質上是一個 小型、資安專用模型：
- 針對資安 log、攻擊手法、規則語意優化，做到 CyberGym 96% 分數
- 嵌入 MDASH 後，微軟宣稱能把成本砍 約 50%，因為只有「難題」才交給 GPT-5.4
一般化到自己的架構，可以拆成三層：
- Rule & Heuristic 層：
- 簡單模式匹配：IP 黑名單、已知 IOC、固定 Regex
-
直接在 SIEM / IDS 裡處理，不進 LLM
-
專用模型層（Small Sec Model）：
- 專門對
security_alert,auth_log,endpoint_event做語意判讀與關聯 -
處理：誤報過濾、風險分級、初步原因歸納
-
前沿模型層（Frontier LLM，如 GPT-5.x）：
- 處理：跨多系統關聯推理、攻擊鏈重建、策略級決策建議
- 通常對應「需要人類資深安全分析師」才會看的事件
路由策略可以簡化為：
- 先經過專用模型，取得：風險分數、信心分數、任務類型
- 再根據這些指標決定是否升級到 GPT-5.x
關鍵是用明確的 路由規則 取代「人工判斷要不要叫大模型」，讓成本與延遲變成可控變數。
2. 資安場景下的多代理設計：權限、工具與決策流程
MDASH 代表的是一套 多代理安全系統，可以抽象成以下角色：
- Alert Ingest Agent（只讀權限）
- 工具：SIEM 查詢 API、log 存取、事件匯流
-
任務：把不同來源的事件標準化成內部
IncidentSchema -
Triage Agent（以 MAI-Cyber-1-Flash 為主）
- 工具：專用模型推理 API、歷史事件資料庫
-
任務：判斷是否為誤報、分級（P1-P4）、初步影響面分析
-
Deep Analysis Agent（前沿模型，如 GPT-5.x）
- 工具：廣義 LLM、攻擊知識庫、拓撲圖、CMDB
-
任務：跨系統推理、建構 attack graph、提出修補與策略建議
-
Response Orchestrator Agent（有限寫入權限）
- 工具：EDR/Firewall API、Ticket 系統、通知機制
- 任務：根據決策模板自動下指令（隔離主機、封鎖 IP、開 Jira/PagerDuty）
核心原則：
- 權限最小化：分析代理與響應代理分開；響應代理只允許執行白名單化的 playbook。
- 工具使用有策略：通過 policy 層限制 agent 能呼叫的工具與參數（例如封鎖 IP 需雙重確認）。
- 決策流程可審計：所有 agent 的推理與工具使用都記錄到 安全事件日誌，便於事後 review。
3. 成本優化、延遲追蹤與失敗重試
要想真的省錢，不能只「加一個小模型」，還要把以下變成系統級設計：
- 模型選擇策略
- 規則：只有當
risk_score >= X且confidence < Y才升級到 GPT-5.x -
對應到 Towards AI 講的 reasoning budget：把「思考代幣」用在真正需要深度分析的事件上
-
延遲追蹤指標（參考 MIT Tech Review 中 Intel 的建議）
-
不只看 CPU 或 GPU 使用率，而是：
- 每個 Agent 任務的 end-to-end latency
- 整個 Incident pipeline 的完成時間
-
失敗重試策略
- API timeout / 工具呼叫失敗：
- 小模型先用 短思考、快路由 重試一次
- 重試 1-2 次仍失敗，升級到前沿模型或標記為「人工介入」
💡 關鍵： 把延遲與重試行為變成具體指標追蹤，才能真正優化整體 SOC pipeline 的效能與穩定性
實作範例
以下用簡化版 pseudo-code 示範如何在自己的系統搭一個「小模型主力 + 大模型備援 + 多代理」資安工作流。
1. 模型路由核心邏輯
# 假設你有兩個模型服務：
# - security_small_model: 例如自訓或微調的資安專用模型
# - frontier_llm: GPT-5.x / Claude Opus 等
RISK_THRESHOLD = 0.7
CONFIDENCE_LOW = 0.6
def route_incident(incident):
# Step 1: 先用小模型做資安專用分析
small_output = security_small_model.analyze(
prompt=incident.to_prompt(),
tools=["ioc_lookup", "log_context"],
max_tokens=512,
)
risk = small_output["risk_score"] # 0 ~ 1
confidence = small_output["confidence"] # 0 ~ 1
# Step 2: 根據風險與信心决定是否升級
if risk < RISK_THRESHOLD and confidence >= CONFIDENCE_LOW:
# 80% 日常事件在這裡結束
return {
"model": "small",
"analysis": small_output,
"needs_deep_analysis": False,
}
# Step 3: 對剩下 20% 事件，丟給前沿模型做深度推理
deep_output = frontier_llm.reason(
system="你是一位資深資安分析師，請結合以下事件與環境資訊給出完整攻擊鏈分析與建議。",
user=incident.to_detailed_prompt(small_output),
reasoning_budget="high", # 對應前沿模型的思考層級
max_tokens=4096,
)
return {
"model": "frontier",
"analysis": deep_output,
"small_analysis": small_output,
"needs_deep_analysis": True,
}
關鍵實作重點：
risk_score/confidence必須由專用模型輸出，不要硬在應用層猜。reasoning_budget/effort_level要跟模型提供的參數對應，對簡單事件不要開最大思考模式。
2. 多代理編排與權限控制
可以用簡單的 Orchestrator 來串 AlertIngest、Triage、DeepAnalysis、Response 四個代理：
class SecurityOrchestrator:
def __init__(self, tools, logger):
self.ingest_agent = AlertIngestAgent(tools["siem"], logger)
self.triage_agent = TriageAgent(tools["small_model"], logger)
self.deep_agent = DeepAnalysisAgent(tools["frontier_llm"], logger)
self.response_agent = ResponseAgent(
tools["edr"], tools["firewall"], tools["ticket"], logger,
)
def handle_raw_alert(self, raw_alert):
incident = self.ingest_agent.normalize(raw_alert)
triage_result = self.triage_agent.evaluate(incident)
if triage_result["false_positive"]:
self.response_agent.create_ticket(
incident, triage_result, level="info",
)
return
# 路由到深度分析（依上節邏輯）
routed = route_incident(incident)
if routed["needs_deep_analysis"]:
deep_result = self.deep_agent.analyze(incident, routed)
else:
deep_result = None
# 根據風險與分析結果，啟動自動化響應
self.response_agent.execute_playbook(
incident=incident,
triage=triage_result,
deep=deep_result,
)
這裡要注意：
ResponseAgent只能執行預先定義好的 playbook：例如isolate_endpoint,block_ip,reset_password等，不要讓 LLM 直接生成任意 API 呼叫。- 所有
execute_playbook行為要寫入 安全審計日誌，包含：誰觸發（哪個 agent）、使用哪個模型、對哪台主機。
3. 延遲與重試追蹤範例
import time
MAX_RETRY = 2
def with_retry_and_metrics(agent_fn, *args, **kwargs):
start = time.time()
attempts = 0
last_error = None
while attempts <= MAX_RETRY:
attempts += 1
try:
result = agent_fn(*args, **kwargs)
latency = time.time() - start
metrics.record(
agent=agent_fn.__name__,
latency=latency,
attempts=attempts,
status="success",
)
return result
except Exception as e:
last_error = e
if attempts > MAX_RETRY:
break
latency = time.time() - start
metrics.record(
agent=agent_fn.__name__,
latency=latency,
attempts=attempts,
status="failed",
)
raise last_error
這種 wrapper 可以套在 triage_agent.evaluate 或 deep_agent.analyze 上，讓每個 agent 的延遲與重試次數變成可量測指標。
建議與注意事項
1. 事件編排與日誌追蹤的坑
- 坑：只記模型輸出，不記上下文與工具使用
-
建議：為每個 Incident 建立完整 timeline：包括 agent 呼叫、模型版本、prompt 摘要、工具參數與結果。
-
坑：把多代理流程寫死在單一服務裡
- 建議：用明確的 workflow engine / state machine（即使是簡化版），讓新增 agent 或改路由不需要重構整套系統。
2. 模型更新與誤報/漏報管理
- 專用模型（類似 MAI-Cyber-1-Flash）更新時，常見問題：
- 誤報率突然上升或下降，影響路由比例（可能變成前沿模型被狂呼叫）。
實務建議：
- 灰度發布專用模型：
-
先讓新版本只處理一部分流量（例如 10% 警報），比對：
- 誤報率、漏報率
- 導向前沿模型的比例
-
把誤報/漏報標記納入訓練 feedback loop：
- 人工 review 後，把
incident_id + verdict回寫到專用模型的訓練資料 - 建一個
feedback API，讓安全分析師可以一鍵標記結果
3. 成本與 reasoning budget 的實際調校
- 不要一開始就用「風險分數」當唯一路由指標。
- 建議至少考量：
- 資產重要性（生產資料庫 vs. 測試機）
- 攻擊類型（帳號暴力破解 vs. 機敏資料外洩）
- 歷史事件模式（某類警報往往是真的）
簡單做法：
前沿模型呼叫條件 =
(risk_score 高 AND asset_criticality 高)
OR (攻擊類型屬於高風險)
OR (專用模型信心低)
這樣能把 reasoning budget 集中在真正影響業務的事件上，而不是把資源浪費在「每天都在發但多半是誤報」的警報。
💡 關鍵： 前沿模型的 reasoning budget 應優先配置在高風險且高重要性的資產與事件上
4. 權限與自動響應的風險控制
- 不要讓 LLM 直接決定「是否執行高風險動作」；改用：
- LLM 提出建議與理由
- 系統透過 policy engine 判斷是否符合執行條件
例如：
- 隔離關鍵伺服器需 雙重條件：
- 前沿模型判定攻擊已在內網橫向移動
- EDR 已偵測到實際惡意行為（非僅異常模式）
結論：如果你現在的資安或運維流程已經在用 LLM 做輔助判讀，下一步非常值得做的是：
- 加一個 資安專用小模型 當主力 triage 引擎
- 用明確的 路由策略 把高難度事件升級到前沿模型
- 用 多代理架構 把偵測、研判、響應變成可編排的 pipeline
這樣你不是在「升級聊天機器人」，而是在逐步把 SOC 的標準工作流，搬成一套可觀測、可調校、成本可控的 agentic 安全系統。
🚀 你現在可以做的事
- 盤點現有 SIEM / SOC 流程，畫出事件從偵測到響應的現有 pipeline
- 在實驗環境導入一個資安專用小模型，實作
risk_score/confidence輸出與路由規則- 實作簡易多代理 Orchestrator（含審計日誌與延遲指標），從單一高價 LLM 呼叫改成「小模型主力 + 前沿模型備援」架構
發佈留言