SharePoint Permission Levels Explained: Governance, AI Risks, and Best Practices

For a significant period, “Permission Sprawl” in SharePoint was a known but ignored IT problem. However, the rapid, wide rollout of Microsoft 365 Copilot has converted these unmanaged permissions into an immediate enterprise security emergency.

Copilot obeys the existing SharePoint permissions strictly. This means it can return sensitive files in the user’s everyday prompt if the user had access (even years ago).

Therefore, if you’re an IT administrator tasked with preparing the organization for Copilot deployment or already did, it is critical for you to understand SharePoint permission levels in depth.

So, check out this detailed guide to wrap your head around SharePoint Online permission levels. And know the exact structure to secure your tenant for AI and routine collaboration.

What are SharePoint Permission Levels?

SharePoint Permission Levels are built-in sets of specific user rights (such as adding items, deleting versions, or managing hierarchy). These permissions are merged to streamline control. Administrators assign these merged levels to SharePoint Groups to enforce Role-Based Access Control (RBAC). Instead of assigning multiple individual permissions directly.

What are the Different Permission Levels in SharePoint?

Permission Levels in SharePoint are severely hierarchical. Each default level is built from over 30 precise technical permissions that are distributed across List Permissions, Site Permissions, and Personal Permissions.

• Full Control: It contains all available meticulous permissions. Including ManageWeb, ManagePermissions
• Design: It allows users to create lists and document libraries, edit pages, and apply themes or style sheets (ApplyStyleSheets, AddAndCustomizePages). It is built for site developers. However, it stops short of allowing users to manage site-wide permissions.
• Edit: This is the default permission for the Members group. It enables users to add, edit, and delete both individual items. Including complete lists or libraries (ManageLists). Also, this is the common source of accidental data deletion.
• Contribute: Gives access to users to view, add, update, and delete individual list items and documents (AddListItems, EditListItems, DeleteListItems). But strictly denies the ability to create, delete, or manage the list or library structure itself.
• Read: This is the default permission for the Visitors group. It permits ViewListItems, OpenItems, and ViewPages rights. It grants users the ability to view content and download documents (without making any administrative or structural modifications).

Custom Permission Levels (When and Why to Use Them)

Relying completely on the default permissions mostly results in over-privileged users. Hence, Custom Permission Levels enable administrators to copy an existing default level. And systematically check or uncheck specific base permissions. This assists them in achieving the principle of least privilege.

Here are the high-value use cases for Custom Permissions:

Edit vs Contribute: The Most Common Security Mistake

Knowing the difference between Edit and Contribute in SharePoint prevents the number one cause of accidental data loss in SharePoint. Confusing the Edit and Contribute permission is the most common governance error in Microsoft 365.

The root cause of this vulnerability stems from Microsoft’s default settings. When a new SharePoint site is provisioned, users assigned to the standard Site Members group automatically get the Edit permission level.

Most admins believe that “Edit” permission allows users to edit documents only. But in SharePoint’s backend architecture, the Edit level permits structural administrative rights.

Acknowledge the following “direct comparison” table to understand the critical risk. And the base permissions assigned to each level:

 
But why is the “Edit” Level Dangerous?

Because the only critical difference between the “Edit” and “Contribute” lies in the ManageLists granular permission.

When a user has the Contribute level, they can only access the content within a container. And if they mistakenly delete a single file or a batch of files. Those deleted files go to the Site Recycle Bin. They can be easily restored by the user or an IT admin.

On the other hand, when a user gets the Edit level, they can dictate the containers themselves. So, if a standard user clicks the wrong button in the site settings, it can delete an entire document. This action removes thousands of files and completely obliterates the folder hierarchy.

Including erasing custom metadata columns and cutting off broken inheritance links. However, a Global Admin can retrieve the library from the Second-Stage Recycle Bin. But the disruption to business operations is drastic.

The best fix for this is for organizations to modify the default behaviour of their standard user groups. To do so, follow the simple steps shared below:

• Go to Site Permissions >> Advanced permissions settings.
• Select the checkbox next to the (Site Name) Members group.
• Click Edit User Permissions (in the top ribbon).
• Uncheck Edit>> check Contribute.
• Click OK.

For more info on this, check out: Difference Between Contribute and Edit in SharePoint [Detailed Guide]

What is SharePoint Permission Inheritance?

SharePoint Permission Inheritance refers to a built-in security architecture. In this framework, the child objects (such as folders and documents) automatically receive and implement the same access rights as their parent object (such as a document library or site). This top-down flow confirms a centralized, manageable, and scalable access control.

How Permission Inheritance Works?

Natively, SharePoint Permissions flow hierarchically downward. So, when an administrator assigns a Microsoft Entra Security Group to the “Site Members”, that specific group automatically provides access to every asset contained within that site.

• For your better understanding, here is the exact Security Hierarchy Flow: Site Collection ➔ Subsite ➔ List/Document Library ➔ Folder ➔ Item/Document.

This respective structure simply lowers the administrative overhead. So, when an employee leaves a department, the IT teams are only required to remove them from the top-level Security Group. This update immediately propagates down. And instantly revokes access to dozens of thousands of files within that site.

How Broken Inheritance Exposes Data?

Broken Inheritance is basically a configuration where a child object is deliberately cut off from its parent’s security structure. It is done to apply unique, custom permissions at the folder or item level. Breaking inheritance is occasionally required for restricting highly privileged files within a broader team site. However, executing at large numbers creates severe data governance vulnerabilities:

• The “Share Link” Trouble: When an employee uses the default “Share” button to provide access to a particular colleague, SharePoint automatically breaks inheritance for the specific document. Gradually, a single library is dispersed into dozens of unique, invisible permission scopes.
• Administrative Blind Spots: Specialized permissioned items do not comply with the changes made at the parent level. This means that if an employee moves to a different department and is removed from the main site’s security group, they may still access deeply nested folders. Especially those folders that have broken inheritance.
• Cross-Tenant Migration Failures: Cluttered permissions are a core cause of access mapping failures during complex cloud tenant migrations. And fixing it often needs dedicated IT migration utilities to delete, map, and successfully transfer these unique item-level permissions (to the destination tenant without leaving data orphaned).
  Performance Drop: You might not know, but Microsoft enforces a strict threshold on broken inheritance. Yes, a single list or library cannot exceed 50,000 uniquely permissioned items.

Microsoft 365 Copilot & AI Risks (Why Permissions Matter More Now)

Undeniably, the introduction of Microsoft 365 Copilot has permanently transformed SharePoint security. Back then, it was assumed that if a user didn’t know that a file existed or didn’t have a direct link, they wouldn’t access it. And Microsoft’s AI discarded this assumption entirely.

Acting as a high-speed data retrieval engine, Copilot carries the exact permissions of the user querying it. Therefore, it is imperative for enterprise and IT admins to comprehend how Copilot surfaces over-permissioned data and how to prevent it.

How Copilot Surfaces Over-Permissioned Data?

Understanding how Copilot retrieves information is a critical step for administrators to gauge the risk. Microsoft 365 Copilot doesn’t simply search for keywords; it utilises the Semantic Index for Copilot. A system that maps massive amounts of data vectors across the Graph tenant.

And when Copilot indexes SharePoint content, it saves permission metadata directly with these semantic embeddings. And, when the following permissions remain unmanaged, this creates critical exposure risks:

• The “Everyone Except External Users”: if a legacy site or folder was shared with this default Microsoft Entra ID, Copilot will immediately index that content for every employee.
• Plain-Language Discovery: Users can easily force the Semantic Index to access every file that they have technical access to using a simple prompt. It includes nested folders with accidentally broken inheritance.
• Quick Re-Indexing: Copilot can re-index the affected items and make them available to plain-language queries almost immediately. This typically happens when a site owner inappropriately breaks inheritance and updates broad access.

How to Prevent Copilot from Exposing Data?

To ensure that Microsoft Copilot does not surface enterprise confidential data, administrators need to deploy a multi-layered defense strategy. The framework will determine what AI can access and restrict it from exposing unwarranted information. Even if underlying file permissions are overly broad.

#1: Deploy Restricted SharePoint Search

Restricted SharePoint Search enables admins to disable organization-wide Copilot indexing by default. And enforces a strict “allow list” of up to 100 governed sites. Also, Microsoft introduced it as a stopgap measure for enterprises deploying Copilot before their permission audits are done.

To enable it, run the given command in PowerShell:

Enable-SPORestrictedSearch

#2: Enforce Restricted Access Control (RAC) via SharePoint Advanced Management

Restricted Access Control is a policy that completely denies access to a SharePoint site to any external individual of a designated Microsoft Entra. Enterprises must implement RAC policies for an expansive, long-term solution. To do so, they can use SharePoint Advanced Management (SAM).

Run the given script to enforce RAC via PowerShell:

# 1. Enable RAC at the Tenant level (Takes up to 1 hour to propagate)

Set-SPOTenant -EnableRestrictedAccessControl $true

# 2. Lock down a specific site to a designated Security Group

Set-SPOSite -Identity "https://tenant.sharepoint.com/sites/ExecutiveHR" -RestrictedAccessControl $true -AddRestrictedAccessControlGroups "HR-Exec-Security-Group"

Once it is enforced, Microsoft 365 Copilot will immediately drop the site from the semantic index. This will apply to anyone not in that specific security group, regardless of the previous permissions.

#3: Block AI Indexing using Microsoft Purview Sensitivity Labels

Apply data security posture management (DPSM) at the file level instead of the site level. So, utilize the Microsoft Purview to configure Sensitivity Labels (such as “Highly Confidential”) that completely block Generative AI processing.

So, when setting up the label in the Purview Compliance Center:

• Go to Information Protection >> Labels >> create/edit a label.
• Find Content marking or encryption settings >> move to AI service controls.
• Select “Block Microsoft Copilot from accessing this content”.

By implementing these labels automatically via DLP (Data Loss Prevention) policies, you make sure that Copilot’s Semantic Index will refuse to read, analyze, or return that document in user prompts.

Security Groups vs. Microsoft 365 Groups vs. SharePoint Groups

Before moving to the steps to manage SharePoint Permission Levels, it is important to understand the difference between Security Groups, Microsoft 365 Groups, and SharePoint Groups:

How to Manage SharePoint Permission Levels: Step by Step

Balancing user accessibility with precise data control protocols is the key to managing SharePoint permissions efficiently. Here’s how you can manage SharePoint Permission levels:

Assigning Permissions via the SharePoint Admin Center

Assigning permissions via the SharePoint Admin Center prevents orphaned data and permission sprawl. And provides strong SharePoint governance. It is highly advised not to allot permissions directly to individual users. Always assign individuals to Entra ID, Security Groups, or Microsoft 365 Groups. And permit those groups access to specific SharePoint Levels.

Here are the steps to assign site-level permissions:

• Go to the SharePoint Admin Center (admin.microsoft.com >> SharePoint). Note: It requires an account with SharePoint Administrator or Global Administrator credentials.
• In the left-hand navigation pane, expand Sites >> click Active sites.
• Search for and select the name of the target site collection. It will trigger the site’s properties flyout panel (on the right side of the screen).
• Click the Permissions tab. It will display the current access hierarchy.
• Under the standard permission tier (Site admins, Site owners, Site members, or Site visitors) >> click Manage.
• Locate the appropriate Entra ID Security Group or Microsoft 365 Group >> click Add.
• Lastly, right-click Save (to apply the configuration).

Important Note: The SharePoint Admin Center only applies assignments to the main default groups (Owners, Members, Visitor). To assign groups to the Custom Permission Levels (like “Contribute without Delete”):

• Click “Advanced permissions settings” (at the bottom of the permissions panel).
• It will redirect to the classic _layouts/15/user.aspx page. Here, you can manually map groups to custom role definitions.

Reviewing Permissions with PowerShell Automation

Administrators must automate permission reporting via the PNP PowerShell module for compliance structures and security checks. Because relying on the Graphical User Interface (GUI) to review who has access to what across a sprawling organization is virtually unattainable.

Use the given script to determine all the explicit role assignments (who has which Permission Level) for a particular site collection. And to export the structured data into a CSV file for compliance review.

Additionally, this script outlines “PrincipalType” directly. So, by reviewing the exported CSV, admins can instantly determine if a PrincipalType of “User” (instead of “SecurityGroup”) has been allowed explicit permissions. And flag the violation and enforce group-based RBAC.

# 1. Install PnP PowerShell if not already present

# Install-Module -Name PnP.PowerShell -AllowClobber -Force

# 2. Define target parameters

$SiteURL = "https://yourtenant.sharepoint.com/sites/TargetSite"
$ExportPath = "C:\Reports\SharePoint_Permissions_Audit.csv"

# 3. Authenticate securely utilizing modern Entra ID auth

Connect-PnPOnline -Url $SiteURL -Interactive

#Array to store the audit results

$PermissionReport = @()

Write-Host "Scanning role assignments for: $SiteURL" -ForegroundColor Cyan

# 4. Retrieve all users and groups with explicit role assignments on the site

$RoleAssignments = Get-PnPProperty -ClientObject (Get-PnPWeb) -Property RoleAssignments
foreach ($Role in $RoleAssignments) {

# Load the Member (the User or Group entity)

$Member = Get-PnPProperty -ClientObject $Role -Property Member

# Load the Role Definition Bindings (the Permission Levels assigned to them)

$RoleDefs = Get-PnPProperty -ClientObject $Role -Property RoleDefinitionBindings

# Concatenate the permission level names (e.g., “Full Control”, “Contribute without Delete”)

$PermissionLevels = ($RoleDefs | Select-Object -ExpandProperty Name) -join ", "

# Append structured data to the report array

$PermissionReport += [PSCustomObject]@{
SiteURL = $SiteURL
PrincipalName = $Member.LoginName
PrincipalType = $Member.PrincipalType
PermissionLevel = $PermissionLevels
}
}

# 5. Export the audit log to a CSV file

$PermissionReport | Export-Csv -Path $ExportPath -NoTypeInformation
Write-Host "Permission audit completed successfully. Report saved to $ExportPath" -ForegroundColor Green

SharePoint Permissions Governance: 5 Golden Rules

Implementing a strict SharePoint Permissions governance framework is the only effective route to prevent data sprawl. Including securing AI deployments and maintaining compliance.

So, take account of these five golden rules to ensure your SharePoint environment remains secure, scalable, and most importantly audit-ready.

#1: Adopt a Zero Trust Architecture

Do not entrust a user based on a user’s location or role in the organization. Users should be granted the absolute minimum level of access. Necessary to perform their job functions.

Actionable Step: Assign standard users to the Contribute or Read permission levels. And reserve the Full Control and Design levels specifically for trained Site Collection Administrators and IT personnel. Say an employee only needs to view a financial report. Do not provide them the ability to edit or download it.

#2: Avoid Assigning Permissions Directly to Individual Users

Entrusting a user directly with permissions is the fastest way to create a management horror. Because when a user changes roles or leaves the organisation, IT is left with no centralized way to locate them. And revoke their access across thousands of files. It often results in orphaned data and security breaches.

Actionable Step: Always assign users to Microsoft Entra Security Groups or Microsoft 365 Groups. And then delegate those respective groups to SharePoint Permission Levels. So, when a user leaves and IT removes their identity from the centralized Entra ID group, it will instantly revoke access across the entire tenant.

#3: Limit and Monitor Broken Inheritance

Sometimes breaking inheritance becomes necessary specifically for highly sensitive folders. But doing it at scale impedes tenant performance. Including breaking search indexing and causing severe mapping failure during tenant to tenant migrations.

Actionable Step: Guide Site Owners to develop new document libraries or dedicated sites for restricted content. And educate them to avoid creating deeply nested folders with broken inheritance. To identify and reset uniquely permissioned items back to site-level inheritance, use PowerShell scripts monthly.

#4: Enforce Time-Bound Access for External Guests

Stale accounts are the main target for credential compromise and data exfiltration. Therefore, implementing time-bound access specifically for users outside of the enterprise plays a key role.

Actionable Step: Use Microsoft Entra Access Reviews that prompt business owners to periodically validate guest access. Additionally, set up SharePoint tenant settings to implement automatic expiration policies on external sharing links (such as links automatically expiring after 30 days).

#5: Automate Audits and Restrict Generative AI Indexing

For enterprise compliance frameworks (like HIPAA, GDPR, or SOC 2), manual auditing of site permissions is impractical. And due to unchecked permissions, Copilot can surface privileged information and increase data leak risks.

Actionable Step: Apply dedicated third-party auditing tools or automated PnP PowerShell scripts to generate weekly permission reports. So, to restrict Copilot from indexing unverified or over-permissioned legacy sites, deploy Restricted Access Control (RAC) and Purview Sensitivity Labels.

Permissions Management During Tenant-to-Tenant Migrations

SharePoint Online tenant to tenant migration (due to mergers, acquisitions, or divestiture) is a consuming, high-stakes task. However, transferring the physical files is easy. But migrating the permissions is where most enterprise IT projects frequently struggle.

Primarily, this happens because SharePoint access control is linked to Microsoft Entra ID Object IDs. So, when you migrate a SharePoint Site to a new destination tenant, the users in that new environment carry completely different Entra Object IDs.

And when admins attempt to copy the data over using basic file transfer methods, all granular access gets removed. And this also creates critical security vulnerabilities such as:

• Broken inheritance Collapse
• Copilot Over-Indexing
• Orphaned users.

Since manual PowerShell mapping is insufficient and risky for enterprise environments during a cross-tenant move, what is the effective solution?

FAQs (Frequently Asked Questions)

Q.1: What are the default permission levels in SharePoint Online?
The core default permission levels in SharePoint Online include Full Control, Design, Edit, Contribute, Read, View Only and Limited Access. These map directly to default groups like Site Owners, Members, and Visitors.

Q.2: How do I create a custom permission level in SharePoint?

• Open the SharePoint Site >> click Settings (Gear Icon) in the top right.
• Choose Site permissions >> click Advanced permission settings (at the bottom of the pane).
• Right-click Permission Levels (in the top ribbon).
• Choose an existing baseline permission level (such as Contribute or Read).
• Scroll down to the bottom of the page >> click Copy Permission level.
• Type a new Name and Description (for the custom level).
• Check or uncheck the specific list, site, or personal permission boxes as required.
• Finally, select Create to save a new custom permission level.

Q.3: What does “Limited Access” mean in SharePoint?

Limited Access in SharePoint refers to a system-managed permission level. It is automatically granted when a user is given access to a particular sub-item, file, or folder (without having permissions to the parent site or library). Although, it doesn’t give extra viewing rights, it allows SharePoint to load the navigation. Including the page layout for that specific file.

Q.4: How do I break permission inheritance for a specific folder or document?

• Open the document library >> hover over the targeted folder or document.
• Click the three vertical dots (Show actions).
• In the new panel, click the ellipsis (…) in the top-right corner.
• Select Advanced Settings (or click Advanced at the bottom of the panel.
• Click Stop Inheriting permissions (in the top ribbon of the new page).
• On the warning pop-up, click OK.

Q.5: Who has the authority to change permissions on a SharePoint site?
Users with Full Control permissions or Site Collection Administrators have the authority to change permissions on a SharePoint Site. Global IT administrators (via the SharePoint Admin Center) can also alter SharePoint Permissions.

Q.6: Should I use Microsoft 365 Groups or SharePoint groups for permissions?

Use SharePoint groups for:

• Communication sites (where you manage unique owners, Members, and Visitors directly inside SharePoint).
• Precise roles (when you need custom permission levels such as read-only or review group).
• Isolated scopes (for blocking access strictly to one site collection (without creating extra mailboxes or Planner boards.

Use Microsoft 365 Groups:

• If the site is connected to a Microsoft Team, Outlook shared inbox, or Planner.
• To get membership controls access to the SharePoint site. Including other connected workload tools automatically.
• When the same broad access is required across the whole collaborative workspace.