Copilot Studio's governance sits in an admin centre, not the builder

A living page for a low-code agent builder

Microsoft's own dated announcement of Copilot Studio's launch could not be confirmed from a page still live at a working address, so what follows describes the product from Microsoft's current documentation and product page as retrieved on 16 September 2026, rather than as first announced. Copilot Studio is described as 'a platform for building and managing agents' that lets a person 'create, customize, and launch AI agents easily' using natural language or a graphical designer, aimed at low-code builders rather than only professional developers. The company's Copilot Studio blog, retrieved the same day, still carries this framing forward, describing itself as covering 'AI-powered agent news' with recent posts about expanded governance features.

What it connects to, and how a person builds

The documentation describes agents 'grounded' in organisational knowledge and connected through 'more than 1,400 external connectors', with the finished agent publishable 'directly in the Microsoft 365 apps your employees use every day — such as Microsoft Teams, SharePoint', or to websites and other channels. Building is described as an iterative, tested process rather than a single step: the overview documentation states a person can 'test it before you publish', and that 'Evaluations' let a team 'validate quality with test sets... before and after you publish'. A separate building block, agent flows, is documented as able to 'run prompts, call agents, and include human review steps' — a review point named explicitly inside the flow itself, not left implicit.

Where governance actually sits

The product page places broader control outside the builder altogether: management runs 'through the Microsoft Power Platform admin centre', where an administrator can 'protect data, control agent creation and sharing', apply 'agent lifecycle management controls', and 'track agent ROI using Microsoft Purview'. That separation matters for a low-code tool aimed at non-specialist builders: the person assembling an agent is not necessarily the person who can see across an organisation's whole agent inventory or enforce a data-loss-prevention policy on it. A custom assistant is only as governed as the admin centre a given organisation actually configures; the documentation describes the controls that exist, not whether a particular deployment has turned them on.

• Who in the organisation has access to the admin centre where agent-wide governance controls actually live?
• Does an agent flow's human review step apply to every action, or only to the ones a builder chose to route through it?
• Which of the 1,400-plus connectors touch data that should not leave a specific system or jurisdiction?

A low-code builder lowers who can create an assistant. It does not, by itself, answer who is watching what all those assistants can now do — that is a separate, administrative layer the documentation places deliberately outside the builder's own screen.