How do I manage permissions across models, agents, MCP servers, and AI tools?

Summary

• Unity Gateway unifies AI governance by registering all AI assets (models, agents, MCP servers, functions, and external model providers) as Unity Catalog securable objects, so you manage them with the same permission framework as tables and volumes.
• The core permission is EXECUTE: grant EXECUTE on individual assets or use schema-level grants to provide broad access to all current and future model APIs within a schema.
• Advanced mechanisms include attribute-based access control (ABAC) grants to automate rule-based access (e.g., grant analysts access to every production-tagged model) and service policies to evaluate and filter requests per content.
• Rate limits, budgets, and traffic management policies provide additional governance layers to prevent abuse, control costs, and ensure fair resource allocation across users and workloads.

How do I manage permissions across models, agents, MCP servers, and AI tools?
Unity Gateway brings all AI governance into a single framework: every AI asset (models, agents, MCP servers, custom functions, and external model providers) is managed as a Unity Catalog securable object. This means you apply the same permission model you already use for data governance to AI.

The unified permission model

The core principle is simple: register an AI asset in Unity Catalog once, then grant and revoke access using standard privileges. All assets inherit the same privilege system as tables, volumes, and schemas. The key permission is EXECUTE, which lets authorized users invoke the asset.
Unity Catalog prerequisites apply: to use a model or agent in a schema, you need USE CATALOG on its parent catalog and USE SCHEMA on its parent schema. From there, EXECUTE on the specific asset controls who can run it.

Asset types and governance

Asset type	Registration mechanism	How it's governed	Example usage
Databricks-hosted models	Register in UC	EXECUTE permission	Grant analysts EXECUTE on gpt-4-turbo
ML models (MLflow)	Register in UC	EXECUTE permission	Restrict model promotion to approved version
MCP servers	Register as UC service with tool filtering	EXECUTE permission	Grant data engineers EXECUTE on internal MCP server
Agents	Register as agent service (Beta)	EXECUTE permission	Restrict agent use to specific teams
Custom functions	UC functions in SQL/Python	EXECUTE permission	Let agents use only whitelisted functions
External providers	Register (OpenAI, Anthropic, Bedrock) with BYOK	EXECUTE permission	Centralize provider access and credentials

Permission granting strategies

Schema-level access: Grant EXECUTE on the system.ai schema to provide blanket access to all current and future model APIs. This is simple but permissive; useful for trusted teams with full model access.
Direct asset grants: Revoke schema-level access and grant EXECUTE on individual models, agents, or MCP servers. This follows the principle of least privilege: users get access only to what they need.
Attribute-based access control (ABAC): Use governed tag policies to grant EXECUTE to assets matching specific tags. For example, grant analysts EXECUTE on every model tagged with lifecycle = production. This scales governance: add or remove models from a category by modifying their tags, not by re-granting permissions.

Request-level governance and controls

Beyond permissions, Unity Gateway provides several additional controls:
Rate limits: Cap requests per minute (QPM) or tokens per minute (TPM) per endpoint or per user. Prevent any single user or workload from consuming all available capacity.
Budgets: Set monthly spend thresholds and per-user spending limits. You can configure hard caps to prevent overspend, or soft limits that trigger alerts.
Service policies (Beta): Evaluate each request and response. A service policy can allow, deny, or require approval based on request content, user attributes, or time-of-day. This is useful for compliance rules like "block requests mentioning PII" or "require approval for queries on sensitive tables."
Traffic management: Configure fallbacks (route to a cheaper model if the primary is unavailable), traffic splitting (A/B test two agents), and request/response transformations.

MCP servers at scale

For teams that use many MCP servers, centralized registration in Unity Catalog ensures consistent governance. Register the MCP service once in Unity Catalog, grant EXECUTE to the appropriate groups, and apply tool filtering policies server-side. This way, every MCP client connecting through the gateway enforces the same access rules.
For developer environments, you can script MCP client configuration and distribute it through your device management system (Intune, Jamf) until Databricks-native central configuration becomes available.

Integrating with external AI tools

Databricks-hosted foundation models are one category of asset; external providers like OpenAI, Anthropic, and Bedrock are another. Register external providers with bring-your-own-key (BYOK) credentials and govern them through Unity Gateway. This consolidates access control: developers request access to "OpenAI via Unity Gateway," and admins grant or deny that at a single control point.

FAQs

Can a user inherit different permissions for the same asset in different catalogs?

Yes. If a model is registered in multiple catalogs or schemas, permissions are per-registration. A user might have EXECUTE on model A in catalog-dev but not in catalog-prod. Grant permissions at the scope where the asset is registered.

How do I know if a user has EXECUTE permission on an asset?

Use the Databricks permissions API or the workspace UI to check permissions on the asset. You can also query the audit log to see who has executed a model or agent and when.

Can I grant EXECUTE conditionally, like "allow access only on weekdays"?

Not directly through basic EXECUTE grants. However, service policies (Beta) allow you to deny or require approval for requests based on time-of-day or other attributes, achieving conditional access at the request level.

What happens if a user has EXECUTE on an agent but not on its underlying model?

The agent cannot invoke the underlying model. In a chained workflow, all dependencies must be accessible. The agent will fail with a permission error. Ensure the user or agent's service principal has EXECUTE on all upstream models and functions it needs.

Can I audit who used which model or agent and when?

Yes. The audit log captures all Model Registry and foundation model API calls, including user, timestamp, and asset name. Query the audit log to build usage dashboards or compliance reports.