Microsoft’s emerging agentic security model changes the role of artificial intelligence in the Security Operations Centre (SOC). AI is no longer limited to summarising incidents or helping analysts interpret information. Through Project Perception, currently described as a preview capability, Microsoft is exploring specialised agents that can participate in connected workflows across exposure discovery, investigation, remediation and security hardening.
Human involvement remains central, but ‘human in the loop’ is not a sufficient operating model. The phrase confirms that someone participates in the process. It does not define who has authority, what evidence they must review, which actions require approval or who remains accountable for the outcome.
For an agentic SOC to operate responsibly, organisations need to turn human involvement into explicit objectives, permissions, decision rights and review requirements.
How Do Microsoft ISOC & Project Perception Fit Together?
Microsoft’s Integrated Security Operations Center (ISOC) is the operational foundation within Microsoft Defender for connecting security signals, context, investigations, workflows and protection controls. It is intended to give analysts and agents a shared environment in which they can see, understand and act across the security estate. CyberOne’s Microsoft ISOC explainer examines this relationship in greater detail.
Microsoft describes this foundation through connected elements. Sensors and signals create awareness, context turns those signals into understanding and actuators translate decisions into protective action. The aim is to create an integrated protection loop rather than a series of disconnected technical handovers.
Project Perception provides the specialised agentic capabilities operating across that foundation. Red agents examine the environment from an attacker-oriented perspective. Blue agents investigate threats and assemble evidence. Green agents support remediation and security hardening. Microsoft describes these agents as working through coordinated workflows, allowing information to move between activities without requiring a manual handover at every stage.
The distinction matters. ISOC provides connected signals, context and controls. Project Perception provides specialised agents, reasoning and orchestration. The organisational SOC still provides authority, business judgement and accountability.
ISOC is not a managed SOC service and does not replace the organisational capability around it. An organisation or its security partner remains responsible for operating and governing the environment.
Where Does Human Oversight Fit in an Agentic SOC?
Microsoft’s model gives agents more responsibility for continuous analysis and preparation while people set objectives, apply judgement and define acceptable outcomes. Approval gates remain relevant when an action could create significant operational, security or business consequences.
Oversight should not be reduced to a person approving a recommendation at the end of an automated process. It starts before an agent begins work.
Security leaders must decide which environments an agent may access, which data and controls it may use and what outcome it is authorised to pursue. They must also determine whether the agent may observe and recommend only, prepare a change for review or execute a defined action under approved policy. This requires organisations to address the wider identity, permission and security risks created by AI agents, rather than treating approval as an isolated control.
The practitioner’s role then changes as work moves through the system. Instead of repeatedly rebuilding context across separate tools, analysts can focus more of their attention on testing evidence, interpreting business consequences and handling exceptions. The quality of oversight should therefore be measured by the clarity of human authority, not by the number of manual handovers retained in a workflow.
How Should Humans Oversee Red, Blue & Green Agents?
Each Project Perception agent performs a different form of security work. The appropriate control point changes with the activity.
Red Agents: Define the Scope
Microsoft describes red agents as examining the environment from an attacker’s perspective to expose weaknesses, attack paths or defensive gaps.
Oversight should establish where that activity is permitted, which systems are excluded and what permissions the agent receives. Practitioners must then validate the finding and interpret its significance.
A weakness affecting an isolated test system does not carry the same consequence as one affecting a privileged identity or critical service. The agent can expose the weakness, but the organisation must decide what it means for the wider risk posture.
Blue Agents: Challenge the Evidence
Blue agents investigate threats by connecting relevant signals and assembling context to support a response.
A well-presented investigation is not automatically a defensible decision. Analysts still need to ask whether evidence is missing, whether contradictory signals exist and which identities, assets or services could be affected. They must determine whether the proposed response is proportionate to both the threat and the potential operational impact.
The blue agent may assemble the case. A practitioner must decide whether the evidence is strong enough to justify consequential action.
Green Agents: Control Consequential Change
Green agents support remediation and security hardening. Their work can become operationally significant when a proposed response would change systems, access or security controls.
Organisations should distinguish between three levels of involvement:
- Recommend: The agent proposes a response.
- Prepare: The agent stages or specifies the proposed change.
- Execute: An authorised change is applied.
This is a CyberOne governance distinction, not a workflow that Microsoft formally prescribes for Project Perception. It prevents an agent’s ability to formulate a technically valid action from being mistaken for authority to perform it.
What Is a High-Impact Security Action?
Microsoft states that high-impact Project Perception actions remain subject to human approval. Its public overview does not provide a universal approval matrix covering every organisation, environment or security action.
Each organisation therefore needs to define impact within its own operating model. Relevant factors include:
- Whether the action affects privileged access
- Whether it changes a production system
- Whether it could interrupt a critical service
- How many identities or assets are affected
- Whether sensitive data is involved
- Whether the action can be reversed safely
- Whether the available evidence is current and complete
Approval should become stronger as consequence increases, scope widens or reversibility decreases. Confidence in an AI recommendation should not override these considerations. The same principle already applies to human-led incident response, where pre-agreed containment authority allows organisations to define response boundaries before the pressure of a live incident.
A high-confidence action can still be wrong for the business. Containing a system may be technically justified while creating unacceptable disruption to a critical operational service. That context may not be visible from security telemetry alone.
A Six-Stage Authority Model for Human Oversight
CyberOne’s proposed interpretation divides agentic security work into six authority stages:
Observe → Recommend → Prepare → Approve → Execute → Review
At Observe, the agent accesses authorised signals without changing the environment. Humans define its identity, data scope and permitted purpose.
At Recommend, the agent proposes an investigation or response. Practitioners inspect the evidence, assumptions and potential consequences.
At Prepare, the agent makes the proposed intervention specific enough to review. This may include identifying affected assets, defining the intended scope or setting out the conditions for execution. Preparation separates intelligence from authority.
At Approve, an authorised person decides whether the action may proceed. Approval should identify what was authorised, for which assets and within what limits.
At Execute, a human, automation or agent performs only the authorised action.
At Review, the organisation confirms what occurred, whether the threat was reduced and whether legitimate activity was disrupted. This stage turns execution into an accountable security outcome.
Can Security Agents Act Without Immediate Human Approval?
Not every security activity needs approval on every occasion. Requiring a person to approve each low-impact step could undermine the speed and continuity that agentic security is intended to provide.
A useful distinction is between human-approved and policy-approved action. Human-approved action requires a person to authorise each instance. Policy-approved action operates under conditions that authorised people have defined in advance.
Policy-approved autonomy may be appropriate when an action is narrow, observable, reversible and fully logged. Actions affecting privileged identities, production services or broad control boundaries require greater scrutiny. Organisations must also ensure an agent’s permissions do not create excessive agency, where its capabilities or access extend beyond the purpose it was authorised to fulfil.
Bounded autonomy does not remove human authority. It moves part of that authority into the prior design of policy, including the conditions under which the agent must stop and escalate.
Human Judgement Becomes More Important, Not Less
A connected agentic SOC can reduce manual investigation, but it cannot decide which outcomes matter or who is accountable when an action goes wrong.
Whether operating an internal SOC or using MXDR as a Service, organisations must define where agent authority begins, where approval remains necessary and how consequential actions are reviewed.
Book an agentic SOC readiness conversation to understand how your Microsoft security environment and operating model should evolve.
