Security Copilot has been a recurring topic in many of the Microsoft 365 and Azure tenants I work with, particularly since early 2024. Its actual impact has stayed modest, though. Most teams use it as a chat assistant or for the occasional ad-hoc analysis, and it rarely shows up in the day-to-day workflows of SOC, identity or compliance teams. That is why Microsoft's announcement of Security Copilot agents on March 24, 2025 caught my attention. Now we are talking about automating real tasks: phishing triage in Defender, Conditional Access optimization in Entra, vulnerability remediation in Intune and even alert triage in Purview. I find this appealing, but it immediately raises questions about permissions, billing and, most of all, human oversight (Microsoft's announcement).

Security Copilot agents target the routine work that eats up team capacity

In most SOCs and security admin teams, a large share of the day still goes to repetitive work. Reviewing phishing reports, prioritizing alerts, tuning policies and sorting through vulnerabilities all take time and attention. The agents are aimed squarely at this kind of work, and they run directly inside each portal. Phishing triage happens in the Defender portal, Conditional Access optimization in the Entra admin center, remediation workflows in Intune and insider risk triage in Purview (agent overview).

In my projects, the limiting factor is rarely know-how. It is usually plain capacity. If agents can triage, summarize and suggest workable next steps reliably, that would make a real difference. For this to work, though, they have to fit into the escalation and approval processes a team already has instead of going around them.

Agents get their own identities, permissions and SCU billing in the preview

Microsoft has been clear on one point. Security Copilot agents have their own identities and role assignments, and they appear in the RBAC of whichever platform they work in, so Entra roles, Defender roles or Intune RBAC (details). For governance this matters a lot. You can (and should) give each agent only the permissions it needs for its task rather than broad admin rights. In the current preview, agents don't need full Global Admin and only request the specific permissions they require. Still, check this carefully in your pilot.

There is also a cost side. Agents consume Security Compute Units (SCUs), just like the standard Copilot features. Once you run several agents, that affects both cost and capacity planning, so include it in your planning from the start.

The following flowchart shows a typical agent workflow, including the human review step:

flowchart TD
  User["Security admin"] --> Agent["Security Copilot agent"]
  Agent --> Platform["Defender / Entra / Intune / Purview"]
  Platform --> Action["Agent recommends action"]
  Action --> Approval["Human reviews and approves"]
  Approval --> Execution["Action is carried out"]

Figure: Security Copilot agent workflow with a mandatory human review step

The diagram makes the point well. Automation helps, but it doesn't replace judgment. Someone still has to stay in control, especially when an action changes a production environment.

Human oversight stays mandatory for every material agent action

Both the documentation and the announcement describe Copilot agents as assistants, not decision-makers. Any material step, such as blocking a user, changing a policy or fixing a vulnerability, requires explicit human review and approval by default. In a real environment that review can't become a formality. If you pilot agents, define clear workflows for reviewing proposals, documenting decisions and escalating. With security and compliance tasks, keep agents under tight control so they don't trigger accidental or unwanted automated actions. In early pilots I always give the same advice: keep agent permissions separate, require human approval and make every step auditable.

Practical tip: Give agents only the minimal, task-specific roles they need and never blanket Global Admin. That limits risk, makes troubleshooting easier and gives you much clearer audit trails.

These five areas deserve testing first during the preview (April 2025)

Agents roll out in public preview from April 2025, and I would not move them into production straight away. Work in pilot tenants and go about it systematically. These are the five things I check first:

  • What permissions do agents actually request (and are they documented and reasonable)?
  • Are agent actions clearly logged (in the Defender portal, Entra audit logs, etc.)?
  • How accurate and explainable are the agent's recommendations, and are there false positives or odd logic?
  • Is human approval flexible (manual, multi-stage, more than one reviewer)?
  • What's the real SCU usage and billing impact with agents enabled?

Auditability is not optional. Anyone who has worked with Defender XDR knows that automations can make changes in the background that are hard to trace afterwards. Make agent activity as transparent as you can right from the beginning.

In the Defender portal → Hunting → Advanced hunting (with the right licensing and device events enabled), this KQL query shows Copilot agent activity:

DeviceEvents
| where InitiatingProcessAccountName contains "CopilotAgent"
| project Timestamp, DeviceName, ActionType, InitiatingProcessAccountName, ReportId

I would pilot the agents carefully and keep control throughout

Security Copilot agents are a logical next step in Microsoft's ecosystem, but you can't just switch them on and walk away. With the preview starting in April 2025, admins get a chance to test automation where security is most sensitive. SCUs and licenses alone won't be enough, though. You also need fine-grained permissions, human approval that can't be skipped and audit trails you can follow end to end. My recommendation is to start with a proof of concept, adjust your policies and workflows, and measure the costs before you scale. If you take the pilot seriously now, you stay in control as agents move from preview into the core of SOC, compliance and identity operations.