01 · The challenge
A human check on the model, and the permissions to make it work.
People needed to check model predictions before they became decisions, and the app needed secure access to data and storage. Permission errors were blocking staging tables and secrets.
02 · What I did
What I owned and built.
- Built the app with a modular design: separate config, auth, database utilities, and page components.
- Mapped the Unity Catalog grants the app needs (catalog, schema, create table, modify, select) and identified which identity actually runs the queries for each connection method.
- Moved the app from a Databricks-managed to an Azure-managed service principal so it could be granted Azure permissions.
- Untangled the two permission layers on a Key Vault-backed secret scope (Azure RBAC and Databricks ACLs), switched the Key Vault to RBAC, and set up ACL management through the Databricks SDK.
03 · Architecture
How it fits together.
Databricks Apps
Key Vault RBAC + secret-scope ACLs
04 · Key decisions
The judgment behind the build.
Why human-in-the-loop?
Inventory decisions carry real cost. A review step lets people catch what the model can’t see before anything takes effect.
Why an Azure-managed identity?
Only an Azure-managed service principal can be granted Azure-side permissions like Key Vault access. That made it the foundation for everything else.
Why RBAC on Key Vault?
Two overlapping permission models are how access breaks silently. Standardizing on RBAC made the layers predictable and auditable.
05 · Impact
What changed because of the work.
- Keeps a person in the loop on ML inventory decisions before they take effect.
- Established a secure, least-privilege access pattern that other apps using the same secret scope can reuse.
06 · What’s next
Where it goes from here.
Apply the same permission pattern to future Databricks apps.
This case study is a sanitized reconstruction. Organization names, proprietary code, data, and internal schemas are intentionally left out.