> For the complete documentation index, see [llms.txt](https://k-ai.gitbook.io/knowledge-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/access-control.md).

# Access & roles

The [Roles model](/knowledge-ai/the-k-ai-platform/roles.md) describes the organisational roles a K-AI programme is built around. This page describes their concrete counterpart inside the platform application at `app.kai-studio.ai` — the **organization roles** that govern what each user can do.

Access is organised per organization. A user is a member of one or more organizations, and within each organization holds one or more roles. A user's effective permissions are the **union** of their roles — roles are additive, never subtractive. An action a user's roles do not authorise returns `403`.

## How roles work

* **Membership is per-organization.** The same user can be a Document Steward in one organization and a Consumer in another. Roles never cross organization boundaries.
* **A user can hold several roles at once.** Someone may be both `AUTHORITY_MANAGER` and `BILLING`; their access is the combination.
* **Default role.** A user added to an organization with no role specified joins as `CONSUMER` — baseline membership.
* **The creator owns the org.** Whoever creates an organization becomes its `ORG_OWNER`.
* **API keys carry the same roles.** An [Organization API key](/knowledge-ai/authentication/organization-api-keys.md) mints tokens authorised exactly as a portal user holding the key's roles would be — the enforcement is identical.

## The roles

| Role                 | Portal label       | What it grants, in practice                                                                                                                      |
| -------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ORG_OWNER`          | Org Owner          | Full control of the organization, including transferring ownership. Assigned automatically to the org creator. **Not assignable to an API key.** |
| `ADMIN`              | Administrator      | Full organization administration — members and roles, instances, API keys, and every workflow below — except granting ownership.                 |
| `AUTHORITY_MANAGER`  | Data Authority     | View and create instances; define governance scope; run Govern operations across the organization's instances.                                   |
| `STEWARD`            | Document Steward   | Govern operations plus the full **Clean** workflow — view, resolve, and manage cleaning items. The daily operational role.                       |
| `KNOWLEDGE_EXPERT`   | Knowledge Expert   | View and resolve Clean items on the instances they belong to; view the documents they own.                                                       |
| `ACTIVATION_MANAGER` | Activation Manager | Manage **Activate** exposure for the organization — which instances are reachable through K-AI MCP / Retrieval, and their groups.                |
| `BILLING`            | Billing Manager    | View billing information for the organization.                                                                                                   |
| `CONSUMER`           | Consumer           | Organization access only — read-level membership. The baseline every member has.                                                                 |

{% hint style="info" %}
`ORG_OWNER` and `ADMIN` are broad. Grant the **fewest roles** that let someone do their job, and prefer the discipline-specific roles below over `ADMIN` for day-to-day work. The same principle applies to API keys — see [Organization API keys](/knowledge-ai/authentication/organization-api-keys.md).
{% endhint %}

## Roles by discipline

The operational roles line up with the three disciplines — [Govern · Clean · Activate](/knowledge-ai/the-k-ai-platform/govern-clean-activate.md):

* **Govern** — Data Authority defines scope and runs governance; Document Steward operates within it.
* **Clean** — Document Steward runs the full Clean workflow; Knowledge Expert resolves the items surfaced to them.
* **Activate** — Activation Manager controls what the organization exposes through K-AI MCP.

`ORG_OWNER`, `ADMIN`, and `BILLING` are cross-cutting tenant-administration roles — they run the organization itself (members, keys, billing), not a single discipline.

## Mapping to the conceptual model

The discipline-oriented roles are the platform's implementation of the conceptual [Roles model](/knowledge-ai/the-k-ai-platform/roles.md):

| Organization role                     | Conceptual role                                                                                                         |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `AUTHORITY_MANAGER` (Data Authority)  | [Document Authority](/knowledge-ai/the-k-ai-platform/roles.md#document-authority) — transverse governance standard      |
| `STEWARD` (Document Steward)          | [Document Steward](/knowledge-ai/the-k-ai-platform/roles.md#document-steward) — daily animation and Clean operations    |
| `KNOWLEDGE_EXPERT` (Knowledge Expert) | [Document Producer](/knowledge-ai/the-k-ai-platform/roles.md#document-producer) — subject-matter expert resolving items |
| `CONSUMER` (Consumer)                 | [Document Consumer](/knowledge-ai/the-k-ai-platform/roles.md#document-consumer) — end user of the clean estate          |

The administrative roles — Org Owner, Administrator, Billing Manager — have no single conceptual equivalent. They exist to run the tenant, not to carry a documentary responsibility. The [Document Owner](/knowledge-ai/the-k-ai-platform/roles.md#document-owner) and [Document Engineer (DocOps)](/knowledge-ai/the-k-ai-platform/roles.md#document-engineer-docops) of the conceptual model are business and platform-operations responsibilities that sit around the application rather than mapping to one assignable role inside it.