If you manage endpoints at scale, you already know the operational tax of chasing stale devices, reviewing policy change requests, and triaging vulnerability reports that never quite match your actual remediation capacity. Microsoft’s Security Copilot agents in Intune are a direct attempt to automate exactly those workflows — not by removing admin judgment, but by pre-doing the analysis so you can decide faster.
This guide breaks down each of the four available agents, what they actually do under the hood, how to enable them, and the gotchas you’ll hit before they’re genuinely useful.
What Are Security Copilot Agents in Intune?
Security Copilot agents are purpose-built AI assistants embedded directly in the Intune admin center. Unlike the general Security Copilot chat interface (which you query reactively with prompts), these agents run with their own task scopes. They observe state in your tenant, reason about it, and surface recommendations or proposed actions for an admin to approve.
The key phrase is “admin approval before action.” These agents are not autonomous. They are advisory by design, which matters when you’re in a regulated environment where changes need an audit trail.
There are currently four agents:
- Change Review Agent: Evaluates pending Intune approval requests and recommends what action to take.
- Device Offboarding Agent: Identifies stale or misaligned devices across Intune and Entra ID, proposes offboarding candidates.
- Policy Configuration Agent: Takes a document or plain-language instruction, maps it to Intune settings catalog entries, and can draft a policy from the result.
- Vulnerability Remediation Agent: Pulls Defender vulnerability data, applies AI-driven risk scoring, and prioritizes what to patch or remediate.
All four are built on the same Security Copilot generative AI backbone. They respect your existing RBAC roles and Intune scope tags, so the agent can only see what the signed-in admin can see.
Prerequisites Before You Touch Anything
The single biggest tripping point for most teams: Security Compute Units (SCUs).
Security Copilot is not included in your existing Microsoft 365 or Intune license. You need to purchase SCUs separately through Azure. Microsoft uses a consumption model; the more prompts and agent runs you execute, the more SCUs you burn. Each agent run costs more than a single ad-hoc prompt because the agent is running a multi-step reasoning chain internally.
Before enabling any agent:
- Confirm your tenant has SCUs provisioned. Check in the Microsoft Security Copilot portal under Manage > Usage monitoring.
- Read the Privacy and data security documentation. Your prompts and Intune data retrieved during agent runs are processed and stored within the Security Copilot service, which has data residency implications.
- Verify the signed-in admin has the correct Entra ID role. For full Intune data access, the Intune Service Administrator role is the safest bet. Scoped roles will work but you’ll get partial data depending on scope tags.
With that covered, the setup flow is straightforward:
- Run the Security Copilot setup guide to provision your SCU capacity.
- Sign into the Intune admin center with the appropriate role.
- Navigate to Agents in the left nav and select View details on whichever agent you want to configure.
The Four Agents, One by One
Change Review Agent
Change management in Intune (particularly when you’ve enabled Endpoint Privilege Management (EPM) or multi-admin approval workflows) generates a queue of approval requests. The Change Review Agent reads those pending requests and gives you a recommendation: approve, deny, or escalate for further review.
In practice, this saves time when your approval queue has ten pending requests from different requestors on a Tuesday morning. The agent evaluates each request in context: does this change align with existing policy? Has this requestor made similar requests before? Are there conflicting policies that would make this change redundant or risky?
One thing to note: the agent’s recommendation is only as good as the policy signal it can read. If your Intune environment has inconsistent naming conventions, overlapping configuration profiles, or a lot of orphaned policies, the agent’s reasoning will reflect that noise.
Device Offboarding Agent
Stale devices are a security liability. Devices that show as managed in Intune but haven’t checked in for 90+ days — or devices that appear in Intune but are no longer present in Entra ID — represent a gap in your endpoint posture. The Device Offboarding Agent cross-references Intune and Entra ID to surface these misaligned or dormant devices.
What makes this practically useful is that the agent does not just give you a list. It provides context for each device: last check-in date, primary user, enrollment type, and a recommendation on whether to offboard. You then approve or reject each proposed action before anything happens.
The agent works well in organizations that have gone through mergers, contractor offboarding waves, or device refresh cycles where the physical device was replaced but the Intune record was never cleaned up. It works less well if your check-in threshold signals are misconfigured or if your Autopilot-enrolled devices have long offline windows by design (field devices, kiosks, etc.). Those will show up as offboarding candidates when they shouldn’t be. Build an exclusion group before you run this at scale.
Policy Configuration Agent
This one has the highest ceiling and the most variability in results.
The workflow: you give the agent a document (a security baseline document, a compliance framework excerpt, a vendor hardening guide) or you type plain-language instructions. The agent reads the content, searches the Intune settings catalog, and maps your requirements to specific settings with recommended values. You then review the proposed settings and, if satisfied, can use the agent to create an Intune policy directly from that output.
The practical upside is substantial for teams implementing CIS Benchmarks or NIST 800-53 controls. Instead of manually translating 200-page compliance documents into settings catalog entries one by one, the agent compresses that translation step significantly.
The gotchas are real though. The agent works best with well-structured documents that use precise language. Feed it a loosely written internal policy document or a framework section that uses abstract control language (“ensure strong authentication”), and you’ll get vague or incorrect settings mappings that need significant cleanup. Treat the agent’s output as a first draft, not a finished policy. Always review against the Windows security baselines before deploying.
Also: the agent maps to the settings catalog, which is Windows-centric. If you’re managing macOS, iOS/iPadOS, or Android devices, this agent’s utility drops considerably for those platforms.
Vulnerability Remediation Agent
This agent bridges the gap between Defender Vulnerability Management and Intune remediation tasks. Historically, that workflow looked like this: a security analyst identifies vulnerabilities in Defender, exports a report, sends it to the endpoint team, who then manually maps CVEs to Intune remediations or scripts. The Vulnerability Remediation Agent shortens that loop.
The agent pulls active vulnerability data from Defender, applies AI-driven risk prioritization (factoring in CVSS score, asset criticality, and exposure level), and surfaces a ranked list of what to address. For each vulnerability, it can recommend or initiate a remediation task in Intune: software updates, configuration changes, or script deployments.
The value here is in the prioritization. A raw Defender report might list 3,000 vulnerabilities across your estate. The agent helps you decide which 20 to actually work on this week.
The dependency is real: this agent is only as valuable as your Defender Vulnerability Management coverage. If your devices aren’t reporting back to Defender consistently, the agent is working with incomplete data. It also won’t remediate vulnerabilities that require manual intervention. Third-party application updates that aren’t handled through Windows Update or Intune-packaged apps fall outside its reach.
A Practical Workflow for Rolling This Out
A staged approach works better than enabling all four agents simultaneously.
Week 1-2: Start with Change Review. It’s the lowest risk since it only makes recommendations on pending requests, not proactive changes. This gives your team a chance to calibrate how well the agent’s recommendations align with your own judgment. If you find it’s recommending approval for things you’d reject, that’s a signal your policy naming or approval workflow needs cleanup first.
Week 3-4: Enable Device Offboarding in report-only mode. Build an exclusion group for devices with legitimate long offline windows (kiosks, shared devices, field machines). Review the first batch of offboarding recommendations manually before approving anything in bulk. Run a small pilot of 20-30 devices to validate the agent’s accuracy on your estate.
Month 2: Policy Configuration Agent for a new initiative. Pick a new compliance requirement you’re implementing (not an existing policy you’re editing) and use the agent to draft it from source documentation. Compare what it produces to what your team would have written manually. This calibration is valuable.
Month 2-3: Vulnerability Remediation Agent. Confirm your Defender coverage is solid first. Then use the agent to prioritize a backlog of known vulnerabilities and measure whether the prioritization matches what your security team would have chosen.
Limitations and Caveats
A few things worth knowing before you commit the budget:
SCU costs add up fast in large environments. If you’re running agent workflows across thousands of devices daily, model out your SCU consumption before deploying at scale. Microsoft provides usage monitoring tools, but budget surprises are common in the first month.
RBAC scope limits agent visibility. If the admin running the agent has a scoped role (not a global Intune Administrator), the agent will only see devices and policies within that admin’s scope. This is by design and the correct security behavior, but it means you can’t get a tenant-wide view from a scoped account.
The agents do not replace change management process. They assist with analysis, not governance. Your change advisory board process, your ticketing system, your audit trail — those still need to exist. The agent recommendation becomes one input into that process, not a replacement for it.
Cross-platform coverage is uneven. Policy Configuration and Vulnerability Remediation are strongest for Windows endpoints. macOS, iOS, and Android are partially supported but the settings catalog coverage and Defender integration depth is thinner on those platforms.
Data privacy is a real consideration. When you run an agent against your tenant, device names, user names, policy content, and vulnerability data are processed by the Security Copilot service. Review your data classification policy and confirm this is acceptable before running agents against sensitive endpoint groups.
Conclusion
Security Copilot agents in Intune are a genuine step forward for endpoint teams drowning in operational workload. The Change Review and Vulnerability Remediation agents deliver the most immediate value for most organizations. The Policy Configuration Agent has the highest ceiling but requires structured inputs to produce reliable output. Device Offboarding requires upfront cleanup of your exclusion groups to avoid false positives.
The model that works: treat agents as an experienced analyst who pre-digests the data and presents you with a recommendation. You still own the decision. You still need good policy hygiene underneath. The research time before each decision compresses significantly, and that’s where the real return is.
Start small, measure the recommendation accuracy against your own judgment, and expand once you trust the output.