Microsoft is hosting the code Copilot writes
Microsoft Copilot Managed Runtime entered public preview on September 25, 2026. Microsoft now hosts and manages code created by Copilot inside the Microsoft 365 tenant boundary, under governance that IT controls. The announcement is bylined by David Blyth, Vice President and General Manager for Managed Apps and Agents, and says the runtime already sits underneath Copilot Cowork, Copilot Code and Microsoft Copilot Studio. A software development kit lets third-party tooling and professional developers build on it.
The named controls cover the ground you would expect. Microsoft Entra handles identity and sharing. Runtime environments are Microsoft-hosted. Organisational policies cover connectors, data access, approved endpoints and auditing, with deployment, versioning and lifecycle controls alongside them. A new Apps experience in the Microsoft 365 admin center provides central inventory, access review, usage monitoring, health tracking and policy enforcement.
Nothing in the post covers pricing, licensing or regions, and nothing states a general availability date. This is public preview, so the control list is a set of commitments to test in your own tenant.
Generated apps have been running where nobody chose
The problem this addresses is one most readers already have. Tools that turn a description into a working application have been producing software that runs somewhere nobody chose, holds data nobody inventoried and keeps going long after whoever made it moved teams. The hosting decision was made by whoever clicked deploy.
You know the shape of it. Someone in finance builds the thing that reconciles two reports every Tuesday morning. It works, so it quietly becomes the process. Then that person changes role and the first anyone hears about it is the Tuesday the report does not arrive. The low-code app that outgrew its maker is a pattern that keeps repeating, and generated code makes it repeat faster.
A managed runtime inside the tenant boundary answers the hosting half of that. The code runs where your company controls it, under an identity your company issued, subject to policy your administrators set. Against the alternative of a personal account and infrastructure nobody on your team can reach, that is a real improvement, and Entra plus policy on connectors, data access and approved endpoints is the right control set.
You cannot govern software you cannot enumerate
The least glamorous piece here is the most consequential one. Central inventory means somebody can finally answer how many generated applications exist in the tenant, who can reach them and which ones people actually use. Every other control depends on that answer. A policy you cannot apply to an application you never knew about protects nothing.
Access review and usage monitoring matter for the same reason. An application with two users and a connector into payroll is a different conversation from one with two hundred users and a SharePoint list behind it. Usage figures let you sort by risk instead of treating every row the same way.
Health tracking is the piece we would watch closely. The post names it without saying what it measures. Whether that means the runtime is up, or whether the application still does the job it was built for, are two different levels of usefulness the announcement does not settle.
An inventory tells you what exists, not what should
Hosting an application under governance says nothing about whether the application is correct. Generated code can run on Microsoft-managed infrastructure, authenticate through Entra, respect every connector policy you set and still calculate the discount wrong. Governance limits how far a mistake travels. It does not review the logic.
The same limit applies to enumeration. A list tells you what exists. It does not tell you what should exist. The companies that struggle here will be the ones that open the Apps experience, find forty applications they had never heard of, and have no process for deciding which deserve to survive.
Someone has to make the retirement calls, and that someone needs the standing to switch things off over an objection. If your teams already argue about which systems belong on a retirement list, forty fresh candidates now join that queue with nobody named against them.
Power Platform learned this arc the slow way
Readers of this publication lived through the same sequence with low-code apps. Capability arrived first and people built. Sprawl followed, because building was easy and nothing counted what had been built. Governance tooling turned up afterwards, and plenty of admin teams spent years retrofitting environment strategy and ownership onto estates that grew without either. Flow ownership debt is the version most Power Platform admins can recite.
Arriving with the runtime and the inventory in the same announcement is better sequencing than that, and Microsoft deserves credit for it. Whether it holds depends on how fast adoption moves against how fast administrators switch the policies on, which is the part no vendor controls.
The thinking in governance that keeps low-code moving transfers almost unchanged. Deny by default on connectors reaching regulated data. A named owner per application and a review date. A route for makers that does not need a ticket for every small thing. None of that is new, and all of it now applies to software a person described rather than wrote.
What to do the week the Apps experience appears
The software development kit is the signal worth reading carefully. Microsoft is building this for more than its own tools, since third-party tooling and professional developers can target the same runtime. If they do, your inventory will hold applications made by products your procurement team never evaluated, and the policy set becomes your only control over them.
So when the Apps experience shows up in your Microsoft 365 admin center, do one thing first. Export the inventory and put a name against every row. Not a maker name, an owner name, meaning the person who answers when it breaks and who can decide it should stop. Then set connector policy to deny anything reaching your finance and HR systems.
Take the finished list into your next Copilot Studio governance review with two columns completed, owner and review date. Every row you could not fill in is the first candidate to switch off, and that argument is easier this month than it will be next year.
