AI and the End of Manual Endpoint Management
You've been writing the configs and packaging the apps. That assumption has an expiry date — here's what comes next.
In Part 1, we made the case for standardisation. In Part 2, we codified endpoint configuration — treating Intune policies like source code, with Git, pull requests, and pipelines. In Part 3, we tackled application packaging and lifecycle management.
Every process described in those posts — writing DSC configurations, building MSIX packages, managing deployment rings, reviewing pull requests — assumed a human doing the work. A skilled, disciplined human following frameworks and checklists.
Part 2 ended with a hint: "everything above assumes you're the one writing the code and making the commits. That assumption has an expiry date."
This is the post where the expiry date arrives.
What This Isn't
Let me be clear about what follows. This is not a breathless "AI will replace your IT team" piece. If you've been in this industry long enough, you've survived at least three cycles of "this technology will change everything" — and the reality was always more nuanced than the marketing.
AI in endpoint management is real, it's accelerating, and it's going to meaningfully change how teams operate. But the change is in what your team does, not whether you need one. The teams that understand this distinction will thrive. The ones chasing full automation without governance will learn expensive lessons.
What's Already Here: Copilot in Intune
Microsoft shipped Security Copilot integration with Intune through 2024 and 2025, and it's worth an honest assessment.
What it does well:
Natural language queries against your tenant are genuinely useful. "Which devices are non-compliant with our BitLocker policy?" returns an answer in seconds rather than requiring you to navigate through three levels of portal UI and mentally correlate filter results. Policy summarisation — "explain what this configuration profile does in plain English" — turns the seventeen "Standard Device Configuration" profiles from Part 2's nightmare scenario into something a new team member can actually understand.
Device troubleshooting with contextual awareness is where Copilot earns its keep for day-to-day operations. Instead of bouncing between Intune, Entra, and Event Viewer trying to correlate why a specific device failed a compliance check, you can ask and get a consolidated answer with context.
What it doesn't do:
Copilot in Intune is an assistant, not an operator. It answers questions; it doesn't make changes. It can tell you what your policies do, but it can't write new ones. It can identify non-compliant devices, but it can't remediate them. It's a read-only intelligence layer bolted onto your existing management plane.
This is useful — genuinely, meaningfully useful for reducing the cognitive load on your team. But it's the starting point, not the destination.
Configuration as Code, Written by AI
Let's pick up exactly where Part 2 left off. The Configuration-as-Code workflow was:
- Export configuration
- Commit to Git
- Branch and pull request
- Peer review
- CI/CD validates
- Merge and deploy to tenant
- Drift detection loops back
That workflow assumed you were doing steps 1 through 4. AI changes who does what.
Generating Configuration from Intent
Instead of writing PowerShell DSC or hand-crafting Intune policy JSON, you describe what you want:
"Enforce BitLocker with XTS-AES-256 on all OS drives. Escrow recovery keys to Entra ID. Allow TPM-only unlock for standard users; require TPM + PIN for devices in the Executive Devices group. Exempt the Kiosk Devices group entirely."
An AI agent generates the Microsoft365DSC configuration or Graph API payload, creates a branch, and opens a pull request with the changes and a summary of what was generated and why.
This isn't speculative — it's how AI coding assistants already work for software development. The endpoint management domain is smaller and more constrained than general-purpose programming, which actually makes it more tractable for AI. The policy surface area of Intune is large but finite, well-documented, and highly structured. These are ideal conditions for AI-generated configuration.
The "we're not developers" objection from Part 2 dissolves here. Your team doesn't need to learn PowerShell DSC or Graph API syntax. They need to articulate what the policy should be — which is the skill they already have. The AI handles the translation from intent to implementation.
AI-Assisted Review
In Part 2, we argued that pull request review was essential — a second pair of eyes catching mistakes before they hit production. AI makes that second pair of eyes significantly more capable.
An AI reviewer can check a configuration PR against:
- Your established baseline: "This change removes a setting that's been in place since the initial deployment. Was this intentional?"
- Security benchmarks: "This BitLocker configuration doesn't meet CIS Level 1 requirements because it allows USB key protectors. The current baseline uses TPM-only, which is more restrictive."
- Known conflicts: "This new Wi-Fi profile uses the same SSID as an existing profile assigned to a different group. This will cause deployment conflicts on devices in both groups."
- Blast radius: "This compliance policy change will affect 2,847 devices. 312 are currently non-compliant and will be blocked from Exchange access within 24 hours of deployment."
No human reviewer can hold your entire policy estate in working memory. AI can. The human reviewer still makes the final call — but they're making it with dramatically better information.
Intelligent Drift Remediation
Part 2 introduced drift detection as a binary operation: drift detected, alert sent, human investigates. AI adds a layer of judgement.
Not all drift is equal. A display name change on a configuration profile is cosmetic. A disabled conditional access policy is a security incident. Today, both generate the same alert and require the same human triage. With AI, the response can be proportional:
- Cosmetic drift (naming, descriptions, non-functional metadata): auto-remediate silently, log for audit.
- Operational drift (deployment assignments, ring memberships, non-security settings): auto-remediate, notify the team.
- Security-critical drift (compliance policies, conditional access, encryption settings): block remediation, escalate with full context — what changed, when, by whom, and what the impact assessment is.
The human still defines the classification rules. The AI applies them consistently at a speed and scale that manual triage can't match.
Application Packaging, Automated
Part 3's decision framework — "Does it need kernel access? Win32. Low-risk evergreen? Store. Everything else? MSIX" — is exactly the kind of structured, repeatable decision that AI handles well.
Format Selection at Scale
Feed an AI agent a vendor installer, the application's documentation, and your organisation's packaging standards. It determines: does this application modify system-level components? Does it register shell extensions or COM objects? Does it require a kernel-mode driver? Does it install services?
Based on the answers, it selects the packaging format, documents the rationale, and flags any edge cases for human review. The decision tree from Part 3 stops being a document your team consults — it becomes logic the AI applies consistently to every intake request.
MSIX Conversion
The learning curve objection to MSIX from Part 3 — "our team doesn't know how to create MSIX packages" — starts to lose its force. AI-assisted packaging tools analyse an installer, determine the correct capabilities declarations, handle the conversion, and produce a signed package.
Not every application will convert cleanly. Complex installers with custom actions, kernel drivers, or COM interop will still need human expertise. But the 60-70% of straightforward applications that are currently packaged as Win32 purely out of inertia? Those are candidates for automated MSIX conversion today.
The economics shift from "MSIX conversion is too expensive for most apps" to "MSIX is the default and Win32 needs justification" — exactly the hierarchy Part 3 argued for, but achievable without a team of specialist packagers.
Detection Rule Generation
One of the most tedious parts of Win32 packaging is writing detection rules — registry key checks, file version comparisons, custom scripts. It's pattern work. AI excels at pattern work.
An AI agent analyses the installer, determines what it installs and where, generates appropriate detection rules, validates them against a test installation, and flags ambiguities. The hours your team currently spends crafting and debugging detection rules evaporate.
The Catalogue Problem — and How to Actually Solve It
Part 3 argued that an application catalogue is a prerequisite for everything else: you can't plan a Win32-to-MSIX migration if you don't know what you have. In practice, this is where most organisations stall. The catalogue starts as a spreadsheet, someone maintains it enthusiastically for a month, and then it quietly rots as reality diverges from the documentation.
The building blocks to fix this already exist — they just need wiring together.
Intune's Graph API exposes two datasets: managed apps (what you're intentionally deploying) and discovered apps (deviceManagement/detectedApps — what's actually installed across your estate). The gap between these two lists is your problem space. A scheduled Power Automate flow pulls both datasets, and an AI classification step correlates them — matching discovered apps to catalogue entries by name, publisher, and version, then flagging what doesn't match.
ACTIONABLE OUTPUTS
The AI layer is what turns raw data into actionable output. It can identify orphaned software (installed but not managed by Intune), flag applications with no ownership assignment, detect end-of-life versions by cross-referencing vendor lifecycle data, and — critically for the MSIX conversation — generate a migration shortlist by identifying Win32 packages that have no custom install logic, no kernel dependencies, and no COM registration. Those are your low-hanging fruit for MSIX conversion.
This isn't a product you buy off the shelf. It's a Power Automate + AI + SharePoint build — a few days of work, not a few months. But it transforms the catalogue from a chore someone grudgingly updates quarterly into a living asset that surfaces the exact list of "these 47 apps are straightforward MSIX candidates" that makes the business case for migration tangible.
Deployment Intelligence
Ring Progression
Today, promoting an application from pilot to broad is a human decision based on... vibes, mostly. Someone checks the helpdesk queue, asks a few pilot users how it went, and makes a call. AI makes this decision informed rather than instinctive.
An AI agent monitoring the pilot ring can analyse: crash rates compared to the previous version, user-reported issues correlated with the update timeline, performance metrics (login time, app launch time, battery impact), and helpdesk ticket volume with semantic analysis of whether tickets are related to the update.
The output isn't "automatically promote to broad" — not yet, and maybe not ever for business-critical applications. It's a recommendation: "Pilot has been running for 72 hours across 340 devices. Crash rate is 0.3% (unchanged from baseline). Two helpdesk tickets mention the update, both resolved as user error. No performance regression detected. Recommend promotion to Broad."
Or: "Pilot has been running for 48 hours. Crash rate has increased from 0.3% to 2.1%, concentrated on devices with less than 8GB RAM. Fourteen helpdesk tickets reference application freezing. Recommend holding pilot and investigating memory-related regression."
That second insight — "concentrated on devices with less than 8GB RAM" — is the kind of pattern a human reviewing dashboards would likely miss but an AI agent correlating telemetry surfaces immediately.
Predictive Patching
Combine application dependency data from the catalogue with vulnerability feeds, deployment telemetry, and threat intelligence. AI can prioritise patching based on actual risk rather than CVSS score alone.
"This vulnerability has a CVSS of 9.8, but the affected component is only present in three test lab machines with no network exposure. Meanwhile, this CVSS 7.2 vulnerability affects a runtime installed on 80% of your estate, is being actively exploited in the wild, and the affected applications have internet-facing functionality."
Prioritisation by actual risk — considering your specific environment, not just the abstract severity — is something experienced security engineers do intuitively. AI makes it systematic and consistent.
The Agentic Shift
Everything above describes AI as an assistant — helping humans do their existing jobs faster and with better information. The next shift is more fundamental: AI as an agent that monitors, decides, and acts within defined guardrails.
Consider a concrete scenario. A new vulnerability is published affecting a runtime library. An AI agent:
- Monitors: detects the advisory via threat intelligence feed.
- Detects: cross-references with your application catalogue to identify affected applications and the devices they're installed on.
- Plans: generates a patching plan — which applications need updating, in what order (respecting dependencies), through which deployment rings.
- Presents for approval: creates a PR with the patching changes, a risk assessment, and an estimated impact summary. A human reviews and approves.
- Acts: deploys the patches through your established ring structure.
- Verifies: monitors telemetry through each ring, pauses automatically if error rates spike, and reports completion.
The human in this scenario made one decision: approve or reject the plan. Everything else — detection, correlation, planning, execution, monitoring — was handled by the agent. The human's time-to-decision went from "three days of investigation and planning" to "thirty minutes reviewing a well-structured recommendation."
Guardrails, Not Handoffs
The critical design principle is guardrails. You define the boundaries:
- "Never deploy to Broad without 48 hours in Pilot."
- "Always require human approval for security baseline changes."
- "Auto-remediate cosmetic drift. Escalate security drift."
- "Halt any deployment that increases error rates by more than 1% in any ring."
The AI operates within those boundaries (who read those bullet points and thought "Asimov's Laws?"). It doesn't need permission for routine operations that fall within policy. It escalates when situations fall outside its authority. This is the same principle as delegation in any well-run organisation — you don't approve every purchase order, but you set spending limits.
What This Means for Your Team
| Task | Today | With AI |
|---|---|---|
| Write DSC configuration | Human | AI |
| Review for security compliance | Human | AI + Human |
| Define desired policy | Human | Human |
| Package applications | Human | AI |
| Detect & classify drift | Tool | AI |
| Decide exception governance | Human | Human |
| Manage deployment rings | Human | AI + Human |
| Approve production changes | Human | Human |
EXECUTION SHIFTS TO AI · GOVERNANCE STAYS WITH HUMANS
Let's be specific about what changes and what doesn't.
What AI takes over:
The repetitive, pattern-based work that consumes most of your team's time today. Detection rule writing. Catalogue maintenance. Drift reports. Compliance evidence gathering. Deployment monitoring. These tasks are necessary but mechanical, and AI handles them faster and more consistently than humans.
This is good. These tasks are not what your team was hired for. Nobody entered endpoint management because they dreamed of writing MSI detection rules.
What stays human:
Architecture decisions. Stakeholder negotiation. Exception governance. Risk appetite. "Should we even deploy this application?" is a business question, not a technical one. "How do we handle the CEO who insists on running unsanctioned software?" is a political question. AI has no opinion on either.
The skill profile shifts. Less time writing PowerShell, more time defining policies and reviewing AI-generated recommendations. Less "how do I configure this?" and more "what should the policy be and why?" The team becomes more strategic.
The real risk:
The danger isn't that AI replaces endpoint teams. It's that teams over-trust AI output and stop applying critical judgement.
An AI that confidently generates a misconfigured security baseline is more dangerous than a human who cautiously clicks through the console, because the AI's output looks authoritative and complete. It comes with documentation. It passes syntax validation. It might even pass automated compliance checks against the wrong benchmark.
The teams that will succeed with AI are the ones that treat it the way they should treat any powerful tool: with appropriate scepticism, clear governance, and a culture that values understanding why a configuration exists, not just that it exists.
Where to Start
Each post in this series has ended with pragmatic next steps. This one is no different.
-
Try Copilot in Intune if you have the licensing. Ask it to summarise your compliance posture, explain a complex conditional access policy, or troubleshoot a device that's failing compliance. See if the answers are useful. This costs nothing beyond the licence and gives you a calibration point for how capable the current generation actually is.
-
Use AI to generate one configuration. Take a policy you need to create — a new compliance policy, a configuration profile, a Windows Update ring — and use an AI assistant to generate the DSC or Graph API payload from a natural language description. Compare what it produces against what you'd have written manually. Note where it's right, where it's wrong, and where it made assumptions you wouldn't have.
-
Define your guardrails now. Before agentic AI is mainstream in your tooling, decide: what actions should always require human approval? What can be automated? What's the escalation path when AI encounters something outside its authority? This is governance work, not technical work, and it's easier to do thoughtfully before the tooling forces the question.
-
Invest in your team's AI literacy. The team that understands both endpoint management and how to work effectively with AI will be dramatically more capable than either discipline alone. This doesn't mean everyone needs a machine learning course. It means everyone should understand how to prompt effectively, how to evaluate AI output critically, and when to trust versus verify.
The Series in Perspective
Four posts, one throughline: reducing manual toil while increasing auditability at every step.
Part 1 argued that standardisation is the foundation — you can't automate what you haven't defined. Part 2 showed how to codify that standard, making it versionable, reviewable, and reversible. Part 3 applied the same discipline to what you deploy, not just how you configure. And this post argues that AI is the accelerant that makes the whole vision achievable at a pace and scale that manual operations never could.
None of this is theoretical. Copilot in Intune is shipping today. AI-assisted packaging tools exist today. Agentic workflows are emerging in adjacent domains and will reach endpoint management imminently. The organisations that have their standardisation, configuration-as-code, and packaging practices in order will be positioned to adopt AI capabilities as they mature. The ones still clicking through consoles will find themselves further behind than ever.
The best time to start was when you read Part 1. The second best time is now.
One more thing. If you've been following the Configuration-as-Code thread through this series, you'll know that Microsoft365DSC has been the primary tool for declarative tenant management. That landscape is about to shift. Microsoft recently announced Unified Tenant Configuration Management (UTCM) — a first-party, Graph API-native approach to desired-state configuration, drift detection, and multi-workload management. It's in preview, it covers Intune, Entra, Defender, Exchange, Purview, and Teams from a single control plane, and it looks like the direction Microsoft is heading for declarative tenant management.
What does this mean for organisations already invested in Microsoft365DSC? How soon should you be thinking about switching? That's a deep dive for a future post — a head-to-head comparison of the two approaches, their maturity, their trade-offs, and practical guidance on timing. Watch this space.
This is Part 4 — the final instalment — of the Windows Endpoint Management series. Part 1: Standardisation · Part 2: Configuration as Code · Part 3: Application Packaging