Copilot Agents Appear in Many Places in Microsoft 365
Adoption of generative AI is increasing, with Gartner forecasting that global spending on generative AI will see a 76.4% year-over-year increase in 2025. It is no surprise to see Microsoft taking a leading role, embedding capabilities such as AI-powered content drafting, and chat experiences to ask questions on the current context across as many applications as possible.
Copilot is Microsoft’s answer to generative AI in Microsoft 365. Much of the focus for tenant administrators to date has been to address problems that AI can expose. Fixing oversharing in SharePoint, deploying sensitivity labels and tools like Restricted Content Discovery, using the DLP policy for Copilot, and policy settings in the Microsoft 365 Admin Centre are all key to prepare a tenant for Copilot.
Microsoft 365 Copilot accesses tenant data through Graph APIs. Most IT administrators don’t have just Microsoft 365 in their organizations and other toolsets are in use. To exert more value from Copilot, IT admins can extend Copilot to ground its research in information from other tools and to take action for users to support them to complete tasks.
The capability from Microsoft for Copilot extensibility
Copilot extensibility has evolved since the initial release of Microsoft 365 Copilot. Today, a more solidified capability for extending Copilot and building AI agents for Teams and other experiences focuses on Copilot agents.
Copilot agents are AI assistants with a more scoped role and focus than the generalist view of internal and external information taken by Microsoft 365 Copilot. Agents are built to either extend Microsoft 365 Copilot or to operate in a standalone experience. Agents can be published in different channels, like Teams, SharePoint Online and Facebook, both inside and outside the tenant. Channels are the ways users consume agents.
There are multiple types of Copilot agents for administrators and developers to know about, and multiple tools are available to develop agents. The variety of tools can improve the experience from a low-code maker and developer standpoint; however, it gives administrators a broader scope to be aware of, where different tools allow developers to deploy different capabilities. For example, the REST API capabilities in the Microsoft 365 Agents Toolkit don’t have the control that Power Platform provides to administrators via its REST API capabilities in Copilot Studio. In Power Platform, DLP allows administrators to prevent or more granularly control the use of REST APIs in Copilot Studio agents. Microsoft 365 Agents Toolkit has no similar control for this. Today, developers can provision agents with API plugins without any ability for an administrator to prevent this other than to turn off the use of agents entirely for those users. Administrators do have more control around preventing users from sharing those agents, but it only takes one user to exfiltrate data from the organization. Microsoft has an improvement on the roadmap to address this security gap.
Copilot Studio is the low-code capability for building Copilot agents
Copilot Studio sits within Microsoft’s Power Platform, the low-code application development toolset targeted at business users (makers), enabling them to solve simple business problems without always needing developer skills.
Microsoft’s focus is to enable users to build Copilot agents with low-code tools. With the attempt to democratize software development, the need arises for controls to administer the platform and make sure that organizations remain compliant as agent usage grows. No one wants agents to run amok in a tenant.
A license is the first control to accessing Copilot Studio
Tenant administrators must begin by procuring Copilot Studio user licenses for the tenant. These are free (Figure 1) and act as a control for makers being able to access Copilot Studio. To use this control, administrators must also disable the ability for makers to start their own Copilot Studio trials, using PowerShell. Without a trial, a Copilot Studio user license, or Copilot Studio enabled within the Microsoft 365 Copilot SKU, makers cannot access Copilot Studio.
Often organizations need to use Copilot Studio user licenses as they have people building agents who don’t have a Microsoft 365 Copilot license. Tenant administrators also often disable the Copilot Studio application within the Microsoft 365 Copilot SKU, as readiness for Copilot agents is an additional story to just deploying Microsoft 365 Copilot.
You can procure the needed number of Copilot Studio user licenses and assign them to the users who need to create agents, through the Billing section of the Microsoft 365 admin center (Figure 1).
Enabling users to build within environments
The next step is to create a Power Platform environment for makers to build agents in. This can be done in the Power Platform Admin Centre (PPAC), which I cover in Power Platform: Areas for Microsoft 365 Admins to Explore.
Under ‘Manage’ and ‘Environments’ within PPAC, administrators can select ‘New’ to create a Power Platform environment. People who develop agents should be added to this environment with a maker security role, which grants them the right to create agents in that environment (Figure 2).
Data Loss Prevention for Copilot Studio
I mention DLP policies in Power Platform: Areas for Microsoft 365 Admins to Explore. There are specific connectors to be aware of in DLP for Copilot Studio, which aren’t Power Platform connectors. Prior to the advent of agents, DLP was used to prevent communication between one or more Power Platform connectors based on ‘business’, ‘non-business’, and ‘blocked’ categories assigned by an administrator. Various Copilot Studio features appear to DLP as ‘connectors’ despite these features not being Power Platform connectors available across the rest of the Power Platform.
The ‘connectors’ added to DLP in Power Platform for Copilot Studio focus on data integration points and features within the platform. For example, administrators can use DLP to prevent the use of the application insights integration for Copilot Studio agents. For more information, see the Microsoft documentation for the connectors relevant to Copilot Studio features.
The use of business and non-business categories is still important. Figure 3 highlights an example where ‘Chat without Microsoft Entra ID authentication in Copilot Studio’ is configured as a business connector, preventing the use of non-business connectors in scenarios where the agent uses Entra for authentication. This prevents agents interacting with non-business classified data connectors when they have a need to interact with data or channels secured by Entra.
Publish Copilots with AI features
Within ‘Manage’ in PPAC, administrators can set several tenant settings that control behaviors across the Power Platform. To enable makers to build Copilot Studio agents with AI features, such as generative orchestration, the ‘publish Copilots with AI features’ setting must be enabled. If this setting is not enabled, limited value is achievable from building agents. A primary purpose of agents is to have a system capable of taking on tasks or a workflow through capabilities and instructions provided to it, without the need to fully develop a deterministic set of code logic which solves the problem. Without generative AI features turned on, capabilities such as generative orchestration cannot be used, limiting an agents ability to orchestrate its capabilities to solve a problem. This setting is scoped at the tenant level and applies across all environments.
Enabling generative AI features against the environment
The availability of the Azure OpenAI Service determines the availability of generative AI functionality in Power Platform, across regions of the world. In some cases, movement of data across regional boundaries is required to be able to use generative AI features. Microsoft documents the regions where data is processed for Copilots and generative AI features when working with Power Platform.
Administrators should assess whether the location for data processing based on the environment location remains compliant with the organization’s regulatory requirements, before accepting the terms of use to enable generative AI features for the environment.
Bing Search is a service relied on by various Microsoft Copilot products to fetch content from websites. Features in Copilot Studio such as using a custom website as a knowledge source, rely on this service. Where agents call on Bing Search to return website content, they first generate a search query to send to the service, that can include business context and document content previously referenced in the same chat, to return the appropriate result. Outside the U.S., Bing Search is a feature to pay close attention to as this routes all data processing to the United States region, for those search queries.
To enable generative AI features in the environment you provide to makers, select the environment from ‘Environments’ in PPAC, and select ‘edit’ next to ‘Generative AI Features’, then accept or untick the terms of use (Figure 4). For Bing Search, accept the relevant terms of use to turn on custom websites as a knowledge source. These capabilities are separated, so you can enable generative AI features whilst having Bing Search disabled.
Scaling with Copilot Studio requires further work
These baseline control implementations are the first steps to provide makers with the ability to build agents in a manageable way within a tenant. To manage agents at scale, further work and attention is needed. Topics such as Managed Environments, inventory of applications and agents, auditing and observability, and more come into scope. I will cover these topics in future articles.
