> For the complete documentation index, see [llms.txt](https://docs.kula.digital/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kula.digital/connect-claude-and-access/scopes.md).

# Permission levels

How role-based access works — each connect link or access token is issued at a permission level that controls how much personal data the assistant can see.

Access in Kula is controlled by **rules and roles**. When you create a connector in **console.kula.digital**, you set a **permission level** for it. That level travels inside the credential — a [connect link](/connect-claude-and-access/claude.md) for Claude, or an **access token** for other clients — and controls how much personal information the assistant can ever see.

Redaction happens on our server, so a credential **can't be talked into revealing more than its level allows**. The level is the cap, set by you, per person.

**Rule of thumb: give each person the lowest level that lets them do their job.** You can always create a second connector at a higher level for a specific task.

## The four levels

| Level          | Sees member & staff names? | Sees emails & phone numbers? | Can delete saved items & run admin tools? | Sees card details? | Recorded on every use? |
| -------------- | -------------------------- | ---------------------------- | ----------------------------------------- | ------------------ | ---------------------- |
| **Analytics**  | No (aggregates only)       | No                           | No                                        | No                 | No                     |
| **Operations** | **Yes**                    | **Yes**                      | No                                        | No                 | No                     |
| **Admin**      | **Yes**                    | **Yes**                      | **Yes**                                   | No                 | No                     |
| **Full**       | **Yes**                    | **Yes**                      | **Yes**                                   | **Yes**            | **Yes — every call**   |

**Names and contact details come together.** From Operations up, the assistant sees members' and staff's names *and* their emails and phone numbers, along with other personal details such as date of birth. Operations and Admin see exactly the same personal data — Admin adds deleting and admin tools, not more visibility. To keep contact details hidden, use Analytics.

If an action needs a higher level than the credential holds, it returns a clear error (`scope "analytics" cannot call …`) and **nothing leaks** — the assistant simply can't see it.

## Narrow further: hide the books

The four levels control how much **personal** data a credential sees. You can also exclude a whole **category** of data on top of the level — independent of which level you picked.

Today there's one such option: **Hide the books.** Tick it when you create a connector and that credential can never read your **accounting ledger** — the chart of accounts, journals, entries, and invoice lines. Your **commerce** data — sales, payments, and refunds — stays fully visible, so the assistant can still answer revenue and membership questions; it just can't open the general ledger.

It's enforced the same way as the levels: server-side, on every query. A credential set to hide the books gets a clear denial if it tries to read any accounting table, and **nothing leaks**. Use it for, say, a front-desk or operations login that should see who paid and when, but not the studio's books.

> Hide the books is set per connector, like the level, and shown on the credential's card under **Connectors** so you can see at a glance which logins have it. The split between commerce and accounting is the same one in the [schema reference](/for-developers/schema.md).

## Which level for which role?

```
Does this person's assistant need to see member or staff names?
├── No  → Analytics
└── Yes (it will see their emails and phone numbers too)
    └── Does it need card details or other sensitive records?
        ├── Yes → Full  (recorded on every call)
        └── No
            └── Does it need to delete saved items or run admin tools?
                ├── No  → Operations   ← the sensible default for an owner or coach
                └── Yes → Admin
```

* **Analytics** — trends and totals, no individuals. Good for a shared dashboard or a public stat ("our retention was 78% this quarter"). The only level that keeps names and contact details hidden.
* **Operations** — names *and* contact details visible, so the assistant can tell you who to check in with and draft outreach to specific people. It can save views, notes, and skills, but can't delete anything. **The everyday default** for an owner or coach. Card details stay hidden.
* **Admin** — the same personal details as Operations, plus deleting saved items and running admin tools. Card details still hidden.
* **Full** — reveals sensitive records like card fragments. Every use is recorded for your own audit trail. Reserve it for a compliance export or a formal data request — a fire extinguisher, not a light switch.

## Good habits

* **One connector per person or assistant.** Separate connectors give you a separate trail for each, and you can revoke one without breaking the others.
* **Match the level to the role**, not to convenience. Don't hand out Admin "just in case."
* **Treat connect links and tokens like passwords** — don't paste them into a chat or commit them to code.
* **Revoke when someone leaves or changes role.** Revoking a connector in **console.kula.digital** stops its access within about a minute.

## Where to manage access

Everything lives under **Connectors** in **console.kula.digital**: create a connector at the right level, see what each is for, and revoke any of them with one click.

## Related

* [Connect Claude](/connect-claude-and-access/claude.md) — where the connect link goes.
* [Is my data safe?](/get-started/trust.md) — the plain-English safety summary.
* [Security & data handling](/trust-and-legal/security.md) — the technical detail.