When Your Intern Can Delete the Master Contract, You Have a Permissions Problem

A friend who runs a small legal practice told me this story last month. New paralegal, first day, given access to the shared Google Drive to get up to speed. Two hours later she'd renamed the master client folder, dragged half the files into a new structure that made sense to her, and emptied something into the trash that she thought was a duplicate. It wasn't a duplicate. The firm spent the rest of the day in restore-from-backup mode.

Nobody was malicious. The setup was. Everyone had admin because admin was easier than thinking about who actually needed what.

That's the problem RBAC — role-based access control — is supposed to solve. It sounds boring until you've lost a contract revision because the wrong person had write access.

The everyone-has-admin problem

Most small teams start the same way. Two founders, one shared drive, full access for everyone because there's no time to set up something fancier. Then the team grows. The contractor gets the same access as the partner. The intern gets the same access as the contractor. By the time anyone notices, twelve people can delete the company's signed contracts and nobody can tell who did what.

The risk isn't usually theft. It's accidents — the renamed folder, the overwritten version, the file moved to a place nobody can find. Audit trails fix tracking after the fact, but RBAC stops the accident from happening in the first place by making sure the people who shouldn't be able to do something simply can't.

The four roles that cover most teams

Chaindoc has four standard roles, and they map to most companies pretty cleanly.

Owner is the founder seat. Billing, security settings, the ability to delete the whole workspace. There should be one or two of these. Not seven.

Admin runs the people side. They invite members, change permissions, set up custom roles. They can't touch billing, which is the right call — the person who manages user accounts shouldn't also be the person who can change the credit card on file.

Member is the default for most employees. They can edit, comment, sign, and collaborate on documents. They can't change who else has access. This covers 80% of a typical team.

Accounter is the underrated one. View-only access to billing and invoices, no document editing. Useful for bookkeepers and finance leads who need to see what's spent without being able to change contract terms.

Most teams overcomplicate the setup before they need to. Start with these four.

When the standard roles aren't enough

The real edge cases tend to look like this. A freelance copywriter needs to edit marketing collateral but should never see the employment contracts. An external auditor needs to read every contract but absolutely should not be able to modify any of them. A junior associate at a law firm needs to draft NDAs but shouldn't have access to ongoing M&A files.

This is where custom roles earn their keep. You define exactly what someone can read, edit, sign, share, or delete, on which folders, and assign that role to them. The auditor gets read-only on the contract folder. The freelancer gets edit on /marketing and nothing else.

The legal industry runs on this stuff. So does anyone working under SOC 2 or HIPAA, where appropriate access controls isn't optional advice — it's a compliance requirement.

The principle of least privilege in plain English

Security people love the phrase principle of least privilege. It means: give each person the minimum access they need to do their job, and nothing more.

In practice this is hard because it feels stingy. You're constantly tempted to give someone just a little extra access so they can do their job without bothering you for permission. Don't. Every extra permission is a possible accident, a possible leak, a possible audit finding. The version of trust that scales is the one where the system enforces boundaries so individual judgment doesn't have to.

Setting it up without making everyone hate you

The fastest way to lose your team's trust is to suddenly tighten permissions without warning. Two weeks ago they could see everything. Now they're locked out of half the drive and they don't know why.

Three things help.

First, communicate before you change. We're moving to role-based access on Monday. Here's why, here's what changes for you, here's who to ask if you need more access.

Second, default to the lowest sensible role for new hires and let people earn more access as their responsibilities expand. Onboarding day is the easiest time to set boundaries. Re-tightening later is a fight.

Third, audit quarterly. Roles drift. The person who was a member three months ago is now leading a project and needs more access. The contractor who left in March still has access in May.

If you want the deeper breakdown, role-based access in Chaindoc covers the specifics on standard roles, custom permissions, and audit logs before you roll it out.

The goal isn't perfect security theater. It's making sure that nobody — not the new paralegal, not the helpful intern, not you on a tired Friday — can break something they didn't mean to break.