← Back to Blog

External Users + Copilot: The Guest Access Problem

E2E Agentic Bridge·March 2, 2026

External Users + Copilot: The Guest Access Problem

Your tenant has guest users. Every tenant does. Partners, contractors, agencies, clients — Microsoft Entra ID makes it trivially easy to invite external users into your M365 environment. A few clicks and they have access to a Teams channel, a SharePoint site, or an entire M365 Group.

Before Copilot, guest access was already a security concern that most organizations managed loosely. Now it's a potential data breach vector that demands immediate attention.

Here's the problem in one sentence: if a guest user has a Copilot license (or your tenant policies allow it), Copilot can surface any content that guest has access to — and guest permissions are almost always broader than anyone realizes.

How Guest Access Actually Works in M365

To understand the Copilot risk, you need to understand how Microsoft Entra ID handles guest users. When you invite a guest, they get a user object in your tenant directory. That user object can be assigned to:

  • M365 Groups (which grants access to the group's SharePoint, mailbox, Teams, and Planner)
  • SharePoint sites directly
  • Teams channels (as a member or guest)
  • Individual file and folder shares via OneDrive or SharePoint

The guest user's access is governed by your tenant's external collaboration settings in Entra ID, combined with SharePoint external sharing settings and Teams guest access policies.

The critical detail: these settings are configured independently, creating overlapping permission boundaries that are hard to audit. SharePoint might restrict external sharing, but if a guest was already added to an M365 Group before the restriction, they retain access. Teams might limit guest features, but the underlying SharePoint permissions remain untouched.

Where Copilot Changes the Game

Without Copilot, a guest user could only find files they knew about. They'd browse a SharePoint site they were given a link to, or check the Teams channel they were invited to. Discovery was limited to navigation.

Copilot removes the discovery barrier entirely. A guest user with Copilot access can prompt: "What documents mention [sensitive topic]?" and Copilot will search across every file, conversation, and email that guest has permissions to access. Content that was technically accessible but practically invisible is now one prompt away.

Consider a real scenario. You invite a marketing agency as guests to collaborate on a campaign. You add them to a Teams channel for the project. That Teams channel sits inside an M365 Group. The M365 Group has a SharePoint site with document libraries that contain not just campaign materials but also:

  • Internal strategy documents uploaded months before the agency joined
  • Budget spreadsheets with cost breakdowns for multiple vendors
  • Competitive analysis documents referencing the agency's competitors
  • HR-related files that someone accidentally uploaded to the wrong library

The agency could always technically access those files by browsing the SharePoint site. Almost nobody ever did. With Copilot, a simple prompt surfaces everything.

The Scope of the Problem

Microsoft's Entra ID external identities documentation describes guest users as having "limited" access by default. But "limited" is relative. The default guest permission level in Entra ID still allows guests to:

  • Read properties of other users and groups (including group membership)
  • Read applications registered in the directory
  • Access any M365 resource they've been explicitly granted access to

That last point is where the risk lives. "Explicitly granted access" accumulates over time. A guest who started with access to one Teams channel might now have access to five channels across three teams, two SharePoint sites, and a shared mailbox — because different people across your organization invited them to different resources over months or years.

Nobody has a unified view of what any given guest user can access. Until Copilot surfaces it.

Audit Your Guest Users Today

Step 1: Inventory All Guest Users

Start with a complete inventory of guest users in your tenant:

Get-MgUser -Filter "userType eq 'Guest'" -All -Property DisplayName,Mail,CreatedDateTime,SignInActivity |
    Select-Object DisplayName, Mail, CreatedDateTime,
    @{N='LastSignIn'; E={$_.SignInActivity.LastSignInDateTime}} |
    Export-Csv -Path "guest-users-audit.csv" -NoTypeInformation

Pay attention to guests who were created more than 12 months ago and haven't signed in recently. These are the highest risk — they have accumulated permissions but nobody is actively managing their access.

Step 2: Map Guest Permissions

For each guest user (or at least the high-risk ones), map their effective permissions:

$guestId = "guest-user-object-id"
Get-MgUserMemberOf -UserId $guestId -All | ForEach-Object {
    $group = Get-MgGroup -GroupId $_.Id -ErrorAction SilentlyContinue
    if ($group) {
        [PSCustomObject]@{
            GroupName = $group.DisplayName
            GroupType = if ($group.GroupTypes -contains "Unified") { "M365" } else { "Security" }
            Visibility = $group.Visibility
        }
    }
}

Also check SharePoint site permissions directly — guests might have access to sites without being in the associated M365 Group:

Get-SPOSite -Limit All | ForEach-Object {
    $siteUrl = $_.Url
    $externalUsers = Get-SPOExternalUser -SiteUrl $siteUrl -PageSize 50
    if ($externalUsers.Count -gt 0) {
        [PSCustomObject]@{
            SiteUrl = $siteUrl
            ExternalUserCount = $externalUsers.Count
            Users = ($externalUsers | Select-Object -ExpandProperty Email) -join "; "
        }
    }
}

Step 3: Identify Over-Permissioned Guests

Look for guests who have access to resources beyond their original purpose. Common patterns include:

  • Guest added to an M365 Group that contains multiple Teams channels (they only needed one)
  • Guest with access to a SharePoint site's root, when they only needed one document library
  • Guest who was added to a "company-wide" or "all-staff" group accidentally
  • Guest who retains access to completed project resources

Restricting Guest Access for Copilot Safety

Configure Entra ID Guest Restrictions

In Entra ID > External Identities > External collaboration settings, configure:

  1. Guest user access restrictions: Set to "Guest users have limited access to properties and memberships of directory objects" at minimum. For maximum security, select "Guest user access is restricted to properties and memberships of their own directory objects."

  2. Guest invite restrictions: Limit who can invite guests. "Only users assigned to specific admin roles can invite guest users" is the most secure option.

  3. Collaboration restrictions: Use allow/deny lists to control which domains can be invited. If you only work with five partner organizations, allowlist those five domains and block everything else.

Configure SharePoint External Sharing

In the SharePoint Admin Center, configure external sharing at both the tenant level and per-site:

  • Tenant level: Set to "Existing guests only" or "Only people in your organization" for sites containing sensitive content
  • Per-site overrides: Allow broader sharing only on specific collaboration sites that are designed for external use

This prevents new guest access from being created through SharePoint sharing links, which is one of the most common ways guests accumulate unexpected permissions.

Use Conditional Access for Guest Copilot Access

Create a Conditional Access policy in Entra ID that specifically targets guest users and Copilot:

  1. Users: Target all guest and external users
  2. Cloud apps: Target Microsoft 365 Copilot
  3. Grant: Block access (or require compliant device, MFA, etc.)

This is the most direct way to prevent guest users from using Copilot in your tenant. If your organization doesn't need guests to have Copilot access — and most don't — block it entirely.

Implement Information Barriers

Microsoft Purview Information Barriers can segment your tenant so that guest users can only communicate with and access content from specific internal groups. This is particularly useful when you have guests from competing organizations who shouldn't see each other's collaboration spaces.

The Shared Link Problem

Beyond formal guest user accounts, there's an even harder problem: shared links. Every SharePoint sharing link that was set to "Anyone with the link" or "People in your organization" represents a potential access path.

Copilot doesn't currently follow anonymous sharing links for users who don't have the link. But "People in your organization" links are accessible to guest users who are part of your organization directory. A guest user with Copilot could potentially surface content from files shared with this link type.

For a comprehensive approach to SharePoint permissions auditing that covers sharing links, direct permissions, and inherited access, review our SharePoint permissions audit guide.

Guest Lifecycle Management

One-time cleanup isn't enough. You need ongoing lifecycle management for guest accounts.

Entra ID Access Reviews for Guests

Configure recurring access reviews specifically targeting guest users:

  1. Navigate to Entra ID > Identity Governance > Access Reviews
  2. Create a review with scope "Guest users only"
  3. Set reviewers to the resource owners (group owners, site admins)
  4. Enable auto-removal for guests who aren't re-approved
  5. Set frequency to monthly for high-sensitivity resources, quarterly for others

Guest Expiration

Set a maximum lifetime for guest accounts using Entra ID lifecycle policies. A 90-day expiration with renewal options forces periodic re-evaluation of whether each guest still needs access.

Monitor Guest Activity

Set up alerts in Microsoft Defender for Cloud Apps for:

  • Guest users accessing files in bulk
  • Guest users accessing resources they haven't accessed before
  • New guest invitations to sensitive M365 Groups
  • Guest users running Copilot prompts (if logging is enabled)

What About Microsoft's Built-in Protections?

Microsoft has added some Copilot-specific controls for guest scenarios. As of early 2026, these include:

  • Copilot access management: Admins can control Copilot license assignment, excluding guest users by default
  • Semantic index boundaries: The semantic index respects existing permission boundaries, including guest access limits
  • Sensitivity label enforcement: Content labeled as "Internal Only" with Copilot restrictions won't surface for guest users

However, these controls are only as good as your configuration. If you haven't deployed sensitivity labels — and most organizations haven't fully — these protections don't apply. Our sensitivity labels setup guide covers the complete configuration process.

The Honest Assessment

Guest access was already a mess before Copilot. Every organization knows it. The difference is that pre-Copilot, the mess was mostly theoretical risk — guests could find sensitive files but rarely did because they didn't know where to look.

Copilot eliminates the discovery problem. A guest user can now effectively search your entire accessible tenant with natural language. That changes the risk calculation from "unlikely" to "inevitable."

The organizations that will avoid Copilot guest access incidents are the ones that treat guest access as a first-class security concern, not an afterthought. That means audit, restrict, monitor, and automate — before Copilot turns your external collaboration into an external data exposure.

Take Action Now

Guest access risks multiply with Copilot. Don't discover your exposure after a partner's contractor prompts Copilot and finds your M&A documents.

Scan your tenant for guest access risks → Our free assessment maps every guest user's effective permissions and identifies Copilot-specific exposure in minutes. Know what your guests can see before Copilot shows them.