Autonomous endpoint management starts with the admin experience

Every IT organization is being asked to do more with less and support a workforce that expects instant resolution, all while preparing for a world where AI agents act alongside human admins. Earlier this year, we made the case that autonomous endpoint management (AEM) is here. 

But getting to autonomy doesn’t happen in a single leap. It requires rethinking how admins interact with Workspace ONE UEM across three dimensions: 

1. How they engage with it
2. How they deploy resources through it
3. How they establish trust in every action it takes. 

The capabilities we’re announcing at Omnissa ONE address each of these dimensions directly, improving not only the day-to-day experience of the UEM admin, but importantly it is building the operational groundwork that makes autonomous, agent-driven IT possible.

Engage: a new way to work with the platform

For years, engaging with Workspace ONE UEM meant navigating a console. That model still works, but it no longer reflects how admins want to operate in an AI-driven environment.

Omnissa MCP, now generally available, changes things. Built on the Model Context Protocol, Omnissa MCP server allows administrators to connect their preferred AI client, like Claude, Copilot, or another MCP-capable tool, directly to Workspace ONE UEM and Omnissa services. In the future, instead of clicking through multiple screens, an admin can simply ask, “What needs attention today?” and get an answer that draws on Workspace ONE and Horizon, as well as other platform services like Omnissa Intelligence and Omnissa Access.

Because the protocol is standards-based, Omnissa is not locking customers into a single AI vendor or rebuilding integrations every time the AI landscape shifts. When we add a new feature, the existing AI client discovers it dynamically, so as new capabilities are added to Workspace ONE UEM, they appear as an option in the AI tool automatically. Critically, every action taken through an AI client inherits the same role-based access controls and audit trail admins rely on for security and compliance. The agent only sees what the admin is authorized to see, and every call lands in the same audit log admins already review.

Deploy: precision and control at scale

Omnissa MCP server gives admins a fast way to push a change. But identifying pushing that change and rolling it out safely are not always the same problem, since pushing an update to an entire fleet at once risks amplifying any possible issues. 

Phased deployment lets admins roll out applications in controlled stages rather than to the entire fleet at once. Phases can be tracked, paused, and resumed at any point, and progression can be governed by install success rates, configured wait times, or DEX signals (like crash rates and startup performance). And to reduce risk and manual effort, admins can build a rollout pattern and reuse it across multiple applications.

While phased deployment has been available in Workspace ONE for some time, this announcement extends what customers already have in production: DEX-based progression, reusable rollout templates. Smart Groups was already an extremely dynamic way to target profiles and payloads in UEM. Now, with Smart Groups 2.0, we’re adding multi-step rule building and logic criteria behind it.

Smart Groups 2.0 will complement this by giving admins far more precise targeting. A rule builder now supports sensor values and nested AND/OR logic, allowing admins to construct groups based on what is actually happening on a device rather than relying on custom scripts or static lists to approximate it.

Together, these capabilities mean IT is no longer choosing between speed and caution. They can both move quickly and stay precise.

Trust: verified, governed action

As more actions are initiated by agents rather than admins alone, trust becomes the deciding factor in whether autonomy is viable at all. At Omnissa ONE, we announced that dual admin approval and root of trust resource signing are coming to Workspace ONE UEM.

Dual admin approval introduces a second layer of review before a change takes effect. Admins define which resources require approval, who can approve them, and where the policy applies. Nothing changes for actions that are not explicitly governed, and every governed change still follows the same publish workflow administrators use today, with one additional step before it reaches devices.

Root of trust resource signing for apps and profiles ensures that only verified, unmodified resources are installed. A signing token allows Intelligent Hub to validate a resource before installation and block anything that fails that check, protecting the fleet even if the console itself were compromised.

The foundation for what comes next

These capabilities aren’t AI features in and of themselves. They are the guardrails that make AI trustworthy, and together they let the platform target devices precisely, stage safely, and verify every action before it reaches a device. 

That is what separates AEM from simple automation. Autonomy without governance is a liability. Omnissa is building the governance first, so when AI does more of the work, IT still defines the boundaries.

We’ll be covering these advancements (and more!) in depth this week at Omnissa ONE. If you couldn’t make it this year, we’ll be revisiting these announcements during our virtual, Omnissa ONE Encore series later this fall. Stay tuned!