5 insights from Frost & Sullivan’s 2025 Frost Radar™ for Cloud Security Posture Management
July 7, 2026Copy of Sustainability and Security
July 7, 2026
AI represents a major shift in how users interact with organizational data. Instead of finding information one file, email, or chat at a time, users can ask natural language questions and get synthesized answers drawn from content they already have permission to access. That can improve productivity, but it can also amplify the impact of broad access, oversharing, and weak governance.
Microsoft 365 Copilot brings this shift into focus. It doesn’t grant new permissions, but it acts as a force multiplier for existing access, making it faster and easier for users to discover, aggregate, and act on data across Microsoft 365. That makes it critical to understand both who can access Copilot and what data it can surface on a user’s behalf. A second layer of risk follows from how organizational data is structured, shared, and governed. In environments with overshared content, excessive permissions, or inconsistent governance, this acceleration can lead to faster and broader access to sensitive information than organizations may expect.
This shift carries important security implications, especially as organizations move from pilots to scaled deployment. While customers with Microsoft 365 E5 licensing may already have access to tools that help identify and reduce risk, licensing alone does not reduce exposure.
What’s often missing during early Copilot deployments is a clear view of the risk surface itself: what data is exposed, who can access it, and through which vectors. Organizations building their Microsoft 365 Zero Trust posture can use the Zero Trust Workshop to assess their current posture, identify gaps, and better understand how existing permissions and governance impact Copilot readiness.
In this post, we map Copilot-related risk to the key Zero Trust control areas most relevant to deployment: identity, endpoints, apps, and data. Our goal is to help organizations understand where exposure exists and which control areas they should focus on before scaling deployment.
Use Zero Trust to assess Microsoft 365 Copilot risk
Microsoft defines Zero Trust as a security model built on three core principles:
- Verify explicitly
- Use least privileged access
- Assume breach
Instead of trusting users or devices based solely on network location, Zero Trust requires continuous validation of every user, endpoint, and request, regardless of where the request originates. Microsoft’s Zero Trust adoption model groups security controls across technology pillars such as identities, endpoints, apps, data, network, infrastructure, and security operations.
For this analysis, we’ll focus on the four pillars most directly involved in Microsoft 365 Copilot deployments: identity, endpoints, apps, and data.
Figure 1. Four control areas that shape Copilot exposure
Together, these pillars help answer three key questions:
- Who can access Copilot
- From which endpoints and applications
- What data can Copilot surface once access is granted
For more information and details about Microsoft’s Zero Trust framework, visit Zero Trust Overview at Microsoft Learn.
Why Microsoft 365 Copilot changes the risk conversation
Before assessing specific risks, it helps to understand why Copilot changes the risk conversation compared to traditional Microsoft 365 applications. Most enterprise apps operate within a bounded context. The time and effort required to manually locate, connect, and synthesize information across systems creates friction and a practical limit on how quickly users can surface and act on data across systems. Copilot removes much of that friction. At the speed of a prompt, Copilot lets users retrieve and bring together information from across a user’s existing access—spanning emails, files, meetings, chats, and other Microsoft 365 services—in a single response.
This exposure is not a result of new permissions. It comes from how quickly and easily existing access can be discovered, aggregated, and used. To understand where exposure appears, it helps to break Copilot risk into two interconnected layers: access and data.
The two-layer Microsoft 365 Copilot risk model
The foundation of this analysis is simple: Copilot acts as a force multiplier for whatever access a user already has. If that access is governed well, Copilot can improve productivity. If not, it can amplify exposure.
With that framing in mind, we’ll examine Copilot risk in two distinct layers:
- Access to the Copilot service itself
- Access to the data that Copilot can ground on and surface
The first layer focuses on who can access Copilot and under what conditions. The second focuses on what Copilot can see and surface once access is granted.
Risk layer 1: Who can access Microsoft 365 Copilot?
The first layer of risk begins at the point of entry: the conditions that determine whether a user can access Copilot. Organizations don’t need to address every potential exposure point at once. Start by using the table below as a map of where exposure can exist across identity and endpoint controls. We’ll explore how to mitigate these risks in the second post of this series.
The risks below are primarily governed by Microsoft’s Zero Trust identity and endpoint pillars. Together, these pillars help determine whether the right user can access Copilot from a trusted endpoint under the right access conditions.
Table 1. Identity and endpoint risks that affect Copilot access
|
Risk |
Pillar |
Description |
|
| R1 |
Unmanaged identity access |
Identity |
A compromised, shared, or former employee account can authenticate Microsoft 365 and access Copilot. Because Copilot operates across the full scope of a user’s permissions, compromised accounts can expose a much larger risk surface than before Copilot existed. Strong account hygiene and identity lifecycle management can reduce that exposure. |
| R2 |
Weak or absent multi-factor authentication (MFA) |
Identity |
If MFA isn’t enforced, or if legacy authentication bypasses modern sign-in controls, users can start Copilot sessions with only a password. In environments with inconsistent MFA coverage, stolen credentials may be enough to gain access. Because Copilot can synthesize data across services, compromised accounts create more risk than access to a single application. |
| R3 |
Unmanaged or non-compliant devices |
Endpoints |
Users can access Copilot through browsers and native apps from any device where they can authenticate. Unmanaged or noncompliant endpoints without endpoint protection, encryption, or compliance evaluation can expose Copilot sessions and allow outputs to be stored or exfiltrated locally. |
| R4 |
Broad Copilot licensing without role-based scoping |
Identity and apps |
Broad Copilot licensing without role-based scoping. Copilot pilots often begin with broad license assignments across departments or business units instead of smaller, security-reviewed user groups. When organizations assign licenses without reviewing access rights, permission posture, and role sensitivity, they can expand exposure across both well-governed and minimally governed users. |
| R5 |
Missing real-time risk evaluation at sign-in |
Identity and endpoints |
If Conditional Access doesn’t evaluate sign-in and user risk signals, such as anomalous activity, or identity protection alerts, high-risk sessions may still reach Copilot. Without real-time risk evaluation, controls may respond only after access is granted. |
| R6 |
App protection gap on mobile devices |
Endpoints and apps |
Users can access Copilot from personal mobile devices that are not enrolled in device or app management. Without app protection policies, organizations may not be able to control how Copilot outputs move into unmanaged apps or remove organizational data from lost devices. |
Key observations from Layer 1:
Identity appears most frequently across Layer 1, reflecting how tightly Copilot access depends on authenticated user permissions and sign-in conditions. Endpoint-related risks also play a major role because unmanaged or noncompliant endpoints can expose Copilot sessions and outputs beyond the organization’s trusted environment.
Together, these risks show that securing Copilot access is shaped by two factors: who can sign in, and whether the endpoint and session meet the organization’s access requirements.
Risk layer 2: What data can Microsoft 365 Copilot reach?
The second layer of risk assumes that the user is already authenticated and actively using Copilot. At this stage, the focus shifts from who can access Copilot to what data Copilot can surface on the user’s behalf. These risks reflect the exposure created by existing permissions, overshared content, connected systems, and governance gaps.
Layer 2 risks are governed primarily by the apps and data pillars, with identity playing a secondary role in defining the scope of data each user can access. Much of Copilot’s value and risk comes from how it surfaces information based on user intent.
Data and application risks that shape Copilot exposure
These risks highlight how permissions, sharing, labeling, and governance directly shape what Copilot can retrieve, synthesize, and surface across organizational data.
|
Risk |
Zero Trust pillar(s) |
Description |
|
| R7 |
Overshared SharePoint and OneDrive content |
Apps and identity |
Content shared with “Everyone,” “Everyone except external users,” or broad groups can become part of Copilot’s queryable surface for licensed users who already have access to that content. Years of oversharing, combined with Copilot’s ability to retrieve and synthesize content in a single prompt, can turn long-standing governance gaps into immediate exposure. Copilot can make data that was once hidden by volume, discoverable by intent. |
| R8 |
Sensitivity label gaps |
Apps and data |
Microsoft Purview sensitivity labels and related protections tell Copilot how to handle content, including whether it can summarize, cite, or include that content in responses. Across containers such as SharePoint sites and Teams, unlabeled, incorrect, or inconsistently labeled content may be treated as unclassified and surfaced freely. Large volumes of legacy content can make that gap harder to manage at scale. |
| R9 |
Excessive user permissions |
Identity and apps |
Copilot follows each user’s existing Microsoft 365 permissions and does not surface content users cannot access. However, users often accumulate access beyond their current role through leftover project permissions, temporary group memberships, and inherited access. Copilot doesn’t create this overprovisioning, but it can make the full scope of it easier to discover and use. |
| R10 |
No DLP coverage on Copilot-generated outputs |
Apps and data |
Copilot outputs, such as summaries and drafts can combine sensitive details from multiple sources. Organizations should review how their DLP labeling and data protection policies apply to generated content, especially when users move Copilot outputs into email, chat, or external documents. |
| R11 |
Plugin and connector data surface expansion |
Apps and identity |
Organizations can extend Copilot through agent and connectors that pull external data from CRM systems, ITSM platforms, and other line-of-business tools. Each connected source expands the set of data users can access through Copilot. Each connected source expands the set of data users can access through Copilot and may introduce governance and access model differences that need to be reviewed. |
| R12 |
Audit and visibility gap |
Apps and data |
Organizations need enough visibility to understand how users interact with Copilot and which resources Copilot accesses in response to prompts. Audit logs and monitoring help security teams investigate suspicious activity, understand usage patterns, and reduce risk over time. |
| R13 |
Privileged user data amplification |
Identity, apps and data |
Privileged users often hold access across sensitive systems and data. A compromised privileged account with Copilot access can expose a much larger slice of organizational data than a standard user account. Privileged identities therefore need tighter access to governance and review. |
Key observations from Layer 2:
Apps-related risks appear throughout Layer 2 because Microsoft 365 Copilot depends on connected systems, accessible data sources, and governance over generated outputs. The data pillar reinforces the need to protect both sensitive source content and the AI-generated responses that bring content together. The table above maps each risk to its primary and secondary Zero Trust pillars to show where to act. Primary pillars represent control areas that most directly govern a given risk, while secondary pillars represent contributing factors.
Governing Microsoft 365 Copilot risk: Next steps
Copilot typically doesn’t grant broader access than a user already has. Instead, it makes existing access easier to discover, connect, and use across Microsoft 365. Organizations that successfully scale Copilot are the ones that understand and govern that access first. Understanding where exposure exists is the first step. Your next step depends on where your organization is in their Zero Trust journey.
Need to assess your current status? Visit the Zero Trust Workshop.
Ready to learn more about reducing risk by strengthening access controls at the point of entry? Check out post 2 of this series: Mitigating Microsoft 365 Copilot access risk: Identity and device controls for Zero Trust.