Codename MDASH Azure Government 部署让智能体安全接受公共部门考验
Microsoft 已在 Azure Government 中部署 Codename MDASH 功能，凭借超过 100 个专门的 AI 智能体，将其代码扫描器带入高要求的安全环境。部分美国政府客户和获授权合作伙伴现可在预览阶段访问该系统。
此次部署之所以重要，是因为 Microsoft 承诺的不只是更快的静态分析。Codename MDASH 使用多个模型和智能体角色，调查疑似软件漏洞是否可达、是否可被利用。这一方法旨在解决长期限制传统应用安全工具的误报问题。
不过，在 Azure Government 内部完成部署，并不意味着该扫描器已被证明能在各类联邦代码库中可靠运行。Microsoft 已公布了令人鼓舞的基准测试和内部测试结果。现在，各机构必须判断这些结果能否转化为准确的发现、可控的审查工作量以及更快的修复速度。
因此，核心竞争并非 Microsoft 与另一家安全厂商之间的较量，而是自动化漏洞发现与政府安全运营证据要求之间的较量。只有当团队能够验证、排序并修复真正重要的风险时，发现更多可疑代码才有意义。
Codename MDASH Azure Government 有何变化
Codename MDASH 已从 Microsoft 的内部安全研究和商业预览，进入为符合条件的政府工作负载构建的环境。
Microsoft 于 2026 年 9 月 8 日宣布了这项部署。其 Azure Government deployment 为部分美国政府客户和获授权合作伙伴提供预览访问权限。
该系统通过多阶段流水线分析源代码。它首先绘制代码库结构，并依据复杂性和潜在风险等因素对不同区域进行排序。随后，专门的智能体会检查选定的代码路径，寻找不同类别的弱点。
据 Microsoft 称，一次扫描可有超过 100 个智能体参与。该公司列举的示例包括专注于注入漏洞、内存安全问题和身份验证绕过的智能体。
第二组智能体会对初步发现提出质疑。这些智能体会围绕疑似漏洞是否可达、是否危险展开正反论证。系统随后会合并重复结果，并赋予置信度信息。
对于允许动态测试的漏洞类别，Codename MDASH 可以尝试生成能够触发漏洞的输入。该证明步骤旨在区分可被利用的条件与无法影响运行中系统的可疑代码。
这种区分至关重要。传统静态应用安全测试通常会将代码与已知模式或数据流规则进行匹配。这些工具能够快速扫描，但其告警有时缺少判断实际暴露风险所需的运行时上下文。
Codename MDASH 采取了更具调查性质的方法。它结合语言模型、代码分析、类型信息、调用图以及智能体之间的对抗性审查。Microsoft 将其描述为以更接近安全研究人员的方式对代码进行推理。
它进入政府环境也改变了评估该技术的受众。私营公司可以在有限的开发项目中测试新兴安全工具。政府机构则必须考虑授权边界、敏感源代码、审计要求以及任务后果。
该产品仍处于预览阶段，这是一个重要限定。Microsoft 并未将其定位为成熟扫描器、渗透测试或人工审查的通用替代方案。其访问权限也仍有限，而非普遍可用。
这构成了本文的核心张力。Codename MDASH 将更深层次的自动化分析带入政府环境，但其发现必须达到比基准测试成功更高的标准。
政府安全团队为何此刻面临压力
政府软件负责人需要更好的发现工具，但每一条新增告警都会争夺有限的修复能力。
联邦系统依赖定制应用、商业产品、开源组件，以及对机构任务仍不可或缺的旧软件。一个细微的弱点可能跨越多个模块，最终才变得可被利用。
传统扫描器对于已知模式、依赖项和配置问题仍然很有价值。然而，逻辑错误和复杂的利用路径可能逃过那些高度依赖预定义规则的工具。
攻击者正获得与防御者相同类别的语言模型和自动化编码工具。AI 可以帮助检查陌生代码库、提出测试用例，并追踪海量代码中的关系。
这种共享能力压缩了防御者可用的时间。漏洞不会因为自动化系统率先发现它而变得无害。机构仍须确认结果、识别受影响的部署、准备修复方案、完成测试并发布。
Microsoft 将时间视为持久优势。如果防御者能在攻击者发现漏洞之前定位并修复它，自动化就创造了实质价值。如果发现结果停留在队列中，更快的发现只会扩大积压。
政府要求已强调持续可见性和漏洞管理。CISA 的联邦指导方针包括定期资产扫描、对已知被利用漏洞进行优先排序，以及对覆盖系统的修复预期。
这些要求通常聚焦于已部署资产和已知暴露面。Codename MDASH 将注意力前移，转向源代码和开发流水线中的弱点。这支持了在缺陷进入运营系统前发现它们这一更广泛目标。
CISA 的安全开发指南也强调，应在系统整个生命周期内对安全结果负责。当智能体代码扫描能够增强证据和开发者反馈时，它符合这一方向。
压力落在机构应用负责人、安全运营团队和授权官员身上。他们必须决定，AI 生成的发现将如何影响发布决策和风险评估。
开发者同样需要可用的修复信息。一条告警应识别脆弱路径，解释安全后果，并提供审查人员可以复现的证据。仅有严重性标签几乎没有帮助。
安全团队还面临相关的治理问题。他们必须确定一项发现是来自确定性的代码分析、概率性的模型推理、动态测试，还是这些方法的组合。
这种溯源会影响置信度，也会影响团队在底层模型、提示词或智能体编排发生变化后如何复现结果。
因此，必须作出的是运营层面的回应，而非口头回应。采用 Codename MDASH 的机构需要制定接收规则、明确人工审查责任、设定升级阈值，并衡量发现结果与已完成修复之间的关联。
如果缺少这种结构，智能体扫描可能沦为另一个告警来源。有了这种结构，该系统则可以将安全工作转向现有工具往往难以优先处理的复杂漏洞。
真正的赌注是验证，而非更多 AI 智能体
只有当其智能体辩论能产生更强的证据，而不只是更多模型生成的观点时，Codename MDASH 才算成功。
该系统的机制将发现与验证分开。一组智能体搜索可疑行为，另一组则质疑每个候选问题是否会在现实条件下发生。
这一架构试图解决单次模型分析的一个弱点。语言模型可以给出看似合理的解释，但这种解释未必符合程序实际的控制流或运行时行为。
Microsoft 将智能体推理与更传统的技术信号结合起来。其 scanner documentation 描述了调用图分析、代码复杂度指标、污点分析、类型解析、置信度评分和结果去重。
调用图映射函数之间的关系。污点分析追踪不可信信息能否从输入流向敏感操作。类型解析则帮助扫描器理解值和函数在特定语言中的行为方式。
这些方法为智能体提供了有关代码库的结构化信息。它们也有助于约束模型，避免模型仅凭不完整的代码片段进行推理。
辩论阶段随后会测试可达性和可利用性。可达性关注执行是否能够进入疑似路径。可利用性关注攻击者能否将该路径转化为有实质意义的安全后果。
这两个问题并不相同。危险函数可能存在，却未必能被攻击者访问。可达路径也可能包含控制措施，阻止恶意输入造成危害。
据报道，Codename MDASH 会要求智能体在赋予置信度前分别构建正反两方论据。这种内部对立是其设计中最重要的部分，因为它直接针对每项结果的可信度。
在可行时，最终证明阶段会更进一步。系统可以尝试生成并执行能够展示脆弱条件的输入。可复现的触发条件为人工审查人员提供的依据，强于模型的解释。
不过，并非所有严重漏洞都支持安全或简单的证明。授权弱点、分布式逻辑错误、竞态条件和依赖环境的漏洞，可能难以在隔离环境中复现。
政府软件还包括专门的架构和运营限制。有些代码无法在受限环境之外执行。其他代码库可能缺少判断暴露情况所需的部署配置。
智能体数量本身无法解决这些限制。增加更多模型调用可以使假设更多样化，但相似系统之间的一致意见并不等于独立验证。
模型可能共享训练数据、假设和盲点。当每个智能体收到相似证据时，它们也可能相互强化一种颇具说服力却不正确的解释。
因此，更有力的主张应当更为克制。Codename MDASH 将专门搜索、对抗性审查和程序分析整合为一条漏洞调查流水线。
这一机制值得关注，因为它反映了人类安全团队既有的工作方式。研究人员会形成假设、追踪执行、质疑前提、复现行为，并删除重复报告。
自动化可以加速这一过程，但无法消除在机构实际运行环境中证明一项发现为何正确的必要性。
Azure Government 是安全论证的一部分
部署边界并非包装细节，因为机构无法随意将敏感源代码发送至商业 AI 服务。
源代码可能揭示系统架构、内部接口、身份验证逻辑和防御控制措施。对于任务关键型应用而言，即使代码未被正式定密，这些细节也可能具有敏感性。
微软表示，这一多模型框架能够使用适当的模型，同时将源代码及相关学习内容保留在获批边界内。这一说法直接回应了政府采用过程中的一项重大障碍。
Azure Government 为符合条件的美国政府机构及合作伙伴提供微软云的物理隔离实例。这里提供的服务遵循独立的可用性、授权和运营流程。
将 Codename MDASH 引入该环境后，获批用户无需将其代码库迁入普通商业服务边界，即可评估该扫描器。这也为机构在身份、访问、日志记录和监管方面提供了更熟悉的路径。
该预览版仍需谨慎配置。使用政府云并不意味着每项工作负载都天然适用于每项服务。各机构仍有责任将数据敏感性和系统要求与相应授权相匹配。
团队还必须了解扫描期间哪些信息会离开代码库。潜在敏感材料包括代码片段、依赖项信息、提交历史、生成的验证材料、提示词和模型输出。
数据保留同样值得关注。安全团队应了解扫描产物可保留多久、结果存储在何处，以及这些内容是否会用于服务改进。
模型路由带来了另一个问题。微软强调可针对不同任务使用不同模型的能力。机构需要了解哪些获批模型参与其中，以及路由变化是否会影响其授权假设。
商业版本与 GitHub 和 Azure DevOps 集成，支持通过 Defender CLI 进行本地或持续集成扫描，并将发现结果发布到 Microsoft Security Exposure Management。
这些连接可以减少摩擦，但也会扩大系统权限。扫描器需要足够的访问权限来读取代码库及相关元数据。修复功能可能还需要修改代码或创建建议变更的权限。
最小权限设计因此至关重要。发现、验证材料生成和自动修复不应仅因属于同一工作流而获得相同权限。
对生成的修复方案尤其需要谨慎。一项补丁可能消除眼前的触发条件，却引入回归问题，或保留另一条可利用路径。机构应将 AI 生成的变更视为需经过审查和测试的建议代码。
审计日志必须保留从初始发现到最终处置的完整链路。审查人员应能够看到受影响的修订版本、支持证据、置信度变化、人工决策及最终补丁。
Azure Government 正是在这里成为该产品可信度的一部分。该环境可以为扫描器提供周边控制，但各机构必须测试这些控制是否为可问责使用提供了足够透明度。
因此，这项部署推进了微软的政府安全战略。它并未将风险所有权从机构转移给供应商。
强劲的基准测试分数并非生产环境证明
微软公布的结果足以支持严肃评估，但并不能证明其在未知政府代码库中的表现。
微软于 2026 年 5 月首次公开介绍 Codename MDASH。该公司表示，该系统帮助其研究人员发现了 16 个此前未知的 Windows 漏洞，其中包括四个严重的远程代码执行漏洞。
受影响领域包括 Windows 网络和身份验证堆栈。微软的安全测试结果还报告称，在一个私有测试驱动程序中，对 21 个植入漏洞实现了完整检测，且没有误报。
微软报告称，在 Windows Common Log File System 驱动程序中过去五年的已确认案例中，召回率达到 96%。该公司报告称，在 Windows TCP/IP 驱动程序的历史案例中，召回率达到 100%。
这些均为第一方评估。它们表明微软测试的并不只是一些人工构造的代码片段，但外部人士不能据此假设其在不同语言和架构中具有相同表现。
该公司 9 月的政府公告援引了 CyberGym 上 96.55 的分数。这一结果高于微软 5 月公布的 88.45 分，表明系统或其基准测试配置已发生变化。
CyberGym 是一个公开基准测试集，包含来自 188 个软件项目的 1,507 个历史漏洞。其基准测试方法评估代理能否通过生成可运行的概念验证测试来复现漏洞。
该基准测试使用真实代码库和已披露漏洞，因此比孤立函数分类更具挑战性。其代码库包含大量文件和代码行。
然而，该任务会向代理提供漏洞描述和对应的未修补代码库。生产环境中的发现工作起点更为困难，因为扫描器通常并不知道存在哪一种漏洞。
因此，复现已描述的历史缺陷并不等同于发现未知弱点。这一区别并不会否定该分数，但限制了这一数字所能证明的内容。
随着系统直接针对公开基准测试进行调优，这类基准测试的信息价值也会下降。机构应询问：96.55 分由哪种配置取得、该配置是否与 Azure Government 一致，以及结果的可重复性如何。
微软 5 月与 9 月分数之间的差异需要更多背景说明。它可能反映了产品改进、评估框架变化、模型访问范围扩大，或其他基准提交设置的变化。
政府评估人员还应区分召回率与精确率。召回率衡量系统发现了多少真实漏洞。精确率衡量报告的发现中有多少实际有效。
一款召回率高但精确率弱的扫描器可能会淹没审查人员。一款精确率高但覆盖范围狭窄的扫描器则可能带来虚假的完整性认知。
此前的学术研究提供了保持谨慎的理由。一项 IEEE Security and Privacy 评估发现，受测试的语言模型产生了较高误报率，并且在重复运行中对漏洞的判断并不一致。
较新的研究支持多代理筛选，但仍将不同模型和漏洞类别间的表现描述为不均衡。结果取决于提示词、分析工具、代码库上下文和成功标准的定义。
NIST 的 2026 年代理安全分析得出了更广泛的结论：现有网络安全原则仍然适用，但代理系统需要调整后的评估实践和指导。
对于 Codename MDASH，必要证据应来自受控的机构试点。评估人员需要获得来自陌生代码库、隐藏漏洞、已修补代码，以及本应不产生发现结果的干净代码的结果。
他们应重复扫描以衡量一致性，也应将结果与专家审查及成熟的静态或动态工具进行比较。
决定性指标并非扫描器生成了多少漏洞，而是由于扫描器参与，机构能够更快修复的、经验证且具有实际影响的发现所占比例。
代理式代码安全仍需要人工授权
最安全的运行模式是让 AI 负责调查，而由人类保留风险接受、代码变更和部署的决策权。
Codename MDASH 可以减少追踪代码路径和验证潜在发现所涉及的机械性工作。这让安全专家有更多时间进行架构判断和困难的修复决策。
不过，该系统也可能带来新的运营风险。AI 生成的概念验证可能执行不受信任的代码。建议修复可能改变安全敏感行为。代码库连接器可能暴露超出扫描所需范围的信息。
机构应在受控环境中隔离概念验证生成。网络访问、凭据、密钥、构建工具和测试数据应遵循明确政策，而不是继承广泛的开发者权限。
人工审查人员还需要明确的发现接受标准。置信度分数可以支持优先级排序，但不应取代有关可达性、攻击者前提条件、受影响版本和运营影响的证据。
审查人员应能够在不依赖隐藏模型推理的情况下复现关键路径。如果只有服务本身能够解释警报为何存在，该机构就会依赖于不透明的评估。
当扫描器报告未发现问题时，同样适用这一原则。没有发现并不证明代码库安全。系统可能因不支持的构建条件、缺失上下文或模型错误而遗漏易受攻击的代码。
因此，Codename MDASH 应补充现有控制措施。依赖项分析、密钥扫描、静态分析、模糊测试、渗透测试、代码审查和运行时监控各自观察不同的故障模式。
当代理式扫描连接这些层面的证据时，便能创造价值。例如，当部署上下文显示面向互联网的服务可访问受影响函数时，可疑的数据流就会变得更紧急。
微软的 Exposure Management 集成正指向这一方向。该系统可将发现置于更广泛的组织风险视角中，而非将每一项代码弱点都视为同等重要。
这一上下文也带来了治理义务。机构应记录部署信息何时改变发现的严重程度，以及人工何时推翻自动排名。
团队还必须监控模型更新。模型变更可能在不改变产品可见界面的情况下，改变发现覆盖范围、置信度评分和一致性。
发行说明应标明实质性的扫描变更。机构可能需要在接受新配置用于敏感工作负载之前，重新运行验证套件。
采购团队应询问微软如何处理模型退役和回退行为。多模型设计提供了灵活性，但也可能使数月后复现结果更加困难。
针对不受支持或专业化语言，独立测试尤为重要。微软表示，Codename MDASH 广泛支持主流语言，同时针对 C、C++、Java 和 C# 进行了更深入的调优。
这一表述并不能证明其在所有环境中具有同等表现。使用罕见语言、遗留框架或运营技术的机构，应在具有代表性的代码中衡量覆盖范围。
正确的部署模式应是渐进式的。应从拥有已知测试用例、成熟责任归属，以及足够安全专业能力来评估有争议发现的代码库开始。
随后衡量 MDASH 是否改变了结果。可用的问题包括：它是否发现了遗漏的缺陷、是否缩短了分诊时间、是否提高了修复质量，还是仅仅产生了不同的警报。
美国机构接下来应关注什么
三个信号将决定 Codename MDASH 会成为可靠的政府控制措施，还是仍停留在前景可期的预览阶段。
第一个信号是来自政府试点的独立准确性数据。在政策允许的情况下，机构应公布匿名化指标，包括经验证的发现、误报率、遗漏缺陷和审查人员耗时。
在陌生代码库中展现出强劲精确率和召回率，将强化微软的论据。不同语言或重复扫描之间的大幅差异，则会削弱对广泛部署的信心。
第二个信号是有关修复的运营证据。评估者应追踪从扫描完成到确认修复所需的时间，而不只是统计生成了多少项发现。
更短的修复周期将表明，智能体 AI 安全正在改善结果。不断增长的积压则意味着，发现能力的提升已超过机构的响应能力。
第三个信号是从预览版走向有文档记录的政府服务的路径。买方需要更清晰地了解可用性、授权、模型路由、保留和审计细节，才能将 MDASH 视为标准控制体系的一部分。
透明的生产部署计划将增强此次部署的重要性。长期处于预览状态或服务边界不清晰，则会使该系统仍局限于受到严格管理的实验。
这些信号的重要性不止于 Microsoft。智能体驱动的漏洞发现很可能会成为各类应用安全平台的标准能力。政府部门的采用将影响供应商如何记录证据、可重复性和人工监督。
开发者应当关注，因为扫描器发现越来越可能影响发布决策。安全负责人也应当关注，因为这些工具能够改变漏洞队列的数量和质量。
企业买方出于不同原因应关注政府试点项目。公共部门环境对数据边界、授权、可追溯性和问责制提出了严格要求。
如果 Codename MDASH 能在这些约束下表现出色，智能体代码扫描在其他场景中的应用理由将更有说服力。如果它遇到困难，其失败模式同样会提供宝贵指引。
因此，Codename MDASH 在 Azure Government 的部署是一项重要测试，而非既定结论。Microsoft 已将一套复杂的扫描架构进一步推进至关键任务软件领域，并获得了显著的第一方和基准测试结果支持。
现在，证据必须来自日常安全工作。机构能否复现这些发现、信任其优先级，并在攻击者利用之前修复重要弱点？
这才是值得追踪的结果。评估 Codename MDASH 的政府技术团队，在扩大访问权限之前，应要求进行受控对比、提供可审计证据，并衡量修复指标。
