User roles and permissions decide who can do what in a system: who can read a file, who can edit it, and who can delete it or manage other people's access. When you can view a shared file but not edit it, that is a permission system doing its job.
The most common way teams break this system is by giving everyone Admin access. This guide follows that mistake from the first odd entry in an activity log to its cause. It then covers a step-by-step fix using roles and the habits that stop the problem from coming back.
- A permission is one action. A role is a named bundle of permissions.
- Teams usually end up all-Admin through a quick shortcut, not bad intent.
- Diagnose first: list every admin and ask whether each person's job needs that power.
- Fix it in four steps: define actions, group them into roles, assign roles, and check every request.
- Keep it tidy: start new people small, review regularly, and remove access promptly.
- 0:00Intro
- 0:25Something vanished, and anyone could do it
- 1:17Why everyone ends up Admin
- 2:14Permissions grouped into roles
- 3:13The check on every request
- 3:59Find out who really has Admin
- 4:54Questions to ask each admin
- 5:46Define the actions your system allows
- 6:35Group permissions into clear roles
- 7:21Assign each person one role
- 8:10Check the role on every request
- 9:01Same team, far less risk
- 9:46Habits that keep access tidy
- 10:37Similar symptoms, different causes
- 11:23The whole fix in five points
- 11:53Give everyone only the access they need
Something vanished, and nobody broke a rule
This problem rarely shows up as an error message. It shows up as a quiet surprise in the activity log, followed by a confused message in the team chat asking who deleted the budget. Nothing crashed and nothing warned you. That is what makes it sneaky: the mistake can sit unnoticed for months before it causes real harm.
Look at a typical log. A new intern deleted the budget file. A contractor shared the client list with anyone who has the link. A guest changed the billing settings. The system allowed every one of those actions, because its settings said yes to everyone on the team.
You can't point to a bug, because there isn't one. The damage is also often hard to roll back. Some deleted files can be restored, but a link that has already leaked can't be pulled back out of someone's inbox.
- No error appears, because the system did exactly what it was told
- Deleted files, leaked links and changed settings can be slow or impossible to reverse
# Activity log: Shared Drive
Budget.xlsx deleted by: intern
Clients.csv shared to: anyone
Billing changed by: guest
# Error shown: noneWhy does everyone end up with admin access?
The root cause is almost never bad intent. It is a shortcut that feels helpful on a busy day. Someone messages you saying they can't edit something. You want them unblocked now, not after a long hunt through settings. So you click Admin, and nobody ever goes back to change it.
Repeat that a few times and every request from every person flows through the same Admin role. Read, edit, delete and manage users are all allowed, and nothing is ever blocked.
Two deeper issues make the shortcut tempting. Access is often handed out one person at a time, so nobody sees the overall picture. With a large team, it becomes impossible to tell who can do what. Often there is also no in-between role set up. If the only choices are no access or full Admin, people will get full Admin.
- Granting access person by person hides the overall picture
- Without Viewer or Editor roles, the only options are 'nothing' or 'everything'
Permissions vs roles, and the check behind them
Roles are what the system was designed to use instead. You'll find the same idea in Google Drive sharing, company apps, databases and cloud services such as AWS. Think of keys and key rings. A permission is a single key that opens one door, such as read, edit or delete. A role is a ring that holds several keys together.
A simple set of roles looks like this. Viewer can only read. Editor can read and edit. Admin can read, edit and delete, and usually manage other people's access too. Roles let you manage access by job rather than by person. Admin is just one role, meant for the few people who run the system itself.
Every time someone tries an action, the system runs a quick check first. Say the intern tries to delete Budget.xlsx. The system finds the role Viewer, sees that Viewer only allows reading, and denies the delete. If the intern were set to Admin, the same check would work perfectly and allow it. The check is only as good as the role you assigned.
How to find out who really has admin access
Measure the problem before fixing anything. Your goal is an honest list of who can do what right now, not who you think can. Most tools show this on a page called something like members, users, sharing or access. In cloud services you can also ask from the command line. In this AWS example, the first command lists everyone in a group called Admins. The second shows the permission policies attached directly to one user, which can reveal full-access policies hiding there.
Compare that list to reality. Who actually manages the system day to day? If the admin list is much longer than that, you've confirmed the mistake. Also look for access given straight to individuals, outside any role. Those one-off grants are where surprises hide.
Then ask one question about each admin: does this person's job need this power? A designer who uploads and updates files needs to read and edit. Deleting whole folders or adding users isn't part of that work, so Admin is too much.
- Count admins against the people who truly manage the system
- Check when each account was last used, because old or unused accounts are a top risk
- Look for non-human accounts, such as scripts, integrations and shared logins
# AWS: who is in the admin group?
aws iam get-group --group-name Admins
# Which policies does a user have?
aws iam list-attached-user-policies \
--user-name internDefine your actions, then group them into roles
Start the fix by writing down every action your system allows, before you think about any people. This keeps the design honest. You are describing what the system can do, not who you happen to trust today. A small file-sharing app might have four permissions: read files, edit files, delete files and manage users.
Keep each permission to a single action. If you bundle read and delete into one permission, you can never give someone reading without also giving them deleting. Mark the risky permissions too. Deleting and managing users are hard to undo, so they deserve extra care.
Next, group the actions into roles that match real kinds of work. Everyone, including Viewers, can read. Editors and Admins can also edit. Only Admins can delete files and manage users. Each role steps up a little from the one before. This is the principle of least privilege: give each person only the access they need.
- Viewer: read
- Editor: read and edit
- Admin: read, edit, delete and manage users
# Every action the system allows
permissions:
- files.read
- files.edit
- files.delete
- users.manageAssign each person one role
With roles ready, move people onto them. Each user gets one role and every permission it contains, nothing more and nothing less. Work in small batches, and tell people before you change their access. Changing access in the middle of someone's day can break their work.
In AWS, groups act like roles. This example takes the intern out of the Admins group and adds them to Editors. In Google Drive, you use the dropdown next to each person's name. Whenever you can, assign roles to groups instead of individuals. When someone joins the finance team, they join the group and get the right access automatically.
Don't remove every admin in a rush. Keep a small, trusted backup admin, so that one person's absence never locks everyone out of your own system. The aim is fewer admins, but never zero.
# Move the intern out of Admins
aws iam remove-user-from-group \
--group-name Admins --user-name intern
# Put them in the Editors group
aws iam add-user-to-group \
--group-name Editors --user-name internCheck the role on every request
Roles only matter if the system enforces them. If you build your own app, the role check must run on every request, without exceptions. Hiding a delete button from Viewers is helpful, but it isn't protection. Anyone clever can send the request directly, so the real check has to live on the server.
This short JavaScript example uses a table that maps each role to its permissions. A function called can looks up the user's role and checks whether the requested action is on its list. If the role or the action isn't listed, the answer is no. This is called deny by default. It means a forgotten setting fails safely instead of opening the doors.
Log every denial as well. If people keep hitting the same wall, a role may need adjusting. The check protects you, and the log shows you how to tune it.
const roles = {
viewer: ['files.read'],
editor: ['files.read', 'files.edit'] };
function can(user, action) {
return roles[user.role]?.includes(action);
}Habits that keep access from drifting back
Compare the team before and after. The people and files are the same, but the outcomes differ. The intern can now read and edit but not delete the budget. Guests can only view. One table explains everyone's access. If a password is stolen, the attacker gets only that person's role, so one bad day stays a small problem.
Fixing access once isn't enough, because it drifts back if nothing changes. Treat access as a lifecycle that follows a person's time on the team. Each stage needs one small habit. When someone needs Admin, they ask, explain why, and another person approves it. That short pause is enough to stop the old shortcut.
- Join: new people start as Viewer or Editor
- Review: put a recurring access review on the calendar and remove unused roles
- Leave: update or remove a person's role the day they change jobs or leave
When it isn't actually a role problem
Some access problems look like this one but have a different cause. Rule them out before changing anyone's role, or you may grant more access than you meant to. A classic case: you upgrade someone to Editor and they still can't edit. Often they only need to sign out and back in, because their old session still carries the old role.
Inheritance is another lookalike. In tools like Google Drive, files usually take their sharing settings from the folder they're in, so the setting you need may be one level higher. Sometimes people get in through a share link rather than a role. 'Anyone with the link' bypasses careful roles, so check link sharing separately.
Key takeaways
- A permission is one action; a role groups permissions to match a job.
- Everyone-as-Admin comes from a convenient shortcut, and it removes all protection.
- List your admins and ask whether each person's job really needs that power.
- Define actions, build roles, assign them, and check the role on every request.
- Deny by default and keep a trusted backup admin.
- Start people small, review regularly, and remove access promptly.
Frequently asked questions
What is the difference between a permission and a role?
A permission is a single allowed action, such as read, edit or delete. A role is a named bundle of permissions, such as Viewer, Editor or Admin, that you assign based on someone's job.
Why is giving everyone admin access risky?
Admin allows every action, so anyone can delete files, share data or change settings by mistake. If one account's password is stolen, the attacker gets full access too.
What is the principle of least privilege?
It means giving each person only the access they need to do their work. In practice, everyone gets the smallest role that works, and Admin is kept for the few people who run the system.
Is hiding a button enough to stop users from doing something?
No. Hiding a button only changes what people see, and anyone clever can still send the request directly. The role check has to run on the server for every request.
I gave someone Editor access but they still can't edit. Why?
Their old session may still carry the old role, so ask them to sign out and back in. Also check whether the file inherits its sharing from a parent folder.
Should I remove all admins from my system?
No. Keep a small number of trusted admins, including a backup, so that one person's absence never locks everyone out.
