Understand who can do what in Sasha, through everyday examples from one small firm

A simple explanation of Sasha permissions. Role, projects and connection, shown through the people of one small advisory firm and the jobs they do.

Where

Settings → Users for roles and member grants. Settings → My Account → API Tokens for your own API keys.

Who

Admins give roles and grants. Every person, and every tool they connect, works inside those limits.

Needs

Nothing to set up. The permissions come with each role.

What it is

This page explains Sasha's permissions in plain words, with examples. For the full table of every capability, see Understand exactly what each role can do, what keys and system accounts can reach, and what Sasha records. To add people and change roles, see Add people to Sasha, give each person a role, and control what members can reach.

Three questions decide every request

Each time a person, or a tool that acts for them, asks Sasha to do something, Sasha asks three questions:

1. What may this person do? The person's role answers this: admin, staff or member. A role is a set of capabilities. A capability is one named permission, for example "read knowledge" or "run skills".
2. Where may they do it? The person's projects answer this. Admin and staff reach every project. A member reaches their own home and the shared projects that an admin grants.
3. How much of that may this tool use? The connection answers this: a Claude connection or an API key. A connection can do less than its owner, never more.

Each answer can only make access smaller. Sasha checks the role again on every request, so a change applies at once.

Meet Harbour & Finch Advisory

Harbour & Finch is a small advisory firm. Four people use its Sasha:

The examples below show what each of them can do, and why.

Examples: the admin

Priya adds Ana to Sasha. Priya opens Settings → Users, adds Ana and chooses the member role. Sasha makes Ana's home project in the same step, and sends Ana an email with a link to connect Claude. Only an admin can add people or change roles.

Priya gives Ana access to client work. On Ana's row, Priya chooses Knowledge Grants, then sets the Larkspur project to Read & write and the Methodology project to Read. Ana can now work in Larkspur and read the firm's methods, and nothing else outside Ana's home.

Priya chooses the AI provider and system settings. These are admin capabilities. No staff or member account can hold them.

Examples: staff

Tom asks Sasha to draft a client report. Tom chats in the Sasha web interface, runs a skill and reads last week's meeting transcript. Chat, skills, meetings and schedules are all in the staff role.

Tom checks Ana's notes. Tom opens Ana's home and reads the draft there. Admin and staff see and work in every member's home. A home is private from other members only.

Tom wants to add a new associate. Sasha refuses. Managing people is above the staff ceiling, so an admin cannot give it to Tom. If Tom must add people, Priya makes Tom an admin.

Tom wants the firm's CRM to save notes into Sasha. Tom makes an API key in Settings → My Account → API Tokens and gives it to the CRM. The key can read and write knowledge, and read and manage meetings. It can never do more than Tom can do. If the CRM no longer needs it, Tom revokes the key.

Examples: members

Ana works from Claude. A member cannot sign in to the Sasha web interface. Ana connects Claude to Sasha (Connect Claude to your Sasha). From Claude, Ana searches and reads three places: the home, Larkspur and Methodology.

Ana writes a findings document in Larkspur. Larkspur is granted Read & write, so Ana can create and edit documents there, if your Sasha is set up to allow member writes. Ana cannot delete documents in a shared project, at any level of access.

Ana tries to edit a Methodology page. Sasha refuses. Methodology is granted Read only.

Ana looks for Sam's home. Ana cannot find it. A member never sees another member's home, and Sasha gives the same answer for a project that is hidden as for one that does not exist.

Ana asks Claude to run a skill or join a meeting. Sasha refuses. Members cannot run skills or work with meetings. If a meeting transcript is saved as a document in Larkspur, Ana can read it like any other document.

Sam reads only what the firm shares. Priya grants Sam Read on Larkspur. Sam sees the Larkspur documents, and nothing about other clients.

Examples: changes over time

Priya grants Ana a second project. Ana can reach it from Claude at once, with no need to connect again.

Tom becomes an admin. The new role applies at once in the Sasha web interface. Tom's existing Claude connection keeps the permissions it had. To use the new role from Claude, Tom connects Claude again.

Ana's contract ends. Priya deletes Ana's account, or removes Ana's grants. Ana's Claude connection loses that access on its next request.

A staff account becomes a member. Sasha revokes every API key the person holds, in the same step. The person starts with no shared-project grants, and an admin chooses them.

The rule to remember

Nothing in Sasha can do more than the person behind it:

• a role sets the most a person can do;
• a member's grants set where they can do it;
• a connection or key can only narrow that again.

Limits to know

• No screen can give one person extra capabilities or take some away. Each person has exactly their role's default set.
• Admin and staff can see every member's home. An organisation that needs homes that no admin can see needs its own Sasha.
• Members use Sasha only from Claude today.
• Every key made on the API Tokens screen has the same grant. You cannot choose a narrower one there.