Microsoft quietly shipped something significant in early 2026: AI agents embedded directly inside the Intune admin center. Not a chat sidebar, not a button that opens a new portal — actual agents surfaced inside the workflows you already use. If you’ve been waiting to see what Security Copilot actually looks like in endpoint management, this is it.
There are four agents total, though one is on its way out. This article covers what the three remaining agents actually do, how to set them up, what they miss, and whether the SCU spend is worth it. No hype. Just what you need to know before you start clicking “Run.”
Prerequisites and Licensing: The SCU Question
Before anything else, you need Security Compute Units (SCUs) provisioned in your Security Copilot workspace. The agents consume SCUs every time they run. That’s not a caveat buried in the docs. It’s the central cost variable you need to track from day one.
Standalone pricing: $4 per SCU-hour. You pay on demand or pre-provision capacity.
Included with Microsoft 365 E5: Starting with the E5 inclusion rollout (April 20 – June 30, 2026), tenants get 400 SCU per month per 1,000 E5 licenses, capped at 10,000 SCU total. This is rolling out tenant-by-tenant, so you may not see it yet.
Microsoft 365 E7 (Frontier Suite): The new $99/user/month bundle that went GA on May 1, 2026, includes E5, Copilot, Entra Suite, and Agent 365. If your org is on E7, the SCU inclusion is baked in.
If you’re running overage-only SCUs (no pre-provisioned capacity), the workspace spins compute on demand. It’s convenient, but the per-SCU cost is higher than maintaining warm capacity. Watch the SCU usage graph in the Security Copilot portal early in your testing. The meter moves with every agent run.
Setup checklist:
- Provision SCUs via the Security Copilot setup guide
- Assign a Capacity Owner role in Security Copilot
- Configure Owner and Contributor Entra groups
- Review the privacy and data sharing settings. The agents inherit your existing Intune RBAC roles, and Copilot does not bypass Entra ID role assignments.
Once that’s done, navigate to the Agents section in the Intune admin center and select View details on any agent to configure it.
Change Review Agent
Status: Generally Available
The Change Review Agent is designed for one specific workflow: Multi-Admin Approval requests for PowerShell scripts. If your organization uses the MAA feature in Intune to require a second admin to approve scripts before they run, this agent steps in as an additional reviewer.
When you run it, the agent evaluates up to ten pending approval requests at once. It pulls together signals from Defender, Entra ID, and Intune — identity risk, historical approvals, device state — and returns a recommendation: approve, reject, or needs more information.
What it does well: It forces a structured analysis pass on changes that might otherwise get approved based on trust in the requester rather than on the content. The agent adds a layer of accountability to what is often an informal process.
What it doesn’t do (yet): Deep content analysis of the script body. In testing, a PowerShell script containing commands to remove items from C:\Windows came back with a “NeedsMoreInfo” recommendation rather than high-risk. The agent could see the script content, but its evaluation relies on metadata aggregation rather than semantic reasoning over what the code actually does. If you’re expecting it to catch destructive logic in a script the way a code review tool would, that’s not where it is right now.
This behavior appears intentional. The documented design treats “NeedsMoreInfo” as the safe default when critical validation signals are absent or ambiguous. The agent won’t guess. That’s a reasonable position for an early capability, but it means you still need a human who understands PowerShell to make the final call on anything non-trivial.
The improvement path here is clear: stronger script-level risk classification as an evaluation input. Until that ships, treat the Change Review Agent as a signal-aggregation layer, not a code auditor.
Policy Configuration Agent
Status: Generally Available
This agent addresses one of the most painful parts of compliance work: taking a dense security document (NIST 800-53, a STIG, a CIS benchmark) and figuring out which Intune settings actually map to it.
The workflow has two stages. First, you create a Knowledge Source by uploading a document. The agent currently accepts .txt files only, so if your source document is a PDF or JSON policy file, you’ll need to convert it first. Second, you ask the agent to map the requirements from that Knowledge Source to the Intune Settings Catalog and generate a draft policy.
What it does well with: Plain English. When tested with natural language like “Disable Internet Explorer 11 as a standalone browser on all Windows 10 and 11 devices,” the agent extracted requirements correctly, matched them to the right Settings Catalog entries with high confidence scores, and produced a usable draft.
Where it struggles: Structured compliance documents. Feeding the agent a well-formatted but complex STIG policy JSON (renamed to .txt) produced a misleading result: the agent reported a 100% match rate at the summary level, but the Identified Settings section was empty. The classification layer saw the intent; the rendering layer didn’t produce anything actionable. This appears to be a current limitation with how the agent handles highly structured input.
The practical implication: if you’re importing a real compliance baseline, write a clear plain-English description of what you want before uploading the formal document. You’ll get better results. The agent does well when the requirement is stated in human terms.
The policy creation flow works like any other Settings Catalog policy in Intune. The agent populates suggested values with confidence scores, you review each one, remove anything that doesn’t fit your environment, and then kick off the standard policy creation workflow. Nothing is applied automatically.
A few things to calibrate expectations on:
- The agent currently handles well-scoped requirements better than layered, exception-heavy baselines.
- Every run consumes SCUs. For a large compliance document with dozens of controls, that can add up quickly across multiple iterations.
- The output is a draft, not a finished policy. You still need someone who understands the settings to validate the recommendations before deployment.
Vulnerability Remediation Agent
Status: Limited Public Preview
This agent isn’t broadly available yet. Access requires contacting your Microsoft sales team to get into the preview program.
What it’s designed to do: use Microsoft Defender Vulnerability Management data to identify CVEs on managed devices, apply AI-driven risk prioritization, and provide step-by-step remediation guidance directly in the Intune admin center. The goal is to close the gap between Defender’s findings and the actual Intune remediation workflow, removing the need for admins to context-switch between portals to correlate vulnerability data with device configuration.
Based on published documentation, the agent surfaces vulnerabilities by CVE, prioritizes them by risk score, and walks through the specific Intune actions needed to remediate each one. It doesn’t auto-remediate. Admin approval is required before any change goes out.
If you’re trying to get into the preview, sign up at the Intune Agents Feedback Forum. Microsoft has been using that channel to identify participants.
The Device Offboarding Agent Is Gone
Worth mentioning briefly: a fourth agent was available in preview but is being retired. You cannot set it up after April 30, 2026, and it’s removed from the admin center entirely on June 1, 2026.
It was designed to identify stale and duplicated devices across Intune and Entra ID and surface them for cleanup. If you already have it configured, you have until early June to finish using it. After that, it’s gone with no replacement announced yet.
What These Agents Actually Cost in Practice
SCU consumption isn’t huge per-run — but it’s not nothing, and it scales with usage. Running the Policy Configuration Agent on a substantial document, iterating on the Knowledge Source a few times, and then running the Change Review Agent on ten pending approvals in a single session can burn through a meaningful slice of your monthly SCU allocation if you’re on E5 inclusion.
A few guidelines:
Pre-provision SCUs if you plan to use agents regularly. Overage-only pricing is more expensive per unit and can make costs harder to predict.
Monitor the SCU usage dashboard from day one, before any production use. The graph in the Security Copilot portal shows consumption in near-real-time.
Don’t run agents speculatively. Every click of “Run” has a cost. Be intentional about when and why you’re invoking an agent.
Role-scope your access carefully. The agents inherit Intune RBAC. An over-permissioned role won’t break anything, but it means the agent sees more data than it needs to for the task.
Limitations to Keep in Mind
These agents are useful, but they’re early. A few things to carry into any deployment:
Advisory only. None of the agents take autonomous action. Every recommendation goes through admin review and approval. That’s the right design for an endpoint management context, but it means the time savings come from faster analysis, not eliminated steps.
Signal aggregation, not semantic reasoning. The Change Review Agent evaluates metadata and cross-product signals. It doesn’t reason deeply about what a script or policy is actually doing. That gap matters for anything with real security weight.
Plain English beats formal documents in the Policy Configuration Agent today. Structure your inputs accordingly until Microsoft improves the document parsing layer.
SCU availability is still rolling out. If you’re on M365 E5 and not seeing the 400 SCU/month inclusion yet, you’re not behind. The rollout goes through June 30, 2026.
These are not the Entra agents. The naming overlap (Entra has its own “Access Review Agent”) causes real confusion. The Intune agents and the Entra agents are separate, workload-specific assistants. Don’t conflate them.
Where This Is Going
The direction is right. Agents embedded in the workload, surfacing where the work actually happens, with human approval checkpoints built in. That’s a sensible model for bringing AI into endpoint management.
The Change Review Agent is one good iteration away from being genuinely powerful, specifically if Microsoft adds script-body risk classification to the evaluation pipeline. The Policy Configuration Agent already produces value for teams dealing with compliance baselines, once you understand how to feed it. The Vulnerability Remediation Agent, when broadly available, could meaningfully reduce the friction between Defender findings and Intune remediation actions.
For now: set up your SCU capacity, run the Policy Configuration Agent against a real compliance document, and watch the SCU meter. Start building familiarity with the tool before it becomes more capable. The agents are not going to replace the need for Intune expertise — but for teams that already have it, they’re a useful addition to the workflow.