Who Can Build Copilot Agents, and How to Set the Limits

A policy question that looks like a setting

Microsoft Copilot (formerly Microsoft 365 Copilot) lets people build their own agents in more than one place. Anyone with Copilot Chat can make a simple one in Agent Builder, agents can be created on SharePoint sites, and employees who build agents with actions or connections to other systems, whom Microsoft calls makers, use Copilot Studio. Microsoft's comparison of the two builders notes that the richer capabilities draw on Copilot licenses, prepaid capacity or pay-as-you-go billing. The IT lead can restrict part of this from the admin centers. What the settings should say is a separate question, and it belongs to the people who carry the risk and the cost: the IT lead who owns the company's Microsoft 365 environment (the tenant), the compliance lead who answers for the data, the CFO who pays for licenses and usage, and in Germany the works council.

We see two failures. Some companies leave the defaults on, and agents spread through the tenant before anyone reviews them. Others switch off everything they can find, and people may turn to public tools instead. The four decisions below sit between those two, and each maps to a control Microsoft documents. The paper Copilot after rollout places them in the wider set of agent guardrails.

Decide by reach

The useful line runs by reach rather than by tool. A personal agent, used only by its maker, sees only what that person can already open, so the risk is small and the rule can be light. Team agents need an owner and a review date. For an agent the whole company can use, or one that takes actions in other systems, a named reviewer should sign before it is published. Microsoft runs its own tenant along these lines. Its Inside Track team reported in November 2025 more than 100,000 agents on the Microsoft tenant, with personal agents kept in a safe space and team and line-of-business agents reviewed.

The tier method, with what a reviewer checks at each level, is set out in our guide to citizen-built agents. For the decision group, one rule per reach level is easier to agree and to explain to staff than a rule per tool, and it survives Microsoft renaming or adding builders.

Decision one: who may build at each level

We would let everyone build personal agents, ask for a short maker course before someone builds for a team, and limit anything that runs actions, uses connectors or reaches the whole company to named makers. Microsoft's controls fit this only in part. In the Microsoft 365 admin center, agent settings decide who may use agents (all users, no users, or named groups) and who may share Agent Builder agents with the whole organization. Microsoft documents no switch that stops users creating Agent Builder agents, and even with organization-wide sharing set to "No users", people can still share with named colleagues. The rule on who builds what therefore has to live in the policy, with the tenant enforcing the limits on sharing and publication.

Copilot Studio has its own controls in the Power Platform admin center. The "Copilot Studio authors" setting grants authoring to a security group, but it does not take authoring away from people who hold a Copilot license, according to Microsoft's troubleshooting guidance. Environment routing, a premium governance feature, sends makers into separate, company-governed workspaces of their own, which Microsoft calls managed personal developer environments, instead of the shared default one, per Microsoft's environment routing page. Routing alone does not decide who may build shared agents, so for those IT uses dedicated environments with restricted access. Unmanaged developer environments are suspended from 15 December 2026, and from February 2027 users without a license cannot open apps in managed environments, so the routing decision is also a cost decision for the CFO. The three-zone environment layout in our Copilot Studio implementation guide is one way to arrange it.

Decision two: who approves an agent for the whole company

When a maker submits an agent for the organization, it lands in a Requests queue in the Microsoft 365 admin center, where an admin publishes it to the store or rejects it, per Microsoft's agent actions documentation. The queue does not say who should look at it. We put two people on it: someone from IT who checks the agent's connectors and whose credentials they use, and the compliance lead or a delegate who checks what data it reaches and who will see its answers. Microsoft now gives Copilot Studio agents their own identity in Entra, and our page on agent identity explains what that means for the review.

Decision three: which connectors and data makers may use

This one belongs to the compliance lead, and Power Platform enforces it. Data policies sort connectors into Business, Non-business and Blocked groups, and for agents they can block unauthenticated chat, HTTP calls, skills, event triggers and publishing channels such as Teams or SharePoint, per Microsoft's page on data policies for agents. Managed Environments add sharing limits, so makers can share only with individuals and only up to a set number of viewers, while access that already exists stays as it was.

The risk is concrete. Datadog Security Labs showed in October 2025 that a Copilot Studio agent's demo website, hosted on a Microsoft domain, could be fitted with a fake sign-in step to steal the sign-in tokens that give access to connected services, a technique it called CoPhish. Its suggested fixes included a tighter app consent policy and monitoring of agent creation events, both of which the compliance lead can ask IT to show.

Decision four: who owns an agent, and what happens when they leave

Every shared agent needs a named owner, and the policy should say what happens when that person moves on. Microsoft's own tenant deletes individually owned agents when the employee leaves and keeps team agents on a lifecycle tied to attestation, in which owners confirm at intervals that each agent is still needed, per the same Inside Track report. In the admin center, owners of Agent Builder and Copilot Studio agents can be reassigned, and a management rule can hand ownerless Agent Builder agents to the former owner's manager. The how-to on Copilot Studio agent guardrails shows the controls for one agent end to end.

Worked example. A manufacturer could write the whole rule in four sentences of its AI policy. Everyone may build personal agents in Agent Builder. Team agents need the maker course and a named owner, and shared agents in Copilot Studio are built only by trained makers, in environments whose access IT restricts to them. Anything shared with the company goes through the Requests queue with an IT reviewer and a compliance reviewer. IT then tests the settings with an account that should be refused, so an auditor can compare the policy with what the tenant actually does.

The case for leaving creation open

Restricting personal Agent Builder agents can push staff toward tools the company cannot see, and we take that argument seriously. A personal agent works with what its maker could already find, so blocking it protects little and teaches people that the company's AI tools are the awkward ones. Staff who cannot build at work can still build with consumer tools on their phones, where the company sees nothing. The controls that matter sit at the points where an agent's reach grows, which are sharing and connections to other systems. Keeping creation open and putting review at those points gives the compliance lead a shorter list to review, and gives staff a reason to stay inside the tenant.

Where QueryNow fits

QueryNow writes these maker rules with your decision group and then sets the tenant to match, as part of our Copilot AI Foundation service. That covers the agent settings in the Microsoft 365 admin center, Copilot Studio environments and routing, connector data policies, the review route for company-wide agents, and maker training tied to each level. We have been a Microsoft partner since 2015, and the setup goes to your IT team with a runbook rather than staying with us.