Skip to main content
Applies to: Embedded ❌, Enterprise ✅ Authentication establishes who is calling. Authorization decides what they may do. An access control entry grants one privilege on one object to one subject. Everything on the Principals and Privileges pages is a consequence of that shape.

​
Granting a privilege

GRANT and REVOKE cover every object in the catalog — system, database, schema/namespace, table, view, materialized view, secret, function, and storage integration. A Secret, the one a day-to-day user shares most often, looks like this:
The caller must already hold OWNERSHIP on the object being granted (GRANT additionally requires the object to already exist; REVOKE does not, so an entry left on a dropped object can still be removed). A role need not exist beforehand, but a USER or GROUP name must resolve to exactly one identity in your identity provider, or the statement fails. See Privileges for the full statement syntax and every privilege each operation needs. See Principals for who a grant can name.

​
What to read next

Principals

Users, groups, and roles — where each comes from, and how a grant names one.

Privileges

Every object’s privileges, and the GRANT/REVOKE syntax that covers them.