Generating enterprise apps got easy. Copilot Managed Runtime is about the hard part.
Microsoft now hosts and governs the code people create with Copilot. What a managed runtime solves for AI-built internal apps, and what it leaves to the business.
Listen to this article · 6 min
AI-generated narration of the full article.

The most honest sentence in Microsoft’s September announcements was not about AI at all. It was this one, from the post introducing Copilot Managed Runtime: “Functioning code is only the first step.”
Microsoft goes on to list what follows: provisioning and securing cloud resources, configuring identity and security, honoring organizational policies, establishing deployment processes, and operating the app throughout its lifecycle. Anyone who has tried to take an internal AI prototype into production will recognize that list. It is where most of them stall.
What Microsoft announced
Copilot Managed Runtime entered public preview on September 25. Microsoft describes it as an enterprise platform to run code inside the Microsoft 365 tenant boundary, governed by IT. According to Microsoft, it already powers apps built in Copilot Cowork, Copilot Code and Copilot Studio, and it is opening to third-party tools and professional developers through an SDK and a CLI.
Apps deployed to the runtime can use, in Microsoft’s words:
- Microsoft Entra identity and sharing.
- Microsoft-hosted runtime environments.
- Organizational policies for connectors, data access, approved endpoints and auditing.
- Deployment, versioning and lifecycle controls, with Git-based source control.
- Central inventory, monitoring, usage visibility and IT control in the Microsoft 365 admin center.
Admins can enable and disable apps and review default policies in a new Apps experience. The announcement does not cover pricing, licensing or regional availability; those should be confirmed with Microsoft before planning.
The real problem: app volume, not app quality
Enterprises have been here before. Access databases, macro-heavy spreadsheets and, more recently, low-code apps all followed the same pattern: easy to create, hard to find, harder to retire. AI makes creation even cheaper. Microsoft now describes small, purpose-built apps as a new unit of knowledge work, alongside documents and spreadsheets.
When creation is nearly free, the bottleneck moves to operation. Every app needs a host, an identity model, a data access policy, an audit trail and an owner. If each team has to assemble that foundation separately, two things happen: most useful apps never ship, and the ones that do ship follow a different governance model each.
That is the case for a managed runtime. Microsoft frames it as “the separation of open build and managed run”: anyone can build in the tool that fits their job, but everything runs on one governed layer.
- Built in Copilot Cowork, Code, Studio or third-party tools
- Entra identity, policies and versioning
- Admin center: inventory, usage and health
- App owner: logic, data use and retirement
- Open build: Built in Copilot Cowork, Code, Studio or third-party tools
- Managed run (preview): Entra identity, policies and versioning · Admin center: inventory, usage and health
- Still the business: App owner: logic, data use and retirement
Standardized by the managed runtimeDecisions that stay with the business
What a runtime cannot decide
A governed platform removes a large class of risk: apps without authentication, credentials in code, data connectors nobody approved, apps nobody knows exist. It does not remove the questions that belong to the business:
Is the logic right? An app can be perfectly hosted and still calculate the wrong number. AI-generated code needs review proportional to what the app decides.
Is the data use appropriate? Governed access means the app can only reach what policy allows. It does not mean every allowed use is a good idea. A connector approved for reporting may not be appropriate for an app that emails customers.
Who owns it? A central inventory shows what exists. It cannot make someone accountable for an app when its creator changes roles.
Is the AI inside it good enough? If the app calls a model, its behavior still needs evaluation and a way to recheck it after changes.
When is it retired? Versioning makes change safe. Retirement is a decision someone has to make.
Rethinking the operating model
For US enterprises with thousands of Microsoft 365 users, the runtime makes a different operating model possible, one where IT governs how apps run rather than who may build them. That only works if a few rules are clear:
- Promotion criteria. When does a personal app become a shared one, and what review does that trigger?
- Mandatory ownership. No shared app without a named business owner and a review date.
- Default policies that reflect risk. Review the default connector and endpoint policies before enabling the runtime broadly, not after.
- A path to engineering. Microsoft notes that developers can pull the code and keep building on it. Decide when an app is important enough to move to a team that maintains it.
The bottom line
Copilot Managed Runtime targets the layer where internal AI apps most often die: hosting, identity, policy and lifecycle. Standardizing that layer is the right move, and it is still in preview. The decisions about ownership, correctness and appropriate use do not come with it. They are the difference between a governed platform and a governed portfolio.
For how this fits the wider stack, see our 2026 guide.