For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/articles/microsoft-mdash-reaches-95-on-cybergym.md.
Microsoft has reported a 95.95% success rate on CyberGym for a new configuration of MDASH, its multi-model, multi-agent system for identifyi...
Microsoft has reported a 95.95% success rate on CyberGym for a new configuration of MDASH, its multi-model, multi-agent system for identifying, validating, prioritizing, and remediating software vulnerabilities.
The number is striking. The original CyberGym paper reported that its strongest tested combination—OpenHands with Claude 3.7 Sonnet—reproduced 11.9% of the benchmark’s vulnerabilities in the first published evaluation.
Microsoft’s latest result is far higher. However, the most important part of the announcement is not simply that a newer model is more capable.
The 95.95% score was produced by a complete security system combining:
Microsoft summarizes the approach in three words:
Model
Data
Harness
The model contributes intelligence. The data gives that intelligence security context. The harness converts model outputs into a repeatable, verifiable workflow.
This distinction matters because enterprise security teams do not buy benchmark answers. They need a system that can operate continuously, control false positives, prove that a finding is real, and help turn the result into a safe remediation.
Microsoft’s published CyberGym chart compares five model-and-agent configurations:
| System or model configuration | Microsoft-reported CyberGym success rate |
|---|---|
| MDASH: MAI-Cyber-1-Flash + GPT-5.4 | 95.95% |
| GPT-5.5 Cyber | 85.6% |
| Mythos 5 | 83.8% |
| GPT-5.6 Sol | 83.6% |
| Gemini 3.5 Flash Cyber in CodeMender | 83.2% |
The MDASH configuration leads the next entry in Microsoft’s chart by more than ten percentage points.
Microsoft also says the configuration costs about 50% less than the previous strongest MDASH setup, which used GPT-5.4, GPT-5.4 mini, and GPT-5.3 Codex.
The comparison is therefore about two dimensions:
Security scanning is not a one-time question. Large organizations may need to inspect millions of lines of code, repeat scans after every change, validate suspected vulnerabilities, retest patches, and monitor a constantly changing software estate.
A configuration that is extremely capable but too expensive to run frequently may create less real protection than a slightly smaller model embedded in a better routing and validation system.
Microsoft says MAI-Cyber-1-Flash was designed to handle up to 90% of the tasks inside the MDASH workflow.
The most difficult 10% can be routed to a larger model, which Microsoft identifies in the published configuration as GPT-5.4.
The strategy can be expressed as:
Common and frequent security tasks
→ MAI-Cyber-1-Flash
Exceptionally difficult tasks
→ GPT-5.4
This is not the same as saying that MAI-Cyber-1-Flash fixed 90% of vulnerabilities by itself.
The 90% figure refers to the share of tasks the small model is designed to cover within the routed workflow. The complete MDASH result still depends on the task router, the larger model, the specialized agents, validation, proof generation, deduplication, security tools, execution environments, and system-level controls.
The small model lowers the average cost of the workflow without removing the need for stronger models on the hardest cases.
Microsoft describes MAI-Cyber-1-Flash as its first cybersecurity-specialized model.
The official model card lists:
| Specification | MAI-Cyber-1-Flash |
|---|---|
| Architecture | Sparse Mixture of Experts Transformer |
| Total parameters | 137B |
| Active parameters | 5B |
| Context length | 256K |
| Input | Text |
| Output | Text |
| Base model | MAI-Code-1-Flash |
| Primary environment | Microsoft codename MDASH |
| Release date | July 27, 2026 |
| Availability | Azure AI Foundry Private Preview for approved MDASH customers |
The model is a cybersecurity-specialized fine-tune of MAI-Code-1-Flash.
It was designed for workflows including vulnerability identification, validation, prioritization, triage, remediation support, and enterprise-scale code scanning.
It is not a general public cyber model.
Microsoft’s model card says access is restricted to selected MDASH customers and requires additional review because advanced cybersecurity capabilities are dual-use.
The model is also designed specifically for integration with MDASH, rather than as a standalone downloadable model or unrestricted public API.
MAI-Cyber-1-Flash has 137 billion total parameters but activates approximately 5 billion for a token.
That sparse Mixture-of-Experts design gives the model access to a larger total capacity while keeping its active inference footprint relatively small.
The more important optimization, however, is specialization.
A general frontier model must support writing, mathematics, research, coding, conversation, planning, multimodal work, and tool use. A specialist model can focus more of its training and post-training on one operational domain.
For MAI-Cyber-1-Flash, that domain includes executable security environments and vulnerability-management workflows.
Specialization can improve price-to-performance when the model repeatedly encounters tasks similar to its training and evaluation environment.
The system still needs a fallback because difficult or unusual cases may exceed the specialist model’s capability.
This creates a practical multi-model architecture:
Low-cost specialist for breadth
+
Frontier model for exceptions
+
Verification system for trust
The model card provides a particularly useful system-level comparison.
Microsoft says the previous MDASH configuration scored 88.4% on CyberGym.
After replacing 80% of the existing model calls in the workflow with MAI-Cyber-1-Flash, the result increased to 95.95%.
The cost also fell by about half relative to the previous strongest configuration.
This result challenges a common assumption:
A cheaper model must reduce quality.
That may be true when models are compared in isolation on the same task. It is not always true inside a routed system.
A specialist model may handle common tasks more consistently because it was trained for those tasks. A router can reserve the expensive frontier model for cases where it creates the most value.
The result depends on correctly answering three questions:
Model routing becomes part of product quality.
Microsoft’s model card also reports standalone results for MAI-Cyber-1-Flash on other cybersecurity evaluations.
Those model-only results are not equivalent to the MDASH CyberGym score.
The model card lists:
| Benchmark | Standalone MAI-Cyber-1-Flash result |
|---|---|
| CVEBench | 0.314 |
| CyberSecEval4 Threat Intelligence | 0.553 |
| CyberSecEval4 Malware Analysis | 0.33 |
| CRSBench | 0.651 at POV=1200 |
| ExploitGym Kernel | 0 |
| ExploitGym Userspace | 0 |
| ExploitGym Browser | 0 |
These figures show why the system-level distinction matters.
The small model is not universally dominant across every cyber benchmark. Its strongest published result appears when it operates inside MDASH with other models, agents, tools, data, and validation stages.
This supports Microsoft’s central message:
The model is a component.
The system is the product.
MDASH is Microsoft’s multi-model, multi-agent vulnerability identification and remediation harness.
Microsoft says its security experts have created more than 100 specialized agents within the system.
Different agents can perform different parts of the workflow, including code targeting, candidate discovery, vulnerability reasoning, validation, proof construction, triage, deduplication, remediation, patch-related workflows, and comparison between findings.
A simplified system flow may look like this:
Code and security context
↓
Candidate-discovery agents
↓
Validation agents
↓
Debate and comparison
↓
Deduplication
↓
Proof-of-concept generation
↓
Patch or remediation support
↓
Human review and controlled action
The exact internal implementation is proprietary, but Microsoft has described several important design principles.
Microsoft says MDASH separates parts of the pipeline—such as targeting, validation, deduplication, and proof—from any one model.
That makes it easier to replace or compare models.
When a new model becomes available, the system can A/B test it against the current panel.
The organization’s earlier investments can remain useful:
This reduces dependence on one model vendor or checkpoint.
It also makes continuous improvement possible. The best model for one stage may not be the best model for another.
Some vulnerabilities require more than reading source code.
A system may need to build the project, create a triggering input, run the vulnerable version, run the patched version, inspect a crash, query a code-analysis database, compare control flow, and verify whether the behavior is reproducible.
Microsoft says MDASH can use specialized domain plugins and code-analysis systems.
Its May announcement discusses a proving plugin for Common Log File System vulnerabilities and notes that CodeQL databases can also be used.
The model does not need to perform every operation through free-form text.
Tools can provide deterministic capabilities for tasks that are better handled by software.
A security model can produce a plausible vulnerability description that is wrong.
If a system forwards every speculative result to a developer, it creates alert fatigue.
The operational value comes from proving that a finding is real.
Useful evidence may include:
This is why a benchmark such as CyberGym is relevant.
It does not score the persuasiveness of a written explanation alone.
It checks whether the generated proof can actually reproduce the target behavior.
CyberGym is a large-scale benchmark created by researchers associated with UC Berkeley.
The current public project includes 1,507 real-world vulnerability instances across 188 software projects.
For its primary PoC-generation setting, the agent receives:
The agent must generate a proof-of-concept that triggers the vulnerability.
The benchmark then evaluates behavior against the vulnerable and patched versions.
A successful reproduction should generally satisfy the intended contrast:
Pre-patch version:
The PoC triggers the target vulnerability.
Post-patch version:
The same PoC no longer triggers the vulnerability.
CyberGym uses real vulnerabilities from major open-source projects, including projects from the OSS-Fuzz ecosystem.
Its execution-based structure makes it more rigorous than a benchmark that only asks a model to classify code or write an explanation.
The 95.95% number needs careful interpretation.
CyberGym’s primary setting gives the agent a vulnerability description.
The agent is not necessarily starting from a completely unknown repository with no clue that a vulnerability exists.
The benchmark therefore measures a form of known-vulnerability reproduction.
It does not directly mean:
The benchmark still requires difficult work. The agent must navigate a real codebase, locate the relevant behavior, construct an effective trigger, build or execute the software, and verify the result.
The correct description is:
The reported score is a vulnerability-reproduction success rate on the CyberGym evaluation configuration used by Microsoft.
The original CyberGym paper’s first version reported that the strongest tested combination, OpenHands with Claude 3.7 Sonnet, reached an 11.9% reproduction success rate.
Later benchmark revisions, agent frameworks, model generations, and system designs improved results substantially.
Microsoft’s reported 95.95% demonstrates how quickly the combination of models and harnesses has advanced.
However, the comparison should not be interpreted as a clean model-to-model improvement.
The systems differ in model generation, agent framework, prompting, tooling, validation, compute budget, cost, task routing, benchmark version, infrastructure, and retry policy.
The progress is real, but it is system progress.
The source article notes that Microsoft’s 95.95% result was not yet reflected on the public CyberGym leaderboard at publication time.
Microsoft’s earlier May configuration, reported at approximately 88.4%–88.45%, had been publicly presented as the benchmark leader.
The new 95.95% figure is published by Microsoft in the MAI-Cyber-1-Flash announcement, the model card, and Microsoft’s Project Perception announcement.
Until an external leaderboard entry or independent reproduction is available, it should be described as a Microsoft-reported result.
This does not make the result meaningless. It means readers should distinguish:
Vendor-reported evaluation
from
independently reproduced public result
That distinction is especially important in fast-moving benchmark comparisons.
Microsoft identifies historical security data as its deepest advantage.
The company says it processes more than 100 trillion security signals per day and has operational insight from 1.6 million customers.
Its security visibility spans identity, endpoints, cloud, networks, data, browsers, and applications.
The value is not simply the number of events.
The company can connect security actions with outcomes:
This creates a feedback loop.
Security event
→ investigation
→ validation
→ remediation
→ observed outcome
→ better data and rewards
→ improved models and agents
A competing company can obtain access to similar foundation models.
It cannot instantly recreate decades of validated operational history.
Large data volume is only useful when it is transformed into training, evaluation, and operational context.
Raw security signals can be repetitive, noisy, incomplete, customer-specific, sensitive, incorrectly labeled, biased toward visible attacks, or missing the final outcome.
The data pipeline must connect events to trustworthy labels and outcomes.
For example:
Alert raised
→ analyst investigated
→ vulnerability confirmed
→ patch deployed
→ exploit no longer works
That sequence is more valuable than the alert alone.
The moat comes from data plus curation, feedback, evaluation, and secure operational access.
Microsoft’s three-part framework provides a useful way to evaluate any enterprise AI security system.
Questions include:
Questions include:
Questions include:
Describe your idea once, and We0 AI can generate a showcase site, pages, and CMS, then help you attract customers and traffic after launch.
One complete project generation for free registration
Best for trying one complete generation flow and seeing a first project draft quickly.
A strong model with weak data and no verification may generate impressive but unreliable reports.
A well-designed system can make a smaller model more useful by assigning it the correct tasks and checking its work.
Microsoft argues that token cost becomes a central constraint when security scanning runs continuously.
Consider a simplified workload:
10 million code-analysis tasks per month
If every task uses the most expensive frontier model, the system may become difficult to operate at full coverage.
A routed design changes the average cost:
90% lower-cost specialist
+
10% expensive frontier model
The actual economics also depend on input length, output length, tool calls, retries, sandbox execution, code indexing, validation, human review, infrastructure, and data storage.
The model token bill is only one component.
Still, routing creates a powerful optimization opportunity because the expensive model is used selectively.
A benchmark can compare individual models under a common harness.
A product needs to optimize the complete workflow.
The best system may use a model that is not individually ranked first if it offers better speed, cost, specialization, predictability, tool use, context efficiency, safety calibration, and compatibility with the harness.
This is similar to other production systems.
A database does not choose one algorithm for every query. A cloud scheduler does not place every workload on the largest machine. A security system should not send every task to the most expensive model.
Cybersecurity models create unusual safety risks.
The same capability that helps a defender validate a vulnerability may help an attacker exploit one.
Microsoft has therefore limited access to MAI-Cyber-1-Flash.
The model card says:
Microsoft says the model was calibrated with a security-first approach, evaluated by the Microsoft AI Red Team, tested through automated adversarial exercises, tested by security experts, and assessed by an independent third party.
The independent assessment reportedly found no critical-severity issues.
That does not prove the model is risk-free. It explains why the company is beginning with a restricted deployment rather than an unrestricted public release.
Microsoft’s model card lists several limitations.
The model was primarily trained and evaluated in English. Performance may be lower in other languages.
Like other language models, it may produce inaccurate, incomplete, or incorrect code and text. Outputs require review and validation.
The model is intentionally calibrated to be cautious. Safeguards may activate when a legitimate defensive request is ambiguous or resembles harmful activity.
The model is designed for MDASH. Standalone results do not represent the full system’s capability.
Use outside approved defensive security operations is not supported.
Microsoft’s May MDASH announcement includes examples from actual security research.
The company reported testing the harness on an unpublished sample driver containing 21 deliberately inserted vulnerabilities. It said MDASH identified all 21 in that controlled test with zero false positives.
Microsoft also reported that MDASH contributed to the identification of 16 CVEs included in a May 2026 Windows Patch Tuesday release.
These are Microsoft’s own product and research claims.
They are more relevant to deployment than a benchmark score because they involve private code, real engineering workflows, vulnerability validation, patch processes, and security-team review.
At the same time, selected case studies do not establish a universal false-positive rate or success rate across every codebase.
Microsoft introduced Project Perception as a larger agentic security system.
Its objective is to move from AI that assists a defender to AI that performs more of the security workflow while leaving critical judgment under human control.
Project Perception coordinates three classes of agents:
| Agent class | Main role |
|---|---|
| Red agents | Simulate attacker thinking and identify possible paths to compromise |
| Blue agents | Investigate, reason over context, detect, and triage meaningful risks |
| Green agents | Remediate, harden systems, and reduce exposure |
The three roles form a loop:
Red agent finds a path
→ Blue agent validates and prioritizes it
→ Green agent remediates it
→ System observes the outcome
→ Future defense improves
Microsoft says Project Perception entered public preview on August 3, 2026.
Microsoft describes the system as several connected layers.
The system observes endpoints, identities, clouds, applications, and other parts of the digital estate.
Raw signals are transformed into a connected representation of assets, identities, relationships, policies, risks, activities, and historical incidents.
The platform uses a multi-model strategy, including specialized cyber models such as MAI-Cyber-1-Flash.
The harness coordinates models, agents, tools, workflows, testing, permissions, and controls.
Red, blue, and green agents perform specialized security work.
Actuators translate decisions into actions within integrated security products.
This architecture is broader than a chatbot. It is intended to form a continuous security operating system.
Microsoft explicitly says that humans remain in control of high-impact actions.
Its Project Perception page frames the division as:
Agents carry the work.
Humans carry the judgment.
Defenders set objectives, policies, guardrails, approval requirements, scope, and response priorities.
High-impact actions remain subject to human sign-off.
This is necessary because security remediation can itself cause harm.
An automated system might disable a legitimate account, block production traffic, remove a critical file, quarantine a business system, deploy a flawed patch, or interrupt operations.
The cost of a false action can be higher than the cost of a missed alert.
Microsoft describes Security Copilot as an AI-assisted conversational interface.
Project Perception is presented as the wider agentic system.
| Product concept | Role |
|---|---|
| Security Copilot | AI that assists through a generative interface |
| Project Perception | AI agents that continuously reason and act across security workflows |
The products are intended to work together.
A human may use Copilot to understand and direct work, while Perception agents perform more of the ongoing operational process.
Microsoft says Project Perception uses consumption-based pricing measured in Security Compute Units, or SCUs.
Different agents consume different amounts depending on the intensity of the task.
This makes model and workflow efficiency economically important.
A red-team simulation, a quick triage task, and a long remediation workflow may consume different resources.
The multi-model routing strategy used in MDASH fits this broader pricing model.
If routine work can be handled by a smaller specialized model, more security coverage may be delivered for the same budget.
Access to frontier models is becoming less exclusive.
Organizations can increasingly call capable public models through APIs.
The scarce part may be the system that can determine whether a model’s security claim is true.
That system needs executable environments, build infrastructure, version control, proof generation, patch comparison, security knowledge, sandboxing, deduplication, human review, and evidence tracking.
In security, a polished explanation without evidence is often not enough.
The moat moves from:
Access to a powerful model
toward:
A trusted process that validates and operationalizes the model's work
Do not automatically use the most expensive model for every operation.
Build an evaluation set and determine which tasks can be handled reliably by a smaller specialist.
One agent or model can generate candidates. A different agent, tool, or deterministic test should validate them.
Where possible, require a reproducible test rather than accepting a textual claim.
Automate collection, analysis, and verification first. Keep destructive or production-changing actions behind approval gates.
Token price alone is not the correct metric.
A cheap model that produces many false positives can be more expensive operationally.
Useful metrics include cost per confirmed vulnerability, time to validation, false-positive rate, human-review time, patch acceptance rate, and regression rate.
Model generations change quickly.
Keep task definitions, tools, validations, and security controls reusable when the underlying model changes.
Record outcomes, not only alerts.
The system should learn which findings were real and which remediations worked.
CyberGym’s repository warns against exposing its services to the public internet.
Microsoft also describes sandboxed, network-isolated environments for testing.
Vulnerability reproduction should run in controlled infrastructure.
A serious evaluation should include more than one headline score.
The 95.95% score is important, but it should not be generalized beyond the evidence.
MDASH, several agents, two model tiers, tools, and data produced the result.
Microsoft published the result. Independent reproduction remains valuable.
CyberGym measures a defined vulnerability-reproduction task.
Production false-positive behavior requires separate measurement.
Microsoft retains human sign-off for critical actions.
MAI-Cyber-1-Flash is restricted to approved MDASH customers in private preview.
Results can vary across languages, vulnerability classes, codebases, tools, and benchmark harnesses.
MDASH is Microsoft’s multi-model, multi-agent system for identifying, validating, prioritizing, and remediating software vulnerabilities. It combines specialized agents, multiple models, code-analysis tools, proof generation, validation, and enterprise security controls.
MAI-Cyber-1-Flash is Microsoft’s cybersecurity-specialized sparse MoE model. The official model card lists 137 billion total parameters, 5 billion active parameters, a 256K context window, and restricted availability inside MDASH through Azure AI Foundry Private Preview.
No. The 95.95% result belongs to the complete MDASH configuration using MAI-Cyber-1-Flash, GPT-5.4, agents, tools, data, and validation. Microsoft’s standalone model-card results are different and lower on several other cyber benchmarks.
Microsoft says MAI-Cyber-1-Flash was designed to handle up to 90% of tasks in the routed MDASH workflow. It does not mean the model independently discovered or repaired 90% of all vulnerabilities.
CyberGym primarily evaluates whether an agent can generate a proof-of-concept that reproduces a known real-world vulnerability using a vulnerability description and the pre-patch codebase. The PoC is tested against vulnerable and patched versions.
The score is published by Microsoft in its announcement and model card. At the time described by the source article, it had not yet appeared as the updated result on the public benchmark leaderboard, so it should be described as Microsoft-reported.
No public model download is documented. Microsoft says it is available only to selected MDASH customers through Azure AI Foundry Private Preview and subject to review and approval.
Project Perception is Microsoft’s wider agentic security system. It coordinates red agents, blue agents, and green agents across detection, investigation, remediation, and hardening workflows while keeping humans responsible for critical decisions.
Microsoft reports that MDASH reached a 95.95% success rate on CyberGym after integrating MAI-Cyber-1-Flash and routing the hardest cases to GPT-5.4. The company also reports a 50% cost reduction compared with its earlier strongest model configuration.
The result does not belong to one model. It comes from a multi-model security system with more than 100 agents, historical security data, specialized tools, proof generation, validation, deduplication, sandboxing, and human-designed orchestration.
CyberGym mainly tests reproduction of known vulnerabilities from descriptions and pre-patch code. The score is therefore evidence of strong vulnerability-reproduction performance on that benchmark, not a universal zero-day discovery or autonomous-remediation rate.
Project Perception extends the same system philosophy beyond code scanning: red agents expose risks, blue agents investigate them, and green agents remediate them, while critical decisions remain under human control.
The central lesson is that frontier cybersecurity advantage is shifting from access to one powerful model toward the ability to route, verify, and operationalize many models inside a trusted security system.
Start from one sentence and have a complete website in minutes.
