How to restrict Databricks Apps and Vector Search endpoint creation for workspace users

[Raman_Unifeye]

I am looking to restrict all workspace users' access to create Databricks Apps and Vector Search endpoints.

I am aware there is no simple toggle, what is the best way to implement it?

[Kartikb]

I propose a CI/CD process that automatically deletes apps or vector searches within three days if they are not listed in your configuration. For Databricks apps, you can also implement a scheduler to automatically pause the app.

[Raman_Unifeye]

That's a reactive approach. Is there any proactive way to stop that esp Apps?

[saurabh18cs]

Hi @Raman_Unifeye 

Users cannot create an app without compute.
Restrict compute creation/attachment via Cluster Policies ?? 

Also remove admin acess and unrestricted cluster creation acces at workspace level for added user or group/

[Raman_Unifeye]

@saurabh18cs - user do not have cluster creation permission except the serverless compute which I dont want to block for rest of the work.

User do not have admin or unrestricted cluster creation.

[KartikBhatnagar]

Hi Raman,

You can use a budget policy and define which groups or users are allowed to use that budget policy. A budget policy can be attached to an app or a Vector Search. Stop all apps that are running without a budget policy.
You can find cost burn for apps or Vector Searches without a policy by using system tables, and this information can be shared with the team. Databricks has published a cost dashboard that also helps you filter app and Vector Search costs.
Second, use CI/CD automation to operate workloads on a schedule.

Regards,
Kartik

[SteveOstrowski]

Hi @Raman_Unifeye,

You are correct that there is no single toggle to block creation of these resources today. Here is a breakdown of the proactive and detective controls available for each.

VECTOR SEARCH ENDPOINTS

Vector Search endpoints use access control lists (ACLs) with these permission levels: CAN CREATE, CAN USE, CAN MANAGE, and NO PERMISSIONS.

The key mechanism is the Permissions API. A workspace admin can remove the CAN CREATE permission from the "users" group at the workspace level, then grant CAN CREATE (or CAN MANAGE) only to specific groups or service principals that should be allowed to create endpoints. You can do this through the Permissions API:

PUT /api/2.0/permissions/vector-search-endpoints
{
"access_control_list": [
{
"group_name": "vector-search-admins",
"permission_level": "CAN_MANAGE"
}
]
}

This sets object-level permissions on all vector search endpoints. By granting only your designated admin group the create/manage permission and not granting it to the broader "users" group, you effectively restrict who can create new endpoints.

Documentation reference:
https://docs.databricks.com/aws/en/security/auth/access-control/index.html (see the "Vector search endpoint ACLs" section)

DATABRICKS APPS

Databricks Apps currently follow the same model as other serverless products: any user in a workspace can create an app. There is no ACL-based creation restriction for Apps the way there is for Vector Search endpoints.

Here are the proactive strategies available today:

1. Workspace segmentation: If you need strict control, consider dedicating a separate workspace for app development and only granting access to that workspace to approved developers. Users who should not create apps simply do not have access to the app-enabled workspace.

2. Serverless budget policies: While these are primarily for cost attribution, they give you visibility and some guardrails. You can create a budget policy and assign it only to approved groups. When a user who is not assigned a budget policy tries to create an app, the policy enforcement may limit them depending on your configuration. More details here:
https://docs.databricks.com/aws/en/admin/usage/budget-policies.html

3. Automated cleanup via API: Use the Databricks Apps API to periodically list all apps and delete or stop any that were created by unauthorized users. This can be scheduled as a job:

import requests

host = "https://<workspace-url>"
headers = {"Authorization": "Bearer <token>"}

# List all apps
response = requests.get(f"{host}/api/2.0/apps", headers=headers)
apps = response.json().get("apps", [])

# Define allowed creators
allowed_creators = ["admin-user@company.com", "app-team@company.com"]

for app in apps:
creator = app.get("creator")
if creator not in allowed_creators:
app_name = app.get("name")
# Stop the app
requests.post(f"{host}/api/2.0/apps/{app_name}/stop", headers=headers)
# Or delete it
requests.delete(f"{host}/api/2.0/apps/{app_name}", headers=headers)

4. System tables monitoring: Query the system.billing.usage table to monitor for app creation events and set up alerts. This gives you near-real-time detection if someone creates an unauthorized app.

SUMMARY OF APPROACHES

Proactive (prevents creation):
- Vector Search: Use Permissions API to restrict CAN CREATE to specific groups
- Apps: Use workspace segmentation (separate workspace for app development)

Detective/Reactive (detects and remediates):
- Both: Automated cleanup scripts via REST API
- Both: System tables monitoring and alerts
- Both: Serverless budget policies for cost visibility and attribution

The Vector Search endpoint restriction is straightforward through ACLs. For Databricks Apps, workspace segmentation is the most reliable proactive approach until a dedicated creation-restriction mechanism is available.

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.