Roles and permissions

This is the reference for who can do what. The model behind it is described in authorization and delegation; this page is the catalog.

Three facts shape everything below:

• Permissions live in three planes, each backed by a different database.
• A role is granted at a scope, and an unscoped grant is a deliberate choice rather than the default.
• Authority is re-derived on every request, so nothing here is a token a caller keeps.

The three permission planes

Plane	Backed by	Count	What it governs
Directory	The directory database	203	Authority that crosses cells: organizations, nodes, fleets, security posture, AI and agent teams
System	The node's system database	148	Internal services on this node: compute, messaging, storage, data, metrics, cells
Catalog	The catalog database	92	The data platform's securables: catalogs, schemas, tables, volumes, functions, skills, clean rooms

443 permissions in total. The split is not filing: a plane is where the permission is stored and evaluated, so a directory permission survives a cell being rebuilt, while a system permission is meaningful only on the node holding it.

Cross-plane projection

Roles do not span planes. Instead, a directory role projects onto a set of system permissions, so external authority becomes internal capability without either plane having to know the other's vocabulary.

A node administrator holding the directory role gets the full node-operations system permission set. An organization administrator projects onto the same set, because an organization administrator can operate every node in the organization. An observer projects onto exactly two: inspect cells, read metrics, and nothing that writes.

The projection is declared, not inferred, which is what lets you answer "what does this directory role actually let someone do inside a node" by reading a list rather than tracing code.

Risk tiers

Every permission carries a risk tier. The tier is metadata for review and gating, not a second enforcement path.

Tier	Directory	System	Catalog	Total
Low	47	34	23	104
Medium	69	60	42	171
High	73	47	27	148
Critical	6	7	1	14

The shape is worth noting. Only 14 permissions are critical, and more than half of everything sits at medium or below. A catalog with everything marked high is a catalog nobody can use for review, so the tiers are only useful because most things are not at the top.

Scope: where a grant applies

A role assignment attaches a role to a principal at a scope, naming the thing administered rather than a persona.

Scope	A grant here covers
Organization	Everything in the organization, across its nodes
Node	One node and its cells
Workspace	One workspace
Clean room	One clean room, and nothing outside it
Entity	One principal, for grants that administer a specific entity
(unscoped)	Everywhere. Flat role membership

An unscoped grant is possible and is sometimes correct, but it is a distinct state rather than the absence of a decision.

Two mechanics sit alongside:

• Inheritance is explicit and revocable. A grant can be linked to a parent grant, and that link carries a flag that can turn inheritance off without deleting either assignment.
• Federation-managed grants are tagged. A grant created by identity federation records which provider produced it, so reconciliation only ever touches its own rows and never a hand-authored grant. See identity federation.

The built-in roles

48 roles ship. They are starting points: a deployment can define its own, and these are the ones that exist before anyone does.

Directory roles

Two naming conventions coexist here, and the difference is meaningful.

Named roles, for a specific job:

Role	What it is for
OrgAdmin	Administrative control over an organization and its members
NodeAdmin	Full administrative control over one node
DomainAdmin	Governs a single catalog domain. Assigned at that domain's scope
CleanRoomCollaborator	Participates in one clean room. Assigned at that room's scope
Observer	Read-only node metadata and audit logs
PortalMember	A member of the node's public portal, browsing shared data
FleetViewer	Read-only view of the device fleet: devices, bays, and their state
FleetOperator	Day-to-day fleet operation, beyond reading
MLOperator	Cross-workspace machine-learning and data-platform operation
DataViewer / DataEngineer	Read-only and engineering data access through the directory surface
ComputeUser / ComputeEngineer / ComputeAdmin	The compute ladder through the directory surface
SkillDeveloper	Create and manage AI skills, and submit governed coding runs

Spine roles, a grid of <domain>.<level> covering the four platform spines:

Spine	Levels available
core_system.*	viewer, operator, admin
security.*	viewer, operator, engineer, admin
data.*	viewer, operator, engineer, admin
ai.*	viewer, operator, engineer, admin
ai.alignment.*	operator, admin
agent_teams.*	viewer, builder, admin

The ladder is consistent: viewer reads, operator runs day-to-day work, engineer changes how things are built, admin governs. Where a level is absent, it is because the distinction does not exist for that spine, not because it was forgotten.

System roles

Role	What it can do
SystemOperator	Operate internal services on this node: cells, groups, messaging
SystemAdmin	Administrative control of internal services
NodeAdmin	Full administrative control of every system-layer service
PlatformReader	Read-only across the vertical platform dashboards
MetricsAgent	A headless identity: read metrics, consume diagnostic streams
StorageUser / StorageAdmin	Read and list objects in storage namespaces / full storage control
WorkspaceUser	Create, read, write files, and import content in a workspace
DataViewer / DataEngineer / DataAdmin	Query and read catalog / plus schema and storage write / full data-service control
MessagingUser / MessagingAdmin	Publish and subscribe / full messaging control
ComputeUser / ComputeEngineer / ComputeAdmin	Kernels and execution / plus notebooks, pipelines, libraries / full compute control

MetricsAgent is worth a second look: a role designed for a non-human caller, which is the model working as intended rather than a person's role being reused for a service.

Catalog roles

Role	What it can do
CatalogAdmin	Every catalog permission
DataEngineer	Build and maintain pipelines, tables and schemas
DataScientist	Query data, invoke skills, create experiments
Analyst	Read-only data access, with skill invocation
DataProductOwner	Manage data products, publish them, set quality contracts
DataSteward	Govern data quality, approve changes, manage the glossary
SecurityAdmin	Manage access-control lists, row and column policies across all securables
SkillDeveloper	Create and manage AI skills, and submit governed coding runs

A clean-room permission a catalog role cannot hold

Contributing to and running in a clean room are directory permissions granted at one room's scope, not catalog permissions. A catalog role cannot hold them.

That is the point of the split. Holding "contribute to clean rooms" globally would mean holding it for every room, which is exactly what a clean room exists to prevent.

What the planes cover, by area

Catalog: 92 permissions over the data securables

The catalog vocabulary follows the securable hierarchy, with a consistent verb set:

• Traverse: browse, use_catalog, use_schema
• Create: catalogs, schemas, tables, views, functions, volumes, external tables, external volumes, data products, skills
• Manage: catalogs, schemas, tables, data products, quotas, tags, glossary, credentials
• Read and write data: select, modify, execute, read_files, write_files, read_volume, write_volume
• Govern: manage_acls, manage_rls_cls (row and column security), manage_policies, steward, approve_glossary, audit_read
• Skills: create_skill, compose_skill, invoke_skill
• Families of their own: discovery and mapping (16), domain governance (12), clean rooms (7), credentials, lineage, ownership transfer

manage_rls_cls is the one to notice: row-level and column-level security are a separate permission from managing the table. Someone who can reshape a table does not thereby control who can see which rows of it.

Data and database: the system plane

Around 55 data permissions cover the database surface, split by concern rather than by table: query and DML (query, select, insert, update, delete, alter, lock, frame), schema management, metadata, policy, ontology, graph, data modeling, functions, backups, bundles, sharing, visibility, grafts, clean-room data access, products and subscriptions, and skills.

The pattern throughout is a .read / .write pair per concern, so read access to a surface never implies the ability to change it.

Object storage: RBAC and then ACLs

Object storage is the one area with two authorization layers, and both must be satisfied.

Layer	What it resolves
1. Role-based	Ownership, scoped roles, inheritance, and cross-organization access
2. Namespace ACLs	An access-control entry naming a specific grantee on a specific namespace

The ACL layer takes grantee kinds the role model does not: as well as an entity, an ACL can name a cell, a service group, or an agent. That is what lets a namespace be shared with a piece of infrastructure or a running agent, rather than only with a principal a person is behind.

The system-plane storage permissions cover the operations themselves: read, write, list, delete, import, database provisioning, ownership transfer, and the workspace-scoped set (create, read, write, manage, delete).

How it composes

A caller's effective authority is the intersection of several independent narrowings, and each can only subtract:

1. Role assignments, resolved at their scope.
2. Cross-plane projection, where a directory role grants system capability.
3. Delegation, for agents and devices, which can only attenuate what the delegator holds.
4. Credential scope. A scoped API key or OAuth token intersects with its owner's roles, so a credential never exceeds its owner.
5. Classification and compartments, which travel on the identity.
6. The consequential-action and net-potential-gain gates, which judge the specific call rather than the permission name.

Strictest wins at every step, and the evaluator is deny-by-default: a permission that resolves to nothing is a refusal, not a pass.

Authority is re-derived per request, so revoking a role takes effect on the next call rather than when something expires. See immediate structural revocation.

Related

• Authorization and delegation, the model this catalog implements.
• Governance (deny-closed), the gates that judge a call after the permission check passes.
• Capability control and approval, including N-of-M dual control.
• Identity federation, mapping an identity provider's groups onto these roles.
• Programmatic authentication, how a credential's scopes intersect with its owner's roles.
• Data governance, the row filters and column masks manage_rls_cls controls.