Project Perception's Load-Bearing Word Is "Actuator," Not "Agent"

Microsoft's red, blue, and green security agents entered public preview on August 3. The design decision worth reading twice is that a finding becomes a fix without a hand-off at every step.

Two sentences sit on the same Microsoft product page, about four scrolls apart.

The first: "Reactive security is over. Project Perception defends at machine speed, autonomously."

The second: "Defenders set the objectives and guardrails, and every high-impact action stays under human sign-off."

Both are true at once, and the space between them is the entire product. Everything that matters about Project Perception lives in how Microsoft draws the line between an action that needs a human and an action that does not, and that line is not on the page.

Three roles, and the hand-off that got deleted

Perception, announced July 27 alongside Microsoft's first security-specialized model and now in public preview, splits security work across three classes of agents. Red agents probe like an attacker and search for paths into your environment. Blue agents investigate activity and decide whether it represents real risk. Green agents apply corrective actions and harden defenses.

That much reads like an org chart, and org charts are not interesting. This sentence is:

Red agents probe like an attacker, blue agents investigate like your best responder, and green agents remediate and harden, sharing intelligence through orchestrated workflows so a finding becomes a fix, proactively, without a hand-off at every step.

Read the last clause again. The three agents "hand off to each other automatically," per Microsoft's own description of them.

The security tooling most teams run today has a human wedged into the middle by construction. A scanner produces a finding. A person reads it, decides it is real, and opens a ticket. Someone else writes the change. The latency everyone complains about is also, accidentally, the review step.

Perception removes that middle and keeps humans at the two ends: strategy at the front, sign-off on high-impact actions at the back. That is a defensible design. It is also a completely different risk profile, and the word that gives it away is not "agent."

Actuators

Microsoft lists six building blocks inside Perception: agents, models, context, signals and sensors, a harness, and actuators. Five of those are familiar. The sixth is defined like this:

The mechanism an agent uses to act on its environment, turning a decision into a real-world effect, not just a recommendation.

That is the whole thing in one line. A recommendation is a claim about your environment. An effect is a change to it. Every security product of the last decade shipped recommendations, and the reason nobody had to think very hard about the false-positive rate of a red-team tool is that a false positive cost an analyst an hour.

Wire red directly to green through an actuator and the cost function changes. Red's output is a hypothesis about how an attacker could move. Green's output is a modification to production. If the hand-off between them is automatic, a wrong hypothesis becomes a real config change, and the thing that used to absorb the error (a person reading the finding and saying "no") is the thing that got optimized away.

I want to be fair about what Microsoft did put in. Perception is not a machine with no brakes. High-impact actions stay under human sign-off. Decisions are described as scoped, traceable, and replayable. Pricing is consumption-based in Security Compute Units, which means agent activity shows up as a number on a bill rather than as invisible background work, and different agents burn SCUs at different rates depending on task intensity. At launch, it runs inside Microsoft Defender rather than everywhere at once.

Those are real controls. They just all depend on one definition that the public material does not give you: what counts as high-impact, and who gets to change it.

The question is the threshold, not the technology

I keep coming back to the fact that "high-impact" is doing enormous work in that sentence and is nowhere defined publicly. In a large tenant the space of actions a green agent could take is enormous, and the interesting ones are not obviously high-impact by any simple rule.

Is revoking one session token high-impact? Is adding an IP to a block list? Is tightening a conditional access policy that happens to be the one your field sales team depends on? Is quarantining a host that turns out to be the domain controller for a satellite office nobody documented?

Every one of those is defensible as routine and defensible as high-impact, and which bucket it lands in decides whether a machine does it at 3 a.m. or a human sees it first. That threshold, not the model quality and not the agent architecture, is the actual security control.

There is a second question stacked on it. In most enterprise products, a setting like that is configurable, which means somebody in your organization can move it, which means it belongs in change management alongside firewall rules. If it is not configurable, you are accepting a vendor's judgment about your environment. Both answers are workable. Not knowing which one you have is not.

Put this into practice

You do not need preview access to start on any of this, and most of it is worth doing whether or not you ever buy the product.

Write your own high-impact list first. Before you evaluate any vendor's threshold, write down what would need a human in your environment. Be specific and concrete: anything touching conditional access, anything that disables or modifies an identity, anything that changes a network boundary, anything that touches a system on your critical-path inventory. One page. This takes an afternoon and it is the artifact you will compare every vendor default against.

Turn on red only, for the first month. Findings without actuators is a report, and a report is a safe way to learn what the system thinks about your environment. You will also learn the false-positive rate before that rate can cost you a change. If the product does not let you run one agent class without the others, that is worth knowing on day one.

Exercise the replay before you trust the loop. Microsoft says decisions are traceable and replayable. Pick one closed red-to-green sequence and try to reconstruct it end to end: what red found, why blue rated it real, what green changed. If you cannot answer all three from the logs, the loop is running faster than your ability to audit it, and that gap will not close by itself.

Meter SCUs like a token budget. Consumption pricing means a noisy red agent is a real invoice. Set the alarm before the bill teaches you the lesson. Anyone who has watched an agent loop run unattended over a weekend knows this is not a hypothetical.

Ask three questions of every vendor in this category. Where exactly is the hand-off between finding and fix? What is the published definition of a high-impact action? Who in my organization can move that line, and does moving it leave a record? Perception is the most visible product asking these questions of its buyers right now, and it will not be the last.

Where this is thin

I have not run Project Perception. It went into public preview today, and outside of preview customers nobody has operational experience with it. Everything above comes from Microsoft's own product page and announcement, which are marketing surfaces, not specifications. Read them that way.

The absence of a public definition of "high-impact" does not mean the product lacks one. Admin documentation is usually far more specific than a landing page, and I would expect the preview docs to name the categories. My argument is about what a buyer can see before signing, and that is a narrower complaint than it might read as.

Preview scope is genuinely limited. Perception ships into Defender first and extends across Microsoft Security products "over time," which is vendor language for unscheduled. If your detection and response lives elsewhere, none of this is available to you yet.

The page itself is not internally consistent. The overview names MAI-Cyber-1-Flash; the FAQ names MAI-Cyber-1. That is trivial on its own and it is a reminder that a launch page is a marketing artifact assembled by several teams, not a contract.

And the benchmark figures floating around this launch deserve the caveat they always deserve: they are vendor-measured, and in agentic security the number usually belongs to the harness, the routing policy, and the proprietary data history rather than to the model in the headline. Microsoft has been fairly direct about that in its own technical writing. Treat any single-number model comparison in this space as a starting point for questions.

There is also an argument on the other side that I take seriously. Attackers are already running agent loops with no approval step, no sign-off, and no change-management board. A defender who insists on a human in the middle of every action is choosing to be slower than the threat on purpose. That is a real cost, and "add more human review" is not a free answer. My position is that the threshold is where the argument should happen, out loud and in writing, rather than being settled by a default nobody read.

What to do this week

Write the high-impact list. It costs an afternoon, it does not depend on any vendor, and it converts a vague worry about autonomous remediation into a document you can hold a product against.

Then go find where your current tooling already acts without asking. Most teams have more of that than they think: auto-quarantine rules, auto-disable policies, EDR responses that fire on a signature. Perception is not introducing automatic action to your environment. It is making the boundary explicit and putting a reasoning model behind it, which is exactly the moment to check where that boundary sits.

Sources: Project Perception, Microsoft Security, Rethinking security for the age of AI, Official Microsoft Blog, Microsoft launches its first cyber model and a new agentic cybersecurity system, TechCrunch.