# Permissions: MatrixOne


This page describes the permission model and its use within a **MatrixOne instance (tenant)**.
Each instance is a tenant (Account). Users in one instance cannot access resources in another instance.

For a quick reference to permission points and SQL permission categories, see [Reference: Permissions](../../reference/permissions/index.md). For AI Studio workspace roles, see [User Permissions](../ai-studio/permissions/index.md).

---

## Security and permission goals

| Capability | Purpose |
| --- | --- |
| Identity verification and authentication | Users, roles, passwords, and so on |
| Access control | Restrict objects and operations to authorized users |
| Transport encryption | Protect data in transit (see the TLS and related documentation) |
| Auditing and logging | Track activity (in conjunction with events and related capabilities) |
| User roles and permission assignment | Grant permissions to roles and roles to users |
| Object-level permissions | Databases, tables, views, and so on |
| Permission inheritance | Controlled transfer of permissions between roles |

Password recommendation: use uppercase and lowercase letters, numbers, and special characters, with a minimum length of 8 characters. The admin password used to create an instance has mandatory rules; see [Database instances](instances.md).

---

## Two access-control models

MatrixOne combines:

1. **RBAC (role-based access control)**
   Permissions → roles → users. A user without a role cannot perform operations.

2. **DAC (discretionary access control)**
   Objects have an **Owner**, who can manage permissions on those objects.

---

## Core concepts

### Objects

Permissions are attached to **objects** (account/instance tenant, user, role, database, table, view, and so on).
Higher-level objects can create lower-level objects, forming a hierarchy.

### Owner (creator role)

- After an object is created, the **role** active at creation becomes its Owner and has **Ownership** of the object (equivalent to the set of all permissions on that object).
- An object has **only one** Owner at any time. A role can own multiple objects.
- A role is itself an object and also has an Owner.
- When an Owner role is deleted, ownership of its objects is transferred to the Owner of the deleted role.
- Ownership can be transferred to another role.
- Although **ACCOUNTADMIN** (the tenant administrator, automatically created with the tenant) is not necessarily the Owner of every object, it has Ownership permission on all objects.

A user can have multiple roles. The currently active role is the **primary role**, and the others are **secondary roles**. Use `set role <role>` to switch roles. Use `set secondary role all` to enable the permissions of all roles at the same time, and `set secondary role none` to disable them.

### Tenant (Account)

Each **instance corresponds to one tenant**, with isolated data and permissions.

### Roles

- A role can have multiple permissions and can be granted to multiple users.
- A role can pass its permissions to another role through dynamic inheritance; cycles are not allowed.
- Roles and users are valid only within the current tenant.
- Only a role with **Manage Grants** can pass permissions between roles. This permission belongs to **MOADMIN / ACCOUNTADMIN** by default and should not be granted casually to custom business roles.

The system initializes default highly privileged roles and users for a cluster or tenant. **Do not** grant them directly to accounts that only run routine business SQL. Create custom roles for business use and grant the minimum required permissions.

---

## Typical sign-in workflow

1. Use admin or a highly privileged role to create users and roles.
2. `GRANT` permissions on databases, tables, and other objects to a role.
3. `GRANT` the role to a user.
4. Sign in to the Database Management Platform with `username:role_name` (see [Database instances: Sign in](instances.md#sign-in-to-the-database-management-platform-for-an-instance)).

For details about `GRANT`, `REVOKE`, `CREATE USER`, and related statements, see Reference: SQL/DCL.

---

## Network and access settings (summary)

You can also configure the following at the instance level:

- **IP allowlist/network policy** (select **Allow specified IP addresses** when creating an instance; edit it in the instance details)
- **TLS transport encryption**
- **Private network access** (such as PrivateLink/VPC endpoints)

Refer to the network and security pages in the Instance Management Platform for the exact settings and procedures.

---

## Differences from AI Studio permissions

| | MatrixOne (this page) | AI Studio user permissions |
| --- | --- | --- |
| Scope | Databases, tables, and roles within an instance tenant | Workspace users and feature/object permissions (such as knowledge base K codes) |
| Entry | Instance/SQL roles and users | Console > User Permissions |
| Quick reference | Reference: SQL permission categories | Reference: AI Studio permission matrix |

---

## Related documents

- [Database instances](instances.md)
- [User Permissions: AI Studio](../ai-studio/permissions/index.md)
- Reference: Permissions