can Unity Catalog govern ML models and feature tables

Summary

• Yes. Unity Catalog governs registered ML models and feature tables as first-class securable objects, in the same catalog and schema hierarchy it uses for tables, so one permission model, lineage, and audit cover data and ML assets together.
• A model registered in Unity Catalog is a governed object you grant with standard privileges: USE CATALOG and USE SCHEMA plus EXECUTE to call it, CREATE MODEL to register one, and CREATE MODEL VERSION or APPLY TAG for narrower rights.
• Any Delta table in Unity Catalog with a primary key is a feature table, governed with the same privileges as any other table, so there is no separate feature-store system to secure on its own.
• Unity Catalog tracks lineage across data, features, and models, so you can see which features, notebooks, jobs, and endpoints use a table and which models consume which data down to the column level.
• Because governance is inherited, a model picks up the permissions of the data it was trained on, and models and feature tables resolve in any workspace with access to the catalog.

can Unity Catalog govern ML models and feature tables

Yes. Unity Catalog governs both as first-class securable objects, not as an afterthought bolted onto a separate ML tool. A registered ML model and a feature table each live in the catalog and schema hierarchy alongside your tables, and both are secured with the same privilege model, tracked by the same lineage, and recorded in the same audit log. The access rules and lineage you already trust for data extend to the models built from it and the features that feed them, with no second governance system to run and reconcile.

What to look for in ML asset governance

Capability	Why it matters
Models as securable objects	A model should carry its own permissions, versions, and metadata, not sit in an ungoverned file store.
Granular privileges	Separate rights to use, create, version, and tag let you split who can call a model from who can register or change it.
Feature tables under one model	Features are governed data; securing them with the same privileges as tables avoids a second access system.
End-to-end lineage	You need to trace which data trained a model and which features, jobs, and endpoints depend on a table.
Inherited permissions	A model should pick up the access rules of the data it was trained on, so sensitive data stays protected downstream.
Cross-workspace consistency	The same object and its permissions should resolve in every workspace that can reach the catalog.
Audit and discovery	Every access should be logged, and users should be able to find and understand assets through search and metadata.

How Unity Catalog governs models and feature tables

Models in Unity Catalog. A registered model is a governed object in the catalog and schema hierarchy, implemented as a type of function. To call or load it, a user needs USE CATALOG on the catalog, USE SCHEMA on the schema, and EXECUTE on the model; EXECUTE also lets them view the model's metadata and versions and download its files. Registering a model needs CREATE MODEL on the schema or catalog, and narrower rights exist for specific jobs: CREATE MODEL VERSION lets a pipeline register new versions without the ability to run or change the model, and APPLY TAG lets someone tag a model and its versions. Each model is a versioned container, where every training run's artifacts and metadata become a model version, and reassignable aliases point to the version that is, say, in production, replacing rigid stages. Granting EXECUTE at the schema or catalog level flows down to all current and future models there, and models are discoverable across any workspace attached to the catalog. See Data governance with Unity Catalog and Models in Unity Catalog.
Feature tables in Unity Catalog. Any Delta table in Unity Catalog with a primary key constraint is automatically a feature table, governed with the same privileges and ownership as any other table, so there is no separate feature-store system to secure on its own. With Feature Engineering in Unity Catalog, a feature table is a normal governed table with zero-copy access and automatic governance inheritance, not a copy sitting in separate infrastructure. When you train a model on those features, it inherits the permissions of the data it was trained on. Lineage ties it together: for a given feature you can see the models, notebooks, jobs, and endpoints that use it, giving end-to-end lineage from features to models. The Features UI lets you browse and search by table, feature, tag, or comment, and shows ownership, tags, and which online stores serve a feature table for low-latency lookups. See Feature governance in Unity Catalog and the Unity Catalog product page.

FAQs

What privileges control access to a model in Unity Catalog?

The same privilege model used for data: USE CATALOG and USE SCHEMA on the parents, plus EXECUTE to call the model. CREATE MODEL registers a new model, CREATE MODEL VERSION adds versions without run or edit rights, and APPLY TAG manages tags.

How does Unity Catalog govern feature tables?

A feature table is a Delta table with a primary key, so it is governed like any other table: standard privileges, ownership, lineage, and audit. There is no separate feature store with its own access model to maintain.

Does Unity Catalog track lineage for models and features?

Yes. It captures lineage across data, features, and models down to the column level, so you can see what data trained a model and which features, notebooks, jobs, and endpoints depend on a table.

Do models inherit the permissions of their training data?

Yes. A model trained on governed data inherits the permissions of that data, so access controls carry through from the source to the model.

Are models and feature tables available across workspaces?

Yes. Because they are Unity Catalog objects, models, functions, and feature tables resolve in any workspace that has access to the catalog, with consistent permissions.