Every time someone clicks Copy Link on a single file and picks one person, SharePoint breaks permission inheritance on that item and its parent library. But one share like that isn't a problem. Ten thousand of them, scattered across your tenant and invisible from any site-level report, are how a clean permissions model turns into one nobody can explain.
Broken SharePoint permission inheritance happens when an item stops taking its permissions from its parent and keeps its own set instead. Two things cause it: someone deliberately applying unique permissions to a library, folder, or item; and someone sharing a single file, which breaks inheritance on that item automatically. Both can look identical in a report, and they may need different fixes.
At a handful of exceptions, that's fine. Across thousands of sites, it's how access drifts past anything you can audit, and how Copilot ends up surfacing content the requester was never meant to see.
Permissions in SharePoint cascade down from the site. Everything inside it, libraries, lists, folders and files, inherits from that one place, and nothing re-grants permissions along the way. The chain only becomes something you have to think about where a break interrupts it.
Leave everything connected and you manage access in one place, at the top, and every item below follows along. That default is the whole reason inheritance exists: it keeps a site predictable.
Inheritance holds until something stops it. When an item stops inheriting, SharePoint takes a snapshot of who currently has access, copies it onto the item as its own permissions, and cuts the link to the parent. From that point the item is on its own, and a change made at the site level never reaches it.
One side effect trips up almost everyone reading a permissions report for the first time. When you give someone access to a single file, SharePoint grants them a "Limited Access" entry on the parent folder, library, and site so they have a path to navigate to that file, without seeing anything else. You never assign Limited Access on purpose, but it shows up everywhere unique permissions exist, which is exactly why a raw permissions export looks like noise.
Inheritance can break at any level: site, library, folder, or file. Where it breaks changes how much you should worry.
A deliberate break on a library that holds HR reviews is a controlled exception; a break on a single file because someone shared it in a hurry is the kind that multiplies. A break at one level also becomes the new starting point for everything beneath it, so a single library with unique permissions reshapes access for every folder and file it holds.
The largest containers come with a hard limit. Once a list, library, or folder holds more than 100,000 items, Microsoft's documentation says you can't break or restore inheritance on the container itself, only on the individual items inside it. On a library that has already fragmented, that limit decides what remediation is even available to you.
This is the distinction that decides your fix. A break caused by a deliberate unique permission is an intentional exception: someone chose to manage access on that object directly. A break caused by a sharing link is a byproduct: someone shared a file, and SharePoint broke inheritance to record who they shared it with.
The two look the same in a native report. Both read as "unique permissions" in native permission screens. But the deliberate one usually has an owner and a reason, and the sharing-link one usually has neither, because it happened through a Share dialog nobody thought of as a permissions change.
Only 13% of M365 admins could accurately describe how the SharePoint Copy Link sharing default inherits. What most of them miss is that a single copy link breaks inheritance twice: on the item itself, and on the library above it. That's how invisible the second cause is, even to the people responsible for it.
That distinction is where tooling has to do the work. Orchestry's Broken Inheritance report finds breaks on the items and folders inside a library and labels each one by cause: a sharing link, or a unique permission. Instead of a flat list of items that "have unique permissions," you get a report that already tells you which fix each break needs.
Orchestry's Broken Inheritance report labels every break by cause, so the sharing-link breaks and the deliberate ones can be filtered apart.
Finding one broken item is trivial. The problem is finding all of them, across every site, which is where native tooling stops helping.
There's no built-in report that says "show me every object in the tenant where inheritance is broken." You're left checking sites one at a time, or writing PowerShell that enumerates unique permissions and produces a snapshot that's stale the week after you run it.
A site-level permissions report shows you the starting point and little else. The moment inheritance breaks on a library or folder, the objects beneath it drop out of the tidy top-level view, and the direct grants living inside become invisible unless you go looking for them by hand.
Nested groups make it worse, because access granted through a group inside a group doesn't show up where you'd expect it. This is how SharePoint permissions quietly turn into a mess that no one signed off on.
Scale also has a documented ceiling. Microsoft supports up to 50,000 unique permissions in a single list or library but recommends no more than 5,000, because performance degrades as the count climbs. By the time a library is deep into that range, you have both a performance problem and a visibility problem, and no native way to see the whole picture at once.
Orchestry narrows that gap where most of the damage is. Permissions Reporting brings the broken-inheritance items from across your libraries into one place, each labeled by cause, alongside permission stats that refresh nightly, including how many objects grant access to Everyone Except External Users, the group that most often turns one library into tenant-wide exposure. Libraries are where copy-link breaks accumulate, so that's the surface worth watching first.
For the full hierarchy behind any workspace, the Permission Browser (on Orchestry's Enterprise plan) expands the whole permission tree, broken-inheritance items included, so you can see who has access and how they got it without hunting through tabs.
Once you know the cause, the fix follows. Sharing-link breaks and deliberate unique-permission breaks get handled two different ways, and treating them the same is how you either miss real exposure or wipe out access somebody needed.
For a sharing-link break, removing the link is where most people start, and it doesn't finish the job.
Deleting or expiring the link retires the access it created, but the object stays flagged as having unique permissions, so inheritance doesn't come back on its own. If that link held the last principal, you get orphan broken inheritance: an object cut off from its parent with nobody on it, where non-admins lose access entirely and SharePoint never restores the connection for you.
Knowing which links to go after is the first half of the work. Putting the object back under its parent is the second, and native tooling leaves you to do it one object at a time.
For a deliberate break you actually want to undo, the fix lives in SharePoint. Open the object's permissions and use Delete unique permissions to reconnect the item to its parent. Don't touch Stop Inheriting Permissions while you're in there: that's the control that creates a break, not one that shows you the current state.
SharePoint's own warning when you delete unique permissions: every custom rule on the object goes at once.
Microsoft is blunt about the tradeoff: restoring inheritance removes every unique rule on that object at once, and you can't selectively keep one. Confirm the object no longer needs its own access before you reset it.
Doing that at scale is the gap Orchestry is closing next. Workspace Access Actions, now in development, will run bulk access changes, sharing-link purges and broken-inheritance resets across thousands of workspaces in one pass, with whole-tree depth down to item permissions.
Cleaning up once buys you a quieter tenant for a few weeks. Keeping it that way means changing the habits that broke inheritance in the first place.
Two habits help, and neither one is a fix.
But Copy Link sits in front of every user in every app, and one click undoes a quarter of careful practice. Treat prevention as slowing the rate, and put your real effort into finding and resetting the breaks that accumulate anyway.
The harder part is review, because exceptions are only safe when someone with context checks that they're still justified. The workspace owner knows whether the finance folder still needs its own permissions; you don't, and you can't chase every one of them yourself.
A recurring permission review turns a fire drill into a routine. Orchestry's Workspace Review Automation (available on Professional and Enterprise plans) schedules owner-driven attestation of sharing links, membership, and access, so the person closest to the content confirms what's still needed on a cadence you set, and the exceptions that used to accumulate get caught while they're still small. That routing of the decision to the owner, rather than back to IT, is the difference between a cleanup that holds and one you repeat every quarter.
Getting habits and reviews right is also how you keep Copilot from surfacing the access you already had. Copilot retrieves whatever your permissions allow, so every broken inheritance you leave in place is one more thing it can pull into an answer.
No. Breaking inheritance doesn't harm anything; it just gives that one object its own set of permissions instead of taking them from its parent. The real risk is losing track of how many breaks exist and why, until no one can explain who has access to what.
Limited Access is a permission level SharePoint assigns automatically when someone is given access to a single item, so they can reach that item without seeing everything around it. You never grant it on purpose. It appears on parent folders, libraries, and sites wherever unique item-level permissions exist, which is why it fills up permissions reports and makes them hard to read.
Microsoft supports up to 50,000 unique permissions in a single list or library but recommends staying under 5,000, because performance drops as the count grows. Treat 5,000 as a ceiling to design away from, not a target, and remember that containers over 100,000 items can't have inheritance broken or restored at the container level at all.
Yes. Copilot respects existing SharePoint permissions, so any content exposed by a broken inheritance, especially through a stray sharing link or an Everyone Except External Users grant, is content Copilot can retrieve and surface in an answer. Broken inheritance is one of the most common reasons Copilot returns information a user was never meant to see.
Broken inheritance starts as a diagnosis problem and ends as a remediation one. Two causes that look identical in a native report need two different fixes, and neither fix is a single click. Tell them apart, reset what should never have been separate, and you have a permissions model you can defend to an auditor.
To see where SharePoint permission inheritance is broken across your own tenant, and which breaks came from sharing links versus deliberate permissions, book an Orchestry demo to see it against your real environment.