Who sees what — access permissions before you automate
Access granted person by person quietly drifts out of step, until nobody can say who sees the price list. Fixing it with roles, structure and quarterly review.
Ask around your company who can see the purchase price list. Not who should — who actually can, today.
The answer usually starts with "sales and the board, I think" and ends when somebody remembers the same file sits in a project folder two subcontractors were added to last year. Access was granted one request at a time, each grant sensible on its own, with nowhere to see them side by side.
A boundary first: this piece is about people's permissions. What an AI agent may do is the next question, covered in AI agent permissions — a continuation, not an alternative. An agent runs on some account's permissions, so if the human accounts have drifted, it inherits the drift and speeds it up.
Where the drift comes from
No company decides that access should be a mess; the mess is the sum of individually sensible decisions.
Someone asks for a folder because they need one file in it, and gets the folder, because that is quicker. Someone covering a two-week absence gets rights "for the cover" that nobody removes afterwards, because removing them is nobody's job. A new joiner gets whatever their predecessor had, including everything the predecessor accumulated over years and several roles.
A few months on, the real state matches nobody's picture of it, including that of whoever granted the access.
Roles, not people
This is the difference between a state you can describe and one you cannot reconstruct.
A role describes work, not a person. "Field engineer" is the access a field engineer needs: jobs in their region, the schedule, equipment records, customer contact details. Not "whatever Mark got when he joined".
A permission granted to a person has no reasoning anyone can go back to. Only that person and the grantor know it, if the grantor remembers. A role is written once and visible to all, so "why can he see that?" stops being an investigation.
Scope changes in one place. If engineers should not see the margin on parts, you fix one role rather than forty accounts.
Companies need fewer roles than they assume, because an access role is not a job title: an engineer and a senior engineer see the same things and differ in what they answer for. Mapping roles one-to-one onto titles recreates the problem roles were meant to solve.
Exceptions are fine on one condition: an expiry date and a named grantor. Without a date, an exception quietly becomes part of the role.
Access that follows from structure
The second step matters more and gets done less often: access should follow from an assignment, not a tick box.
A person belongs to a team, the team owns an area, the area has its data. Whoever is on a project sees the project's documents; whoever is assigned to a job sees that job. There is no separate "grant access" step, only an assignment that has to happen anyway — without it nobody knows who is doing what.
The payoff shows up on change. Moving someone between teams is one operation, not a checklist. Coming off a project removes the access the moment the person stops working on it.
One condition, and an uncomfortable one: the structure has to be real and maintained. Teams in the system that do not match teams in the building make inheritance propagate a fiction. It is the same prerequisite as preparing company data for AI.
The day somebody leaves
A leaver is the exam on everything above. Where access follows from a role and a structure, removing it is one action; where it was clicked in by hand, it depends on three people's memories.
Four places where the most is left behind:
Tools on no shared list. An account in an app a department put on its own card shows up in no central place — one reason to know how many tools exist at all, covered in how to cut down your tool stack.
Documents the leaver owns. When the account is disabled the files vanish with it or sit with no owner.
Shared accounts. People remember the office@ password for years. Disabling a personal account does not close that door; changing the password does.
Access on the client and supplier side. Portals, ticketing systems, shared drives — nobody inside your company can revoke these, so they belong on the list.
That list is the joining list read backwards, which is why it is worth writing down while onboarding a remote employee. And disable accounts rather than deleting them: a deleted account takes the change history with it.
A review that fits in an hour
Once a quarter, with a date in the calendar and one named owner. Without those three things it never happens: not hard, just never urgent.
- Exceptions. Any whose date has passed either goes, or gets a new date and one sentence of justification. There is no third option.
- People who changed roles. A role change adds new access; removing the old is a separate act, and the review is the only place it happens.
- Access nobody uses. If the system shows who opened what, the conclusion is free: anything untouched since the last review was not needed.
The review belongs to whoever owns the area, not to whoever granted the access — the grantor will only re-confirm their own choices.
"Everyone sees everything" is a decision
And often a good one: full openness shortens the chain of asking and removes the bottleneck on whoever hands out access. But chosen openness and inherited openness differ. The chosen kind has a written list of what falls outside it — pay, HR records, commercial terms, client-confidential documents — and someone maintaining it. The inherited kind has neither, and the company discovers its own model the day something leaks.
Openness nobody announced also ends: the day the first person decides it is safer to keep their files to themselves. Then there is neither openness nor control, just a second, invisible set of documents.
Summary
Access granted to people records history rather than the present, which is why before long nobody can say who sees the price list. A role describes the work and changes in one place; access derived from a team, a project or a job updates with the structure.
The rest is two dates in a calendar: a quarterly pass over the exceptions, and the joining list read backwards when someone leaves. Choosing that everyone sees everything is an answer too — as long as somebody said it out loud.
The wider context — putting data and permissions in order before letting anything automatic near them — is in the guide on AI adoption for companies with no IT department.
Frequently asked questions
- Should permissions be granted to roles or to individual people?
- To roles. A permission granted to a person is known only to that person and to whoever granted it, so after a few months nobody can reconstruct why someone can see a particular set of records. A role is written down once, visible to everyone, and changing its scope takes effect immediately for everyone who holds it.
- How often should a small company review access?
- Once a quarter is enough, provided the review is short, has a date in the calendar and one named owner. Beyond that, always on a change of role and always when someone leaves — the two moments when access drifts fastest, because new grants get added and old ones never get taken away.
- Is an open model where everyone sees everything a bad idea?
- Not necessarily bad, but it has to be a choice rather than the result of nobody sitting down to the question. Even with full openness some areas fall outside it: pay, HR records, commercial terms and anything covered by a client agreement.
Read next
Metrics worth tracking — and the ones that just look smart
Dashboards die because they show what was easy to count, not what anyone reacts to. What separates a real metric from a chart, and how to cut the list down.
Why AI pilots stall — five reasons they never reach production
The pilot works and production never arrives. Five mechanisms that stall AI adoption at the demo stage, and what to do differently in a company of 11–200.
Where to start with AI — how to pick the first process
The first process matters more than the tool. Four conditions a good candidate meets, three choices that reliably fail, and how to set success upfront.