Govern model APIs (model services)

Note

Unity AI Gateway is not supported on Azure Government.

A model API gives you governed access to a large language model. Send a request, get a response, with no infrastructure to run. By default, every account user can query the system-provided model APIs in the system.ai schema with no setup. These are foundation models served natively by Azure Databricks, billed per token.

On Azure Databricks, a model API is a Unity Catalog securable object (a model service) that represents a governed LLM endpoint. Because Unity Catalog stores it, you define, share, and govern access to it centrally, alongside your data and across workspace boundaries. To govern additional models or expose a custom endpoint, you create your own model APIs.

Model APIs support the following:

  • Azure Databricks-served pay-per-token foundation models, as system-provided services in system.ai and as services you create.
  • Creating and managing model APIs with the Unity AI Gateway UI, Catalog Explorer, and the Unity Catalog REST API.
  • Querying model APIs across workspaces, from inside and outside Azure Databricks.

What is a model service?

A model service lives in a Unity Catalog schema and references one or more destinations, with routing and fallback between them. Callers invoke the model service by its fully qualified name, and Unity AI Gateway routes each request to a destination. A destination can be a Azure Databricks-served model or a model provider service that routes to an external provider, and a single model service can mix both.

Because a model service is a Unity Catalog securable object, it:

  • Lives in a catalog and schema, where it inherits schema settings such as workspace bindings.
  • Carries standard Unity Catalog metadata, such as name, owner, comment, and tags.
  • Is governed by Unity Catalog privileges, so you grant access using the same GRANT and REVOKE statements you use for tables, functions, and models.
  • Is discoverable in Catalog Explorer, alongside the rest of your Unity Catalog assets.

The same model service also appears as an endpoint in the Unity AI Gateway UI, where AI teams can configure features such as rate limits, inference tables, and guardrails. For more about those features, see AI governance with Unity AI Gateway.

Why govern LLMs in Unity Catalog?

Unity AI Gateway endpoints created in a workspace are scoped to that workspace. To share an endpoint across workspaces, you must duplicate it in each workspace and manage each copy separately.

Model services move governance into Unity Catalog, so you can:

  • Define an LLM endpoint once and use it from any workspace attached to the same metastore.
  • Govern access centrally using Unity Catalog privileges, instead of per-workspace permissions.
  • Discover models that are available to you across workspaces from a single location.
  • Track usage and cost for model services in Unity Catalog system tables.

System-provided model services

Azure Databricks provides a ready-to-use model service in the system.ai schema for each Azure Databricks-served foundation model, such as system.ai.databricks-claude-opus-5. Azure Databricks adds new system model services as new foundation models become available.

System-provided model services have the following characteristics:

  • By default, all account users have the EXECUTE privilege, so you can query them without additional setup.
  • A system user owns them, and you cannot delete them.
  • By default, only metastore administrators can modify them. A metastore administrator can delegate management by granting the MANAGE privilege.

To restrict access to system-provided model services, see govern model services.

Privileges

Model services use the standard Unity Catalog privilege model. The following privileges apply:

Privilege Description
USE CATALOG, USE SCHEMA Access the catalog and schema that contain the model service. Required for all operations.
CREATE SERVICE Create model services in a schema. Granted on the catalog or schema.
EXECUTE Query a model service.
MANAGE Modify or delete a model service and manage its grants. The owner has a superset of MANAGE.

Model services use definer's privileges. Azure Databricks evaluates a query against the owner's privileges rather than the caller's. When a user queries a model service, Azure Databricks checks that the owner has EXECUTE on the referenced destinations, like the underlying models and any model provider services. The caller does not need direct access to those destinations.

Limitations

The following capabilities are not supported:

  • Provisioned throughput models as destinations.
  • Creating and managing model services with SQL.
  • Discovering model services with only the BROWSE privilege.
  • Global search for model services.

Next steps

  • Last updated on