Copilot Studio Chatbots want EVERYONE to talk to them - here’s what you can do about it

Images in this post generated by Microsoft Copilot

This is a personal blog and all content therein is my personal opinion and not that of my employer.

Introduction

In this post, I’m going to talk about an issue I spotted recently in Power Platform and by extension Copilot Studio.

The Issue

I was doing some work to harden an Azure tenant and inadvertently broke a bunch of chatbots in Copilot Studio.

The subsequent investigation was eye-opening and highlights some poor security design choices by Microsoft in a product suite (Power Platform) that I already knew to have a problematic security model/design.

What Is Power Platform?

Power Platform is a collection of low-code/no-code tools that enable users to build custom business applications, automate workflows, and analyze data.

The key products in the suite are:

1. Power Apps lets you build custom low-code business apps
2. Power Automate lets you automate business processes
3. Power BI lets you visualise and analyse data
4. Power Pages lets you create low code websites
5. Copilot Studio (Formerly Power Virtual Agents) lets you build and manage copilots (chatbots)

What happened?

A colleague had configured a monitoring rule in a tool to detect and alert on Multi-Tenant App Registrations in Azure.

It highlighted a number of them that met this criteria and we got them changed to Single Tenant.

In the days that followed we had some complaints that some chatbots had broken and the timing aligned with that change to the signinAudience of the App Registrations for the affected chatbots.

After a thorough investigation into various settings - it seemed the only option left was to flip the app registrations back to Multi-Tenant. And the chatbots instantly started working again.

Concerns

These were internal only chat bots with no need for anyone external to interact with them.

The setting on an App Registration doesn’t let you select specific tenants - it’s the tenant that the app registration is in or ANY tenant.

I also found during my investigation that there is no RBAC on the copilots - there is instead a sharing control that controls who you can share the app with and by default it allows you to share with EVERYONE in your tenant including guests and external users. So anyone that somehow gets access to what the url for a given copilot is, can access.

In addition, by default you are allowed to configure your copilot with an authentication mode of… No Authentication.

This is, if nothing else, a data breach waiting to happen.

I’m left feeling like the security model of Power Platform is as effective as this gate:

Microsoft’s Response

I haven’t raised with Microsoft Security Response Center because this isn’t a vulnerability, it’s an insecure design choice.

I raised with Microsoft support and was advised that this is intended behaviour and that Copilot Studio doesn’t support single tenant app registrations and always creates Multi Tenant app registrations when you create a copilot.

They did advise that they have a feedback request open for customer feedback on adding single tenant support - by now I think you know what I think about using these types of customer feedback sites for submitting feature requests; it’s typically where feature requests go to die!

I was also directed to an FAQ page where Microsoft asserts that it’s not an issue because the “app registration does not access or expose any customer data, resources, or any copilot information. Copilot Studio stores and manages the app registration securely and compliantly”.

They then give a little more insight as to why the multi-tenant configuration is needed - ”for validating and securing calls from Copilot Studio to our Azure Bot Service resource”.

This concerns me not only because of the overly open inbound comms to the customer tenant but also because Microsoft don’t have the best track record on ensuring tenant separation in their services - I wrote about this previously here.

I challenged that response and an escalation engineer provided some additional information that can help reduce the risk, in addition to controls that were already in place.

Minimising The Risk

1. Configure Cross-Tenant Access Settings to control inbound access to your tenant from only tenants that you trust and authorise.

2. Restrict the ability to invite guests.

3. Restrict guest permissions.

4. Disable the ability to share any new copilots with “EVERYONE” via the following powershell code as a Power Platform Administrator:

   $tenantSettings = Get-TenantSettings
   $tenantSettings.powerPlatform.powerApps.disableShareWithEveryone = $true
   Set-TenantSettings $tenantSettings
   

5. Disable the ability to configure “No Authentication” by enabling the appropriate DLP connector.

6. The eagle-eyed among you will have noticed that steps 4 and 5 only apply to anything deployed new after you set them. You will need to, as a Power Platform Administrator, amend the configuration of apps already deployed before these tenant-wide changes were enabled. You can use the Power Platform Admin Powershell module to make this less onerous. (This is probably a blog post in its own right!)

Whilst this does make quite a large reduction in the risk, I would still advise you to closely monitor your Copilot Studio chatbots and their configuration.

Microsoft needs to do a lot more in this space to provide far more robust controls.

Call To Action

Since Microsoft won’t do anything, I’m asking you to:

1. Share this blog post far and wide!
2. Upvote this feedback request which is seeking feedback on the idea to support Single-tenant app registrations for Copilot Studio.
3. Raise it with Microsoft Support if you have a support plan
4. Raise it with your Microsoft account team

Acknowledgements & Prior Work

As with all things in life, nothing we do is ever 100% original and usually builds on prior knowledge/works.

To that end, I want to call out and thank Michael Bargury, Co-Founder and CTO at Zenity for his great work on No-Code/Low-Code security and especially Power Platform security.

He is the creator of the PowerPwn offensive/defensive security toolset for Power Platform.

We owe him thanks for the tenant-wide switch to disable Sharing with Everyone - it exists because of his research.

We also owe him thanks for exposing issues with default guest permissions in m365.

Summary

As ever, thanks for reading and feel free to leave comments down below!

If you like what I do and appreciate the time and effort and expense that goes into my content you can always