Red, Blue, Green, and Who Can Change Production?

Autonomous remediation shortens the interval between finding a weakness and changing production. It also shortens the time available to catch a bad premise.

Microsoft’s Project Perception coordinates red agents that identify paths to compromise, blue agents that investigate and decide what represents meaningful risk, and green agents that take corrective action. Microsoft describes the result as a closed loop that discovers, evaluates, and improves security posture. Public preview began on August 3.

That architecture is interesting, but the colors are not the control model.

The important questions are familiar deployment questions. Which identity can recommend a change? Which identity can approve it? Which one can touch production? What evidence crosses each handoff? Can a compromised discovery agent influence the remediation path? Who verifies that the change reduced risk without breaking something else?

A green agent is not just another chatbot. Once it can modify code, policy, identity, network, or production configuration, it is part of a privileged deployment pipeline.

The new boundary is the handoff

Project Perception is built around shared context and several specialized agents. Microsoft says its stack combines sensors, security context, models, a coordinating harness, agents, and actuators that translate decisions into protection.

Each handoff can improve the result. Each also creates a place where authority, evidence, and uncertainty can become confused.

A red agent may find a credible attack path using a test identity. A blue agent may raise its priority after joining asset importance, exposure, and threat context. A green agent may propose a firewall change, identity restriction, patch, or configuration update. An actuator may then apply it through a product API.

The finding changes form as it moves:

observation -> exploit evidence -> risk decision -> change proposal -> deployment -> validation

If those stages exchange only prose, the system loses important facts. The green agent may receive a confident summary without the conditions that made the exploit possible. An approver may see a patch without knowing which model produced it or which tests failed. A validator may repeat the same reasoning error as the agent that proposed the fix.

The handoff needs a structured evidence object.

Pass evidence, not confidence

I would require every finding to carry a signed, immutable record that grows as it moves through the loop.

At minimum, it should include:

• a stable finding and correlation ID;
• asset, owner, environment, and data classification;
• the red agent’s model, version, prompt or task template, tools, and run ID;
• the exact observation and reproducible test steps;
• raw evidence locations and integrity hashes;
• the identity and permissions used during discovery;
• affected versions and environmental preconditions;
• uncertainty, failed attempts, and competing explanations;
• the blue agent’s risk decision and policy inputs;
• the proposed change, code or configuration diff, and expected effect;
• tests, safety checks, blast-radius estimate, and rollback plan;
• approval records and policy decisions;
• deployment identity, target, timestamp, and result;
• independent post-change validation.

The object should be append-only. A later agent can add an assessment or proposal but should not rewrite the original evidence. Each transition should identify the principal, policy, and evidence digest used to make the decision.

This makes disagreements visible. If the blue agent changes severity, the record shows why. If the green agent proposes a broad change for a narrow finding, policy can compare the requested scope with the affected asset. If validation fails, responders can reconstruct the complete path without relying on a generated narrative.

Confidence scores can still be recorded. They should not substitute for evidence or authorization.

Separate discovery, decision, execution, and validation

Agent separation is useful only if the identities and permissions are separated too.

I would use at least four runtime identities:

Role	Allowed authority	Explicitly denied
Discovery	Read approved context, run scoped tests, create findings	Production changes, approval, broad credential access
Decision	Read findings and business context, assign risk, request remediation	Direct production writes, rewriting source evidence
Execution	Apply one approved change to named targets	Expanding scope, self-approval, arbitrary discovery
Validation	Test the deployed state and record outcome	Modifying the change being evaluated

The human roles should follow the same principle for higher-risk changes. The person who owns the service may approve a patch. The platform owner may approve a network or identity change. An emergency path may allow faster action, but it should be named, time-limited, and reviewed afterward.

Using separate agents with one shared overprivileged service principal does not create separation of duties. It creates several reasoning paths behind one credential.

The runtime should also distinguish delegated user authority from application authority. A green agent acting on behalf of an analyst should not silently inherit every permission the analyst has. It should receive a short-lived token scoped to one approved action and target.

Put deterministic policy in front of every actuator

Microsoft describes actuators as the layer that connects insight to action across security products. This is where model recommendations become effects, so it deserves the strongest guardrails.

The policy decision should not ask the same model whether its own action is safe. It should evaluate concrete attributes:

• Is the finding still open and within its validity period?
• Does the evidence digest match the approved proposal?
• Is the target in the approved environment and ownership scope?
• Is this action type allowed for this agent and risk tier?
• Does the change stay within its file, resource, identity, or network boundary?
• Are required tests and human approvals present?
• Is the rollback action defined and permitted?
• Is the current production state the same state against which the proposal was tested?
• Is a change freeze or incident override active?

The result should be allow, deny, or require additional approval. The policy version and inputs should be recorded with the deployment.

This is the same design principle I am testing with Foundry Citadel governance: move consequential rules out of prompts and into enforcement points that can reject an action regardless of which model requested it.

Cap the green agent’s blast radius

Autonomous remediation does not have to begin with unrestricted production writes.

A sensible progression is:

1. Recommend: produce a change and evidence package, but do not apply it.
2. Open a review: create a pull request or change request in a restricted repository.
3. Deploy to a disposable environment: apply the change and run tests against representative state.
4. Canary: change one low-risk target with automatic rollback.
5. Scoped production: apply approved classes of reversible change within narrow boundaries.
6. Emergency containment: use preauthorized actions such as disabling one credential or isolating one workload.

Each level should have its own identity and policy. Success at one level does not automatically authorize the next.

Some actions are easier to automate safely than others. Revoking one short-lived token, disabling a compromised account, or isolating one endpoint can be narrow and reversible. Changing a shared network route, rotating a widely used secret, modifying an authorization policy, or patching a core library can have a large and hard-to-predict blast radius.

The green agent’s maximum authority should be based on action class and target criticality, not on a general label such as “remediation agent.”

Rollback is part of the proposal

A remediation is incomplete without a recovery path.

Before an actuator receives production authority, the evidence object should state:

• the prior known-good state;
• how the new state will be applied;
• the signals that indicate success;
• the signals that trigger rollback;
• the rollback command or deployment artifact;
• the maximum observation window;
• the owner who receives control if automation stops.

The rollback should be tested in the same environment used to test the forward change. It should not require the green agent to improvise while production is failing.

Code changes fit naturally into version control. Identity, network, SaaS, and security-product changes need equivalent state capture. If the platform cannot reconstruct the previous policy or configuration, “reversible” is only an aspiration.

Emergency containment is a special case. The safest automated response may intentionally reduce availability to stop active harm. That exception should still have a defined scope, expiration, notification path, and recovery procedure.

Validation must be independent

The agent that produced a fix has already committed to an explanation of the problem. Asking it to validate its own work risks repeating the same blind spot.

Independent validation should vary at least one of the following:

• model or model family;
• task template;
• tools and data source;
• test implementation;
• runtime identity;
• team or human reviewer.

The validator should rerun the exploit condition, check for regressions, inspect the deployed state, and confirm that the change did not create a new path. For high-risk changes, it should also compare real telemetry after deployment with the assumptions in the proposal.

This does not mean every patch needs a committee. It means the closed loop needs a check that is not merely the green agent saying, “my tests passed.”

Read the benchmark numbers carefully

Microsoft’s MAI-Cyber-1-Flash announcement describes MDASH as a harness containing more than 100 agents that use several models to find, validate, and remediate vulnerabilities. Microsoft reports a 95.95 percent CyberGym score for MAI-Cyber-1-Flash combined with GPT-5.4. It says the smaller cyber model can handle up to 90 percent of tasks, while GPT-5.4 handles the hardest 10 percent, with about 50 percent lower cost than its previous MDASH configuration.

Those are vendor-reported benchmark and cost results. They are useful for forming test questions, not for assuming production performance.

The announcement also lists role-based controls, tenant isolation, encryption, auditability, and sandboxed execution without internet access. Those are relevant platform controls. They do not answer every workload-specific governance question.

For a preview evaluation, I would measure:

• precision and recall by vulnerability class and codebase type;
• reproducibility across repeated runs;
• rate of unsafe or overly broad remediation proposals;
• quality and completeness of evidence handoffs;
• permission actually exercised by each agent;
• false-positive cost for service owners;
• test coverage and regression rate;
• rollback success;
• time from finding to verified remediation;
• complete provenance from model routing through production effect.

Model accuracy is one row in that scorecard. It is not the whole system.

A public-preview test plan

Project Perception’s preview is an opportunity to test the control loop before granting it broad authority.

I would run five exercises:

1. Poison the finding context

Place conflicting or malicious instructions in an artifact the red or blue agent can read. Verify that the agent treats it as evidence, not authority, and that the evidence object preserves its source.

2. Request an excessive fix

Create a narrow issue whose easiest proposed remediation would change a shared policy. Confirm that deterministic policy limits the green agent to the approved asset and demands additional review for broader scope.

3. Change production after approval

Alter the target state after a remediation is approved but before execution. The actuator should detect the stale precondition and stop rather than apply a patch to an environment it did not test.

4. Break the forward change

Make the canary fail and verify automatic rollback, evidence capture, token revocation, and human notification.

5. Compromise one agent identity

Assume the discovery, decision, execution, or validation identity is stolen. Measure what it can do alone. No single identity should be able to manufacture evidence, approve a change, deploy it, and declare success.

These tests produce a much more useful answer than a demo in which an agent finds a seeded bug and opens a clean pull request.

Closed-loop defense still needs open evidence

Microsoft’s red, blue, and green model is a clear way to describe cooperating security agents. It also makes the governance problem visible.

The red agent’s output is not automatically true. The blue agent’s priority is not authorization. The green agent’s patch is not proof of safety. The actuator’s successful API call is not proof of remediation.

Each stage needs a distinct identity, a bounded role, evidence it cannot silently rewrite, and a policy decision appropriate to the effect it can create. Production changes need rollback. The final claim needs independent validation.

That may sound slower than full autonomy. It is still much faster than a manual process when the system automates evidence collection, testing, routing, and low-risk changes. More importantly, it preserves the ability to explain who changed production, on what basis, with which authority, and whether the change actually worked.

That is the standard an autonomous security system should meet before the color green means go.

Sources

• Microsoft: Rethinking security for the age of AI
• Microsoft AI: Introducing MAI-Cyber-1-Flash inside MDASH