Copilot Studio went GA at Ignite in November — the rebranded, considerably expanded successor to Power Virtual Agents. The pitch is that anyone in the business can build a custom copilot: point it at some documents, wire up a few connectors, publish to Teams or a website, done. That pitch is largely true, which is precisely the problem. Every organization we work with is about to hand a low-code agent builder to people who have never thought about a data loss prevention policy in their lives, and most of them are planning to do it before anyone has decided what the guardrails are.
We have seen this movie. In 2020, Teams went from a product nobody used to the center of gravity for every organization on earth in about six weeks, and self-service team creation was on by default. The result was tens of thousands of orphaned teams, guest access nobody tracked, and a two-year cleanup that several of our clients are technically still running. Copilot Studio has the same shape: genuinely useful, self-service by design, and governed by whatever settings happened to be the default on the day someone turned it on. The window to get ahead of it is now, while the maker count is still in single digits.
Environments are the container, so design them first
The Power Platform environment is the unit of isolation, and in most tenants it has been left entirely unmanaged. There is a Default environment that every licensed user can build in, it has a maker permission model that is effectively "everyone," and it is where all the ungoverned sprawl accumulates because it is the path of least resistance. If you do nothing else before opening Copilot Studio to the business, decide what the Default environment is for and lock down who can create new environments.
The strategy we land on for most mid-to-large tenants:
- Treat the Default environment as personal-productivity scratch space only. Do not build anything that touches sensitive data or reaches production users there, and set expectations in writing that it is not a supported home for real agents.
- Restrict environment creation to admins. By default a broad set of users can spin up trial and developer environments, which fragments governance instantly. Turn that off in the Power Platform admin center and route requests through a lightweight intake.
- Stand up managed environments with named owners for anything that will reach real users, so you get the sharing limits, usage insights, and maker controls that the base environments lack.
- Separate development from production with an actual environment boundary, not a naming convention and good intentions.
None of this is exotic Power Platform administration. It is the same tenant hygiene we would apply to any self-service capability, and it is dramatically cheaper to establish before the makers arrive than to retrofit around a hundred agents already in flight.
DLP policies decide what an agent can touch
An agent is only as contained as the connectors it can reach, and connectors are where a friendly little FAQ bot quietly becomes an exfiltration path. Copilot Studio agents call Power Platform connectors to fetch and act on data — SharePoint, SQL, Dataverse, HTTP, and hundreds of third-party services including the ones your data governance policy has never heard of. A data loss prevention policy in the Power Platform admin center is what stops a maker from wiring a bot to read from an internal SharePoint site and post to an arbitrary external HTTP endpoint in the same flow.
The DLP model sorts connectors into business, non-business, and blocked groups, and the rule that matters is that connectors in different groups cannot be used together in the same agent or flow. Put your sensitive-data connectors in one group, your general-internet and unvetted connectors in another, and the platform enforces the separation for you. Block the connectors you have no business case for outright. Pay particular attention to the HTTP and custom-connector building blocks, because those are the generic escape hatches that route around every specific rule you wrote.
The mistake we see is a single tenant-wide DLP policy set once and never revisited. Connectors ship constantly; a permissive default today is an unreviewed capability tomorrow. Assign the policy per environment where the risk profile differs, and put connector review on a recurring calendar rather than treating it as a one-time configuration.
Maker sprawl is the 2020 pattern in a new costume
A 9,000-seat health system ran a Copilot Studio pilot late in the winter, and the pilot did exactly what a good pilot should: it surfaced the governance gaps before they became production incidents. Two months in, we did an inventory. There were already thirty-one agents in the Default environment. Roughly a third were abandoned experiments with no owner. Several were reading from SharePoint sites carrying broad org-wide sharing — the same oversharing pattern that makes Copilot for Microsoft 365 hazardous, now with a purpose-built bot handing the content to anyone who could open the chat. One agent had been published to an external-facing channel by a maker who did not realize "publish" meant "publish to the internet."
Nothing there was malicious. Every one of those agents was someone trying to solve a real problem with a tool they had been told they were allowed to use. That is the point: sprawl is not a discipline failure by the makers, it is a design failure by whoever left the defaults in place. The pilot's most valuable output was not a working agent — it was the thirty-one-line inventory that made the steering committee understand what "just let people build" actually meant, and it bought the environment strategy above a budget it would never have gotten as an abstraction.
We ended that engagement with a maker onboarding gate: a short review before anyone gets build access to a managed environment, an ownership record for every published agent, and a quarterly sweep that archives anything with no owner or no usage. Unglamorous, and the entire difference between thirty agents and three thousand.
The other lesson the pilot taught, quietly, is that the makers were not the problem and treating them as one is how governance programs earn their reputation for obstruction. The thirty-one agents represented thirty-one real problems that thirty-one people cared enough to try to solve on their own time. A governance model that responds by locking the door teaches those people to route around IT the way they routed around it to build the agents in the first place. The model that works pairs the rails with a fast yes: a light intake, a named platform contact, a template environment already wired with the right DLP policy, so the sanctioned path is genuinely easier than the shadow one. Governance that is slower than the workaround does not prevent sprawl, it just moves the sprawl somewhere you cannot see it, which is strictly worse than the visible version you started with.
Licensing and message packs, before the surprise invoice
Copilot Studio consumption is metered in messages, and the billing is not intuitive, so it belongs in the plan rather than the postmortem. Agent interactions draw down a message allowance; different action types — a generative answer over your documents, a classic topic, an action that invokes a connector — consume different message quantities per interaction. You buy capacity in message packs, and a single popular agent can burn through a pack faster than anyone modeled if usage takes off.
Model this before you publish anything to a wide audience. Estimate interactions per user per day, multiply by the message cost of the interaction types your agent actually uses, and buy packs against that with headroom. Then wire capacity monitoring so you see consumption climbing rather than discovering it when agents stop responding mid-month. We have watched a genuinely successful internal bot get throttled at the worst possible moment because nobody owned the capacity number, which is a miserable way to reward the one team that adopted the thing enthusiastically.
When Studio is right, and when it is the wrong tool
Not every generative use case should be a Copilot Studio agent, and part of governance is steering the build to the right platform. Studio earns its place when the job is conversational question-answering over a defined content set, the makers are business users rather than engineers, the actions are low-consequence, and time to value matters more than deep customization. An HR policy bot, a facilities helpdesk, an onboarding guide — Studio is genuinely good at these, and telling a capable business team to go build a custom app instead would be its own kind of malpractice.
You reach for a code-first Azure OpenAI build when you need control the low-code surface cannot give: custom retrieval and ranking, specific grounding and chunking behavior, tool orchestration with real validation, latency and cost tuning, or a security posture that has to be argued line by line to an auditor. The heuristic we use: if the requirement sentence contains "and it must," Studio is probably the wrong tool, because "must" is where low-code abstractions stop bending. The two are not competitors so much as different rungs, and part of the governance conversation is making sure the choice is deliberate rather than a function of who happened to be in the room when the idea landed.
If you're facing this
Copilot Studio is going to arrive in your tenant whether or not you have decided how to govern it, and the honest question is only whether the environment strategy and the DLP policy exist before the first thirty agents or after. If you are about to open the maker floodgates and the rails are not down yet, that ordering is worth fixing this quarter. Get in touch and we will help you set the guardrails before the sprawl instead of after.