> ## Documentation Index
> Fetch the complete documentation index at: https://firebolt-aggregate-helm-docs-pr-97.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Learn about the default system roles in Firebolt, their permissions, and how they help manage access control across different database objects and operations.

# Default System Roles

In Firebolt, **system-defined** roles are automatically created for each organization and account. These roles provide predefined privileges and serve specific purposes. System-defined roles **cannot** be dropped, and you can grant any of them additional privileges. Their built-in privileges cannot be revoked, with one exception: `public`, covered under [public privileges](#public-privileges).

## Organization system roles

<Note>
  Organization-level roles, logins, and service accounts are not supported in Firebolt OSS.
</Note>

| Role Name           | Description                                                             |
| ------------------- | ----------------------------------------------------------------------- |
| organization\_admin | Enables all the permissions and the ability to manage the organization. |

<Note>
  The [organization\_admin](/managed-service/organizations-accounts#organizational-administrative-role) role cannot be granted using SQL. It can only be granted using the [Firebolt Workspace](https://go.firebolt.io/signup) user interface (UI). To manage resources at the organization level, you must assign the `organization_admin` role to your login using the UI.
</Note>

## Account system roles

| Role Name      | Description                                                                                                                                                                                |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| public         | Includes `USAGE` on all databases and `USAGE` on each database's public schema. It grants no privilege to read, write, or create anything.                                                 |
| system\_admin  | Enables managing databases, engines, schemas, tables, and views. This includes setting database and engine properties as well as access to the observability functionality on all engines. |
| account\_admin | Grants full permissions to manage the organization.                                                                                                                                        |

<Note>
  By default, every newly created user is granted the [public](/managed-service/organizations-accounts#public-role) role. You can also revoke this role from a user.
</Note>

## Default privileges for system roles

System roles come with predefined default privileges that are automatically applied when objects are created. These default privileges are built into the system and **cannot be revoked**, with one exception: `public`, from which an `account_admin` can revoke a system-defined privilege.

### account\_admin privileges

The `account_admin` role has comprehensive default privileges across the entire account:

* **Account-level**: Full administrative access including user and role management
* **Database-level**: `CREATE`, `MODIFY`, `USAGE`, and `DROP` on all databases
* **Schema-level**: Default privileges include `CREATE`, `MODIFY`, `USAGE`, and `DROP` on all schemas
* **Table-level**: Default privileges include `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, and `DROP` on all tables
* **Engine-level**: Full engine management and monitoring capabilities
* **Location-level**: Full location management and configuration capabilities
* **User-level**: Full user management and administration capabilities
* **Role-level**: Full role management and administration capabilities

### system\_admin privileges

The `system_admin` role has operational privileges for database and engine management:

* **Database-level**: `CREATE`, `MODIFY`, `USAGE`, and `DROP` on all databases
* **Schema-level**: Default privileges include `CREATE`, `MODIFY`, `USAGE`, and `DROP` on all schemas
* **Table-level**: Default privileges include `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, and `DROP` on all tables
* **Engine-level**: Engine management and monitoring capabilities
* **Limitation**: Cannot manage users, roles, or account-level settings

### public privileges

The `public` role lets a user reach objects, not use them. It is navigational only:

* **Database-level**: `USAGE` on all databases
* **Schema-level**: `USAGE` on each database's public schema, granted when the database is created
* **Table-level**: No default table privileges. `SELECT`, `INSERT`, `UPDATE`, `DELETE`, and `TRUNCATE` must all be granted explicitly.
* **Object creation**: None. Creating a table, view, index, or external table in a public schema requires an explicit `CREATE` grant.
* **Location-level**: None. Reading through a location requires an explicit `USAGE` grant on that location, or `USAGE ANY LOCATION`.

A user holding only `public` can connect, reach a database and its public schema, and read a privilege-filtered catalog. Everything else requires a grant.

<Note>
  Firebolt narrowed this role, and applies the narrower set only when it creates something new: the account-level privileges above are written when an account is created, and the public-schema `USAGE` when a database is created. Firebolt never rewrites the privileges of an account or a database that already exists.

  So an account created before the change keeps a `public` that also holds `USAGE ANY LOCATION`, and a database created before it keeps a `public` that also holds `CREATE` on its public schema. An `account_admin` narrows them by hand — and only an `account_admin` can: every `GRANT` and `REVOKE` naming the `public` role requires that role, so owning a database is not enough to narrow the `public` privileges on its own public schema, even though the database owner owns that schema. Location usage is one statement for the account:

  ```sql theme={"theme":{"light":"css-variables","dark":"css-variables"}}
  REVOKE USAGE ANY LOCATION FROM public;
  ```

  Object creation is one statement per database, naming that database's public schema:

  ```sql theme={"theme":{"light":"css-variables","dark":"css-variables"}}
  REVOKE CREATE ON SCHEMA my_database.public FROM public;
  ```

  Both are reversible: `GRANT` the same privilege back if you overshoot. Query `information_schema.object_privileges` to see which of them a given database still holds.

  Object creation also has an account-wide form, in the other direction. `ALTER DEFAULT PRIVILEGES` sets what a role receives on schemas created afterwards, so one statement restores `CREATE` for `public` going forward:

  ```sql theme={"theme":{"light":"css-variables","dark":"css-variables"}}
  ALTER DEFAULT PRIVILEGES GRANT CREATE ON SCHEMAS TO public;
  ```

  `ALTER DEFAULT PRIVILEGES REVOKE CREATE ON SCHEMAS FROM public` takes it back, and this reaches new schemas only — a database that already exists still needs its own `GRANT CREATE ON SCHEMA my_database.public TO public`.

  Note that it restores **more** than the privilege it replaces. A default privilege applies to every schema created afterwards, so it covers schemas made with `CREATE SCHEMA` as well as the public schema of each new database; the built-in grant it stands in for only ever covered the latter. If you want the narrower thing, grant `CREATE` per database on that database's public schema instead.
</Note>

### Important notes about system role privileges

* **Immutable privileges**: Default privileges for `account_admin` and `system_admin` are hardcoded and cannot be modified using `ALTER DEFAULT PRIVILEGES` or `REVOKE` commands
* **Automatic application**: These default privileges apply immediately when objects are created, without requiring explicit grants
* **Additional privileges**: You can grant additional privileges to any system role
* **The public exception**: `public` is the one system role whose built-in privileges an `account_admin` can revoke, and grant back
* **Write time only**: The sets above are written when an account or a database is created. Firebolt does not retroactively change the privileges of an account or a database that already exists.

To view the current default privileges for system roles, query the [object\_default\_privileges](/reference-sql/information-schema/object-default-privileges) information schema view:

```sql theme={"theme":{"light":"css-variables","dark":"css-variables"}}
SELECT 
  grantor,
  grantee,
  object_name,
  object_type,
  privilege_type
FROM information_schema.object_default_privileges
WHERE grantee IN ('account_admin', 'system_admin', 'public')
ORDER BY grantee, object_type;
```