AI in the hunt, part 1: Microsoft’s Project Perception and Codename MDASH

This is the first part of a Cyber-Threat.net series on AI as a threat-hunting tool. We start with Microsoft, which has given two of its newest security AI systems names that sound like a 1950s B-movie: Project Perception and Codename MDASH. One of them is meant for hunters. The other is not, and it still matters to them.

Two systems, two different jobs

Project Perception is Microsoft’s multi-agent system for the security operations centre, and it runs inside the Microsoft Defender portal. It was announced on 27 July 2026 by Hayete Gallot, Executive Vice President of Microsoft Security. It groups its agents into three teams: red agents that “expose vulnerabilities before attackers can exploit them”, blue agents that “detect, triage, and investigate threats”, and green agents that “remediate and harden your posture”.

Codename MDASH (Microsoft’s expansion of the name is the “multi-model agentic scanning harness”) does a different job. It scans source code for vulnerabilities. It was built by Microsoft’s Autonomous Code Security team and announced on 12 May 2026. It is not a threat-hunting tool in the usual sense, because it looks at code, not telemetry. We cover it because the same agentic design runs through both.

Project Perception: what the agents do

The key concepts page lists six Microsoft-published agents:

• Recon Agent (red team): carries out “read-only, attacker-style analysis of Azure environments” to find privilege paths, choke points and exposure risks.
• Triage Agent (blue team): decides whether supported alerts are true or false positives and records its reasoning.
• Threat Intelligence Agent (blue team): reads a threat intelligence article and pulls out actor profiles, MITRE ATT&CK mappings, IOCs, CVEs and KQL hunting queries.
• Attack Investigation Agent (blue team): runs a “tier-2 investigation” of a Defender incident and produces a verdict, timeline, attack graph, affected entities and remediation actions.
• Detection Authoring Agent (blue team): turns threat intelligence into “implementation-ready KQL detection rules”.
• Posture Prioritization Agent (green team): ranks posture findings by severity, exploitability, active exploitation, internet reachability, asset criticality and attack-path context.

The agents are chained together in playbooks, where one agent’s output becomes the next agent’s input. Every run is recorded as a session. Microsoft describes sessions as “immutable records that serve as an audit trail for agentic work”. Work can start from the Playbooks page, from an incident or threat intelligence article page, or from a natural-language Chat.

According to the application card, Microsoft’s responsible-AI document for the product, the reasoning comes from Azure OpenAI models from Foundry Models. Microsoft says these models “aren’t trained on Customer Data from Perception sessions”. The product page lists Microsoft’s own MAI-Cyber-1-Flash among its models, though Microsoft’s July and August posts say its first use is inside MDASH, and that Perception “will also soon use” it.

How a hunter would actually use it

For hunters, the most relevant playbook is Protect against a threat. You give it a threat intelligence source. The Threat Intelligence Agent extracts the structured intelligence, the Recon Agent maps attack paths, the Posture Prioritization Agent ranks what to fix “in the context of a specific threat rather than generically”, and the Detection Authoring Agent writes KQL detections. Across its playbooks, Microsoft says Perception’s outputs include “KQL detection rules and hunting queries”, ranked recommendations, attack graphs and “evidence-backed verdicts”.

In practice, a sensible workflow looks like this:

1. Choose a fresh report on an actor that matters to you and open it from its threat intelligence article page in Defender, or start the Extract threat intelligence playbook.
2. Treat the extracted IOCs, ATT&CK mappings and hunting queries as a first draft. Check each technique mapping against the source report yourself.
3. Run the generated KQL in Advanced Hunting before trusting it. Check the time window, tables and fields. A query that silently returns nothing is worse than one that errors.
4. Run Protect against a threat to get attack paths and posture priorities for the same actor. Remember that the Recon Agent only covers the Azure subscriptions its identity can see.
5. Promote a detection only after testing, and keep the session log as evidence.

Microsoft has not published example generated queries, so we have not invented any. If we get access to the preview, real ones will appear in Hunt Lab, mistakes included.

What Perception can’t do

To its credit, the application card is blunt about the limits. It says agents “can produce responses that are inaccurate, incomplete, or outdated” and that output quality depends on the data, the permissions and the input. Agents “aren’t suitable for tasks outside their defined scope”. The Recon Agent is limited to Azure and only to the resources its configured identity can see. It is also read-only: it “doesn’t modify, exploit, or interact with the resources it analyzes”.

The docs spell out two traps. First, every agent needs its own Microsoft Entra Agent ID, and in a scoped Defender setup that identity must be granted the scopes explicitly. If it sees fewer scopes than its analysts, sessions fail or return incomplete results. (Only Defender for Endpoint device groups need assigning by hand; unified RBAC includes the other scopes by default.) Second, an agent is only as good as your telemetry: missing or stale data sources mean incomplete results.

Codename MDASH: what it is, and why hunters should care

MDASH runs source code through a pipeline Microsoft describes as Prepare, Scan, Validate, Dedupe, Prove. In the Scan stage, “more than 100 specialized AI agents” (with names such as injection-auditor and memory-safety-auditor) look at code ranked by risk. In the Validate stage, a second group of “debater” agents argue for and against whether each finding is reachable and exploitable. In the Prove stage, MDASH builds and runs triggering inputs “where the bug class allows”. Results arrive as SARIF and HTML in the Defender portal.

Microsoft’s headline claims, all from its May announcement:

• 16 new vulnerabilities found in limited internal testing scenarios across the Windows networking and authentication stack, including four Critical remote code execution flaws.
• 21 of 21 planted bugs found “in this run”, with no false positives, on a private test driver.
• 96% recall against 28 confirmed MSRC cases from five years in clfs.sys, and 100% of 7 in tcpip.sys.
• 88.45% on CyberGym’s standard (level 1) test when announced in May, top of the leaderboard at the time.

Microsoft AI later said that MDASH with its new MAI-Cyber-1-Flash model reached 96% on CyberGym’s “any crash” score, at about half the cost of its previous best model mix. That score counts any crash, not just the target bug. On the leaderboard’s own measure, the same setup scored 86.3%, lower than in May. CyberGym’s leaderboard says results are “evaluated and submitted by individual teams”. As at 23 October, MDASH’s best listed score (90.97%, from June) ranks 25th of 85 entries (leaderboard data). These are vendor figures, on Microsoft’s own code and on one benchmark.

For a hunter, the value of MDASH is indirect. If your organisation writes software, MDASH findings that are validated but not yet fixed suggest which internal services may be exploitable. (“Validated” means MDASH’s own checking stage agreed.) Point extra telemetry and hunting hypotheses there until the fixes ship. It does not hunt, and the FAQ says it “does not replace static analysis or manual review”. It is read-only: the defender fix option in the Defender CLI proposes code changes, using GitHub Copilot, for a developer to review.

Availability, licensing and data

Perception: Microsoft’s 27 July announcement said Perception would enter public preview on 3 August, but its Learn documentation, updated as recently as September, calls it a “Limited Public Preview” for “a small, invitation-only set of customers”. In practice you need an invitation, so check with your account team before you plan around it. You need Defender portal access with unified RBAC enabled across Defender workloads. Security Admin can set up agents; Security Reader can use them. Pricing is “consumption-based, pay-as-you-go”, and agents are metered “at different rates depending on the intensity of the task”. For non-EU tenants, including UK tenants, the application card says prompts may be processed “in the US, UK, EU, or Australia and New Zealand”. EU tenants stay in the EU.

MDASH: limited private preview. It needs “an eligible Microsoft Defender XDR plan”, plus Microsoft Foundry endpoints that you provision for inference, and whose token use you pay for. Current limits are roughly 256 MB per repository and one concurrent scan per tenant. Your source code and scan results are stored encrypted in your Defender XDR tenant’s region, and the FAQ classifies them as “Persistent”. The audit trail records scan actions but not source code.

Both are paid, preview-only Microsoft products; we cover them as news, not as a recommendation.

The risks, briefly

• Hallucination: a mapping, IOC or KQL clause that looks plausible but is wrong. Validate against the source report and your own data, every time.
• Over-trust: Microsoft itself warns that over-reliance “could lead to missed threats, incorrect incident conclusions, ineffective detection rules, or remediation of the wrong resources”. A benign verdict from an agent is not proof that nothing is there.
• Data exposure: agent identities are a new class of privileged account. Give them the least privilege they need, review their scopes, and watch their sessions. For MDASH, your source code leaves the repository and sits in the tenant.
• Prompt injection: the Threat Intelligence Agent’s job is to read outside content. Microsoft says it tested for prompt injection, but outside content is still untrusted input to an agent with access to your estate.

Our honest take

Perception is the more interesting of the two for hunters. Microsoft has documented a path from threat report to KQL and attack paths inside Defender, with an audit trail and approval gates, and the application card is unusually candid. It is also a preview that most organisations cannot use yet, and its Recon Agent is limited to Azure.

Microsoft’s reported benchmark numbers for MDASH are impressive, though they are self-reported and MDASH no longer leads the CyberGym leaderboard. It is a vulnerability-discovery engine, so for a SOC its value is as a source of hunting hypotheses rather than as a hunter.

Nadim Abdo, Microsoft’s Corporate Vice President for Identity and Network Access, put the right principle well on Microsoft’s security blog on 19 October, when Microsoft extended Perception with Guardian Agents to secure other agents: “We should not ask a model to be its own security authority” (source). The same applies to hunters. Let the agents draft, then check every query yourself before you rely on it.

For the attacker’s side of agents, see our agentic threat model. For a hunt you can run today, try Plex2Shell implants in the Plex Codecs folder; more are in Hunt Lab.

Next in the series: how Google’s Gemini-powered Threat Hunt Agent compares.