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. For AI Studio workspace roles, see User Permissions.

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.

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).

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