Topic starter
30/07/2026 10:51 pm
TL;DR: Project Perception reframes security around validated remediation, with red, blue and green agents aligned to find, assess and fix issues across a six-layer stack, according to Senserva’s analysis of Microsoft’s Rethinking security for the age of AI. The shift matters because alert volume without governed corrective action keeps producing backlog instead of resilience.
Editorial analysis by NHI Mgmt Group, based on content published by Senserva: “Red, Blue, and Green: Microsoft Just Named the Job”.
Key questions
Q: How should security teams balance automation and governance in remediation?
A: Use automation for enrichment, routing, approvals and validation, but keep humans in the loop for high-risk changes.
Q: Why does joined context matter more than alert volume?
A: Because remediation decisions depend on how configuration, posture, and activity relate to one another.
Q: What breaks when patch remediation is run as ticket-by-ticket work?
A: Ticket-by-ticket handling breaks when one exposure generates many alerts, because teams end up managing volume instead of fixing the cause.
Practitioner guidance
- Define remediation as a governed security workflow Assign ownership, approval, and verification to corrective actions so fixes are not handed off into an unmanaged ticket queue.
- Join configuration, patch, and log context Correlate identity posture, vulnerability state, and activity signals before allowing an automated fix recommendation to proceed.
- Require evidence of closure Keep the original finding, the applied change, and the post-fix validation together so auditors can trace what changed and why.
Bottom line: The article argues that security teams lose value when they stop at findings and do not own validated remediation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:53 pm
Red and blue are no longer enough to describe mature security operations: the article’s most important contribution is the explicit naming of remediation as a distinct security function. That naming matters because modern programmes have over-invested in discovery and under-invested in closure. Once corrective action is inside the security system, the operational question changes from whether a problem was seen to whether it was actually resolved.
A question worth separating out:
Q: What should teams do when automated fixes can change access or configuration?
A: They should require validation before execution and proof after execution, especially when the action can affect access scope or tenant state. If a system cannot explain what it will change, attribute the change, and roll it back if needed, it is not ready for autonomous remediation.
👉 Read our full editorial: Project Perception shifts security from findings to remediation