Every competent person running a Microsoft estate already knows the permissions are wrong. They do not need a tool to tell them that. Ask anyone who has administered SharePoint for more than a couple of years whether there is content in the tenant reachable by people who have no business reaching it, and you will get a shrug and a yes.
What nobody had to think about was that it did not matter. For years it genuinely did not. Then we started pointing agents at it.
Nobody designs a broken permission model
It arrives one reasonable decision at a time.
Someone changes team. Their new access gets added. Their old access does not get removed, because removing it is nobody’s job, and because on the off chance they still need something from the old role, taking it away creates a ticket and a conversation.
A site gets shared with Everyone Except External Users for one afternoon in 2022 so a consultant can find a document. It stays that way.
Inheritance gets broken on a library to fix access to a single file. The break is permanent. The reason for it is forgotten within a fortnight.
A project finishes. The site stays. The membership stays with it, along with the three contractors who were added to it.
Leavers get handled, because HR chases leavers and there is a compliance driver behind it. Joiners get handled, because somebody is standing in reception waiting to start work. Movers are where the model rots, and in any established organisation movers are the majority of what actually happens. Access is additive across a career, and almost nothing ever takes it back. I have written about why the mover leg breaks separately, because it is the root cause of everything else on this page.
The reason it never caused an incident
In most organisations, none of this has ever caused an incident. Not because the access was correct, but because nobody was ever going to find it. No human being navigates four levels into a project site from 2019 to read a spreadsheet they did not know existed. The access was there. The path was not.
Obscurity was doing the work of a control.
It was doing it well enough that nobody ever wrote it down. Go and look at your risk register. There will be no entry that reads “we are relying on our staff being unable to find things.” Nobody formally accepted that risk, because nobody knew they were carrying it. It was load-bearing and invisible at the same time, which is the worst combination a control can have.
What changes when the thing asking is not a person
Agents do not navigate. They index, and they retrieve.
Microsoft 365 Copilot honours existing permissions. That is true, it is the first thing any vendor will tell you, and it is not the reassurance it sounds like. It means the agent returns anything the account could technically reach, and it removes every practical obstacle that used to sit between “technically reachable” and “actually found”. Somebody asks a plain English question about salary bands and gets an answer, drawn from an HR site they were added to for one meeting in 2023 and never removed from.
Notice there is no network anywhere in that sequence.
This is the point where the argument that identity replaced the network perimeter stops being an architectural abstraction and becomes something you can picture. There is no packet to inspect. No traffic crosses a boundary you own. A perfectly patched firewall with IDS and IPS behind it is not in the path of that transaction, because the request is authenticated, legitimate and already inside. The user is who they say they are. The permission is real. Your network control is not being bypassed. It is simply not involved.
Microsoft already ships the tooling
This is the bit that makes the whole situation slightly absurd. The tooling exists, it is documented, and a good deal of it is already sitting in your tenant.
- Data access governance reports tell you which sites are shared with everyone, which have the most sharing links, and which have broken inheritance.
- Restricted content discovery lets you flag a site so its content stays out of Copilot results without changing anyone’s permissions.
- Restricted SharePoint search limits discovery to an approved list of sites while you get the estate in order.
- Sensitivity labels and Purview DLP carry protection with the content rather than with the location.
- SharePoint Advanced Management pulls a lot of this together, and much of it becomes available once Copilot licensing lands.
None of that is secret. None of it is hard. So why does the problem persist?
Because the tooling was never the constraint
Tooling nobody knows about never gets run. And the people who do know about it are rarely the people deciding when the agent gets switched on.
That decision tends to get made somewhere else. It gets made against a delivery date, in a programme with a board slide attached to it, by somebody who asked whether the permissions were handled and was told that they were. The identity lead who could have told them otherwise was not in the room, because identity is treated as an implementation detail of a rollout rather than a precondition for it.
I made this comparison to someone recently and it came out as Challenger.
The engineers at Morton Thiokol knew the O-rings were a risk in cold weather. They said so, on a teleconference, the night before the launch. They gave a no-launch recommendation and it was reversed by management under schedule pressure, and one of them was famously told to take off his engineering hat and put on his management hat. The Rogers Commission documented all of it afterwards.
Nobody dies when an agent surfaces a salary review. I am not putting a data exposure anywhere near seven astronauts, and the outcome is a blown up version of what we are discussing here. But the trajectory is identical. The people who understand the hardware raise the concern, and the people who own the date make the decision.
Why the pre-deployment audit does not hold
Search for advice on this and you will find a great deal of it, almost all of which says the same thing: audit your permissions before you deploy. That advice is correct. It is also incomplete in a way that matters.
An audit produces a report. The report produces a run of urgent remediation meetings, some genuinely useful cleanup, and a slide that says the estate is now in a known state. All of which is worth doing, and I have written up the practical version of it so you have it in one place.
But it fixes a snapshot of a flow problem. The morning after you finish, someone changes team, a site gets shared for one afternoon, and inheritance gets broken on a library to solve an urgent problem. The process that produced the sprawl is untouched, so the estate starts accumulating again immediately. Eighteen months later you are back where you started, except now the agents are already in production and the remediation project has been signed off as complete.
Point-in-time remediation against a continuous process is a treadmill you can only lose on. The audit is the start of the work, not the work.
What actually holds is boring and structural: a mover process that removes as well as grants, access that is scoped and time-bound rather than standing, access reviews that someone owns, and a governance report that gets looked at on a schedule rather than in a panic.
You can reproduce this in your homelab in an afternoon
If any of the above sounds abstract, the failure mode is genuinely easy to build at home, and building it teaches you more than reading about it will.
Stand up a local model. If you have a Pi sitting in a drawer, Ollama on a Pi 5 is enough to do this. Point it at a document store and index a directory tree that has grown organically, which for most of us means anything we have been dumping files into for more than a year. Then ask it a question in plain English rather than going looking for a file.
Watch what comes back. Not what you asked for, exactly, but what it decided was relevant, from folders you had forgotten were in scope.
That is the enterprise failure mode in miniature. Same mechanism, no licence cost, and once you have seen it happen on your own data it becomes considerably harder to nod along when someone tells you the permissions are handled. The homelab version is also a good deal cheaper to be wrong in, which is rather the point of having one. It is the same reason a homelab teaches security basics better than a slide deck does.
Who is actually in the room
The question is not whether you have run the assessment. Plenty of organisations have run the assessment.
The question is whether the person who actually understands your permission model has any say in when the agent goes on, or whether they will find out from the announcement like everybody else.
The rest of this series:
- Joiners, Movers and Leavers: the mover leg is where your permission model rots
- Least Privilege in Practice: standing access, scope, and just-in-time
- The Permissions Work to Do Before You Deploy Copilot
ReadTheManual is run, written and curated by Eric Lonsdale.
Eric has over 20 years of professional experience in IT infrastructure, cloud architecture, and cybersecurity, but started with PCs long before that.
He built his first machine from parts bought off tables at the local college campus, hoping they worked. He learned on BBC Micros and Atari units in the early 90s, and has built almost every PC he’s used between 1995 and now.
From helpdesk to infrastructure architect, Eric has worked across enterprise datacentres, Azure environments, and security operations. He’s managed teams, trained engineers, and spent two decades solving the problems this site teaches you to solve.
ReadTheManual exists because Eric believes the best way to learn IT is to build things, break things, and actually read the manual. Every guide on this site runs on infrastructure he owns and maintains.
Enjoyed this guide?
New articles on Linux, homelab, cloud, and automation every 2 days. No spam, unsubscribe anytime.
