Microsoft Copilot Managed Runtime: What Changed Sept 25

Microsoft now hosts the code, not just the conversation

On September 25, 2026, Microsoft moved Copilot Managed Runtime into public preview. The platform hosts and manages AI-generated code inside the Microsoft 365 tenant boundary, governed by IT and subject to organisational compliance controls. This is not a new AI model or a chat upgrade. It is a runtime — the layer where code actually executes.

That distinction matters operationally. Teams building with Copilot tools previously had to solve hosting, identity, versioning, and data authorisation themselves — each new app meant assembling infrastructure from scratch. Managed Runtime collapses that assembly into a single deployment model.

Why Microsoft made this move

The build layer for AI coding tools is crowded and shifting fast. As Cloud Wars observed, user loyalty to any single build tool is “fickle,” and Microsoft is “positioning itself as the trusted place where all that code ultimately runs. Build anywhere, run on Microsoft.” Rather than compete for every developer’s build-time preference, Microsoft is claiming the execution layer.

Opening the runtime to Lovable — a third-party vibe-coding tool — makes the intent concrete. Apps assembled entirely outside Microsoft’s own surfaces can deploy into the tenant boundary and inherit enterprise governance on arrival. The moat is not the IDE or the code generator. It is the runtime, the identity layer, and the compliance posture that enterprise IT already trusts.

Who this affects and how

Three groups are affected immediately.

IT administrators gain a single control plane — the Apps experience in the Microsoft 365 admin center — to enable or disable hosted apps and review default policies. Hosted apps are also accessible at managed apps.cloud.microsoft.

Internal developers and power users building on Copilot Cowork, Copilot Code, or Copilot Studio are already on the runtime at launch. As Microsoft stated in the official announcement: “Microsoft entry points are already live with Copilot Cowork, Copilot Code, and Copilot Studio, and developers can use the SDK and plugins to build applications for the host.”

External developers and tool vendors can now target the runtime via the SDK and CLI, both in public preview as of the week of September 25, 2026. If your product produces code — or if your customers build with AI tools you support — Managed Runtime is a viable deployment target into a customer’s M365 tenant. Founders evaluating enterprise software distribution should map their current app portfolio against the M365 tenant footprint of their target customers before assuming the runtime accelerates their go-to-market.

Concrete capabilities and current limits

The platform bundles four things teams typically wire together manually: identity access through Microsoft Entra; automatic version and source control via Git; Work IQ for product and data access authorisation, grounding apps in Dynamics 365 and Power Platform data; and the SDK as the connective layer between developer-created code and the runtime host, enabling deployment, versioning, and secure API access to host-exposed services.

Work IQ entered public preview on September 30, 2026, with rollout throughout October 2026. Fabric IQ, the context layer connecting Copilot to Microsoft Fabric data, reached general availability through Chat and Cowork in late September 2026. Cost management now covers Code and Managed Runtime alongside Cowork and Work IQ; Copilot Studio agents are expected to be added to cost management in October 2026.

These are public preview capabilities. Microsoft has not published SLA or uptime guarantees for the runtime at this stage. Treat current constraints as preview constraints, not permanent architecture decisions. A getting-started walkthrough for the SDK and CLI is available. More depth is expected at Microsoft Ignite, November 17–20, 2026.

The vendor lock-in objection — taken seriously

Deploying into the M365 tenant boundary means accepting Microsoft’s runtime, identity model, and policy controls. For organisations with multi-cloud mandates or data-residency requirements outside Microsoft’s footprint, that is a real architectural constraint. The SDK abstracts some of the integration surface, but the runtime itself is Microsoft-specific infrastructure — that is a deliberate design choice, not an oversight, and it does not suit every organisation equally.

For organisations already running Entra, Purview, and Intune, however, the governance infrastructure is largely sunk cost. Managed Runtime converts that existing investment into a deployment advantage rather than a parallel burden. The lock-in concern is legitimate; it is also less acute when the lock-in is already present.

How to act now

Administrators: Open the Apps experience in the Microsoft 365 admin center, review the default policies, and decide which app categories to enable before teams start deploying independently. Setting policy before the first deployment is easier than unwinding it after.

Developers: Pull the SDK and CLI from the official announcement and run a test deployment in a non-production environment. The goal is to understand how versioning and Entra identity behave in practice before committing a production app — preview behaviour can differ from documentation in ways that matter for access control.

Executives and founders: Map your current app portfolio against the M365 tenant footprint of your target customers. The overlap — or absence of it — will tell you whether the runtime accelerates or complicates your distribution strategy. Public preview is the right moment to run that analysis, before the GA roadmap is fixed at Ignite.

— Abhijit Ghosh

Eagentix helps growth-focused enterprises redesign and automate manual business processes. We combine executive strategy, implementation support, and managed services to build dependable operations across Southeast Asia.