[Unity Catalog privileges — the three-level traversal and delegation](/lessons/s7-uc-privileges/) answered "can I reach this object" — the three-level traversal. This lesson answers the other half: when I grant a privilege at one level, how far does it reach? In Unity Catalog, one grant on a parent can silently cover thousands of tables you haven't even created yet — powerful, and a favourite trap.

The spine

Beat 1 — the anchor: grants flow down, to current and future children

Predict: you GRANT SELECT ON CATALOG sales TO analysts. Next month a new table is created in sales. Can analysts read it — without any new grant?

…

Yes. That auto-coverage of future objects is the exact tested fact:

Anchor. In Unity Catalog, privileges inherit down the hierarchy (metastore → catalog → schema → table). A grant on a parent applies to all its children — those that exist now and those created later. So you pick the level of a grant to match the blast radius you intend.

GRANT SELECT ON CATALOG sales isn't "read the catalog object" — it's read every table in every schema under sales, including tables added next month.

Beat 2 — pick the grant level deliberately

Because inheritance is automatic, the level is the whole decision:

• Catalog grant → widest blast radius (a whole data domain, future objects included).
• Schema grant → one domain/database.
• Table grant → surgical, one object.

Granting SELECT at the catalog is convenient but broad; if a team should see only one schema, grant there — else every future table in the catalog is exposed by default.

Lock it. Grants inherit downward to all current + future children. Choose catalog (broad) / schema (a domain) / table (surgical) to match intended reach.

The dials (skim now; return when a question needs one)

◆ ALL PRIVILEGES — all data work, but not administration

GRANT ALL PRIVILEGES is a shorthand expanding to the full standard set — SELECT, MODIFY, CREATE (schema/table/volume/function), USE CATALOG/USE SCHEMA, EXECUTE, BROWSE, etc. The tested catch: it does not include MANAGE, and it is not ownership. So a principal with ALL PRIVILEGES on a catalog can create/manage schemas/tables/volumes and read/write data — but cannot change permissions, rename, or drop the catalog.

Tell: "team must create and manage schemas/tables/volumes but must NOT rename/delete the catalog or change its permissions" → ALL PRIVILEGES. If they also administer grants → MANAGE (or ownership) from [Unity Catalog privileges — the three-level traversal and delegation](/lessons/s7-uc-privileges/). Layering: SELECT/MODIFY < ALL PRIVILEGES < MANAGE < owner.

◆ The default workspace catalog surprise

A workspace auto-enabled for Unity Catalog creates a default workspace catalog, and all workspace users are automatically granted USE CATALOG on it + CREATE/privileges on its default schema (e.g. CREATE TABLE, CREATE VOLUME, CREATE FUNCTION, USE SCHEMA). That's inheritance working for you out of the box — and the answer to "why can new members create objects without me granting anything?" Tighten the workspace-catalog grants explicitly if that's not desired.

◆ Name the collision (four things that sound like "permissions")

• Traversal ([Unity Catalog privileges — the three-level traversal and delegation](/lessons/s7-uc-privileges/)) — can I reach the object (need a privilege at every level).
• Inheritance (this lesson) — how far one grant reaches (down to all current + future children).
• ALL PRIVILEGES — a bundle of data privileges; not MANAGE, not ownership.
• MANAGE / owner — administration (grant/revoke, rename, drop).

Takeaways (rebuild it from these)

1. UC privileges inherit downward: a grant on a catalog/schema covers all children, current and future. SELECT on a catalog → every table under it, including new ones.
2. Grant at the level that matches blast radius — catalog (broad), schema (a domain), table (surgical).
3. ALL PRIVILEGES = full standard privilege set (data work) but excludes MANAGE and ownership — create/read/write, can't administer/rename/drop.
4. A UC-auto-enabled workspace's default workspace catalog grants all users USE CATALOG + CREATE on its default schema — why new members can create objects immediately.
5. Four distinct ideas: traversal (reach) vs inheritance (reach-how-far) vs ALL PRIVILEGES (bundle) vs MANAGE/owner (admin).

Before you move on — say these without scrolling up

1. Grant SELECT on a catalog — do future tables get it too?
2. Which grant level for "a whole domain, future tables included" vs "one table"?
3. ALL PRIVILEGES — the one important thing it does not include.
4. Why can new workspace members create tables without you granting anything?

Next: making all that governed data discoverable — comments, tags, and the metadata commands → [Discoverability & metadata — comments, tags, and DESCRIBE](/lessons/s8-metadata/).