Power Platform | Securing copilot development

In my previous article, I proposed the idea of creating a copilot developer experience that allows developers to work together on designing and building copilots, specifically when using generative AI and using company data sources for grounding. I also mentioned the documentation that I found, which had this statement: To share a bot with others in the environment, users must have the Environment maker security role.

Share copilot dialog

I wanted to test it in one of my development environments where my Power Admin (who has the Environment Maker and System Administrator roles) created a copilot. To collaborate with user Carl (who only has the Basic User role), I shared the copilot with him. However, since he doesn’t have enough environment permissions, the dialog above shows that the Environment maker role is automatically selected when sharing.

I wonder if there are other options besides assigning the Environment maker security role to all developers in an environment. This might be suitable for some developer collaboration scenarios, but it seems to violate the principle of least privilege. The Environment maker role grants access to 164 tables and 8 miscellaneous privileges. Are these all necessary for copilot development?

Design a Custom Copilot Author security role

I created a custom security role and set the table permissions that a user would need to use this role. The visual above shows that my role only contains 65 tables and 5 miscellaneous privileges, which are not visible in the image. I assigned this role to one of my developers, Sanjay, in this environment. Here is the outcome.

Share copilot dialog – showing a difference in Environment security roles section

As you can see, the Environment maker security role is no longer pre-selected. So, I completed the sharing process and logged in as Sanjay to examine the outcome of sharing the copilot.

A shared copilot in edit mode experience

My user can interact and collaborate with the original copilot author seamlessly and enhance the copilot experience. This was a successful outcome of creating a custom security role and assigning this role to my developer before starting the sharing process. For daily use, I can now make sure that my copilot developers get the new security role automatically – for example, by creating a security group that assigns this role to every member.

Share copilot dialog – sharing a shared copilot with a user with insufficient permissions

The final step was to test what happens when Sanjay shares the copilot with other users. The image above shows the outcome of his attempt to share it with Carl, who is not a developer in this environment and only has the Basic user role. This is an excellent result, because Sanjay does not have the permission to „promote“ Carl to an Environment maker. This way, I can ensure that I have control over the access level for my developer environment(s).

Share copilot dialog – sharing a shared copilot with a user assigned the custom copilot security role

Suppose this project requires another developer and Julian needs to work on this copilot. The share dialog visual above shows the result of Sanjay sharing the copilot with Julian. Copilot permissions are already set, and there is no Environment security section to avoid unnecessary access. Julian can then interact and collaborate with the other copilot developers on this project.

This brief exercise demonstrates that it is sometimes valuable to understand the underlying mechanisms and explore the custom options to enhance the security of your Power Platform environments and to monitor the developers who are granted privileges. I hope this exercise encourages you to invest your time in a Power Platform environment strategy that includes the security role assignment process. I am confident that there is more to discover when we discuss using „Managed environment“ and features such as Environment groups. Until then,…

Update: As I received a lot of requests around how such custom security role could look like, please find my composed security role here.

Power Platform | Bot Authoring role

The other day, I received a request about „What happened to the Bot Author role?“. Do you recall that role from the old Power Virtual Agent days? If not, here’s a brief explanation. Previously, a Power Virtual Agent license enabled global admins to designate certain users who could use Power Virtual Agents in your tenant. System administrators for each environment could restrict who could create bots in that environment. This was done by following these steps:

1. Create a new environment that you want users to create bots in (make sure Dataverse created)
2. Launch Power Virtual Agents and create a bot in the environment
3. Go to Power Platform admin portal to assign security roles
4. Assign ‚bot author‘ role to users that you would allow creating bot in that environment

Bots and Power Virtual Agents are things of the past. Nowadays, we use Microsoft Copilot Studio to customize and build our own copilots or enhance the one for Microsoft 365, right? Therefore, no longer we need to assign users to „Bot Author“ role. Neither, we need to assign them the following license part shown in visual below, if you got Office 365 E5 licenses purchased for your tenant.

Microsoft 365 Admin Center – User assigned licenses and options for Office 365

I keep saying this because I ran a test with the user Sanjay, who is shown in the image above, to access Microsoft Copilot Studio.

Microsoft Copilot Studio – showing a prompt to start a free trial

This user expected to get access to Microsoft Copilot Studio and begin creating their own copilots, but they received a message to sign up for a free trial instead. In my test environment, I did not restrict users from signing up for free trials. However, if one of your admins has applied this restriction to your tenant, you may see a different message here.

It seems obvious that with the change to Microsoft Copilot Studio, you now need to assign the user a Microsoft Copilot Studio license instead now. Once this has been assigned to above user Sanjay in my case, this user successfully enters the Copilot Studio experience.

Microsoft Copilot Studio – first time entering after a license being assigned

As shown in the image above, the user is directed to their default environment and prompted to verify their country/region information, which is obtained from their Microsoft Entra information. After confirmation, if this user is trying to switch the environment, this is what´s shown.

Microsoft Copilot Studio – Environment selector

This user only has access to the Default environment, and no other „supported environments“ are displayed for this user. This is because the user has the Environment Maker role for the Default environment, which is unavoidable. However, the user does not have this role for any other environments. You may wonder why this could be a problem?

What if you want to prevent your users in the Default environment from creating new copilots, especially those that use generative AI and other features such as Plugin actions and connectors, you can do the following:

• If your environment is eligible for an opt-in to Generative AI features, you could opt-out for moving data across regions – though this would cause all other Power Platform Generative AI to stop working as well
• Setup a data policy for the default environment that blocks Copilot Studio Connectors

Instead of disabling the Generative AI features for the entire Default environment, I suggest choosing the second option. You may also need to adjust some of the data policies later when you customize Copilot for Microsoft 365.

How about setting up a copilot developer experience where developers can collaborate on the design and creation process of copilots? When I followed this link, one thing caught my attention: Users in the environment need the Environment maker security role to share a bot with others.

Let´s explore this in my next episode and see why would consider least privilege a best principle, even though we should trust developers for being skilled to understand about their opportunities given. Until then,…

Power Platform | Extend your Environment strategy by data policies

I was recently talking and sharing experiences around the importance of having a scaleable environment strategy these days. This due to new features being added by the product team that may become part of specific company requirements, such as the recent EU Data Boundary. A Power Platform environment being a space to store, manage, and share your organization’s business data, apps, chatbots, and flows. It also serves as a container to separate use-cases that might have different roles, security requirements, or target audiences. Based on this definition we could easily understand environments being the foundation of your data strategy as well. So why do I come up with this topic?

By 2025, 70% of orgs will need to shift their focus from big data to small and wide data in order to take full advantage of their available data sources

Gartner via Twitter

We have to understand that with each environment in Power Platform there´s data floating around, but also being actively part of an environment (yours using Dataverse or Azure Synapse Link for Dataverse). So you can imagine if we take Gartner´s prediction for granted to focus from big data to small and wide data, we should think of Dataverse being a central part of this focus and therefore an essential for your environment strategy containing data policies.

Power Platform Admin Center – DLP Policies dialog

Talking about Data policies you may first think of the Power Platform Admin Center interface and setting up your policies. Those can be on Tenant level, or individual (on Environment level) based policies. There´s been a lot of improvements made from the UI perspective, such as not only containing the pre-built connectors, instead allowing the control of custom connectors as well. The visual above outlines this is the dialog path to follow.

DLP Policies – Dialog – Custom connectors

This can become quite flexible though intense work managing a couple of environments inside your tenant and understanding the various combination of policies in practice. In fact, I´ve seen many times the DevOps team being contacted because of a DLP policy blocking a Maker´s work from being saved or executed.

Of course you could now consider deploying an environment each time you do have special requirements in terms of either a prebuilt- or a custom connector, but that could easily end up in a couple of environments. So what´s the alternative here? Let´s say you have a shared environment where you set a combo of DLP policies to work in. Let´s continue the journey by saying there´s a special team acting in that environment that would love to use one of the SAP connectors. As the SAP data should be used to enrich existing data from Dataverse you could now consider to modify the DLP policies and allow for using the SAP connector. But you don´t want this to be used by other users of this environment. You are kind of in a dilemma, aren´t you?

Well, there´s an almost unknown feature of DLP policies. What? You´ve missed something? Well, did you know there´s the possibility of DLP resource exemption. It´s available only via PowerShell cmdlet at the moment and I really would love to see this feature becoming available via the UI instead. In the previous link shared, you´ll also find a given example for an app and a flow that you do want to launch by becoming DLP exempt.

Given this example, you can imagine that your data strategy can become both flexible though governed in granular ways. Let me know in your comments, if you´ve been using this DLP feature via PowerShell and your experiences with it. Until then,…