Databricks quietly switched on dormant MANAGE grants. Check who just became an admin.

A one-line entry in the Azure Databricks release notes dated August 3, 2026 stated that MANAGE no longer requires USE CATALOG or USE SCHEMA on the same object ^[1]. A few paragraphs down, according to a write-up on dev.to, the same note spells out the consequence: if you granted MANAGE broadly without the corresponding usage privileges, those grants are now active ^[2]. There was no keynote, no launch post, and no workspace banner ^[3].

MANAGE matters because it is the closest thing Unity Catalog has to delegated admin. A holder can grant and revoke privileges on the object, transfer ownership, and otherwise behave like the owner for access-control purposes ^[4].

Under the old rule, MANAGE on a catalog or schema only took effect if the principal also held usage privileges on that same object, so a bare `GRANT MANAGE ON CATALOG prod TO platform_engineering` was a row in a metadata table and nothing more ^[5]. The new rule, as the post quotes the docs: MANAGE on a catalog requires no usage privileges; MANAGE on a schema requires USE CATALOG on the parent but no longer USE SCHEMA on the schema itself; MANAGE on a table, view, volume, or function is unchanged and still needs both ^[6].

The design argument is defensible. An owner never needed USE CATALOG on their own object, so aligning MANAGE removes a real inconsistency that has cost engineers afternoons of debugging ^[7]. The operational problem is the direction of travel: the old inconsistency failed closed, the new consistency fails open, and it applies retroactively to grants already sitting in the metastore ^[8]. If your metastore is more than a year old, the post argues, there is a real chance you hold some of these ^[9] - in calendar terms, anything created before August 3, 2025 ^[15].

Three shapes recur, per the same post: a 2024 bootstrap script that granted MANAGE to a platform group across every catalog while usage privileges were handled by a different script; a Terraform module that grants catalog-level MANAGE to a governance group and scopes USE CATALOG per environment, where production lost the usage grant in a refactor and nobody noticed because the effective permission was zero; and incident response, where someone got MANAGE at 3am and the cleanup revoked USE CATALOG, which closed nothing and only made the grant invisible ^[10].

The audit is two queries. Enumerate every MANAGE grant on catalogs and schemas from `system.information_schema.catalog_privileges` and `schema_privileges` to get the population ^[13], then LEFT ANTI JOIN catalog-level MANAGE against USE CATALOG for the same principal to isolate the grants that were dormant and are now effective ^[14]. Run both as a metastore admin: the information schema filters rows to what the caller is allowed to see ^[11], and there is a documented quirk where a user holding MANAGE cannot view all grants through the information schema at all ^[12]. Delegate this to a team lead and the report will lie by omission.

Watch three things. Whether the anti-join returns anything in production but not dev, which is the Terraform-drift signature ^[10]. Whether your Terraform plan now shows the usage grants as absent rather than redundant ^[10]. And whether Databricks ships a first-party report of newly effective grants; the post describes only hand-written SQL ^[13][14], and it cites the Azure release notes, not other clouds ^[1].