An administrator creates a security group, assigns it to the Copilot Studio authors setting in the Power Platform admin centre, adds the three approved makers, and closes the ticket. A month later there are eleven agents in the tenant built by people who were never in the group. Nothing malfunctioned. The setting simply does not do what its name suggests, and Microsoft's own support documentation now has a dedicated page explaining the misunderstanding because it comes up so often.
This guide walks through what the Authors group actually does, where agent creation really leaks from, and the sequence of controls that holds: data policies, default environment hardening, trial-licence lockdown, and the sharing governance that separates who can create agents from who can use them.
Why the Authors security group blocks nobody
The Copilot Studio authors setting grants access; it does not revoke it. It exists to let a named group author agents under pay-as-you-go billing. Per Microsoft's troubleshooting guidance, a user is only blocked from Copilot Studio when all three of these are true at once: they are not in the Authors group, they hold no Copilot Studio per-user or trial licence, and they hold no Microsoft 365 Copilot licence.
That last condition is the one that surprises people. Every Microsoft 365 Copilot seat in the tenant carries Copilot Studio access with it, because the paid licence includes building agents that extend Copilot. Roll out 200 Copilot seats and you have 200 potential agent makers, regardless of what the Authors group says. Add self-service trials, which any user can sign up for unless blocked, and the group is a velvet rope.
The real leak: Environment Maker in the default environment
Copilot Studio agents live in Power Platform environments, and authoring requires the Environment Maker role in whichever environment the maker lands in. The catch is the default environment: Microsoft's guidance is blunt that every employee in an organisation using Power Platform has access to it. It cannot be deleted, it is where users land when nobody has designed anything better, and it is where unsanctioned agents accumulate. Blocking agent creation is therefore mostly a job of governing the default environment, not of managing a licence group.
Data policies: the control that actually holds
Data (DLP) policies in the Power Platform admin centre are enforced against Copilot Studio in real time, and since early 2025 enforcement applies to all agents in all tenants, with the old per-agent exemptions withdrawn (Microsoft announced this in message centre item MC973179). When a policy blocks something an agent uses, the maker sees the violation in the designer and the Publish button becomes unavailable. That is a hard stop, which is exactly what the Authors group is not.
Copilot Studio's capabilities appear as named connectors you can block per environment. The ones that matter most for stopping unsanctioned agents in the default environment:
- Chat without Microsoft Entra ID authentication in Copilot Studio: blocking it means no maker can publish an agent that skips user authentication, closing the anyone-with-the-link hole.
- The knowledge source connectors (SharePoint and OneDrive; public websites and data; documents): blocking these stops agents being grounded in organisational or arbitrary web content. Endpoint filtering can allow specific sites instead of a blanket block.
- The channel connectors (Microsoft Teams + Microsoft 365, Direct Line, SharePoint, WhatsApp, Facebook, Omnichannel): if no channel is permitted, agents cannot be published at all, which in the default environment is a legitimate end state.
- HTTP, and Power Platform connectors used as tools: blocking these removes an agent's ability to call external services, including tools reached through MCP servers, which ride on Power Platform connectors.
- The Microsoft Copilot Studio connector itself: blocking it prevents event triggers, which is what stops autonomous agents from running unattended in the environment.
For a managed default environment, Microsoft's published recommendation goes further: scope a policy to the default environment only, leave Business and Non-business empty, and block all connectors via advanced connector policies. Pair that with setting the default group for new connectors to Blocked, so anything Microsoft ships next month arrives unusable until reviewed.
Shut the trial-licence side door
Even with the environment locked down, users can self-provision Copilot Studio trials unless you block the sign-up paths. Two supported levers, both PowerShell:
- 1Block email-based self-service sign-ups tenant-wide with Microsoft Graph PowerShell: Update-MgPolicyAuthorizationPolicy with allowedToSignUpEmailBasedSubscriptions set appropriately (the Copilot Studio documentation provides the exact script). Then unassign any viral licences already granted, in bulk, from Billing > Licenses in the Microsoft 365 admin centre.
- 2Disable self-service purchase per product with the MSCommerce module: Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase lists every product and its state; Update-MSCommerceProductPolicy with the product's ID and -Enabled $False turns off trials and purchases for that product, Copilot Studio included.
Separate creating agents from using agents
Most organisations do not actually want zero agents; they want agents built in a governed place and consumed widely. That split is what the sharing controls are for. In the Power Platform admin centre, sharing controls for Copilot Studio let you block or limit makers from sharing agents with individuals as editors, with viewers, or with security groups, and managed environments add sharing limits on top. The working pattern Frontrow sets up is a locked default environment (the DLP wall above), a dedicated maker environment with Environment Maker granted to a real, reviewed group, and sharing rules that let finished agents reach users without letting users become accidental co-authors. For what belongs inside that governed build process, Frontrow's guide at /insights/copilot-agents-australian-playbook covers the path from idea to first production agent.
Since mid-2026: every new agent gets a Microsoft Entra Agent ID
One more change reshapes the governance conversation. Copilot Studio now creates a Microsoft Entra Agent ID for every new agent automatically. The capability previewed from late 2025, and with the May 2026 rollout new agents switched from app registrations to Agent IDs and the environment-level opt-out was removed (per Microsoft's Copilot Studio documentation, checked August 2026). As at August 2026 there is no setting that prevents it; agents created before the rollout keep their older app-registration identities until Microsoft migrates them. The upside for admins is real: agent identities appear in the Microsoft Entra admin centre with sign-in and audit logging, the Power Platform connectors an agent uses show up as API permissions on its identity, and those permissions can be targeted with Conditional Access policies such as network location or risk conditions. Deleting the agent deletes the identity with it.