6 Tests That Matter When You Deploy Project Perception

Two months ago, in April, Aleš Holeček announced Microsoft was building a multi-model scanning harness. The team that built it came from Team Atlanta, which won the $29.5 million DARPA AI Cyber Challenge by building an autonomous system that found and patched real bugs in complex open-source code. MDASH proved the concept.

In May, they shipped it against Windows and found 16 vulnerabilities including four critical RCE flaws. The multimodal routing works: frontier models for complex reasoning, distilled models for high-volume scanning.

This week, they wrapped MDASH inside Project Perception: red team agents hunt vulnerabilities, blue team agents determine exploitability, green team agents patch. Perception enters public preview August 3, initially inside Microsoft Defender.

Here’s what shifted: seeing MDASH actually work changed the question from “could this work?” to “what happens when it does?” A multimodal harness that finds vulnerabilities at scale doesn’t solve the operating model problem. It creates it.

Project Perception forces us to answer hard questions about how agentic systems actually operate. I’m using it as a test case for what exposure management programs actually need.

Here are six independent tests. Each one isolates one principle. Each one has a clear pass/fail.

Test 0: Orchestration

Hypothesis: The orchestration layer correctly interprets user intent and routes to the right agents with the right playbook.

Prediction: When a user asks “Are we vulnerable to Log4Shell on internet-exposed systems?”, the orchestration selects red team (discovery), applies filters (internet-exposed assets only), invokes the correct scan playbook, and chains results appropriately. Different user queries invoke different agent combinations in predictable ways.

Test: Issue different user intents through the CLI or chat interface. Observe which agents are invoked in what order. “Show me our posture” should invoke red + blue, not green. “Can we patch this CVE?” should invoke green only after blue has prioritized. “What conflicts with our WAF?” should route to blue-specific playbooks.

Hypothesis for pass: Perception interprets user intent and routes to specific agent combinations based on that intent. Different queries trigger different playbooks. A user asking for posture assessment never triggers automatic patching.

Why it matters: If orchestration routes to the wrong agents or invokes the wrong playbooks, all downstream principles fail. A user asking for posture shouldn’t trigger automated patching. Authorization, observability, and ownership are meaningless if the orchestration layer makes the wrong decisions about which agents to invoke in the first place.

Test 1: Authorization

Hypothesis: Each agent (red, blue, green) runs under its own scoped identity with different permissions.

Prediction: Red team can scan but cannot patch. Blue team can read threat intel but cannot modify patches. Green team can deploy patches but cannot change scan scope.

Test: Deploy red team agent against your infrastructure. Check if it attempts to deploy patches or defer findings. It should reject both. Examine the identity it runs under—it should be distinct from blue and green.

Hypothesis for pass: Each agent runs under a managed identity with scoped permissions independent of the user context. Red team can only scan. Blue team can only read threat intel and assess. Green team can only deploy pre-approved patches. Permissions are enforced at the identity level (like the Sentinel automation model).

Why it matters: Without scoped identities, everything downstream fails. You can’t enforce boundaries you can’t control at the permission level.

Test 2: Observability

Hypothesis: Every agent decision is traceable back to the agent that made it, with reasoning visible.

Prediction: Audit logs show: which agent (red/blue/green), what it decided (scan/prioritize/patch), why (signals, thresholds, context), when (timestamp), outcome.

Test: Run a complete discovery scan. Pull the audit trail. Reconstruct: Which red team agent ran the scan? What scan scope did it use? Which findings did it produce? Can you connect each finding to the agent’s reasoning?

Hypothesis for pass: Audit logs show agent-level granularity: which agent (red/blue/green), what decision (scan/prioritize/patch), why (signals, thresholds, context), when (timestamp), outcome. You can pull a log entry and know exactly which agent made it and why, not just “Perception found this.”

Why it matters: If you can’t see which agent made which decision, you can’t audit conflicts or hold anyone accountable.

Test 3: Ownership

Hypothesis: When agents conflict or make risky decisions, ownership is recorded with approval rationale.

Prediction: Red team finds a vulnerability. Blue team says it’s not exploitable. The log shows: who reviewed the conflict, what decision was made (accept red or blue assessment), and why. The decision is signed off—not anonymous.

Test: Create a scenario where red and blue conflict. Defer a patch based on “our WAF blocks it.” Examine the audit trail. Who made that decision? What was their reasoning? Is it recorded?

Hypothesis for pass: Conflict arbitration is recorded with ownership attached. The audit shows: red assessment, blue assessment, which one was accepted, who reviewed/approved the decision, and explicit rationale. No anonymous decisions.

Why it matters: Without ownership, deferred risk becomes implicit risk. You can’t defend exposure decisions to regulators if you don’t know who made them.

Test 4: Data Governance

Hypothesis: Feedback from failed patches and deployment outcomes flows back into the next agent scan cycle.

Prediction: Green team patches a vulnerability and the patch fails. The failure is recorded. Next time red team scans, it weights that failure pattern differently, or blue team uses the failure to refine exploitability assessment. Agents learn from what went wrong.

Test: Deploy a low-risk patch intentionally. Let it fail or break something. Monitor the next scan cycle. Does red team log the failure? Does it inform subsequent scans or blue team prioritization?

Hypothesis for pass: Patch failures and deployment outcomes flow back into the next scan cycle. Agents see what failed and integrate that into future decisions. Red team learns to weight failure patterns differently. Blue team refines exploitability based on deployment success/failure.

Why it matters: Without feedback loops, you’re not improving your exposure posture. You’re just running discovery repeatedly without integrating what failed or what you learned.

Test 5: Evidence

Hypothesis: You can reconstruct the full decision chain from vulnerability discovery through remediation, in business-readable format.

Prediction: Pull a record for a vulnerability: red team found it (timestamp, agent, signals), blue team assessed risk (threat intel used, assessment, owner), green team patched it (patch deployed, validation result). The chain is complete enough that you could present it to a regulator and they’d understand your decision-making.

Test: Close one vulnerability end-to-end. Pull all related logs and records. Try to write a one-paragraph narrative of what happened, who decided what, and why. If you can’t—if logs are fragmented or lack context—the evidence is incomplete.

Hypothesis for pass: You can reconstruct the full decision chain end-to-end in business-readable format: red found it (timestamp, agent, signals), blue assessed it (threat intel, assessment, owner), green patched it (deployment, validation, outcome). The narrative is complete enough to present to a regulator.

Why it matters: Your board wants proof that exposure is actively managed, not implicitly tolerated. Evidence is that proof. Without it, you have logs but no story.

What to Do

These six tests are independent. Each one has a hypothesis about what needs to be true. Run them in order—orchestration first, then authorization, then observability, then ownership, then data governance, then evidence.

Each hypothesis either holds or it doesn’t.

When you spin up Perception next week, test these hypotheses. Tell me which ones hold and which ones break.

I know there’s a future to “project perception operates safely in your exposure management program.” I’m just not sure we’re there yet. Stay tuned!

Leave a comment