Project Perception: Let AI Agents Test If You're Protected

Every time a threat actor makes the news, the same question lands on the SOC: are we protected from this one? Answering it usually means hours of hunting, posture checks, and chasing app owners. The result is often a slide with a confident color on it.

Microsoft's Mechanics demo of Project Perception shows agents in Microsoft Defender answering that question with a test. I haven't run it myself. It's in an invitation-only preview, so what follows comes from the demo, the Microsoft Learn documentation, and analyst coverage. The demo is impressive. The more useful part, for anyone running a SOC on Defender and Sentinel, is the decision it forces: which steps you let an agent take alone.

What the demo showed

Dave Weston, CVP of Microsoft Security, types one prompt into the Perception chat in the Defender portal: "Is my organization protected against Onyx Sleet?" Microsoft tracks Onyx Sleet as a North Korean actor, first observed in 2014, that mainly targets military, defense, and technology organizations.

A planning agent picks a playbook and sets four kinds of agents to work. A threat intelligence agent pulls the actor's indicators. Red team agents run reconnaissance, find an exposed billing application, and hand it to a pen test agent. That agent pulls earlier findings from MDASH, Microsoft's multi-model code-scanning system, and confirms an internet-exposed SQL injection plus stored cross-site scripting and identity issues.

Then the blue and green teams act. A detection authoring agent writes KQL detections for each vulnerability, to cover the window between finding a bug and shipping a fix. A posture remediation agent proposes a web application firewall in blocking mode, an authorization check, and a code fix that parameterizes the invoice queries. The fix is tested, and Perception opens a pull request that merges into production code.

Weston says the agent stops "any time there's an operation of consequence." In the demo, he approved a few specific requests and otherwise steered. Each session ends with a shareable report: the actor, the attack path, the remediation plan, and a timeline.

Microsoft frames all of this as matching attackers at machine speed. In a separate clip, Weston cites an attack on Mexican government organizations where AI generated about 17,000 lines of tooling across 49 modules and adapted mid-attack. Gambit Security's account of that campaign, as summarized by Let's Data Science, describes a 17,550-line AI-written Python pipeline used against nine agencies.

What the preview actually is

The documentation describes something narrower than the demo. That's normal for a preview, and worth knowing before you plan around it.

• Access. Perception is in Limited Public Preview, available to "a small, invitation-only set of customers," per Microsoft Learn.
• Roles. It needs unified RBAC across Defender workloads. Security Admin sets up and removes agents. Security Reader can start and use sessions.
• Identity. Each agent gets its own Microsoft Entra Agent ID with minimum permissions. Defender for Endpoint device-group scopes have to be granted to that identity by hand, or sessions "fail or return incomplete results."
• Playbooks. The docs say "Playbooks are managed by Microsoft. You cannot create, edit, or delete them." The Mechanics video says you can build your own. For now, I'd go with the docs.
• Remediation. Futurum reports that autonomous remediation is not in the preview, that reversible moves like isolating a machine come later this year, and that riskier ones like patching a host stay behind human approval.
• Cost and positioning. Pure AI reports pay-as-you-go pricing in Security Compute Units, with general pricing undisclosed. Microsoft's framing is that "Security Copilot is AI that assists, while Project Perception is AI that acts."

John Savill's walkthrough adds two scope details. The recon agent currently looks at Azure resources, and the data sources are first party, with third-party ingestion on the roadmap. He also describes the detection agent back-testing new rules against XDR data to limit false positives.

Where "protected" stops

A tested answer is better than a guessed one. It's still bounded by what was tested.

If recon only enumerates Azure, the report says nothing about the on-premises file server or the SaaS app nobody registered. If the threat intelligence is thin on an actor, the simulation is thin too. Forrester notes the initial demos focus on hardening web apps exclusively, and Futurum points out that many intrusions start with credentials and social engineering instead. Futurum's line on the benchmark numbers applies here as well: "an eval proves capability in a harness, not outcomes in your estate."

The second limit is change control. An agent that deploys a detection changes your alert volume. An agent that merges code changes a production application. Both are routine changes with owners, rollback plans, and sometimes a CAB. Approval prompts help, but an approval clicked by whoever has the portal open is not the same as an owner signing off. Forrester's advice is to strictly limit agent permissions so agents can't take irreversible actions.

Decide your lines before the preview reaches you

You don't need preview access to do the useful part. You need one threat actor and an hour.

1. Pick one actor that targets your sector. Start with the actor your leadership asked about last, or the one your threat intelligence flags for your industry.
2. List every step the playbook would run. From the demo: pull indicators, run recon, pen test reachable apps, write KQL detections, enable WAF blocking, add an authorization check, open and merge a code fix.
3. Mark each step agent alone or human sign-off. Read-only steps such as threat intelligence and recon are easy candidates for agent alone. Anything that changes production, including detections that page people, needs a named approver.
4. Name the owner for each sign-off. A detection belongs to detection engineering. A code merge belongs to the app owner, not the analyst on shift.
5. Write down what's out of scope. Non-Azure assets, third-party log sources, and identity attacks the simulation doesn't cover. Put that list in every "are we protected" answer.
6. Scope the agent identities. When you set up agents, give each Entra Agent ID only the device groups and permissions its steps need.

The takeaway

Project Perception is the first tool I've seen that turns "are we protected?" into something closer to a test result. The preview is narrower than the demo, and the answer only covers what the agents can see. The work you can do now is deciding where the agent stops and a person signs.

Pick one actor this week and mark the steps. Which one would you never let an agent take on its own?