作者: kerwin77106

📌 本文重點

• 以資安專用小模型處理 80% 日常事件
• 透過多代理架構編排偵測、研判與響應流程
• 用路由策略與 reasoning budget 降低前沿模型成本
• 建立可觀測、可審計的 agentic 資安系統

微軟這次把很多團隊在做的「資安 LLM 自動化」實作到產品級：用 MAI-Cyber-1-Flash 處理 80% 日常事件，用 MDASH 多代理系統協調整個流程，只有高難度推理才丟給 GPT-5.x 等前沿模型。這直接解決三個痛點：

1. 資安 LLM 成本過高：不再每個警報都用最貴模型算到底。
2. 安全事件處理流程很散：用多代理把偵測、研判、響應變成可編排的工作流。
3. 延遲與穩定性難控：清楚規劃路由策略與重試機制，變成可觀測的系統，而不是「大模型黑箱魔法」。

💡 關鍵： 用專用小模型處理 80% 事件，可在維持高準確度下，把前沿模型成本砍約 50%

以下用 MAI-Cyber-1-Flash + MDASH 的思路，拆成可在你自己系統落地的設計。

重點說明

1. 專用模型 + 通用 LLM 的協同與路由策略

MAI-Cyber-1-Flash 本質上是一個 小型、資安專用模型：

• 針對資安 log、攻擊手法、規則語意優化，做到 CyberGym 96% 分數
• 嵌入 MDASH 後，微軟宣稱能把成本砍 約 50%，因為只有「難題」才交給 GPT-5.4

一般化到自己的架構，可以拆成三層：

1. Rule & Heuristic 層：
2. 簡單模式匹配：IP 黑名單、已知 IOC、固定 Regex

3. 直接在 SIEM / IDS 裡處理，不進 LLM

4. 專用模型層（Small Sec Model）：

5. 專門對 security_alert, auth_log, endpoint_event 做語意判讀與關聯

6. 處理：誤報過濾、風險分級、初步原因歸納

7. 前沿模型層（Frontier LLM，如 GPT-5.x）：

8. 處理：跨多系統關聯推理、攻擊鏈重建、策略級決策建議
9. 通常對應「需要人類資深安全分析師」才會看的事件

路由策略可以簡化為：

• 先經過專用模型，取得：風險分數、信心分數、任務類型
• 再根據這些指標決定是否升級到 GPT-5.x

關鍵是用明確的 路由規則 取代「人工判斷要不要叫大模型」，讓成本與延遲變成可控變數。

2. 資安場景下的多代理設計：權限、工具與決策流程

MDASH 代表的是一套 多代理安全系統，可以抽象成以下角色：

1. Alert Ingest Agent（只讀權限）
2. 工具：SIEM 查詢 API、log 存取、事件匯流

3. 任務：把不同來源的事件標準化成內部 Incident Schema

4. Triage Agent（以 MAI-Cyber-1-Flash 為主）

5. 工具：專用模型推理 API、歷史事件資料庫

6. 任務：判斷是否為誤報、分級（P1-P4）、初步影響面分析

7. Deep Analysis Agent（前沿模型，如 GPT-5.x）

8. 工具：廣義 LLM、攻擊知識庫、拓撲圖、CMDB

9. 任務：跨系統推理、建構 attack graph、提出修補與策略建議

10. Response Orchestrator Agent（有限寫入權限）

11. 工具：EDR/Firewall API、Ticket 系統、通知機制
12. 任務：根據決策模板自動下指令（隔離主機、封鎖 IP、開 Jira/PagerDuty）

核心原則：

• 權限最小化：分析代理與響應代理分開；響應代理只允許執行白名單化的 playbook。
• 工具使用有策略：通過 policy 層限制 agent 能呼叫的工具與參數（例如封鎖 IP 需雙重確認）。
• 決策流程可審計：所有 agent 的推理與工具使用都記錄到 安全事件日誌，便於事後 review。

3. 成本優化、延遲追蹤與失敗重試

要想真的省錢，不能只「加一個小模型」，還要把以下變成系統級設計：

1. 模型選擇策略
2. 規則：只有當 risk_score >= X 且 confidence < Y 才升級到 GPT-5.x

3. 對應到 Towards AI 講的 reasoning budget：把「思考代幣」用在真正需要深度分析的事件上

4. 延遲追蹤指標（參考 MIT Tech Review 中 Intel 的建議）

5. 不只看 CPU 或 GPU 使用率，而是：

   • 每個 Agent 任務的 end-to-end latency
   • 整個 Incident pipeline 的完成時間

6. 失敗重試策略

7. 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）更新時，常見問題：
• 誤報率突然上升或下降，影響路由比例（可能變成前沿模型被狂呼叫）。

實務建議：

1. 灰度發布專用模型：

2. 先讓新版本只處理一部分流量（例如 10% 警報），比對：

   • 誤報率、漏報率
   • 導向前沿模型的比例

3. 把誤報/漏報標記納入訓練 feedback loop：

4. 人工 review 後，把 incident_id + verdict 回寫到專用模型的訓練資料
5. 建一個 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 呼叫改成「小模型主力 + 前沿模型備援」架構