What is connecting Copilot agents to Dataverse, Graph, and connectors, really?

When people hear “Copilot Studio agent,” they picture a chatbot. That’s the wrong mental model. A modern agent is a reasoning layer sitting on top of three very different pipes: your business data in Dataverse, your organisational content in Microsoft Graph, and the wider universe of SaaS via Power Platform connectors.

Each pipe has its own auth story. And that’s where almost every SMB and MSP rollout I see comes unstuck.

That’s not a configuration problem. That’s an identity problem dressed up as a configuration problem.

Step-by-Step: wiring an agent to the three pipes

Set the agent’s authentication first

Before you add a single tool, go to Settings → Security → Authentication in your agent. Pick Authenticate with Microsoft. This uses Microsoft Entra ID to identify whoever is chatting — and it’s the prerequisite for almost everything that follows.

Skip this step and your agent runs as nobody. Which means it can’t read Dataverse on the user’s behalf, can’t honour SharePoint permissions, and can’t call a connector as the signed-in user. Get the front door right and the rest gets easier.

Add a Dataverse table as knowledge

Open Knowledge → Add knowledge → Dataverse. You can wire up to 15 tables per agent. Two things that catch people out:

Dataverse search must be enabled on the environment first.
Add synonyms and glossary terms for any column where your users speak a different dialect to the schema.

“Why doesn’t it find my open opportunities?”

Because your column is called statuscode and your users say “stage.” Synonyms fix that.

Add a Microsoft 365 Graph connector for content

Graph connectors are the other knowledge model — they index external content (Jira, ServiceNow, file shares, intranets) into the same semantic graph that Copilot already uses for Teams, SharePoint, and mail. Set them up in the Microsoft 365 admin center → Search & intelligence → Connectors. ACL-based permission trimming is preserved, so users only see what they’re allowed to see. Microsoft has a clear overview here.

Notice what’s missing? Dataverse is agent-scoped knowledge. Graph connectors are tenant-scoped knowledge. Different governance owners. Plan accordingly.

Add a connector as a tool

In your agent, Tools → Add a tool → Connector. Pick a standard, premium, or custom Power Platform connector. Now the agent can act — create a row, post to Teams, hit your line-of-business API.

Tool = action. Knowledge = retrieval. Don't confuse the two.

Pick the right credentials mode

Every tool asks one question that quietly decides your security posture: Maker Credentials or End User Credentials?

Maker Credentials: the connection runs as you, the builder. Easy demos. Terrible for anything user-specific.
End User Credentials: each chatter authenticates with their own account. Slightly more clicks for users. The only sensible default for production. Details here.

My recommendation? Default to End User and only fall back to Maker when there’s a genuine service-account scenario — like reading a shared mailbox.

Why this actually changes behaviour

Here’s the real win. Once authentication is correctly threaded through the agent, the same prompt produces different, personally-relevant answers for every user — because it’s their identity flowing into Dataverse, their Graph results coming back, their connector permissions being honoured.

That’s not a chatbot. That’s a tenant-aware assistant.

The other thing I notice with clients: governance conversations get easier. “Who can see what?” becomes a question of existing Entra groups and Dataverse row security — not a brand-new permissions matrix you have to invent for the agent.

Get the auth pattern right once and every agent you build afterwards inherits it. Get it wrong and you’ll be unpicking the same mess for months.

Wire the pipes. Mind the credentials. Ship something your clients actually trust.

Script to report tenant users

I have created a script that uses the Microsoft Graph to report users for the tenant as shown above. You’ll find it here:

https://github.com/directorcia/Office365/blob/master/graph-users-get.ps1

along with the documentation here:

https://github.com/directorcia/Office365/wiki/Report-Tenant-Users

You will need to have the Microsoft Graph PowerShell module installed and up to date.

The first time you run the script you maybe prompted to login to your tenant and then you may also be asked to provide permissions This script requires:

User.ReadBasic.All,
User.Read.All,
User.ReadWrite.All,
Directory.Read.All,
Directory.ReadWrite.All”

which you may need to consent to the first time.

After the script executes you should see an output as shown above showing the Display name, User Principal Name, whether the account is enabled and the user type.

You can also use the –csv command line option to put the results to a CSV file in the parent directory.

Script to report tenant devices

I have created a script that uses the Microsoft Graph to report devices for the tenant as shown above. You’ll find it here:

https://github.com/directorcia/Office365/blob/master/graph-devices-get.ps1

along with the documentation here:

https://github.com/directorcia/Office365/wiki/Report-tenant-devices

You will need to have the Microsoft Graph PowerShell module installed and up to date.

The first time you run the script you maybe prompted to login to your tenant and then you may also be asked to provide permissions as shown above. This script requires:

Device.Read.All

which you may need to consent to the first time.

After the script executes you should see an output as shown above showing the device, device id, operating system and tenant join type.

You can also use the –csv command line option to put the results to a CSV file in the parent directory.

Getting started automating Microsoft 365 administration with the Graph

https://www.youtube.com/watch?v=e1ypZGfifSQ

The Microsoft Graph is a unique and powerful way to administrate Microsoft 365. This session will provide you with a introduction to what the Microsoft Graph is, how to access it and how to use to improve the way you maybe currently administrating your customers environments. The session will also be jammed packed with live demonstrations and best practices for automating any Microsoft 365 environment. Save time, save money and save effort by viewing this session.

Issues creating Endpoint Security Policies using the Microsoft Graph

I swear it was all working and now BOOM, it doesn’t! Using PowerShell I had been creating Endpoint Security policies but now those same policies were still being created but WITHOUT the configuration settings I had configured.

You can try this for yourself if you wish, without needing to code. Firstly visit the Microsoft Graph Explorer and authenticate.

Change the method to POST, set the API to beta and use the URL = https://graph.microsoft.com/beta/deviceManagement/templates/6cc38b89-6087-49c5-9fcf-a9b8c2eca81d/createInstance

Then in the Request body use the following:

https://gist.github.com/directorcia/6d8d2e5199c32b22b6fe782739447dc4

If you do you’ll find a new Endpoint Security Attack Surface Reduction – ASR rule has been created like so:

If you look at settings for this policy you’ll see:

all the settings are Not configured!

So, no errors during the POST but no settings! Strange.

If however you return to the Request body and change the word value to settingDelta as shown above and then run the same query.

Now, the Endpoint Security policy is created and the settings are configured.

So in summary, don’t use value any more it seems with the request body, use settingsDelta.

Removing Azure Enterprise app consented permissions

After installing the appropriate PowerShell modules you can connect to the Microsoft Graph with PowerShell using the command:

connect-graph

as shown above. First thing to remember is that this process can’t be completed in the Power ISE, you’ll need to do it elsewhere (here, using Windows terminal). The second thing to note is that you can specific the scope with which you to connect. Thus, in this case, the scope will be Files.ReadWrite.All and Sites.Readwrite.all. The scope is in effect the permissions the current user will be given when they connect to the Microsoft Graph. This allows you to only provide permissions for exactly what you need.

During the connection process you’ll be asked to consent to the permissions just requested, as shown above. If you simply select Accept here, you are just consenting for the current user. However, if you check the Consent in behalf of your organization option you’ll be providing these permissions to ALL users in your tenant! For now, only consent will be granted for the current user. However, be very, very careful consenting for the whole organization as I will illustrate.

You can now happily go off and perform whatever actions you need to using PowerShell for the Microsoft Graph.

With security in mind, I went to have a look at where these permissions just consented to actually appear. You’ll find them by opening the Azure Portal and navigating to Azure Active Directory as shown above. From here, select Enterprise applications from the menu on the left.

From the screen that appears ensure All applications is select from the menu on the left. Then on the right, locate and select Microsoft Graph PowerShell as shown.

From the screen that now appears, select Permissions from the menu on the left as shown. On the right you’ll then be able to select either Admin consent or User consent.

Because the permissions assigned were only for a single user, the User consent item will show these to us as shown above. This list of permissions matches those consented to when connecting to the Microsoft Graph.

The right hand most column in this display, Grant by, has a hyperlink to show the number of users with this assigned permission.

If you select any of these hyperlinks, you’ll see a list of users, on the right, that have been assigned this permission appear on the right as shown above.

Can you see the problem yet? No? Well…….how do you REMOVE or revoke a permission here?

From what I can determine, you can’t remove the permissions via the portal. If you select Review permissions menu option you’ll see a item displayed from the right as shown above. If you select the option This application has more permissions that I want and basically told to use PowerShell to revoke all permissions for this application as well as being provided with the code to do so.

The issue is that even after you disconnect from the Microsoft Graph, having completed any scripting, those consented permissions remain in place i.e. they are NOT rescinded. This means that if the user account with these permissions to the Graph is compromised then that attacker has access to the Microsoft Graph and potentially lots of sensitive areas in a tenant, especially if the permissions have been added to over time. Imagine how much WORSE it gets if permissions were consented tenant wide, rather than to an individual user?

Selecting that little check box in the above Permissions requested dialog, which I see MANY people do without thinking, can really give you a security headache by opening up your Microsoft Graph permissions for EVERY user in the tenant!

Thus, best security practice is going to be to remove these permissions when they are no longer required as well as limiting who has them initially. Personally, I’d remove them after each interaction so I don’t forget and leave a potential attack vector.

To make doing all that a little easier, I have gone out and created a script that you’ll find in my Github repo:

https://github.com/directorcia/Office365/blob/master/graph-adappperm-del.ps1

If you run the script, it will first check whether the Azure AD PowerShell module is loaded. If it is, it will then ask you to login to your tenant. Then it will display a list of all the Azure AD applications in your tenant and allow you to select the ones you want to change (yes, you can select multiple Azure AD apps if you want) as shown above.

In this case, Microsoft Graph PowerShell application is selected.

You’ll then be prompted to select whether you wish to select Admin consent and/or User Consent permissions. You can select both here if you wish by using the CTRL and/or SHIFT key when making selections (i.e. just like when you use Windows Explorer).

If you selected User consent, you’ll then be prompted to select the users you want. Again, multiple selections are available if offered.

You’ll now be prompted to confirm you wish to delete these permissions for these users.

Those permissions will be removed and the script will continue to work through the rest of your selections.

In this case, because there were no Admin consented permissions for this application we receive a notification line as shown in above output.

If you now return and have a look at the permissions for that app in the portal, you should see they have all been removed as shown above.

Leaving users with standing permissions to something as powerful as the Microsoft Graph is not best security practice. It is therefore important to regularly review these and remove what is not required. If you need those permissions again in eth future, after they have been removed, you can always re-consent to them when you next connect to the Microsoft Graph.

Automating the deployment of an Attack Surface Reduction policy across multiple tenants

A while ago I wrote an article on:

Using the Microsoft Graph with multiple tenants

which showed you how to embed a ‘static’ Azure AD application in all the tenants you wish. I then showed how to give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access various tenant configuration settings in this article:

Reporting on multiple tenants with the Microsoft Graph

This meant that you could now run Microsoft Graph requests across all those tenants, securely and without needing a login to each tenant.

Recently, I also wrote about the:

Attack Surface Reduction rules for Windows 10

and how to set these in an automated way via PowerShell. I’m now going to bring these two concepts together and show you how to deploy an Attack Surface Reduction (ASR) policy into Microsoft Endpoint Manager across multiple tenants WITHOUT the need to login to each to do it!

Before you can do all this you’ll need to embed an Azure AD App into all the desired tenants. The information to do this I have previously covered here:

Using the Microsoft Graph with multiple tenants

Once you have an Azure AD application inside your tenants you can continue to use this for continued configuration processes like this. Thus, you only need to add an Azure AD application to the desired tenants once. You can then simply re-use it as needed.

With the Azure AD application in place, the next step is to provide the appropriate permissions for that Azure AD application to do to what it needs. In the case of working with ASR the Azure AD application will need the following Graph API permissions:

Read and write Microsoft Intune Device Configuration and Policies

and

Read Microsoft Intune Device Configuration and Policies

You can add these manually which I have covered off previously here:

Using interactive PowerShell to access the Microsoft Graph

However, I have also made available an automated tool to do this.

In this case, my pre-existing Azure AD application is called ciaops-S6 as shown above.

In this first tenant, you see that there are current no API permissions associated with my Azure AD application.

In the second tenant, there are already existing permissions as you can see above, but they currently don’t include the ones I want detailed above, so they will also need to be added here.

What I want to achieve for both tenants, is to add these two Graph API permissions:

Read and write Microsoft Intune Device Configuration and Policies
Read Microsoft Intune Device Configuration and Policies

to my existing Azure AD application, while also leaving any existing permission in place.

You’ll need to visit my Office 365 GitHub repository and down the program:

https://github.com/directorcia/Office365/blob/master/graph-adapp-per.exe

You’ll need to put the graph-adapp.per.exe in the same directory as the XML configuration files for the tenant, as shown above. Then you’ll need to run:

graph-adapp-per.exe 89a0934cc6064c1a95caffdaec4e5429

The 89a0934cc6064c1a95caffdaec4e5429 parameter tells my program which permissions you wish to add to the existing Azure AD application.

The program will check whether the Azure AD PowerShell has been loaded. If not, it will terminate.

In this case enter A when prompted to ADD permission to those that exist.

You’ll then be prompted to login as an administrator to the first tenant. This is required once for each tenant because you are ADDING permissions to an existing Azure AD application. Once these permissions have been added, you won’t need to repeat for any access to the same properties. For example, say you later on want to configure the Microsoft EndPoint Manager Firewall policy, you won’t need to complete this permissions step because what you are doing here adds the same permissions you need to do the Firewall policy.

The required permissions are added and you will be then prompted to ‘consent’ to these. Unfortunately, I can only find a way to do this via a browser. Selecting Y here will open a browser in-private mode and allow you to complete consent. The required ‘consent’ URL is also copied to the clipboard, so if you already have the tenant open is a browser somewhere, just paste the clipboard there to complete ‘consent’ like so:

You should now see the permissions request as shown above that you need to Accept. What you see will vary slightly. You will always see:

Read and write Microsoft Intune Device Configuration and Policies

Read Microsoft Intune Device Configuration and Policies

as these are new permissions. However, if you have existing rights, as this first tenant did, you will also see those.

Simply select Accept to continue.

If you now return to the program, you’ll be prompted to confirm that ‘consent’ has been completed. Enter Y to continue.

That will complete the first tenant and then commence the same process on all subsequent tenants as shown above.

The only difference you’ll probably see is the list of permissions you need to accept. This is because, in this case, the option to ADD permissions was selected. The above shows you the prompt from the second tenant in this example which started off with no permissions for the existing Azure AD application.

Once the program is complete, it will pause as ask you to hit ENTER as shown.

If you now look at the API permissions for the Azure AD application that was added you should see that they now have:

Read and write Microsoft Intune Device Configuration and Policies

Read Microsoft Intune Device Configuration and Policies

As shown above.

And if you check an Azure AD application that already had permissions, like the second example here shown above, you will see that the appropriate permissions have been added to any that previously existed.

Remember, you only need to go through this process when you want to ADD permissions to your Azure AD application. As mentioned, now that these permissions have been added to the Azure AD application you can work with just about any EndPoint Manager configuration for the tenant.

Now that the permissions are in place, the next step in the process is to run the program to add the ASR policy to EndPoint Manager for the tenant. To do that you’ll need to download the following program from my Office 365 GitHub repository:

https://github.com/directorcia/Office365/blob/master/graph-asr-set.exe

and copy into the same directory you have been using as shown above. That is the one with all the tenant configuration files.

Run the program:

graph-asr-set.ps1

The program will run and work through the required tenants without any prompts.

You will see the policy settings for each tenant, as shown above, as a confirmation.

If you return to Microsoft EndPoint manager for the tenants and refresh that ASR policy listing as shown above, you should a new ASR policy as shown.

If you scroll down to the Configuration settings:

You will see that the individual settings have been configured.

The only you’ll need to do manually, is to actually assign this policy to your environment as shown above. I have chosen not to do this automatically for all users and or devices in the tenant, because there may need to some tweaking of the individual settings as applying to a test group first to ensure there are no issues. Maybe in a future iteration I’ll look at providing that option.

If you run the graph-asr-set.ps1 program again, it will create an additional policy of the same name with the same settings. Another to-do item will be a program to adjust an existing script.

If for some reason you wish to remove ALL the permissions from your Azure AD application in ALL your tenants, use the command:

graph-adapp-per.ps1 693cb755244848a2a556025710cec086

Youi can also, of course, do this manually via the portal as well as selectively by the same method if you wish. However, I see no major not to leave the permissions in place, having gone to all that trouble, so you can make additional configuration changes later on (without the need to login to the tenants as I will again point out!)

So there you have it! An automated way to set ASR policies in Microsoft EndPoint Manager, across multiple tenants, without individually logging in, using the Microsoft Graph.

Case sensitivity is important with the Microsoft Graph

I recently wrote an article about implementing Attack Service Reduction (ASR) which you can read here:

Attack Surface Reduction for Windows 10

The next step was now to automate ASR policies with Microsoft EndPoint Manager via PowerShell. Luckily I found a great blog article by Ben Leader which you’ll find here:

Creating EndPoint Security policies with PowerShell

Ben’s article focused on BitLocker, while mine focused an ASR. It took a little time to reverse engineer things with ASR and I had my script working without error.

However, the problem was that the changes that the script made didn’t show up in the web interface as shown above? There were no errors reported. Strange? Maybe, it was a timing thing? Nope. what could it be?

Puzzled, I contacted Ben again and it turns out that the syntax with the Microsoft Graph is case sensitive!. A simple solution once you know but super frustrating until your do.

So the original code I have set the “value” to Enable as shown above. That is with a capital ‘E’, which is invalid.

As it turns out (thanks to Ben), I learned it should be a lower case ‘e’ as shown above.

As shown above, this works as expected in the web interface. Phew.

The moral or the story is that you need to be careful when it comes to setting values with the Graph. That hopefully, hopefully should accelerate my development of automating ASR across environments!