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

# Roles

> What you can do, depending on your role.

|                                     | Member | Administrator | Owner |
| ----------------------------------- | ------ | ------------- | ----- |
| Read company context                | ✓      | ✓             | ✓     |
| Write your own private context      | ✓      | ✓             | ✓     |
| Propose changes to company context  | ✓      | ✓             | ✓     |
| Approve proposals                   |        | ✓             | ✓     |
| Manage company context directly     |        | ✓             | ✓     |
| Manage users and working principles |        | ✓             | ✓     |
| Manage the organization itself      |        |               | ✓     |
| Read anyone else's private context  |        |               |       |

The last row is empty on purpose. No role grants access to another person's private context — see [Private context](/concepts/private-context).

## Where roles are enforced

In the database, on every table, through row-level security. Not in the user interface, and not in the description an AI reads before calling a tool.

This is worth stating plainly because it changes what a bug can cost. If a permission check lived in the application and someone forgot one, the data would be exposed. Here, forgetting a check means the query returns nothing — the failure mode is an empty page, not a leak.

## Roles over MCP

An AI client acts as the person who signed in, with exactly their role. The server resolves the user, organization and membership from the verified token before every tool call; it never takes an organization or user id from the model.

A model cannot ask for another organization's context, however it phrases the request, because it is never asked which organization it wants.