Microsoft's new Project Perception will end in a Pull Request

Liever in het Nederlands lezen?

TL; DR;

Last week, Microsoft put a team of security agents inside the Defender portal. Six agents: red maps the ways in, blue investigates, green ranks what to fix. Billed in Security Compute Units, each one carrying an Entra Agent ID.

Almost none of the capability is entirely new. Security Copilot was already good at blue. You could already imagine red on top of Defender EASM and Threat Intelligence. What’s new is the orchestration layer, the shared security context, and the fact that Microsoft is framing security work as coordinated agentic labor instead of isolated assistant prompts. We also get the fun of color-coding your work.

Microsoft describes Project Perception as a closed-loop system: red finds exposure, blue investigates, green prioritizes and hardens. But today, the loop still stops at the point where most security programs already struggle: the hand-off from security to engineering. A finding becomes a report. Maybe a ticket. Maybe a backlog item. Maybe a thing everyone agrees is important until the next sprint planning session quietly buries it.

My call: Project Perception eventually gets a GitHub and Azure DevOps surface. The visible signal will be a playbook that ends in a branch, a pull request, or an infrastructure-as-code change instead of a markdown report. But the bigger story is not “security agents will write code.” The bigger story is that Microsoft is building a governed action layer for enterprise agents, and Project Perception is where that layer becomes security-critical.

The pull request is just the easiest actuator to see.

In June I gave the opening keynote at EPN CyberSEC Netherlands in Amsterdam, titled Securing the AI-First Enterprise: why Agentic AI demands Agentic Cybersecurity. The argument was simple enough to fit on one slide. AI collapses the attacker’s timeline. Time to breach, time to exploit, time to exfiltrate, all falling. Your response window closes by exactly the same amount. To defend against machine-speed adversaries, we need machine-speed defenders. I expected to be making that case to boardrooms for another year. Six weeks later Microsoft ships Project Perception.

Then I looked at the colors…

Hayete Gallot, EVP of Microsoft Security, opened the announcement with a line worth remembering.

The physics of cybersecurity are changing

Strip the marketing language and the claim holds: the cost of AI-enabled has fallen hard. Defense did not get cheaper at the same rate. Something has to absorb the difference, and it was never going to be headcount. As we’ve seen in pubic reporting and write-ups from OpenAI, Anthropic and Meta, AI is very capable in more ways than one. Not all of those ways are comfortable for people in the cybersecurity space.

Microsoft’s answer is a coordinated team of agents. Six at launch. One red, four blue, one green.

• The Recon Agent scouts like an attacker: attack paths, choke points, valuable assets, excess permissions. Read-only, and Azure only.

• The blue bench carries most of the load. Triage decides whether an alert is real. Threat Intelligence pulls TTPs and IOCs out of an article. Attack Investigation rebuilds the story behind an incident. Detection Authoring writes the KQL to close the gap it finds.

• Green has exactly one agent: Posture Prioritization, which ranks findings by exploitability, internet reachability and asset criticality.

Six playbooks chain them. The one worth studying is Protect against a threat: it takes a threat intelligence source, runs Threat Intelligence, then Recon, then Posture Prioritization, then Detection Authoring, and feeds each agent’s output into the next.

That is the interesting bit, not the individual agents. It’s the workflow. Microsoft is not just putting Copilot-shaped helpers next to analysts. It is turning security work into an orchestrated chain where one agent’s output becomes another agent’s input. That is the product move. However, the chain still stops before the system changes.

Microsoft’s own language around Project Perception points at a closed-loop system. Red agents expose risk. Blue agents investigate. Green agents remediate and harden. Findings are supposed to become fixes without a hand-off at every step.

That is the right ambition. But a finding only becomes a fix when something changes.

A detection rule changes. A Conditional Access policy changes. A Defender configuration changes. A vulnerable library gets patched. A secret gets rotated. An infrastructure-as-code file changes. A pull request appears.

Today, the most visible green capability is posture prioritization. Useful, and a genuine improvement on a flat vulnerability list. But prioritization is not remediation. Ranking the queue does not empty the queue. Explaining why something matters does not change the system that made it matter.

That is where this really becomes interesting. Project Perception is not interesting because Microsoft shipped security agents; it is interesting that Microsoft is quietly moving security from finding problems to changing systems.

The color codes are worth getting right, because Microsoft picked three of them and the choice tells you something.

• Red is not preventive. That’s the most common misreading. Red simulates a real adversary. Traditional pen testers aren’t there to find every hole, they’re there to prove they can get in and stay under the radar. Usually the SOC doesn’t know they’re coming, and that’s the whole point. If you announce the test, you’re telling someone you’ll be round on Tuesday to check on them. They will ensure everything is tip-top on Monday. You learn less than you think.

• Blue is detection, monitoring and response. The SOC-team. An alert arrives, someone goes and checks whether it’s real, reconstructs the story and decides what to do next. Blue is reactive by design and that isn’t a criticism, it’s the job description.

• Yellow is the builders. Developers, architects, engineers. They write the code and build the systems that red attacks and blue defends. April C. Wright added yellow to the wheel at Black Hat in 2017, in a paper called Orange Is the New Purple, because red and blue had spent a decade arguing with each other while nobody talked to the people writing the code. Yellow usually gets left out of the conversation. In most organizations they’re just called the DevOps team.

• Purple is red and blue working together. Red runs an attack while blue watches whether the detections they built actually fire. Purple is about running the variations until the detection holds across all of them.

• Green makes sure it doesn’t happen again. Not the incident report, not the risk memo and certainly not the “lessons learned“ slide with 4 owners and no due dates. The removal of the thing that caused the incident. Patching the software, chaging the pipeline. Fixing the configuration. Improving error handling. Removing the identity path. Closing the route that made the attack possible.

The mixing works like paint. Red and blue give purple. Blue and yellow give green. Red and yellow give orange. Some versions add white for oversight.

I’m not colorblind, but you can go blind staring at that wheel. What matters is the one relationship: green = blue + yellow.

Green sits on the seam between the SOC and the software engineers. A real green workflow reads a detection insight and goes back to the code, the pipeline, the architecture. This alert traces to a vulnerable library. This one traces to an over-permissive managed identity. Error handling that was never written, which is why the buffer overflows. An internet-facing management place that should not exist in the first place. Green removes the problem instead of reporting the incident.

That only works when the SOC actually collaborates with real software engineers. In practice, red and blue are well established, purple happens where organizations are mature enough to run it, yellow exists but stays outside the security conversation, and green seems to be very rare.

Purple is missing from the naming but present in the product. The documented workflow runs blue, then red, then green, then blue again, with findings moving between them automatically. That is purple teaming in product form. Microsoft built it and didn’t use the word, which I suspect is deliberate, because the term carries a lot of history in enterprise SOC conversations.

Green is in the naming but can’t reach far enough yet.

Posture prioritization ranks findings and explains what to fix first and why. That matters a lot, a security teams drown in technically valid findings with no serious prioritization model. A ranked list based on exploitability, reachability and asset criticality is a better operating model than “critical CVEs first” and “who shouted loudest this week”.

Posture prioritization is a genuine improvement on a flat vulnerability list. But it never touches source, pipelines or artifacts, and it can’t, because there’s no yellow agent on the other side of the seam. Microsoft named the color correctly and shipped half of it. In a system built to close the loop from finding to fix, the loop stops at the edge of the codebase.

We’ve covered the basics of Project Perception whilst in Public preview. Looking ahead, I don’t think we’re seeing the full product yet. Let’s call it a prediction from my end, and we’ll see whether it holds.

Green can’t be finished from inside the Defender portal. The fix often lives elsewhere. a repository, pipeline, policy, configuration file, etc. That means Perception needs a code and configuration surface:

• a connector to GitHub and Azure DevOps

• an agent that reads a finding and proposes a change,

• a playbook that runs the whole chain from threat intelligence through to a remediation artifact or a pull request.

• a human approval gate before impact

I expect that to arrive, and sooner than the preview status suggests, and there are at least four things point that way.

1. The product language already assumes actuators. Microsoft’s own Project Perception material talks about actuators: the mechanism an agent uses to act on its environment, turning a decision into a real-world effect, not just a recommendation. An actuator is not a dashboard, it’s the thing that changes something: detection rule, Defender setting, CA policy, rotated credential, pull request. The architecture already points beyond mere analysis.

2. The models point that way. Perception runs a multi-model architecture, and Microsoft put MAI-Cyber-1-Flash, its first purpose-built cyber model, into the stack. To my knowledge that model is a security fine-tune of MAI-Code-1-Flash, which Microsoft describes on its own model page as “built into GitHub Copilot and VS Code” If the cyber model and the coding model come from the same family, the security work and the development toolchain are already converging one layer below the product.

3. The actuator already exists. The Microsoft Defender for Cloud and GitHub Code Security integration went generally available at Build 2026. Code vulnerabilities get enriched with production signals, and developers remediate through GitHub Copilot Autofix and the Copilot cloud agent, which generate, assign and validate the fix. Microsoft doesn’t need to build the hands. It needs to connect the ones it has to the agents that now do the reasoning.

4. And the output format demands it. A finding that ends in a pull request is worth more than a finding that ends in a markdown report, because one of them changes the system and the other one changes a document. Perception’s whole argument is that a finding should become a fix without a hand-off at every step. Right now the last hand-off is the biggest one: from the SOC to the engineering backlog, where security findings go to age.

Watch the playbooks for the signal. They’re Microsoft-managed and read-only, so you can’t build this yourself and you won’t have to guess when it lands. The day a playbook appears that takes a threat intelligence source and ends in a branch, green is real.

At that point you don’t have a DevOps team any more. You have a DevSecOps team, and this time the security half of the name is doing actual work rather than attending the sprint review. Same threat intelligence input, two ways to act on it: Detection Authoring writes KQL for a technique while a yellow agent patches that technique out of the code. That’s the first genuinely new operating model I’ve seen proposed for this, and it’s why I read Perception as inevitable rather than optional.

The Pull request is probably not the end-state, but the easiest one to see. I recon, that green agents will not stop at code. Pull requests are the developer-facing version of a larger pattern: infrastructure-as-remediation, policy-as-remediation, configuration-as-remediation and workflow-as-remediation.

Now the part closest to my own work, and the part I think is least finished.

A Recon Agent session output is a tenant-specific map of privilege paths, choke points and lateral movement options. It arrives in the Outputs panel as a markdown report with a Download button beside it. That file is not just another security path, it’s a machine-generated attack graph for your environment.

Organizations routinely classify customer data, intellectual property and source code. Project Perception introduces another awkward category: machine-generated offensive intelligence. In many environments, an attack-path report is more dangerous than the documents it references.

Sessions are immutable inside Defender, which covers what the agent did, not what happens to the output afterwards. That needs Purview: a label on agent-generated reports, DLP on the download, retention, an Insider Risk indicator on the analyst who exported eleven attack path maps in a week and then resigned. To my knowledge none of it is wired end-to-end yet, and I’d like to be wrong. Security Copilot already flows into the unified audit log and DSPM for AI, so the precedent exists. Work IQ also leans heavily on permission-aware governance, observability, runtime policy and tenant boundaries. The direction of travel is clear. The specific Perception-to-Purview control plane is the part I would watch.

The more interesting integration runs the other way. Posture Prioritization ranks by exploitability, reachability and asset criticality, and asset criticality is an infrastructure answer. A storage account holding classified customer records and one holding build logs are identical infrastructure and completely different risk. Join Purview classification into Perception’s context layer and green stops ranking by blast radius and starts ranking by consequence.

Microsoft has proved the pattern elsewhere. The Defender for Cloud and GitHub Code Security integration already enriches code findings with data sensitivity. That signal reaches a pull request, not the posture agent a few menu items away in the same portal.

One observation that’s small alone and adds up. The Perception session experience looks and behaves like Microsoft 365 Copilot Cowork. A conversation feed carrying progress updates. Completion markers reading Done in 4 min. An agent counter showing 4/4. An Inputs panel. An Outputs panel with downloadable files. A box at the bottom labeled Ask about this session.

Are we looking at the beginnings of a “Super App” for Cybersecurity Satya Nadella referred to during the Q4 FY2026 earnings call? Maybe not exactly; as this was more or less focused on Microsoft 365 Copilot, but the idea is there.

Some versions of the wheel carry a fourth designation. Mix all colors together, and you’ll get: white; oversight, governance. The people who decide what good looks like and hold the line when the pressure to move faster shows up.

Perception’s whole safety story rests there. High-impact actions pause at an approval gate. Humans review, approve, reject or redirect. Strategy stays with people, scale goes to the agents. I agree with that design. It’s close to what I argued on stage in June: AI-led, human-owned.

But an approval gate is only a control while someone exercises judgment at it. Six agents running coordinated playbooks across your estate will produce approval requests faster than a person reads them, and anyone who has run a SOC knows what happens to a queue that outpaces its reviewers. The failure mode isn’t a rogue agent. It’s a tired analyst approving the fourteenth request of the night because the first thirteen were fine.

We’ve all read that some AI models are escaping their sandbox during cyber evaluation, chained a zero-day into internet access, moved laterally across clusters and (b)reached 3rd party system, all to steal the answer key to the benchmark they were being scored on. Nobody drove it. Those models weren’t malicious either. They were given an objective and pursued it past every boundary someone had assumed was holding.

Your approval gate is a boundary someone assumed was holding.

Microsoft can ship red, blue, green and eventually yellow. White is the one you staff yourself, and it’s the one that decides whether any of this holds.