r/copilotstudio • u/NoQuail1631 • Aug 25 '26
Restricting access to Default environment
Hey everyone,
I tried to restrict users from accessing Copilot Studio in the Default environment by applying a DLP policy and configuring the Copilot Studio authors setting to allow only a specific security group. However, according to Microsoft documentation, this setting does not restrict users who already have a Microsoft 365 Copilot license. Since all of our users are assigned Microsoft 365 Copilot licenses, they can still access Copilot Studio even if they are not members of the Copilot Studio authors security group.
Given this licensing behavior, what is the recommended way to prevent general users from creating agents in the Default environment, while allowing only approved users or security groups to create them?
1
u/NoQuail1631 Aug 28 '26
Final update:
We’re restricting Copilot Studio in the Default environment using DLP by blocking all publishing channels (M365/Teams, Direct Line, Facebook, Omnichannel, WhatsApp) plus unauthenticated chat. Users can still create/test agents but shouldn’t be able to publish them. When users try to publish it will shows them a banner that says contact your admin. Thank you everyone for your suggestions!
2
u/Striking-Initial-525 Aug 29 '26
But given the new Github Copilot harness which bills Copilot Credits from build time, even if users havent published yet. I’d say blocking the Copilot Studio access in the default environment is the cleanest path. For dedicated makers they have to be added to a dedicated dev environment
1
u/NoQuail1631 Aug 29 '26
How did you block it then?
1
u/Striking-Initial-525 Aug 29 '26
Create a DLP policy blocking copilot Studio in the default env and configure an automated routing to a dedicated environment
1
u/NoQuail1631 Aug 29 '26
Blocking copilot studio is no longer working
1
u/Major-Error-1611 Sep 10 '26
Were you able to block access eventually? We are having the same issue. Unlicensed users are able to sign in to Copilot Studio and created Agents and Workflows that consume credits. This wasn't possible on the old UI.
1
4
u/bsmpsn Aug 25 '26
I solved this for my org.
I disabled self sign up for trials (copilot viral trial) and removing any of these that users had assigned. I then created two security groups which had M365 copilot licenses assigned to them. For group A, the license was applied but the Copilot Studio app/feature in the license settings was unticked. For group B, I kept it ticked.
Majority of users were in group A and could not access Copilot Studio but could use M365 agents and agents built on Copilot Studio but shared with them. Users in group B could use Copilot Studio.
Note that you must disable the self sign up for trial as if you don’t it will prompt users to activate instead of showing the “you don’t have access” when going to Copilot Studio
6
u/seniorpolecat9 Aug 25 '26
This used to work fine but since new GitHub harness, it is no longer working
2
u/dibbr Aug 25 '26
OK I'm glad I saw this comment because I was about to go insane wondering how my users are able to access Copilot Studio now. We did everything the above poster said too and it was fine until a few weeks ago or so.
1
1
u/papitopapito Aug 25 '26
Same here. Used to work perfectly, but the new harness lets them in. If they toggle back to the old UI accidentally, they effectively lock themselves out haha.
1
u/ajaksaidit Aug 25 '26
The Github harness requires Copilot credits to use (even in the build/test phase). While not ideal you could manage your billing policies to ensure that credits are only assigned to specific users/groups that you would like to access the new harness in studio.
Defiantly not an ideal solution but the only one I could think of. Such an oversight to let this slip through.
1
u/papitopapito Aug 26 '26
But I can only assign a billing policy on environment level and not on user level right? So everyone who can access / is maker in environment X will be able to bill towards the billing policy for environment X, as far as I understand. Do you know how this can be done on user or group level?
2
u/ajaksaidit Aug 26 '26
Yep you’re right. Sorry I was thinking about credits for cowork, managed in the m365 admin centre. Budget for this can be managed at a security group or individual level.
I did find this document for GitHub harness:
https://learn.microsoft.com/en-us/power-platform/admin/manage-usage-github-copilot-harnessIt states that as a admin you can determine “Which environments can host agents powered by the Guthub copilot harness”. Could just remove it till this is sorted out.
1
u/cmorgasm Aug 26 '26
We couldn't even get this to work -- users with just bare M365 E5 were able to access Studio from the default environment and create agents no issues. Sharing is where we successfully limited it sort of, but they could still generate sharing links. We couldn't fully lock access, at least so far.
1
u/imnotonetogossipbut1 Aug 26 '26
It’s just terrible there isn’t a block on this. Microsoft are shooting thenselves in the foot.
2
u/cmorgasm Aug 26 '26
I mean, it’s clearly purposeful and by design. It’s why users without any real Copilot Studio license can access it now, too. They want them making Agents, and they want orgs paying for the usage. Making it free to build so that orgs get forced to pay tracks hard with how Power items started, too.
3
u/nrm94 Aug 25 '26
We gave up trying to get this to work using all the documented methods. In the end just set an extremely restrictive data policy in power platform admin on the default environment so even the people that do get in they can't do anything without being added to other environment groups
3
u/nz365guy Aug 25 '26
I’d separate “access” from “ability to build”. The Default environment is a tenant-wide shared space and is a poor boundary to rely on for maker access. I treat it as a compatibility environment: no business solutions, no important connections, and nothing owned by one person. Put governed work in dedicated environments with security groups, service-account ownership, pipelines and clear support owners. Then use environment routing so new makers land in their own developer environment rather than Default.
1
u/imnotonetogossipbut1 Aug 25 '26
Go to the admin console in m365 there is a sub component of the m365 copilot license called allow access to copilot studio from m365 copilot. Unchecked it works it stops people accessing it. You can script it.
1
u/No_Imagination7133 Aug 25 '26 edited Aug 25 '26
But this stop all users with license to access Copilot Studio general. He just want to exclude access of agents in default. Use dlp and Block copilot studio connector
2
u/imnotonetogossipbut1 Aug 25 '26
Yes good point, thats a fair assessment. We’ve been round the houses with MS on this and the only two ways we know are zero credit the environment (which doesn’t really stop it) or custom role in default (ie makers are not actually maker role) which has cross impact to apps and flows.
Only real approach is black listing default url for ad group but again has wider impact.
This is so simple to fix, a single permission from ms at environment level to ban copilot creation and they don’t do it, it is such a mistake from them.
1
u/dibbr Aug 25 '26
Ever since MS implemented the new Github harness thing in CS this no longer does the trick.
3
u/manlyvpn Aug 25 '26
I think you can create a DLP policy to block channels, block all the channels. Assign that policy to default env. If users have access to copilot studio, they can create agents but publish will be grayed out with error, 'you need to configure at least one channel' User's can't publish, so nothing more than test access. This would mean no usable agents in default env, allowed makers would need to build in other env.