> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/governance/roles-and-permissions.md).

# Roles & Permissions

Roles in DataOS define a set of permissions aligned to a user persona. A user can hold multiple roles at the same time.

Users with Instance-level elevated roles such as `roles:id:super-app-user` or `roles:id:operator` can create new roles during Tenant creation.

This page is the reference for all default roles: what each role can do, and at which level it operates.

***

## Instance roles

Instance roles are created during Instance creation. They define access at the Instance level and cannot be modified after creation.

### `roles:id:operator`

The Instance-level role for provisioning and configuring DataOS. An Operator can create, configure, suspend, and delete Tenants through the Instance Admin application, invite users into Tenants, and assign Tenant Admins.

* Does **not** grant access to Tenant resources, Tenant data, or workloads within a Tenant.
* Access inside a Tenant must be explicitly granted through Tenant-scoped authorization — the same as any other user.
* For what an Operator does day-to-day, see [Operator Journey](/operate/operator-journey.md).

### `roles:id:user`

Lets a user sign in to the DataOS Instance.

* To perform actions inside a Tenant, the user must also hold Tenant-level roles.

***

## Instance roles capability matrix

<figure><img src="/files/HhAwOpkKqZychZDyjqoz" alt=""><figcaption></figcaption></figure>

***

## Tenant roles

Tenant roles are created during Tenant creation.

### Tenant Admin

The access authority of the Tenant. Invites users, assigns Tenant-level roles, and holds the right to grant or revoke permissions on any resource in the Tenant — including resources they did not create themselves.

Can create resources and holds `Can Edit` and `Can Manage Access` on those by default. Does not hold compute, depot, or Minerva cluster access by default — those require an explicit, audited self-grant.

For the full access model, see [Access Control](/concepts/foundations/access-control-landscape.md).

### Data Admin

Responsible for data infrastructure and governance inside the Tenant. Can create, update, and delete their own resources, and can create and govern Lakehouse namespaces, schemas, tables, and views through the Lakehouse interface.

Can grant or revoke access on resources they created. Does not hold compute or depot access by default — those require an explicit grant.

### Data Developer

Builds workloads, data pipelines, and data products in the Tenant. Can create, update, and delete their own resources — Workflow, Service, Worker, Secret, Depot, and others — and can grant access on those resources.

Does not hold compute, depot, Minerva, or secret access by default. Each requires an explicit `Can Use` permission grant from the Tenant Admin before it can be referenced in a workload.

### Data Consumer

Accesses governed data assets and applications. Can view and interact with permitted data products, dashboards, and governed assets, and can access UI applications for data exploration and consumption.

Does not create resources or run workloads.

***

## Role naming convention

Tenant roles are prefixed with the Tenant name to distinguish similar roles across different Tenants in the same DataOS environment.

For example, for a Tenant named `analytics`, the roles would be:

* `analytics Tenant Admin`
* `analytics Data Admin`
* `analytics Data Developer`
* `analytics Data Consumer`

***

## Tenant roles capability matrix

<figure><img src="/files/S9RKxS7qTjcEt4sBKxPK" alt=""><figcaption></figcaption></figure>


---

# 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, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/operate/governance/roles-and-permissions.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.