MDASH 值得資安團隊借鏡的是驗證與去重流程；採用工具前，仍要確認警告能否變成有證據、可修補的問題。 Microsoft 在 2026 年 5 月 12 日公布 MDASH 的架構與研究成果；公告當時屬有限私人預覽，不能據此認定現在已對所有企業開放。
MDASH 是 Microsoft Security 的多模型代理掃描系統，英文為 multi-model agentic scanning harness。
Microsoft 在同一份公告表示，這套系統協助研究人員找出 16 個 Windows 網路與驗證元件漏洞，其中包含評為重大等級的遠端程式碼執行問題。這是廠商公布的研究成果，不能當成任何企業環境都能得到相同結果的保證。
MDASH 是什麼？
MDASH 以多階段代理分工處理候選漏洞，從理解程式到確認證據，每一步都有不同任務：
| 階段 | 作用 |
|---|---|
| Prepare | 建立程式碼索引、攻擊面與威脅模型 |
| Scan | 由審查代理找候選漏洞 |
| Validate | 由辯論代理驗證可達性與可利用性 |
| Dedup | 合併語意上相同的問題 |
| Prove | 建立可觸發輸入或動態證據 |
這種設計把工作延伸到證據確認；只產生警告，仍會把大量查證工作留給維護者。
為什麼多模型、多 agent？
Microsoft 在原始架構說明提到 MDASH 使用超過 100 個專門 agent。這是微軟公布的系統配置，不是企業採用時必須照抄的代理數量，也不能單憑數量判定掃描品質。
審查代理負責找問題，辯論代理檢查支持或反駁的理由，舉證代理再嘗試建立證據，領域外掛則補充專門知識。這些角色讓候選問題有機會經過多次檢查；但多個代理也可能共享相同盲點，團隊仍須核對最後留下的證據。
對企業資安代表什麼？
AI 資安工具不能只追求「找到很多問題」。
更重要的是：
- 誤報不致增加過多人工負擔。
- 問題能在授權環境重現。
- 能對應程式碼負責人。
- 能進入風險分級與排程。
- 能產出修補草稿或測試。
- 能留下可稽核紀錄。
如果缺少這些交付，警告越多，待處理清單反而可能越難消化。
和 Claude 掃原始碼的共同訊號
和站內的 Claude 原始碼資安分析一起看，團隊都需要回答同一個實務問題：工具提出候選後，誰來確認、安排修補並驗證正常功能仍可使用？即使前段掃描變快，後段也不會自動完成。
資安團隊還需要讓掃描、確認、修補與回歸測試接得起來，模型的發現才有機會落實成修正。
從一則警告到一張能結案的修補工單
假設你負責一個內部報表服務，AI 審查工具指出：「下載報表時可能沒有檢查使用者是否屬於同一部門。」這是用來解釋驗收的假設案例，不是微軟公布的漏洞，也不是本站的掃描結果。此時最不該做的，就是把這句話直接轉成最高優先工單，要求開發者立刻修補。
第一步是讓問題可以被討論。報告至少要指出程式版本、受影響的功能、可能缺少的檢查與適用條件。若只有泛泛的風險描述，維護者無法判定是實際缺陷、過期程式碼，還是工具沒有看見上層已做的授權檢查。沒有足夠證據，應先標記「待確認」，不是把不確定性藏在嚴重性分數裡。
第二步由熟悉系統的人確認設計。假設上層確實已限制部門，AI 可能是因讀不到相關設定而誤報，此時要留下排除理由與依據。若限制只存在於前端，後端沒有對應檢查，才需要在經授權的隔離測試環境驗證。測試使用自行建立的帳號與假報表，不碰正式客戶資料。
第三步才是修補。工單應寫清楚預期：使用者只能下載有權限的報表，沒有權限時應拒絕，且正常授權的使用者仍能工作。單純讓某個測試不再觸發，可能只是把整個下載功能關掉；這雖然讓警告消失，卻不算完成修復。
最後把檢查分成兩組：原本不該成功的存取必須失敗，原本合法的存取仍應成功。把這些條件放入回歸測試，再由維護者審查變更與部署。資安人員負責風險與證據，服務負責人確認業務影響，開發者處理修改，發布人員確認回復方案。模型產生修補建議，不代表它能替所有角色簽核。
這就是「驗證」比多列幾個警告更有用的原因：每一步都把模糊懷疑變成可核對的輸入與輸出。清單可以用來檢查是否漏項，但真正交付的是可追蹤的處理紀錄，不是一份更長的 AI 報告。
怎麼比較掃描工具，才不會獎勵誤報？
先把結果分成已確認問題、重複問題、證據不足與可排除問題，不要只報「找到幾件」。同一個缺陷可能被不同代理用不同說法重複回報；把它們全算新增漏洞，會讓報告量增加，卻沒有增加實際安全收益。
可以用一組已獲准測試、版本固定的內部模組，記錄從警告出現到完成確認的人工作業時間。若工具 A 回報很多，維護者卻要花大量時間逐件否決；工具 B 的候選較少、但更容易確認與修補，後者可能更符合團隊需要。這是評估方法，不是 MDASH 與其他產品的實測排名。
漏報也不能忽略。只檢查工具提出的候選，會看不到它完全沒發現的問題；應另外用已知的歷史修補案例與正常程式作為對照，固定版本、權限、工具與資料範圍再比較。要整理更一般的測試設計，可看 LLM 評測方法。
我不建議讓新導入的 AI 掃描器直接寫入正式環境或自動合併修補。先讓它在有限範圍提出候選、產生測試與修補草稿，再逐步評估自動化；程式碼保密、執行環境隔離與最小工具權限，可搭配 AI 隱私與資料分級及提示注入風險一起檢查。
結論
MDASH 展示了 AI 參與漏洞發現與驗證的方式，修補決策仍須交回負責團隊。
採用前先要求一份可追查的完整處理紀錄：警告如何確認、誰接受風險、修補如何驗收。這比單看代理數量更能判斷工具是否適合現有團隊。
常見問題
Microsoft MDASH 現在可以直接下載使用嗎？
本文查核的微軟公告描述的是內部使用與有限私人預覽，不是公開下載套件。需要產品資格或採用安排，應依微軟當前提供的申請與說明確認；不要把研究架構圖當成完整安裝指南。
AI 說有漏洞，就應該立刻修嗎？
先確認受影響版本、適用條件與證據，再依風險安排處理。證據不足時應標為待確認；若涉及正在被利用的風險，則由資安與服務負責人決定暫時防護，不靠模型分數單獨下結論。
AI 產生修補程式後，還需要回歸測試嗎？
需要。除了確認原問題已被阻止，也要驗證正常功能仍可使用，以及沒有引入新的權限或資料問題。修補草稿、人工審查與正式發布是不同階段。