topic Re: Feature enablement for Foundation Model Unity Catalog permissions in Data Governance

Feature enablement for Foundation Model Unity Catalog permissions

broccobroccolis — Tue, 15 Sep 2026 03:43:09 GMT

I am trying to restrict workspace users' access to Databricks Foundation Models using the guidance in the Foundation Model Unity Catalog Permissions documentation.

I have revoked EXECUTE permission for all users from the system.ai schema. However, workspace users can still successfully query foundation models via ai_query() using the databricks-* serving endpoint names:

-- This SUCCEEDS (should be blocked)
SELECT ai_query("databricks-claude-sonnet-4-5", "whats 1+1?") AS response

-- This FAILS with RESOURCE_DOES_NOT_EXIST
SELECT ai_query("system.ai.claude-sonnet-4-5", "whats 1+1?") AS response

The system.ai.* path returns a RESOURCE_DOES_NOT_EXIST error (which I assume is expected) after revoking EXECUTE. However, calling the same model via the databricks-* endpoint name bypasses the UC permission check entirely.

The documentation states: "Foundation model Unity Catalog permissions is generally available but requires enablement. Reach out to your Databricks account team to enable this feature."

What is the Foundation Model Unity Catalog Permissions feature called in Account Previews and how can it be enabled? So that the EXECUTE revoke on system.ai is enforced consistently across all access paths — including pay-per-token databricks-* endpoints called via ai_query().

Side question: does serverless compute bypass Unity Catalog permissions?

Re: Feature enablement for Foundation Model Unity Catalog permissions

tom_n — Tue, 15 Sep 2026 09:23:07 GMT

The reason the two calls behave differently is that databricks-* and system.ai.* are separate serving and authorisation paths, and only the system.ai.* path runs through Unity Catalog.

- system.ai.claude-sonnet-4-5 resolves to a UC model service, so your EXECUTE revoke applies and the call fails as expected.
- databricks-claude-sonnet-4-5 resolves to the legacy default Foundation Model API serving endpoint. Direct calls to it don't pass through UC model-service authorisation, so revoking EXECUTE on system.ai never touches it.

The feature and how to enable it

In the Account Console it's listed under Previews as "Foundation Model Permissions" (account-level). An account admin toggles it on there and it takes effect immediately. If the toggle isn't visible, we can get it enabled for you from our side. Once it's on, revoking EXECUTE on system.ai is enforced across the UC-governed paths: ai_query, the AI Playground, and the newer gateway endpoints.

One thing to flag: enabling the feature covers newly created model services automatically, but it doesn't retro-fit services that already exist. For those you'll need to revoke EXECUTE per model service. New models landing in system.ai also grant EXECUTE to all users by default.

Enforcing consistently across all paths

1. Revoke EXECUTE at the catalog, schema and securable level (all three), scriptable through the UC Grants API.
2. Enable Foundation Model Permissions so new models don't quietly re-open access.
3. Allow-list the models you do want, either by re-granting EXECUTE per approved model service, or with an ABAC grant policy (grant everything except models carrying a "blocked" tag).
4. The legacy default databricks-* endpoints are the one path UC can't reach. To close them fully, speak to your account team (if you have one) to disable those specific Foundation Model API endpoints for your workspaces, or you migrate that traffic onto Unity Gateway where it's UC-governed.

Does serverless compute bypass Unity Catalog?

No. Serverless SQL and serverless compute enforce Unity Catalog in full. Serverless didn't ignore UC here: your ai_query("databricks-…") call routed to the legacy serving endpoint, which sits outside UC authorisation. Enabling Foundation Model Permissions and dealing with the legacy endpoints closes that gap.

Reference: Foundation model Unity Catalog permissions — docs.databricks.com/machine-learning/foundation-model-apis/model-uc-permissions

Re: Feature enablement for Foundation Model Unity Catalog permissions

ivanvyd — Tue, 15 Sep 2026 10:36:46 GMT

Thank you, @tom_n. Could you please clarify one point against the permissions documentation?

It says pay-per-token calls enforce the restrictions automatically after enablement, while provisioned-throughput endpoints require manual removal.

Does the legacy databricks-* exception still apply after Foundation model Unity Catalog permissions is enabled? Or does it describe the behavior before enablement? That would help establish whether this account needs the feature enabled, additional endpoint restrictions, or both.

Re: Feature enablement for Foundation Model Unity Catalog permissions

tom_n — Tue, 15 Sep 2026 13:24:05 GMT

It persists after enablement. The legacy databricks-* endpoints are a separate serving path from both pay-per-token and provisioned throughput, so they aren't gated by the system.ai EXECUTE revoke. It isn't pre-enablement behaviour that clears once the feature is on.

The permissions page doesn't cover this case, so I've confirmed it on our side.

So the account needs both:

1. Enable Foundation model Unity Catalog permissions. This enforces the revoke on the pay-per-token and AI Functions paths automatically, and covers new models going forward.
2. Clear the endpoints that enablement doesn't touch: delete any disallowed provisioned-throughput endpoints, and remove the legacy databricks-* endpoints. That legacy removal is handled on our side, either via the Enforce Unity Gateway workspace setting where it's available in your region, or a backend request we raise to disable the specific Foundation Model API endpoints. I'll confirm which applies to your workspaces and set it up with you.

Quickest way to scope it: once the feature is enabled, re-run the same call with EXECUTE still revoked. If it's blocked, the only remaining work is clearing the standing endpoints. If it still succeeds, it's routing to an existing endpoint rather than the pay-per-token path.