Every gym has that person. Enormous upper body, legs they haven't thought about since high school. They trained what shows in the mirror and skipped what holds the weight. It works fine for years, right up until they put a heavy bar across their shoulders.
That's Microsoft 365 governance in 2026, and the bar just got loaded. In ourState of Microsoft 365 Governance Report 2026, a Censuswide survey of 327 IT and security decision-makers at organizations of 500 or more employees, 76% have already deployed or piloted Copilot or another enterprise AI tool that reads their M365 data.
This post isn't about that number. It's about what sits underneath it, and why what everyone calls an AI readiness problem is really a permissions and ownership problem that has been compounding for a decade.
One note on the numbers before we start. Everything here comes from practitioners describing their own environments, not from tenant scans, and self-assessment tends to flatter. Whatever the gaps below look like, the real ones are probably wider.
Ask a Microsoft 365 admin how they answer "who has access to this site" and you'll hear the same answer. They wrote a script.
Our data backs that up. 37% of teams govern their tenant with PowerShell they wrote themselves, and 33% run scripts from the community or GitHub. Only 8% have a dedicated governance tool, while half of organizations run all of this on one to two full-time equivalents.
PowerShell isn't the problem. It's the honest workhorse of every Microsoft estate. The problem is what a script is in governance terms: it does exactly what its author understood the day they wrote it, runs when somebody remembers to run it, and is documented in precisely one place, which is that person's head. Every tenant change and renamed cmdlet becomes maintenance work landing on a team that already has a day job.
And the budget conversation that would fix it isn't happening. 47% describe leadership as aware of governance risk but not treating it as a priority, while the biggest trigger that would unlock investment is a leadership mandate after a board discussion, named by 45%. The lever and the blocker are the same people.
So the admin writes another script. That's the diagnosis in one sentence.
Almost no oversharing is malicious. It's ordinary collaboration meeting defaults that are too generous, and three mechanisms do most of the damage.
Sharing links are transferable secret keys. Click Share and Copy link without touching the settings gear and you usually create a "People in your organization" link: revocable, but transferable, and usable by anyone inside your tenant who receives it. Send it to one person with five others in CC, and if those five click, all five now have permission to that document. Do it on a folder and they hold standing access to everything inside until somebody manually removes them, which rarely happens.
SharePoint does tell you what you're about to create. It tells you in a tooltip, on hover, underneath the button most people click without looking.
Whenever somebody shares an item with permissions that differ from its container, SharePoint silently breaks inheritance and that item gets its own permission set. Not manually, not with a warning. Microsoft's recommended limit is 5,000 unique permissions per list or library, with a hard ceiling of 50,000, and the platform never restores inheritance on your behalf. Site owners check site-level permissions and group membership; the broken ones sit a layer below and stay invisible for years.
EEEU is a built-in group containing every internal user in your tenant, and it's faster than adding fifteen people individually. This became such a widespread problem that Microsoft now disables it by default for new tenants, requiring PowerShell to re-enable. If your tenant predates that change, it's probably still in your people picker.
Now let time go to work on all three. Permissions should last only as long as the task that needed them, but nobody circles back to remove somebody from a project that wrapped two years ago. In our study, 58% admit confidential content is currently accessible to departments that should not see it, and 41% report SharePoint sites open to all staff.
None of this has to stay theoretical, because you can measure it. While writing this post I audited my own tenant, checking every site for its default link type, its default permission, and whether a copied link still breaks inheritance.
The script looks a bit complicated but it’s because Get-SPOSite -Limit ALL on it’s own does not populate the sharing properties, so the obvious one-liner returns confident, wrong answers. You have to read each site individually instead, which costs roughly a second per site. Minutes on a small tenant, an afternoon on a few thousand sites.
Forty-nine sites where copying a link still breaks permission inheritance. Two where Anyone is the default. Two handing out Edit without anybody asking for it. That's a demo tenant rather than a 20,000-seat enterprise, and it still took a script I had to write myself to find out. Which is the daily problem most tenants have in real life.
Orphaned workspaces were the most cited challenge in the entire study, named by 47% of respondents, with 92% estimating they carry at least some right now.
It starts with something completely routine. Somebody leaves, you delete their account, and a Microsoft 365 group somewhere quietly loses its last owner. Nothing breaks. Nothing alerts. The files, the members, the guests, and every sharing link anyone ever created carry on exactly as before. The only thing that disappears is the person whose job it was to ask whether any of it still made sense.
Microsoft's ownerless group policy is meant to catch this, and it's worth knowing how far it actually goes. It's off by default. Turn it on and it emails the most active members, asking one of them to volunteer. If the group is dormant, and dormant groups are exactly the ones you should be worried about, it picks members at random. And if nobody accepts, the documented behavior is that it stops sending notifications and takes no further action.
This is not a misconfiguration. Unticked is how the ownerless group policy ships, in every tenant.
There's a second reason these are hard to spot, and it comes down to a quirk in how permissions flow. Microsoft 365 group owners automatically become SharePoint site collection admins, but it does not work the other way around: adding somebody to the SharePoint Owners group does not make them an owner of the M365 group. So a site can show a perfectly healthy owner while the group underneath it has none at all. Spot-check the site and everything looks fine.
All of this stays abstract right up until somebody clicks the wrong link. So ask it the way an attacker would: when one of your people falls for a phishing email, and eventually one of them will, do you want that account to reach five sites or fifty?
That's the whole argument for least privilege. Excessive permissions don't cause the breach, they determine its blast radius. And most exposure never involves an external attacker at all: Microsoft's own research attributes 63% of data breaches to insiders. In our study, 90% reported a confirmed or suspected security incident tied to misconfiguration or over-permissioned access in the past two years.
Then there's the regulator. Nearly every organization in our study operates under at least one compliance regime, and under GDPR, HIPAA, or PCI DSS internal over-permissioning isn't a technicality. Sometimes employees having access to patient records, client lists, or cardholder data is itself the violation, before anything leaks anywhere.
The controls exist. Purview DLP can restrict content containing credit card or bank account numbers, and sensitivity labels can encrypt files or exclude them from Copilot processing entirely. The honest problem is how few organizations turn them on.
Microsoft 365 Copilot enforces your permission model faithfully. It is designed to surface only content a user can already open. The problem is that users can already open things they shouldn't, and AI is the great amplifier: before, somebody had to know what to search for and often had to dig. Now they ask a normal question about their job and overshared content arrives in the answer.
You can watch that play out in the research. 91% of our respondents are confident AI would surface only authorized content, while 58% of those same people admit the wrong departments can already reach confidential files. Both of those are true at once, and that is the whole problem. AI is faithfully reproducing a permission model nobody has audited end to end.
Agents raise the stakes, because they hold standing access rather than momentary attention. 9% of respondents told us agents in their environment run under the same permissions as whoever deployed them, with no separate controls.
Now look at where this is going. Microsoft introduced Scout at Build 2026, its first always-on autonomous agent, working across Teams, Outlook, OneDrive, and SharePoint. The detail that matters for admins is architectural: Scout runs under its own dedicated identity in Microsoft Entra rather than a shared account, with permissions scoped to the task. It is an experimental release today, limited to organizations enrolled in the Microsoft Frontier program, so treat this as direction rather than something landing in your tenant next week.
That's the right design, and it moves the governance question rather than removing it. Microsoft Entra Agent ID, currently in preview, requires every agent identity to have a human sponsor accountable for its lifecycle and access reviews, with sponsorship transferring to a manager when that person leaves. Read that again if you recognize the shape. An agent with no sponsor is, in Microsoft's own words, governance-invisible.
We just spent this entire post describing what happens to a workspace when nobody owns it. We're about to run the same experiment with identities that can act on their own.
Every mechanism in this post has a control that already exists, and the two that matter most are free. What matters more is the order. Fix your defaults before you start cleaning up history, or you'll spend a quarter remediating a tenant that is still manufacturing the problem faster than you can fix it.
Start with permissions
Begin with defaults, because they're the only change that keeps working while you sleep. In the SharePoint admin center, set the default sharing link to Specific people with View permissions, then push the site-level default to "People with existing access" so a copied link stops breaking inheritance at all:
Only then go looking for what's already broken. The Data Access Governance reports will show you EEEU sharing, unique permissions, and sharing link counts, site by site, without writing anything yourself. You get these with SharePoint Advanced Management, with Microsoft 365 E5, or with Microsoft 365 Copilot licenses, which include SAM. That last one catches a lot of people out, because if you're reading this you may already own them.
Sites ranked by how many unique users can reach them, which is useful, and worth knowing where it stops.
One limitation to know before you lean on it. The UI version of the report ranks the top 100 sites by how many unique users can reach them, so on a tenant with thousands of sites, you will need to download to CSV and hopefully build a way to consume it! Whether it’s a nice Power BI report, a Power App, or a vibe-coded app!
Then fix ownership
Turn on the ownerless group policy, but treat it as a smoke alarm rather than a fix: it tells you a workspace has lost its owner, then stops talking. The real control is a two-owner minimum, so one departure can never orphan a workspace in the first place. Then put Microsoft 365 group access reviews on a quarterly schedule, so the people who know what a workspace is for decide who belongs in it, instead of IT guessing from a membership list.
Conclusion
The reason people skip leg day isn't laziness. Nobody sees your squat numbers, the work is boring, and there's no immediate consequence for putting it off. Governance is identical: nobody celebrates the incident that didn't happen, and the invoice arrives years later, all at once, usually with a regulator's name on it.
AI didn't create the weakness. It just added load, and load is how you find out.