SharePoint permissions explained

SharePoint permissions have a reputation for being arcane, and the reputation is only half deserved. The underlying model is small and consistent; the confusion comes from the fact that access can arrive through four or five different doors, and the admin UI shows you one door at a time. Once you know all the doors, most permissions problems turn into five-minute diagnoses.

The core model

Every securable object in SharePoint — site, library, folder, file, list, item — has an access control list that maps principals (users or groups) to permission levels (Full Control, Edit, Contribute, Read, and any custom levels). Permissions inherit down the hierarchy unless inheritance is deliberately broken.

By default:

• A site has three SharePoint groups: Owners (Full Control), Members (Edit), Visitors (Read).
• Libraries, lists, folders, and items inherit the site's permissions.

That's the whole model. Everything else — group-connected sites, sharing links, site collection admins — is a layer on top of it, and every layer resolves back to "some principal got some permission level on some object."

Microsoft 365 Group-connected sites

Modern team sites are usually connected to a Microsoft 365 Group, and that changes the picture slightly. The site's Owners and Members groups mirror the group's owners and members — add someone to the Microsoft 365 Group (from Teams, Outlook, Planner, or Entra ID) and they get site access without anyone touching SharePoint. The Site Visitors group is empty by default.

This is the number one source of "how does this person have access?" confusion: they were added to the Team, and Team membership is site membership. The same applies in reverse — removing someone from the site's Members group in SharePoint does not remove them from the underlying Microsoft 365 Group, and group membership will keep granting access. Manage membership at the group level, always.

Communication sites are the exception: they're not group-connected, so their SharePoint groups are the real source of truth.

Sharing links

The other major path to access is sharing links — "Anyone with the link," "People in your organisation," and "Specific people" links created from the Share button. Sharing links grant permissions behind the scenes, usually at the item or folder level, which means they quietly break inheritance for that object.

Two things make sharing links the origin of most permission mysteries:

• "People in your organisation" links grant access on first use. The link itself carries the permission; whoever in the tenant clicks it gets access, and they show up in Manage access afterwards. Nobody "shared it with them" in the sense the site owner remembers.
• Links outlive intent. A file shared for one meeting is still shared two years later. Nothing expires by default for internal links.

For the external flavour of this problem, see SharePoint external sharing.

Breaking inheritance

You can break inheritance on any library, folder, or item and give it its own ACL. SharePoint warns you when you do it, and the warning is earned: broken inheritance is nearly impossible to audit at scale, it slows large libraries down, and it accumulates. The working rules:

• Grant access at the site level whenever possible. If two audiences need different access, that's often two sites, not one site with clever folder permissions.
• Break inheritance on a library only for a clear, durable reason — an HR site with one manager-only library, say.
• Never manage permissions per file. Item-level unique permissions are a sign the information architecture is wrong, and a restructure will cost less than the ongoing confusion.

Admin-level access

Above the site's own groups sit two roles worth knowing: site collection administrators (full control of everything in the site, set per site) and the SharePoint Administrator Entra role, which can grant itself admin on any site through the admin center. Auditors and migration tools often get access this way — check it when access seems to come from nowhere.

Troubleshooting order

When a user has the wrong access — too much or too little — check in this order:

1. Site Owners/Members/Visitors groups on the site.
2. Microsoft 365 Group membership (for group-connected sites), including nested security groups.
3. Sharing links on the specific item — the per-item Manage access panel lists every link and who's used it.
4. Broken inheritance up the parent chain — folder, library, site.
5. Site collection admins and admin-center-granted access.

The per-item Manage access panel plus the site permissions page cover most cases. For tenant-wide visibility, SharePoint Advanced Management generates data access governance reports that point at oversharing hot spots — sites with broad "Everyone except external users" grants, heavily shared items, and sites with lots of unique permissions.

Why this matters more now

Permissions hygiene used to be a slow-burn problem: overshared content sat unread. Microsoft 365 Copilot changed that — Copilot surfaces whatever the signed-in user can access, so every forgotten sharing link and every "Everyone" grant becomes discoverable by asking a question in plain English. The guide on Copilot data access and permissions covers that angle; the short version is that the boring model described above is now the foundation of your AI rollout. Get the site-level grants right, retire the item-level exceptions, and both your users and Copilot will behave predictably.