> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access control

> Roles, what each one can do, API key scopes, and how operator access to your workspace is recorded.

Who can see and do what, inside your workspace and from outside it.

## Roles

| Role       | Can                                                                                                                         |
| ---------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Owner**  | Everything, including billing, permanent deletion, and transferring ownership                                               |
| **Admin**  | Everything operational: settings, channels, routing, SLA and CSAT policies, categories, triggers, team management, API keys |
| **Agent**  | Work the inbox: reply, assign, add notes, label, prioritise, snooze, close, categorize                                      |
| **Viewer** | Read only                                                                                                                   |

Roles are set per person under **Settings, then Team**.

A few deliberate asymmetries:

* **Viewers cannot be assigned conversations.** Assigning work to an account that cannot reply
  creates a ticket nobody can finish.
* **An agent can categorize a conversation but cannot reshape the taxonomy.** Applying a category is
  daily work; changing the list everyone else works from is a settings change.
* **SLA policies are owner and admin only**, a tighter gate than personal conveniences like macros,
  because an SLA target is a commitment the whole workspace is measured against.
* **Approval policies and budgets are owner and admin only.**

## Permissions follow the person, everywhere

A team member acting through [Telegram](/assistants/telegram), [WhatsApp](/assistants/whatsapp) or
an [MCP client](/assistants/mcp) has exactly the permissions their role gives them in the console.

Their role is read from your workspace at the moment of the action. It is not supplied by the caller
and not inferred from the chat platform. In a shared team group, being in the room is not
permission: the person who pressed the button is the person who is checked.

## API keys

Keys are workspace-scoped and carry explicit scopes. See
[Authentication](/api-reference/authentication) for the full list and the issuance flow.

Key hygiene worth setting up:

* **Scope narrowly.** A reporting integration needs read, not write.
* **One key per integration**, so revoking one does not take down the others.
* **Set an expiry** rather than relying on remembering to revoke.
* **Rotate atomically.** Rotation issues the replacement and ends the old key in one step,
  inheriting its scopes, with an optional grace period so you can cut over without an outage.

Every key records when it was last used, from what address, and by what client, so an unfamiliar key
is answerable.

## Assistant write access

Anything that acts on your workspace from outside the console is gated twice: by the scope on the
key, and by your approval policy for that action. An action set to require approval parks and posts
a card showing what will happen before anyone approves it. See
[Assistant governance](/assistants/governance).

## Vorel operator access

Our operator team can access your workspace to support you.

* **Every access is recorded**, both reads and changes. Opening a page that shows your credentials
  is an audit event, not just changing them.
* **Support sessions where an operator views your workspace as you** are explicitly marked, with a
  start and an end recorded.
* **Operator-side views that cross workspaces** run as a separate database role and are audited.
  Cross-workspace queries without an explicit workspace filter are blocked before they can ship.

You can request an export of the audit trail for your workspace at any time.

## Customer data access

The agent reads only your workspace's data. There is no path by which a conversation in one
workspace can surface data from another, and this is enforced at the database level rather than by
application filtering. See [Security overview](/security/overview).