微软最近公开了一套名为 MDASH(Multi-Model Agentic Security)的漏洞发现系统。这套系统不再依赖单模型"单打独斗",而是让超过 100 个专业化 AI Agent 协作完成从扫描、验证、辩论到最终证明漏洞的全流程。目标很明确——在 Windows 及其他微软大型代码库中,用自动化手段替代传统人工代码审计的瓶颈。
为什么需要多 Agent 协作?
单模型做代码审计有一个根本问题:它擅长"发现可疑点",但不擅长"确认可疑点是真的漏洞"。一个函数指针未初始化,可能是漏洞,也可能只是开发者有意为之的延迟赋值。单模型容易产生大量误报,或者在面对复杂调用链时无法追踪到真正可达的触发路径。
MDASH 的思路是把审计流程拆成多个角色:
- 扫描 Agent——快速遍历代码,标记潜在风险点
- 验证 Agent——对标记点做路径可达性分析,判断是否能被外部输入触发
- 辩论 Agent——多个 Agent 对同一发现提出正反论证,模拟安全研究员之间的讨论
- 证明 Agent——最终生成 PoC 或形式化证明,确认漏洞可被利用
这种分工让每个 Agent 的任务边界清晰,模型可以针对特定角色做优化,而不是让一个通用模型硬扛所有环节。
100+ Agent 的编排逻辑
超过 100 个 Agent 并不是随机堆叠。根据微软的描述,MDASH 采用的是分层编排:
- 顶层调度器决定哪些代码区域需要审计、优先级如何排列
- 中层协调器把一个审计任务拆成子任务,分配给对应角色的 Agent 组
- 底层执行 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 协作辩论"的问题。这个思路可以缩小范围、降低误报、提高最终结论的可信度。但别忘了——最后签字确认的,还是人。