> 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

Access in Kula is controlled by **rules and roles**. When you create a connector in **app.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? | Sees payment details? | Recorded on every use? |
| -------------- | -------------------------- | ---------------------------- | --------------------- | ---------------------- |
| **Analytics**  | No (aggregates only)       | No                           | No                    | No                     |
| **Operations** | **Yes**                    | No                           | No                    | No                     |
| **Admin**      | **Yes**                    | **Yes**                      | No                    | No                     |
| **Full**       | **Yes**                    | **Yes**                      | **Yes**               | **Yes — every call**   |

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.

## Which level for which role?

```
Does this person's assistant need to see member or staff names?
├── No  → Analytics
└── Yes
    └── Does it need to email, call, or text members (so it needs emails/phones)?
        ├── No  → Operations   ← the sensible default for an owner or coach
        └── Yes
            └── Does it need card details or other sensitive records?
                ├── No  → Admin
                └── Yes → Full  (recorded on every call)
```

* **Analytics** — trends and totals, no individuals. Good for a shared dashboard or a public stat ("our retention was 78% this quarter").
* **Operations** — names visible, contact details hidden. **The everyday default** for an owner or coach asking "who should I check in with?"
* **Admin** — emails and phones visible, so the assistant can draft outreach to specific people. Payment 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 **app.kula.digital** stops its access within about a minute.

## Where to manage access

Everything lives under **Connectors** in **app.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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.kula.digital/connect-claude-and-access/scopes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.