MDASH:微软用上百个 AI Agent 组团挖漏洞

2026-05-26 19 预计阅读时间:1 分钟
来源:infoq.com AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:10 分钟

微软最近公开了一套名为 MDASH(Multi-Model Agentic Security)的漏洞发现系统。这套系统不再依赖单模型"单打独斗",而是让超过 100 个专业化 AI Agent 协作完成从扫描、验证、辩论到最终证明漏洞的全流程。目标很明确——在 Windows 及其他微软大型代码库中,用自动化手段替代传统人工代码审计的瓶颈。

为什么需要多 Agent 协作?

单模型做代码审计有一个根本问题:它擅长"发现可疑点",但不擅长"确认可疑点是真的漏洞"。一个函数指针未初始化,可能是漏洞,也可能只是开发者有意为之的延迟赋值。单模型容易产生大量误报,或者在面对复杂调用链时无法追踪到真正可达的触发路径。

MDASH 的思路是把审计流程拆成多个角色:

  • 扫描 Agent——快速遍历代码,标记潜在风险点
  • 验证 Agent——对标记点做路径可达性分析,判断是否能被外部输入触发
  • 辩论 Agent——多个 Agent 对同一发现提出正反论证,模拟安全研究员之间的讨论
  • 证明 Agent——最终生成 PoC 或形式化证明,确认漏洞可被利用

这种分工让每个 Agent 的任务边界清晰,模型可以针对特定角色做优化,而不是让一个通用模型硬扛所有环节。

100+ Agent 的编排逻辑

超过 100 个 Agent 并不是随机堆叠。根据微软的描述,MDASH 采用的是分层编排:

  1. 顶层调度器决定哪些代码区域需要审计、优先级如何排列
  2. 中层协调器把一个审计任务拆成子任务,分配给对应角色的 Agent 组
  3. 底层执行 Agent完成具体分析,返回结果

辩论环节尤其关键。多个验证 Agent 可能对同一个可疑点给出不同结论——一个认为可达,一个认为不可达。辩论 Agent 的职责是综合这些分歧,要求各方提供证据(调用链、约束条件),最终裁决。这比单模型"自己想一遍"要可靠得多。

实际效果与边界

MDASH 已经在 Windows 代码库中运行,发现了多个被确认的安全漏洞。但需要指出几个现实边界:

  • 代码规模限制——系统针对的是微软内部的大型闭源代码库,代码结构、编译配置、内部文档等上下文对外部研究者来说并不具备。开源项目能否直接复用这套架构,还需要验证。
  • Agent 间通信开销——100+ Agent 的协调本身有工程复杂度,辩论轮次过多可能导致分析时间膨胀。
  • 漏洞证明的可靠性——AI 生成的 PoC 是否真正可利用,仍需人类安全研究员复核。MDASH 提高了发现效率,但没有完全消除人工确认环节。

自己搭一个迷你版多 Agent 审计流水线

MDASH 的核心思路——多角色 Agent 协作——并不只适用于微软内部。下面用 Python + OpenAI API 搭一个简化版的多 Agent 代码审计流程,你可以直接跑起来,再按需要扩展 Agent 数量和角色。

"""
mini_mdash.py — 简化版多 Agent 代码审计流水线
依赖: pip install openai
运行前设置: export OPENAI_API_KEY=sk-xxx
用法: python mini_mdash.py <代码文件路径>
"""

import os
import sys
import json
from openai import OpenAI

client = OpenAI(api_key=os.environ.get("OPENAI_API_KEY"))

AGENT_PROMPTS = {
    "scanner": (
        "你是代码安全扫描 Agent。阅读以下代码,列出所有潜在安全风险点。"
        "每条风险点用一行输出,格式: [行号/区域] 风险类型 - 简要描述。"
        "不要做深度验证,只做快速标记。"
    ),
    "validator": (
        "你是漏洞验证 Agent。对以下风险点列表逐条分析:"
        "判断每个风险点是否可被外部输入触发(路径可达性)。"
        "输出 JSON 数组,每个元素包含: risk(原风险描述), reachable(bool), reason(可达/不可达的理由)。"
    ),
    "debater_pro": (
        "你是辩论正方 Agent。针对以下验证结果中标记为 reachable 的风险点,"
        "为每个点补充攻击路径细节:输入如何到达、约束如何绕过。"
        "输出 JSON 数组,每个元素: risk, attack_path, confidence(0-1)。"
    ),
    "debater_con": (
        "你是辩论反方 Agent。针对以下验证结果中标记为 reachable 的风险点,"
        "为每个点提出反驳:为什么实际不可利用(防御机制、运行时约束等)。"
        "输出 JSON 数组,每个元素: risk, rebuttal, confidence(0-1)。"
    ),
    "judge": (
        "你是裁决 Agent。综合正方攻击路径和反方反驳,对每个风险点做出最终判定。"
        "输出 JSON 数组,每个元素: risk, verdict(vulnerable/safe/uncertain), "
        "reason(综合理由), suggested_action(建议修复或进一步验证)。"
    ),
}

def call_agent(role: str, context: str) -> str:
    prompt = AGENT_PROMPTS[role] + "\n\n" + context
    resp = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.2,
    )
    return resp.choices[0].message.content

def run_pipeline(code: str):
    # Step 1: 扫描
    scan_result = call_agent("scanner", code)
    print("=== 扫描结果 ===")
    print(scan_result)

    # Step 2: 验证
    validation_result = call_agent("validator", scan_result)
    print("\n=== 验证结果 ===")
    print(validation_result)

    # Step 3: 辩论
    pro_result = call_agent("debater_pro", validation_result)
    con_result = call_agent("debater_con", validation_result)
    print("\n=== 正方论证 ===")
    print(pro_result)
    print("\n=== 反方反驳 ===")
    print(con_result)

    # Step 4: 裁决
    debate_context = f"正方论证:\n{pro_result}\n\n反方反驳:\n{con_result}"
    final_result = call_agent("judge", debate_context)
    print("\n=== 最终裁决 ===")
    print(final_result)

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("用法: python mini_mdash.py <代码文件路径>")
        sys.exit(1)
    with open(sys.argv[1], "r", encoding="utf-8") as f:
        code_content = f.read()
    run_pipeline(code_content)

跑一下试试——拿一段有已知漏洞的 C 或 Python 代码喂进去:

# 准备一个测试文件
cat > test_vuln.c << 'EOF'
#include <stdio.h>
#include <string.h>

void process_input(char *user_data) {
    char buffer[64];
    strcpy(buffer, user_data);  // 明显的缓冲区溢出
    printf("Processed: %s\n", buffer);
}

int main(int argc, char **argv) {
    if (argc > 1) {
        process_input(argv[1]);
    }
    return 0;
}
EOF

# 运行审计流水线
export OPENAI_API_KEY=sk-your-key-here
python mini_mdash.py test_vuln.c

这个迷你版只有 5 个 Agent,但已经体现了 MDASH 的核心设计:扫描→验证→辩论→裁决的流水线,每个角色有独立 prompt,结果逐层传递。你可以在此基础上:

  • 增加 Agent 数量——比如拆成多个扫描 Agent 各负责不同漏洞类别(内存安全、逻辑错误、加密误用等)
  • 加入证明 Agent——让 Agent 尝试生成最小 PoC 输入
  • 用不同模型混搭——辩论正方用 GPT-4o,反方用 Claude,裁决用另一个模型,减少同模型偏见

采用建议与风险清单

如果你想在团队中引入多 Agent 审计思路,关注以下几点:

维度 建议
适用场景 大型代码库的持续审计,尤其是人工审计覆盖不到的角落
不适用场景 小项目、已成熟的安全测试流程、对误报零容忍的环境
成本 多 Agent 多轮调用意味着 API token 消耗是单模型的 5-10 倍
人工复核 AI 裁决的"vulnerable"结论必须经人类确认,不能直接进 CVE
模型选择 辩论环节尽量用不同模型或不同 temperature,避免"自己同意自己"
迭代节奏 先跑 5 Agent 版本验证流程,再逐步扩展到更多角色

MDASH 证明了一个方向:漏洞发现不是"一个超级模型搞定一切"的问题,而是"多个专业化 Agent 协作辩论"的问题。这个思路可以缩小范围、降低误报、提高最终结论的可信度。但别忘了——最后签字确认的,还是人。


相关推荐