Access control for teams: roles, permissions and sharing without chaos

The moment more than one person works with the same data, a question appears: who is allowed to see and change what? In a spreadsheet the honest answer is usually "whoever has the link". That is fine for a team of three, and a real risk for a team of thirty with contractors, interns and clients in the mix. This article explains how to design access rules that are strict enough to protect you and simple enough that people do not route around them.

Why spreadsheet sharing falls short

Google Sheets and Excel Online offer viewer, commenter and editor roles on a whole file, and some protection of ranges and sheets. That covers a surprising amount of ground, but it stops at certain predictable places:

• Row-level restriction is not really possible. If a salesperson may only see their own accounts, the usual workaround is one copy of the file per person, which is the beginning of version chaos.
• Hidden sheets and hidden columns are not security. Anyone with edit access can unhide them, and anyone with view access can often read them through export or a formula.
• Protected ranges are easy to forget. New columns and new sheets are unprotected by default.
• A shared link is a credential. Once forwarded, you cannot tell who is using it.
• There is rarely a trustworthy record of who viewed or changed what.

The principle: least privilege

Give every person the smallest set of permissions that lets them do their job, and expand only when there is a reason. It sounds like bureaucracy, but it is mostly about avoiding two failure modes: accidental damage (someone deletes a table while tidying up) and disclosure (a contractor sees pricing for every other client). Both are far more common than malicious attacks.

Build roles around jobs, not individuals

Do not assign permissions person by person. Define a handful of roles that match the way your organization works, then assign people to roles. When someone changes jobs you change one assignment instead of editing dozens of rules. A typical small-business set looks like this:

• Administrator: manages users, structure and settings. Keep this group very small.
• Manager: sees and edits the whole team's data, runs reports, cannot change the data structure.
• Staff member: creates and edits their own records, sees shared reference data, cannot delete.
• Read-only: can view dashboards and reports, for executives, auditors and advisers.
• External: customers, suppliers or contractors who see only the records that concern them.

Four layers of permission

It helps to think about access as four layers, from coarse to fine. A good platform lets you control each of them; the more of them you can express, the fewer workarounds you need.

1. Workspace level

Who is in the workspace at all, and who can invite others or change billing. This is the front door.

2. Table level

Which tables a role can see, and for each one: view, create, edit, delete. A support agent might create and edit tickets but only view the product catalog. Finance might view orders but never see the HR table.

3. Column level

Which fields in a visible table are shown. The classic example is a purchase price or a salary column that most users should not see even though they need the rest of the record.

4. Row level

Which records in a table the user may open. "Sales reps see only accounts they own", "a client sees only their own orders", "a regional manager sees their region". This is the layer that spreadsheets cannot do and that most teams eventually need.

Designing the rules: a worked example

Imagine a design agency with five employees, three freelancers and a dozen clients. They keep projects, tasks, time entries and invoices.

1. Owners are Administrators. They manage users and see everything.
2. The two project managers are Managers: all projects, tasks and time entries, plus invoices in view-only mode.
3. Designers are Staff: they see tasks assigned to them and the projects those tasks belong to, and can log time against their own tasks only.
4. Freelancers are Staff with a narrower scope: only the specific projects they are linked to, no access to invoices.
5. Clients are External: they see their own projects and approved deliverables, and can add comments, but cannot see internal time entries or rates.

Notice that most of these rules are expressed through links ("tasks assigned to me", "projects I am linked to") rather than lists of individual records. When a new freelancer joins a project, you link them once and the access follows.

External users and public forms

Sooner or later you want people outside the company to submit or view data: a lead capture form on your website, a support request form, a client portal. Treat these as separate from internal accounts. Public forms should only be able to create records in one specific table with specific fields, never to read anything. A client portal should authenticate each person and apply the same row-level rules described above. Avoid the shortcut of sharing an internal view by link; links leak.

Auditing: knowing who did what

Permissions prevent problems and a history explains the ones that happen anyway. Look for a per-record change log (who changed which field, from what to what, and when) and a log of sign-ins. When something looks wrong in a report, the first question is always "what changed?", and the answer should take seconds rather than a forensic investigation.

Access control and AI agents

Connecting an AI agent to your business data raises the stakes. An agent that operates through a platform's REST API or MCP server should be treated like a user, with its own account, its own role and the same permission checks as everyone else. Avoid giving agents a single all-powerful key. A sensible setup looks like this:

• Create a dedicated user for each agent or integration, with a role limited to the tables it needs.
• Prefer read-only access until the agent has proved itself, then grant write access table by table.
• Require confirmation for destructive actions such as deleting records or changing structure.
• Review the history regularly. Agent actions should be as visible as human ones.

This is not paranoia. Language models can misread an instruction, and a prompt-injected document can try to steer them. Permissions enforced by the platform are the safety net that does not depend on the model behaving well.

Common mistakes

• Everyone is an admin "for now". Temporary admin rights become permanent.
• Shared accounts. A login used by three people destroys your audit trail and cannot be revoked cleanly when one of them leaves.
• Roles by person. Fifteen custom permission sets for fifteen people is unmaintainable.
• No offboarding routine. When someone leaves, their access should end the same day. Keep a checklist.
• Forgetting derived access. Exports, reports and dashboards can reveal data the underlying table hides. Test every report as each role.

A review checklist

1. List all users and the role each one holds. Remove anyone who no longer needs access.
2. Confirm the Administrator group has no more than two or three people.
3. For each role, open the workspace as that role and try to see something you should not.
4. Check that external users can only reach their own records.
5. Verify that agent and integration accounts are read-only or tightly scoped.
6. Make sure you can answer "who changed this record last week?" in under a minute.

Do this review quarterly. Access control is not a one-time configuration; it is housekeeping, and like all housekeeping it is cheapest when done little and often.