Microsoft Build 2026 – My Device Management and Intune round-up James Vincent

Microsoft Build is commonly seen as a conference for developers, which normally means any specifics for Device Management and/or Intune are hard to come by. In this post I try to cover the device management bits, and whilst this year the message was very much agents, agents and more agents, there were still some useful announcements for those of us living in Intune, Windows 365, Autopilot, Security Copilot and wider Modern Workplace world.

This is not a full Build recap, too much was going on and more so, in areas out of my comfort zone. I’ll leave the Foundry, models, GitHub developments and the wider AI bits and pieces to the specialists in those areas. This post is my high level look at the bits that matter most to us device management folk.

The short version

If you manage endpoints, the interesting Build 2026 announcements were roughly these:

Windows 365 is becoming a more serious managed developer platform.
Autopilot device preparation is now available for Windows 365, so Cloud PCs can receive apps, scripts and configuration before the user signs in.
Windows 365 for Agents is now generally available, giving computer-using agents a managed Cloud PC environment.
Agent 365 is becoming the control plane for AI agents, including discovery and governance of local agents on managed endpoints through Defender and Intune.
Windows is gaining more local agent/runtime capability, including Microsoft Execution Containers, with Intune named as part of the management and policy story.
Copilot in Intune and Security Copilot continue to creep closer to day-to-day admin workflows, including RBAC improvements.

In other words, Microsoft is not just giving users and developers more AI tools. It is also starting to build the admin and security plumbing needed when those tools run on corporate devices.

Windows 365 is now the developer Cloud PC story

The biggest announcement around device management, at least for me, was the push on Windows 365 becoming the developers playground. Microsoft described this as its biggest release yet for developer and agent capabilities on Windows 365.

The headline item is a Windows 11 developer configuration image for Windows 365, currently in public preview. It gives developers a Cloud PC with common tooling already present, including Visual Studio Code, Git, GitHub CLI, Python, Node.js and WSL.

That matters because Microsoft also made it clear that Dev Box is now in maintenance mode. Windows 365 is the forward-looking route for standardised developer environments at Microsoft.

From an Intune perspective, this changes the conversation a little. A developer workstation does not have to be a powerful physical laptop with an ever-growing local toolchain. It can be a Cloud PC, Entra joined, Intune managed, policy enforced, and rebuilt or resized as required.

I suspect many organisations will not move all developers there. That would be a stretch. But for contractors, offshore teams, secure projects, high-risk environments and short-lived workloads, Windows 365 is becoming harder to ignore.

Autopilot device preparation for Windows 365

This is the bit Intune admins should pay attention to.

Autopilot device preparation is now available for Windows 365. In practical terms, you can include Autopilot device preparation policies in a Cloud PC provisioning policy and have apps, scripts and configurations applied immediately after the Cloud PC is created, before the user signs in.

That is a good thing. A Cloud PC that looks fine in the admin centre but still needs another hour of app installs after first sign-in is not really ready. If we can move more of that work into provisioning, the first user experience should improve.

It also gives us a more familiar management model. Build the device preparation policy, assign the required apps and scripts, monitor the deployment report, then adjust based on what actually happens. Same tyre kicking, same pilot-first approach, just against Cloud PCs rather than physical devices.

There are still the usual questions: app install order, timeouts, reporting, failed installs, and whether a failed dependency blocks the experience at exactly the wrong point. So I would treat this as something to test carefully rather than something to switch on everywhere over a coffee.

Windows 365 for Agents

Windows 365 for Agents is now generally available. The idea is simple enough: if agents need to use a computer, give them a managed Cloud PC rather than letting them loose in unmanaged or half-understood environments.

This is where Build started to feel less like a developer event and more like a future operations problem.

If agents can browse, click, run tools, interact with apps and perform tasks on behalf of users or business processes, then someone has to manage the machine they are using. It needs identity. It needs policy. It needs monitoring. It needs security controls. It needs a way to be reset when things go wrong.

Windows 365 gives Microsoft a neat answer to that. Put the agent workload on a Cloud PC and wrap it with the controls we already understand: Entra ID, Intune, Defender, Conditional Access and Windows 365 management.

It is early days, but the management angle is obvious. If your organisation starts experimenting with computer-using agents, ask where they run, how they are isolated, how they are patched, what they can access, and who owns the policy.

Agent 365 and local agent discovery

Agent 365 is now generally available for commercial customers and Microsoft is positioning it as the control plane for AI agents. The important device management point is that Agent 365 is not only about agents created inside Microsoft 365 or Copilot Studio. Microsoft is also talking about local agents running on endpoints.

The examples Microsoft has used include developer-style agents and local tools. That matters because local agents are going to become another form of shadow IT. Users will install them. Developers will test them. Some will be useful. Some will be over-permissioned nonsense. Some will quietly receive more access than required and collect more data than they need.

Microsoft says Defender and Intune will be part of discovering and managing these local agents. That is worth watching closely. We already use Intune to manage apps, scripts, browser controls, endpoint security settings and compliance. Agent discovery feels like the next logical inventory problem. (Which perhaps leads nicely into Device Inventory, just recently published by Microsoft within Intune).

I would expect this to become an admin question very quickly:

Which AI agents are installed on corporate endpoints?
Which users are running them?
Which agents have access to files, browsers, terminals or developer tools?
Which ones are approved?
Which ones should be blocked?

That is very much an Intune and Defender conversation.

Windows as a managed agent platform

Microsoft also announced Microsoft Execution Containers, or MXC, as an early preview. This is a policy-driven execution and containment model for agents on Windows.

The detail is still emerging, but the direction is clear enough. If agents are going to run locally, Windows needs a way to identify them, contain them, apply policy to them and connect them back into enterprise security tooling. Microsoft specifically named Defender, Entra, Intune and Purview as part of that protection story.

This will not be something most Intune admins configure tomorrow morning. Still, it is worth keeping an eye on because it hints at where endpoint management is heading. We have spent years managing users, devices, apps and data. Agents may become another managed object in that chain.

Copilot in Intune keeps getting more real

Outside the Build keynote noise, Intune has also had a useful Copilot-related change. Intune RBAC roles now inherit access to Copilot in Intune when Intune is enabled as a data source in Security Copilot.

The Entra ID Intune Administrator role inherits Security Copilot owner access, while other built-in and custom Intune RBAC roles inherit Security Copilot contributor access.

That is not as flashy as a keynote demo, but it matters operationally. If Copilot in Intune is going to be used by real admins, access needs to follow the admin model rather than becoming yet another separate permissions exercise.

As always, I would still be careful. Security Copilot runs on Security Compute Units, and SCUs equal money. Give people access, yes, but make sure they understand what they are doing and when a prebuilt query is a better idea than freestyle prompting. See my earlier article on Security Copilot within Intune for more details.

Other Intune bits worth noting

A few recent Intune updates sit nicely alongside the Build announcements:

Remote Help for Windows has had performance and reliability improvements.
Enhanced app inventory is giving faster Windows app inventory data and richer metadata.
Platform SSO registration during macOS Automated Device Enrollment is now supported during device registration.
Endpoint Privilege Management support-approved elevations now work for all users of a device, not just the primary or enrolling user.
Android Enterprise credential manager permissions give admins more control over credential providers and passkey scenarios.

Not all of that is Build-specific, but it reinforces the same direction: more visibility, more automation, more identity-aware configuration, and more security controls moving into the management plane.

My take

Build 2026 was not an Intune event, but Intune was quietly present in a lot of the important places.

The immediate practical item is Autopilot device preparation for Windows 365. That is something Intune and Windows 365 admins can test now, and it has a clear user experience benefit if it works well in your environment.

The bigger shift is agent management. Microsoft is clearly preparing for a world where AI agents are not just chat windows. They are installed locally, running in developer tooling, interacting with browsers and apps, and sometimes operating in Cloud PCs. That creates a management problem, and Microsoft wants Intune, Defender, Entra, Purview, Windows and Agent 365 to be the answer.

My advice would be simple:

Start testing Autopilot device preparation with Windows 365 in a small pilot.
Review how you currently manage developer workstations and whether Cloud PCs could help in specific scenarios.
Keep an eye on Agent 365 and local agent discovery, especially if your developers are already using AI coding agents.
Do not treat agent tools as harmless toys. If they can access data, run commands or use browsers, they need governance.
Make sure Intune RBAC, Security Copilot access and cost controls are understood before wider rollout.

As ever, pilot it, check the logs, understand the reporting, then decide whether it is ready for your estate. Caveat emptor and all that.

James Vincent

Microsoft Build 2026 – My Device Management and Intune round-up