Security Copilot Agents in Intune: What They Actually Do (and Where They Fall Short)

Microsoft didn’t just add a chat box to Intune. In early 2026, it shipped AI agents that live directly inside the admin center and plug into actual management workflows. The Change Review Agent, Policy Configuration Agent, and Vulnerability Remediation Agent are all powered by Security Copilot under the hood, but they surface in Intune rather than in the Security Copilot portal.

That distinction matters. These aren’t general-purpose prompts. They’re scoped to specific tasks: reviewing approval requests, mapping compliance documents to Settings Catalog policies, and surfacing Defender-backed vulnerability data. They’re also not free. Each run draws down Security Compute Units, and depending on how your SCU workspace is configured, that cost can add up faster than you expect.

Here’s a practical breakdown of what each agent does, where it works well, and where you’ll run into walls.

Prerequisites: SCUs First, Agents Second

Before you can use any of the Intune Security Copilot agents, you need Security Compute Units provisioned in a Security Copilot workspace. No SCUs, no agent reasoning. The agents aren’t running logic locally inside Intune. They’re delegating compute to Copilot’s backend on every run.

You have two provisioning options:

Pre-provisioned SCUs: You commit to a fixed hourly compute capacity. Lower per-unit cost, but you’re paying whether or not agents are running.
Overage-only (pay-as-you-go): Compute spins up on demand. More convenient for low-volume use, but the per-SCU rate is higher.

For shops that only run agents occasionally (say, weekly change reviews), overage-only is fine. Organizations planning to run agents at scale across hundreds of approval requests should model out the pre-provisioned math first.

To enable agents, sign into the Intune admin center, navigate to Agents, and select View details for the agent you want to configure. Each agent has its own setup flow and requires the least-privileged role appropriate to what it does.

The Change Review Agent: Risk Signals Without Script Analysis

The Change Review Agent is designed for organizations using Intune’s Multi-Admin Approval feature. When an admin submits a PowerShell script, policy change, or similar request that requires peer approval, the agent evaluates the pending request and returns a recommendation: approve, reject, or needs more info.

The signal sources are Defender, Entra ID, and Intune itself. The agent looks at things like the submitting admin’s account risk score, whether the target device scope is unusual, and historical approval patterns. Each run evaluates up to ten pending requests at once.

Where it works: For surfacing identity risk and contextual signals around an approval request, it’s useful. If the submitter has a flagged sign-in or an elevated Defender risk score, the agent will surface that alongside the request details. That’s information a busy admin might not manually check before approving.

Where it falls short: The agent doesn’t perform deep analysis of the script body itself. In community testing, a PowerShell script containing commands to clear the C:\Windows directory was evaluated and returned a “NeedsMoreInfo” recommendation rather than a high-risk flag. The agent aggregates external signals. It doesn’t reason over the script’s actual logic.

This makes sense given how it’s architected. The agent works through structured signal aggregation and predefined evaluation rules, not autonomous semantic reasoning over arbitrary code. If the key validation inputs aren’t available (or don’t indicate high risk via the signals it knows how to check), it defaults to a cautious middle ground rather than assuming danger.

For now, treat the Change Review Agent as a signal aggregator, not a code auditor. You still need a human who understands what the script does.

The Policy Configuration Agent: Plain Language Beats Compliance Docs

The Policy Configuration Agent takes a document (or plain text) and maps its requirements to real settings in the Intune Settings Catalog. The use case is translating compliance standards like NIST, CIS benchmarks, or DISA STIGs into draft Intune policies without manually cross-referencing hundreds of settings.

The workflow:

Create a “Knowledge Source” by uploading a document (currently text files only; rename PDFs or JSON exports to .txt before uploading).
The agent analyzes the file, extracts the security requirements, and attempts to match each one to a Settings Catalog entry.
Review the matched settings, remove anything that doesn’t apply to your environment, adjust values where needed, and then create the draft policy through a standard Settings Catalog flow.

Nothing gets applied automatically. You review and commit.

Where it works: When you give it clear, direct language, it performs well. Natural language instructions like “Disable Internet Explorer 11 as a standalone browser on all managed Windows devices” result in accurate Settings Catalog matches with confidence scores attached to each recommendation. The agent correctly identified the applicable setting and mapped it with high confidence.

Where it gets tricky: Structured compliance documents written in formal policy language sometimes trip it up. In testing with a STIG-formatted JSON renamed to .txt, the agent reported a 100% match rate in its summary but showed zero settings in the Identified Settings tab. The classification layer and the rendering layer appear to be separate, and they don’t always agree. The fix, for now, is to rewrite or paraphrase the input in plain English before uploading.

The practical implication: if you’re planning to run CIS Level 2 or a STIG through this agent, consider extracting the relevant requirements into a clean .txt file with straightforward language rather than feeding it the raw document. The results are more reliable and easier to review.

The Device Offboarding Agent: Skip It

If you’ve seen documentation about the Device Offboarding Agent, know that it’s being retired:

April 30, 2026: You can no longer configure it.
June 1, 2026: It is removed from the Intune admin center.

If you’re currently using it to identify stale or misaligned devices between Intune and Entra ID, start building an alternative process now. PowerShell with the Graph API, or tools like Intune Guardian, are reasonable replacements for device lifecycle auditing.

The Vulnerability Remediation Agent: Limited Preview

The Vulnerability Remediation Agent is in limited public preview. You can’t enable it directly; you need to contact your Microsoft account team to request access.

When available, it pulls vulnerability data from Microsoft Defender and applies risk-based prioritization so you can see which device vulnerabilities to address first. The value is reducing the manual correlation between Defender findings and device management state in Intune. Instead of jumping between portals and filtering down Defender’s CVE list yourself, the agent surfaces the highest-impact gaps inside the admin center with context about affected devices.

Keep an eye on it, but don’t plan a remediation workflow around it until access opens up more broadly.

Understanding Your SCU Burn Rate

Every agent run consumes Security Compute Units. This isn’t clearly communicated upfront, and it surprises admins who assume the feature is included in their existing licensing.

A few things worth understanding:

SCUs are shared across the Security Copilot ecosystem. The same SCU pool that the Intune agents draw from is also used by Security Copilot prompts in the portal, Entra agents, Defender agents, and any other Copilot-powered workload in your tenant. Running agents in Intune affects availability for everything else in that workspace.

Overage billing kicks in automatically if you’re in pay-as-you-go mode. There’s no hard stop. If you configure agents and then someone runs them repeatedly without checking the usage dashboard, the bill grows without obvious warning.

Agent runs are manually triggered, not automated. For now, you initiate each run yourself. The agents aren’t polling continuously in the background. This limits the blast radius of accidental overuse, but it also means you won’t get proactive alerting. You get insights when you ask for them.

Monitor SCU consumption in the Security Copilot usage dashboard, especially during initial rollout when admins are experimenting.

What These Agents Are Not

A few misconceptions worth clearing up before you build expectations:

They’re not autonomous. Nothing gets approved, applied, or remediated without an admin sign-off. Every agent surfaces recommendations, not actions.

They’re not replacing Intune expertise. The Policy Configuration Agent still requires someone who can review a Settings Catalog policy and judge whether the recommended values make sense for the environment. The Change Review Agent still requires someone who can read a PowerShell script and recognize when it’s destructive, because the agent currently won’t catch that.

They’re not the same as Entra agents. The naming overlap is confusing. Entra has its own set of agents (including an Access Review Agent) that are separate from the Intune agents. They’re built on the same Security Copilot platform but scoped to different workloads.

They’re not free to run continuously. SCU costs are real and should factor into your deployment decision.

Where This Fits in the Broader Picture

The Intune agents are part of a larger shift in Microsoft’s security platform. Agent 365 hit general availability on May 1, 2026, and it extends this model into a full control plane for discovering, governing, and blocking AI agents running across Microsoft 365, SaaS, endpoints, and multicloud environments. Intune and Defender are both part of that visibility layer.

Shadow AI is the specific problem Agent 365 is targeting: unsanctioned AI tools running on managed devices that IT can’t see, govern, or block. The Intune admin center now includes a Shadow AI page (for orgs enrolled in the Frontier program) where discovered local agents can be inventoried and controlled via policy.

Runtime blocking and policy-based controls for shadow AI are coming to Intune and Defender in June 2026 public preview, along with Agent 365 registry sync for AWS Bedrock and Google Cloud. Endpoint governance is about to get more complicated, and Intune is where a significant chunk of that enforcement will live.

Practical Starting Point

If you want to evaluate these agents without overcommitting, start here:

Provision a small SCU allocation (or use overage-only) and enable the Security Copilot workspace.
Enable the Change Review Agent if you’re already using Multi-Admin Approval for PowerShell scripts. Run it against your next five approval requests and see whether the signal aggregation changes how you think about them.
Test the Policy Configuration Agent with one compliance requirement written as plain English. Pick something specific (a single STIG control or a CIS recommendation) and walk through the full workflow to a draft policy.
Watch the SCU dashboard throughout. Know what each agent run actually costs in your environment before expanding usage.
Plan for the Device Offboarding Agent retirement before June 1 if it’s part of your current lifecycle process.

The direction is right. AI-assisted admin workflows inside the tool you’re already working from, rather than as a separate portal, is how this should work. The agents still have rough edges, but they’re useful enough to start evaluating now rather than waiting for the next iteration.