Microsoft’s agentic security framework has been building quietly in the background for months, and Project Perception is its most concrete expression yet. Currently in limited public preview, Project Perception is a workforce of specialized AI agents, organized into red, blue, and green teams, designed to reason across your security data, identify gaps, investigate threats, and surface remediation priorities. The framing is ambitious: you set strategy, agents carry the load. The reality, at least in this first iteration, is more measured, and understanding that gap is essential before you start sizing up the investment.
What Project Perception Actually Is
At its core, Project Perception lives inside the Microsoft Defender portal at security.microsoft.com and is built on top of the broader agentic security concepts Microsoft has been publishing documentation on for some time. It is not a standalone product you purchase in isolation. It layers on top of a substantial existing investment: you need Microsoft Defender XDR, unified role-based access control enabled across all Defender workloads, and a security administrator or security reader role to get started. From there, specific agents require additional licensing: Defender for Office 365 Plan 2 for email and collaboration coverage, Microsoft Defender for Cloud and Defender for Containers for Azure workloads, and Microsoft Entra ID P2 combined with Microsoft Defender for Identity and Microsoft Defender for Cloud Apps to cover identity-based alerts. If your organization is not already running at or near Microsoft 365 E5, the prerequisite stack alone is a meaningful threshold.
Once you clear those prerequisites, pricing is consumption-based. Project Perception is billed in Security Compute Units, the same currency used across Microsoft Security Copilot. There is no flat monthly fee for a defined capability set. Every agent run draws from your SCU allocation, and the “Contact Sales” button on the product page is a reliable signal about where this sits on the cost spectrum. This is not a technology aimed at the SMB market in its current form. It is designed for organizations that are already deep in the Microsoft security stack and willing to pay for frontier-level tooling.
The Three Teams and What They Do
The agent categories map to the classic security model of offense, defense, and hardening.
The red team currently contains one agent: the Recon Agent. It simulates attacker behavior by mapping attack paths, identifying choke points, surfacing detection gaps, and performing vulnerability code scanning. It operates with significant but read-only graph permissions, including user and group membership reads, audit log access, application and delegated permission enumeration, and Azure RBAC assignments at subscription scope covering Key Vault Reader, Log Analytics Reader, and Security Reader roles. It does not execute attacks. It analyzes configuration and reasons about what an attacker could exploit if they were present. The value is in the correlation, connecting known CVEs and public threat intelligence to your specific tenant posture, rather than in active exploitation simulation.
The blue team contains four agents and is the most operationally rich part of the current release. The Triage Agent classifies and triages alerts across Defender workloads with some autonomous classification capability and feedback-based learning. The Attack Investigation Agent reconstructs incident timelines, maps observed behaviors to MITRE ATT&CK techniques, and produces an incident verdict, a classification of true positive, false positive, or benign, with transparent reasoning. For IT generalists who lack a dedicated SOC but manage Defender environments with real incidents, this agent has genuine practical value. Defender’s incident interface rewards expertise; the Attack Investigation Agent is designed to lower that expertise barrier without sacrificing analytic depth. The Threat Intelligence Agent pulls public signals and correlates them against your environment, producing threat actor profiles and KQL queries scoped to your telemetry. The Detection Authoring Agent is arguably the most technically interesting of the four: it helps security teams build and tune KQL-based detection logic, maps detection coverage to MITRE ATT&CK, and helps reduce false positive rates by reasoning about the nuances of alert tuning. For teams that rely on Microsoft Sentinel and spend real hours authoring analytic rules, this is where AI assistance becomes genuinely additive rather than cosmetic.
The green team currently has a single agent: the Posture Prioritization Agent. It synthesizes outputs from red and blue team activity to produce a ranked list of what to fix and why. Where Secure Score gives you a number derived from binary configuration states, this agent attempts to weight recommendations against real-world signals, incorporating what the blue team has observed about actual attack patterns in your environment. The prioritization is more dynamic than a static score, though the output is still a report you act on manually.
The Human-in-the-Loop Reality
Here is where expectations need calibrating. Every agent in the current release is manually triggered. Nothing runs on a schedule, nothing remediates autonomously, and the entire system is effectively read-only with narrow exceptions. You are not deploying an autonomous security workforce. You are deploying a set of sophisticated analysis tools that require a human to pull the trigger, review the output, and decide what happens next.
That framing matters for two reasons. First, it affects how you should evaluate the investment. If you are comparing Project Perception against a full-time security analyst, the comparison does not hold yet. If you are comparing it against a set of scripted assessments, Defender dashboards, and manually authored KQL queries, the comparison is more favorable because the agents provide richer correlation, adaptive reasoning across your specific configuration, and output designed to flow from one stage to the next. The Recon Agent’s markdown output is structured to feed the blue team agents. The blue team’s classifications and threat profiles are structured to feed the Posture Prioritization Agent. The pipeline design is intentional even if the automation remains limited.
Second, the human-in-the-loop requirement has real operational implications for how you staff supervision. The agents, particularly the Recon Agent, carry privileged read permissions. Whoever reviews that output needs sufficient permissions and sufficient expertise to validate what they are seeing. Junior analysts scoped to narrow roles cannot effectively supervise an agent that can enumerate your entire tenant configuration. That creates a bottleneck: the people qualified to review agent output are typically the same people already stretched thin across your security operations. Project Perception does not eliminate that constraint today. It shifts some of the analytical work while preserving the human decision layer at every step.
Playbooks as the Operational Interface
The most practical entry point into Project Perception is its playbook system. Playbooks act as orchestrators that chain agent runs together in response to events in the Defender portal. When an incident fires, you can trigger a playbook that sequences the relevant agents, routes outputs between them, and surfaces a consolidated result for human review. This is a direct evolution of the Security Copilot prompt workflows that security teams have been building for the past year, now integrated directly into the Defender incident workflow rather than requiring a context switch to a separate interface.
For organizations that have already invested in Security Copilot and built institutional knowledge around prompt engineering for security tasks, playbooks represent a natural upgrade path. The underlying mechanics are similar; the integration is tighter and the agent definitions are more structured.
The Model Question and the Cost Equation
Project Perception does not run on a single foundation model. Microsoft has confirmed it uses a multi-model approach, drawing on Azure OpenAI models and Microsoft’s own MAI Cyber One Flash, a security-specialized model the company claims outperforms general-purpose alternatives on security benchmarks. Which model handles which part of an agent run is not published in detail, and the selection appears to be governed by internal rules weighing quality, latency, reliability, and cost for the specific task at hand. That opacity is worth noting: the non-determinism of model behavior means that agent output could shift as Microsoft updates the underlying models, even if the agent configuration stays constant. Anyone planning to rely on these outputs for operational decisions should build in periodic validation rather than assuming consistency over time.
The cost question ultimately drives the adoption decision. Nationwide’s security team has demonstrated what sophisticated, AI-assisted security operations can look like at scale, as detailed in their Project Perception deployment. For large enterprises already running at E5 licensing levels with active Security Copilot consumption, the marginal cost of adding Project Perception agents to existing SCU capacity is easier to justify. For mid-market organizations without a dedicated SOC, the prerequisite stack and per-use billing create a real barrier even when the use case, particularly the Attack Investigation Agent, maps closely to an unmet need.
What Decision Makers Should Do Now
The limited public preview status means most organizations cannot access Project Perception today regardless of willingness to pay. That is not a reason to wait passively. The documentation is complete and the agent architecture is fully described, which makes now the right time to assess readiness rather than scramble after general availability.
Start with the prerequisite audit. Map your current Defender licensing against what each agent category actually requires. If you are missing Defender for Identity or have not enabled unified RBAC across workloads, those gaps represent real configuration work that takes time regardless of when Project Perception becomes broadly available. Address them now and you get better Defender coverage immediately while positioning for agentic capabilities later.
Next, assess your SCU posture. If your organization is already consuming Security Copilot capacity, work with your Microsoft account team to model what incremental Project Perception usage would cost against realistic trigger frequency. The per-use billing model rewards disciplined use. Organizations that trigger agent runs against every alert will spend significantly more than those who reserve the agents for high-priority incidents and scheduled posture reviews.
Finally, think hard about the supervision model before the technology arrives. The most common failure mode for agentic security tools is deploying them without clearly defining who reviews outputs, what authority that reviewer has to act, and how findings get routed into existing remediation workflows. Project Perception’s read-only, human-in-the-loop design actually gives you a window to build agent governance workflows deliberately. The transition from supervised read-only agents to agents with write permissions and real remediation authority is coming. Organizations that have practiced the governance model while stakes are low will be far better positioned when that transition happens.
Project Perception is early, it is expensive, and it is not yet the autonomous security workforce its framing implies. It is also a credible architectural bet on where enterprise security operations are heading, and the organizations that treat this preview period as a learning opportunity rather than a waiting room will have a meaningful head start when the agents are finally allowed to act.
Project Perception remains in limited preview, but the broader questions about how AI can strengthen your Microsoft 365 and Azure security posture are worth addressing now. If your organization is exploring how to integrate AI-assisted security workflows, audit your existing Defender and Entra configurations, or design governance frameworks that scale as Microsoft’s agentic capabilities mature, we can help. Reach out and let’s talk.