Copilot Managed Runtime: Governance Checklist

Managed Runtime moves Copilot-built apps inside the tenant boundary; the governance decisions still belong to you, and they are easier made before the first app ships.

What Microsoft announced

On 25 September 2026 Microsoft put Copilot Managed Runtime into public preview. Microsoft describes it as an enterprise-grade platform to run code within the Microsoft 365 tenant boundary, operated by Microsoft and governed by IT. The same day, the Official Microsoft Blog described it as hosting infrastructure that lets code run inside your company's Microsoft 365 environment, accessible through the new Code experience.

The points that matter to an administrator are:

• Microsoft Entra identity controls who can access each app.
• Organisational policies govern the connectors, data and endpoints an app can use.
• Version and source control are automatic, backed by Git.
• Apps appear in the new Apps experience in the Microsoft 365 admin center, where administrators can enable and disable apps, review default policies, and review access, usage, health and policy.
• It already powers apps built in Copilot Cowork, Copilot Code and Microsoft Copilot Studio, and Microsoft offers an SDK and command-line interface for developers working in TypeScript.

The practical change is that a user can describe a small business tool to Copilot and end up with a running, shareable app rather than a file. That is useful, and it also means app sprawl can start without a single line of code written by IT.

Decide who can build, and where it bills

Building apps is tied to the agentic features that Microsoft now bills through Copilot Credits. Microsoft's cost management documentation says that enabling or disabling Cowork also enables or disables the app-building capability by default, and that apps built with Cowork are listed under Apps in the admin center. Those services stay off until an admin creates a spending policy.

Before switching anything on:

1. Name one owner for the Apps inventory. In a 20 to 200 person business this is usually the IT lead or the managed service provider, not the finance team.
2. Choose a small pilot group and create a security group for it. Spending policies scope to security groups, so this group does double duty.
3. Create the spending policy for that group only, with a monthly limit and a per-user limit. The steps are in our note on Copilot agent usage billing and budgets.
4. Write down what the pilot is for. "Replace three spreadsheets used for job tracking" is a test you can pass or fail; "explore apps" is not.

Set connector and endpoint policy first

The runtime inherits whatever your organisational policies allow. If the defaults are wide, every generated app is wide too.

1. Open the Apps experience and read the default policies before the first app is published. Record what they allow for connectors, data and outbound endpoints.
2. List the data sources a pilot app genuinely needs. For most SMEs that is SharePoint, a line-of-business system and perhaps Outlook.
3. Block or restrict everything else, especially outbound calls to arbitrary web endpoints. An app that can read the finance SharePoint site and post to any URL is a data exfiltration route, even if nobody intended it.
4. Check third-party app consent in Entra at the same time. Our guide to an OAuth app consent audit covers the review.

Treat each app like a small piece of software

Git-backed versioning gives you history, but not review. Someone still has to look at what changed.

• Require a named business owner for every app, recorded in the inventory.
• Agree a simple publishing rule: an app that writes data, sends email or touches personal data gets a second pair of eyes before it is shared beyond the builder.
• Use the version history when something breaks. Roll back first, then work out why.
• Review sharing. Entra identity controls access, so check whether an app has been shared with "everyone" when it should be a team.
• Disable apps nobody uses. The admin center shows usage; set a quarterly reminder to prune.

Monitoring and audit

Microsoft's material highlights central inventory, monitoring and usage visibility in the Apps experience. Use that as your first view, and pair it with the tools you already run.

1. Check the Apps inventory weekly during the pilot: new apps, owners, sharing and health.
2. Review Copilot Credit consumption in Copilot, then Cost management, so an app that loops or runs heavy tasks shows up as a spend spike.
3. Keep your existing Microsoft 365 audit log retention and alerting in place. The preview materials do not replace your normal audit practice, so do not assume they do.
4. Record decisions in a short register: app, owner, data touched, date approved, date reviewed.

What to decide before you enable

A one-page decision record is enough for most SMEs:

• Scope: which group can build, and for how long the pilot runs.
• Budget: policy-level and per-user monthly limits.
• Data: approved connectors and endpoints, and what is blocked.
• Review: who approves an app before wider sharing.
• Exit: what happens to apps if the pilot ends, including who can disable them.

Remember this is a public preview. Features and defaults can change, and preview terms differ from general availability. Keep the pilot small, keep data in scope modest, and revisit the record when Microsoft moves the service out of preview.

Source basis

• Microsoft Copilot Blog: Copilot Managed Runtime, enterprise code execution for Microsoft 365
• Official Microsoft Blog: Introducing the new Copilot with Home, Code and Autopilot (25 September 2026)
• Microsoft Learn: Usage-based billing and cost management for Copilot Credits
• Microsoft Tech Community: Evolution of the Copilot pricing model