Skip to main content

Unity Gateway

Unity Gateway is the Databricks enterprise governance and control plane for AI. Built on Unity Catalog, it extends governance beyond data and AI assets to the runtime interactions between models, agents, MCP servers, and tools. Partners integrate with Unity Gateway to deliver enterprise safety, observability, and cost controls without building a parallel control plane.

For connected partners, Unity Gateway is the governance layer your product routes through inside the customer's workspace — their access controls, rate limits, budgets, and audit requirements apply on every call. Your product keeps the differentiated experience (workflow, UX, domain logic) while Gateway handles identity, policy, cost, and observability.

Models​

Unity Gateway provides a single governed access path for all model inference — Databricks-hosted foundation models and external providers alike.

Foundation models​

Databricks serves foundation models natively as system-provided model services in system.ai — pay-per-token, no infrastructure to manage, available to all account users by default. Models include Meta Llama, OpenAI GPT, Anthropic Claude, and Google Gemini.

Documentation: Foundation Model APIs

External model providers​

Partners and customers register external model providers as model provider services — Unity Catalog securables that store authentication and connection configuration for the provider. Supported providers include OpenAI, Azure OpenAI, Anthropic, Amazon Bedrock, Gemini Enterprise, Microsoft Foundry, and custom providers (any OpenAI API-compatible endpoint). A model provider service can be queried directly or referenced as a destination in a model service. Once registered, the same governance applies.

Partner integration: if your product provides models, offer an OpenAI-compatible endpoint that customers can register as a custom model provider service.

Documentation: External model providers

Model services​

A model service is a Unity Catalog securable that represents a governed LLM endpoint. It lives in a catalog and schema, carries access controls, rate limits, and usage tracking, and routes inference requests to one or more destinations. A destination can be a Databricks-served foundation model or a model provider service — a single model service can mix both with routing and fallback. Partners call models by invoking model services through their fully qualified name (e.g., system.ai.claude-sonnet-4-5).

Documentation: Query model services

Governed access path​

Route all model requests through Unity Gateway model services:

InterfacePathUse case
OpenAI-compatible (unified)/ai-gateway/mlflow/v1Broadest model portability — recommended default
Native OpenAI/ai-gateway/openai/v1Provider-specific features required
Native Anthropic/ai-gateway/anthropicProvider-specific features required
Native Gemini/ai-gateway/geminiProvider-specific features required

Always pass a fully qualified model service name (e.g., system.ai.claude-sonnet-4-5), not a raw provider model ID.

Traffic management​

Unity Gateway provides traffic controls for model services:

  • Rate limits — enforce consumption limits per service to manage capacity and cost
  • Traffic splitting and fallbacks — distribute requests across multiple model destinations and add failover for availability
  • Budgets — monitor spend and set per-user thresholds and caps. Budget enforcement is near-real-time and approximate, not an absolute hard cap.

Documentation: Unity Gateway | Rate limits | Budgets

Guardrails​

Service policies (also called guardrails) control how each request and response to an AI service proceeds, based on content and caller identity. They evaluate before invocation (input guardrails) and/or after response (output guardrails), returning ALLOW, DENY, or ASK.

Three layers of guardrails​

LayerDescriptionPartner relevance
Built-in baselinesNo-code protection for common risks — unsafe content, jailbreaks, hallucination detectionAvailable to all customers, no partner action needed
Customer policiesCustom SQL or Python UC functions tailored to organization-specific requirementsCustomer-managed; partners can provide SQL/Python UC functions that customers leverage
Partner guardrailsPartner guardrail endpoint called via External Service Policy — Gateway sends request/response content, partner returns ALLOW or DENYPrimary partner integration point

Partner guardrail integration​

Partner guardrails extend coverage beyond built-in baselines — covering domain, industry, and emerging AI risks. Partners integrate through External Service Policies:

  1. Partner exposes an HTTP endpoint that evaluates requests and returns ALLOW or DENY. Must support OAuth M2M and respond within ~5 seconds.
  2. Customer creates a new policy on the target service (Model Service, Model Provider Service, or MCP Service) with guardrail type "External."
  3. Customer configures the policy — phase (input guardrails, output guardrails, or both), rank, and a UC HTTP Connection pointing to the partner endpoint (created inline or selected from an existing connection).
  4. Gateway enforces on every call — sends request/response content to the partner endpoint, receives the verdict, and blocks or allows accordingly. All error paths fail closed.

Partners can host the evaluator endpoint in two ways — both use the External Service Policy flow above:

  1. Partner-hosted endpoint — your SaaS or cloud API, reached via the UC HTTP Connection.
  2. In-workspace Model Serving — deploy an open-source or proprietary guardrail model on Databricks Model Serving and point the UC HTTP Connection at that endpoint. Co-locating the evaluator reduces latency and keeps evaluated content inside the customer's environment.

Documentation: Service policies | Create and attach a service policy

Monitoring​

Every request routed through Unity Gateway is logged for usage, cost, latency, and requester identity — covering model services, MCP services, and related AI traffic. Partners can query that telemetry in place or push their own traces into the same governed store, and surface insights in their product.

Two patterns cover the common partner cases:

Pattern 1: Query governed telemetry in place (pull)​

Partners query Gateway telemetry in place through Databricks SQL, Lakehouse RT, or Lakebase — no separate ingestion pipeline. Three primary sources:

  • Unified trace table (Beta) — OpenTelemetry spans for every request and response across all Unity Gateway model services and MCP services, in one Unity Catalog table. One-time metastore-admin setup; recommended for new deployments.
  • Inference tables — per-endpoint request/response logging for a model service. Still available; prefer the unified trace table when you need cross-service traces in one place.
  • Usage table (system.ai_gateway.usage) — requests, token usage, latency, requester identity, cost, service tags, and request tags for usage and cost analytics.

Use request tags to attribute usage by tenant, product, project, or workload when caller identity alone is insufficient.

Pattern 2: Push external telemetry (push)​

Partners that generate their own traces — from agent frameworks, applications, or frontends — can push OTLP traces via ZeroBus Ingest into governed Delta tables. This enables correlating what happened on the partner's side with what happened on Databricks, in one governed store.

Use OpenTelemetry format and W3C Trace Context to correlate external spans with Databricks platform traces.

Documentation: Observability overview | Unified trace table | Inference tables | Monitor usage | Request tags | Analyze cost | Audit requests and responses | ZeroBus OpenTelemetry

MCP​

Unity Gateway governs MCP servers the same way it governs models — access control, rate limits, and audit through Unity Catalog. On Databricks, MCP servers come from three places:

  • Managed — Databricks-hosted servers for Genie, AI Search, Databricks SQL, Unity Catalog functions, and the code interpreter
  • External — third-party or partner servers the customer connects to, including Marketplace listings (partner-hosted MCP, used from Databricks surfaces) and Databricks-provided connected apps (Slack, GitHub, Atlassian, Google, Microsoft 365)
  • Custom — a server hosted in the workspace, typically as a Databricks App

MCP Services wrap those servers as Unity Catalog securables (catalog.schema.mcp_service) so Unity Gateway can govern MCP the same way it governs models.

Two distribution paths for partner MCP servers​

PathHow it worksBest for
Marketplace listingPartner publishes MCP server to the Databricks Marketplace. Customer installs the listing, which creates a Unity Catalog connection. Customer admin grants access to users and groups.Broad discovery and self-service install by joint customers
Databricks AppPartner builds or adapts an MCP server and deploys it as a Databricks App in the customer's workspace. Access governed through Databricks Apps permissions.Tools/data that need to stay in-workspace for compliance or latency

For either path, partners or customers can also create an MCP Service to govern how customer users call the MCP.

important

Marketplace and Databricks App are independent. A Marketplace install does not create an MCP Service and does not deploy an App.

Invoke Databricks managed MCP​

Publishing a partner MCP is one direction. Partner products and platforms can also call Databricks managed MCP servers — Genie, AI Search, Databricks SQL, and Unity Catalog functions — through Unity Gateway. For Genie One and Genie Agents, MCP is the integration path: Genie One and Genie Agents.

Operational guidance​

  • Discover tools at runtime with tools/list — do not hardcode tool names
  • SQL DDL is not available for MCP Services; use the supported UI or REST paths
  • MCP Services should remain distinct from their underlying HTTP connections

Documentation: MCPs and agent tools | Govern an MCP service | MCP Services | MCP on Databricks | Managed MCP | External MCP | MCP Marketplace Validation

Skills​

Skills teach an agent how to do one task well. On Databricks they are Unity Catalog securables (catalog.schema.skill) — same permissions, tags, and audit as the rest of the customer's data. Skills complement MCP Services: skills are the playbook, MCP is the toolkit.

Partners put product knowledge on Databricks by:

  • Authoring a skill locally (SKILL.md plus supporting files)
  • Publishing it to a Unity Catalog schema in the customer's workspace
  • Sharing it so the customer's agents discover and use the live skill

Documentation: Skills support in Unity Gateway | Create and share Unity Gateway Skills

What's next​