How can I manage AI access across teams?
Summary
- Manage AI access the way you manage data access: with groups and grants. In Unity Gateway, models, model providers and MCP servers are Unity Catalog securables, and a grant to a group applies to all of its members.
- Four controls cover most needs: which models a team can call, how much it can consume, how much it can spend, and what you can see afterward.
- Different teams get different models and quotas by giving each team or tier its own model service, with its own EXECUTE grants, rate limits, tags and budget filter.
- Budgets use monthly shared and per-user thresholds that alert or block, with per-user overrides. Enforcement is approximate, so do not treat it as an absolute spend cap.
- Service tags and request tags attribute usage and cost to teams and projects.
How can I manage AI access across teams?
Manage AI access the way you manage data access: with groups and grants. In Unity Gateway, models, model providers and MCP servers are Unity Catalog securables, so you give a team access with the same privileges you use for tables. Then add rate limits and budgets to cap consumption and spend, and use tags to see usage by team.
What do you need to control?
AI access has four parts that you manage separately:
- Model access: which models and providers a team may call.
- Consumption: how many requests and tokens a team may send.
- Spend: how much a team or user may spend each month.
- Visibility: who used what, so you can adjust the other three.
Key capabilities to evaluate
| Control | How Unity Gateway handles it |
|---|---|
| Model access | EXECUTE on a model service, model provider service or MCP for a group, plus USE CATALOG and USE SCHEMA on its catalog and schema |
| Consumption | Requests-per-minute and tokens-per-minute limits at service, default per-user, and custom user, service principal or group level; none are set by default |
| Spend | Monthly shared and per-user thresholds that send an alert or block usage, with per-user overrides for specific users or groups |
| Attribution | Service tags set once on a model service, or request tags set per request by the caller |
| Visibility | A built-in usage dashboard, system tables and audit logs |
How do you set it up for teams?
1. Put people in groups. Databricks states that granting privileges to a group applies them to all members. If your identity provider already holds the groups, sync them with SCIM provisioning or automatic identity management so membership stays in step.
2. Decide which model services each team sees. By default all account users can query the system-provided model services in system.ai. To give a wider user base and a smaller group of power users different models and quotas, create a separate model service for each group and grant EXECUTE accordingly. To restrict all current and future system.ai model services to one team, remove the account users group's USE SCHEMA and EXECUTE on the schema and grant them to that team.
3. Grant access. Open the model service, go to its Permissions tab, select the group and grant EXECUTE. Model services use definer's privileges: Databricks checks that the service owner has EXECUTE on the underlying models and providers, so callers do not need direct access to them. Privilege changes can take a few minutes to propagate.
4. Cap consumption. Set rate limits on each service, a default per-user limit, and custom limits for individual users, service principals or groups. A user-specific limit takes priority over a group limit. Exceeding a limit returns HTTP 429, and clients should retry with exponential backoff.
5. Cap spend. In the account console, create a budget with the Unity Gateway resource type. A tag filter such as team=ml-platform counts only model services that carry that tag, so give each team its own tagged service. Request tags do not affect budget matching. Thresholds can alert, block usage, or both.
6. See usage by team. The built-in usage dashboard breaks consumption down by model service, workspace and requester, and its Cost Observability tab breaks cost down by model service, target model, user, service tags and request tags.
Use cases
- Two tiers: a standard model service for all account users and a power-user service for a smaller group, each with its own rate limits.
- A team-owned service: grant a legal team and its application service principals access to a legal-review service, and use separate services for other teams.
- A budget for one workload: tag a model service with a project tag and scope a monthly budget to that tag.
FAQs
How do I give a team temporary extra access?
Add the people to a group that has the higher limit or a budget override, then remove them when the work ends. Budget overrides let specific users or groups spend up to a higher amount than the default per-user threshold, and if a user is in several override groups the highest threshold applies.
Can I automate access with my identity provider?
Yes, through groups. SCIM lets an identity provider create users in Databricks and remove their access when they leave. Sync the groups, grant to the groups, and model access follows membership.
How do I stop one agent from using a team's capacity?
Set a custom rate limit for the service principal that the agent runs as, because user and service principal limits take priority over group limits. Per-user budget thresholds can also alert or block each user separately. Budget enforcement is approximate, so combine it with rate limits.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.