Security teams rarely lack alerts. They lack time to determine which alerts describe an exploitable risk, which dependencies are involved and which fix will materially reduce exposure. Microsoft wants to move AI into that decision layer with Project Perception, available in public preview from 3 August.
The system combines security signals, context, multiple models and specialised agents. Its first scenario covers software vulnerability management. The stated goal is not to produce another summary, but to connect discovery of a weakness with priority and remediation while retaining human control.
Three agent families in a continuous loop
Microsoft describes three coordinated roles. Red team agents look for paths to compromise before an attacker can exploit them. Blue team agents investigate signals and assess risk in context. Green team agents propose or take corrective steps to strengthen the environment.
The distinction matters. A conventional scanner may identify a vulnerable version across thousands of machines. Contextual analysis must determine whether the component is reachable, whether an identity can access it, whether sensitive data sits behind it and whether several weaknesses can be chained together.
Project Perception aims to maintain this representation over time. Assets, identities, applications, data, clouds and AI systems form a changing graph. When a dependency changes or a new indicator arrives, priority can be recalculated without waiting for a wholly manual investigation.
MAI-Cyber-1-Flash targets software vulnerabilities
The first specialist model being promoted is MAI-Cyber-1-Flash. It joins MDASH, Microsoft's multi-model agent team for software vulnerabilities. According to results published by the company, this configuration scores 96% on the CyberGym benchmark, twelve points above Mythos, while delivering almost 50% cost savings compared with the MDASH configuration then in market.
Those figures should be read as vendor results, not as a performance guarantee for every repository. A benchmark measures a defined scope whose vulnerabilities and conditions cannot reproduce every constraint in a production codebase: internal dependencies, historical conventions, generated code, external services and incomplete documentation.
They nevertheless illustrate a relevant architecture choice. Microsoft does not claim that one general-purpose model is optimal for every task. Project Perception selects models according to quality, reliability, latency and cost. A fast specialist model can process large code volumes while a more expensive model handles difficult cases.
Context matters as much as the model
A capable security AI can still assign the wrong priority if it lacks environmental context. A critical flaw in an isolated component does not carry the same urgency as a medium-severity weakness exposed to the internet behind overly permissive credentials.
Microsoft therefore emphasises a shared context layer. It connects assets, identities, relationships, risks and activities so agents do not have to reconstruct the situation from raw logs for every request. The approach is also intended to reduce token use and the cost of continuous reasoning.
The competitive advantage may sit here as much as in MAI-Cyber-1-Flash. Microsoft already receives signals from endpoints, identities, cloud services, applications and security products. Analysis quality will depend on each customer's actual coverage, data freshness and the ability to integrate environments that do not rely exclusively on Microsoft's ecosystem.
Moving from recommendation to action
Project Perception introduces “actuators”, connectors that translate a decision into protection. In vulnerability management, this might lead to a proposed fix, a new work item, a policy change or a validation workflow.
It is also the most sensitive part of the system. An incorrect alert wastes time; an incorrect automated remediation can interrupt a service. Organisations will need to separate reversible actions from high-impact changes and define explicit autonomy levels.
A cautious implementation can follow this progression:
- observe and rank without making changes;
- recommend with supporting evidence and the attack path;
- automatically prepare a proposed fix and tests;
- apply only after human approval;
- automate cases that are repeatable, reversible and sufficiently evaluated.
Microsoft's promise of human control must involve more than a confirmation button. Analysts need access to sources, assumptions and the expected scope of a change.
Questions to ask during the preview
A preview is an opportunity to measure a product in its intended environment. Teams should track at least five indicators: priority accuracy, false positives, vulnerabilities actually missed, time from discovery to remediation and the proportion of recommendations accepted without major rework.
Cost also requires end-to-end measurement. Savings on inference can be erased by integration work, context storage, human review or overly frequent analysis. Conversely, an expensive model call may be economical if it sharply reduces time spent investigating alerts that lead nowhere.
Governance remains central. Which repositories and logs are sent to models? How long is that data retained? Can a proposed fix introduce an unapproved dependency? Are decisions auditable after an incident? A team should not expand autonomy until these questions have been tested.
A larger shift than the security chatbot
Project Perception marks a change in the role assigned to AI. The first generation of security assistants summarised an alert or answered a question. The next aims to maintain a model of the system, coordinate several specialists and close the loop through remediation.
That promise matches the needs of security operations centres, but it also raises the required level of trust. An agent connected to identities, code and protection policies becomes a privileged infrastructure component. It should be monitored accordingly, with minimal permissions, complete logs and a kill switch.
The preview will show whether Microsoft can shorten the queue instead of adding another alert layer. The decisive measure will not be the number of vulnerabilities detected. It will be the ability to explain which ones matter, propose a verifiable fix and demonstrate that risk has actually fallen.




Join the discussion
Comments
Loading comments…