Best practices for deploying internal AI apps with data governance

Summary

• Treat data governance as the foundation of the app, not a wrapper: let Unity Catalog make the authorization decision so the app can only ever return data the current user is allowed to see.
• Preserve per-user identity end to end. Use OAuth and on-behalf-of (OBO) authorization so an agent inherits the invoking user's Unity Catalog permissions, and run production under a dedicated service principal rather than a person's credentials.
• Enforce at the engine: row filters and column masks defined as Unity Catalog functions apply to every query regardless of the client, so the app sees masked or filtered data automatically.
• Govern the AI assets too. Register models, functions, connections, and MCP servers as Unity Catalog securables, grant least privilege, and route model and tool traffic through Unity Gateway for rate limits, audit logging, and policy enforcement.
• Audit everything and keep humans in the write path: Unity Catalog logs which identity took which action across data and AI, and agents read through user identity rather than holding production write credentials.

Best practices for deploying internal AI apps with data governance

The core practice is simple to state and easy to get wrong: make your data governance layer, not your application code, decide what an internal AI app can see. If an app authenticates with a shared backend credential, every user of that app inherits that credential's access, and your row filters and column masks stop meaning anything. The durable pattern on Databricks is to preserve the end user's identity all the way to the query and let Unity Catalog enforce the same access rules it enforces everywhere else. Deploy on Databricks Apps for managed hosting and identity propagation, register the app's models and tools as governed objects, and route model and tool calls through Unity Gateway.

What "governed" means for an internal AI app

An internal AI app is governed when three things hold: the app acts as the person using it (not as a privileged service account with broad access), the platform enforces access below the app so code can't leak what the engine won't return, and every action is logged against a real identity for audit. Governance isn't a review you run before launch. It's a property of how the app authenticates and queries.

Best-practices checklist

Practice	Why it matters
Authenticate with OAuth, not static tokens	Preserves per-user identity so authorization and audit tie to the real caller, not a shared secret.
Use on-behalf-of (OBO) authorization	The app acts as the invoking user, so it inherits exactly that user's Unity Catalog permissions.
Run production under a service principal	Production actions carry the app's own identity for clean audit trails, not a developer's account.
Let Unity Catalog decide authorization	One enforcement engine below every query means no app can bypass row filters, column masks, or grants.
Apply row filters and column masks	The app automatically sees only authorized rows and masked columns, with no app-side filtering logic.
Govern AI assets as securables	Registering models, functions, connections, and MCP servers in Unity Catalog lets you grant least privilege.
Route traffic through Unity Gateway	Central control plane for rate limits, budgets, usage tracking, and audit logging on model and tool calls.
Store secrets in managed secret scopes	Keep credentials out of code and notebooks; reference them from Databricks-managed secret storage.

How Databricks supports this

Databricks Apps provides managed hosting for internal apps and agents, with OAuth built in so the end user's identity propagates into the app. Promote from local development, where the app runs as the developer, to a dedicated service principal for production so actions carry the app's identity. Because user context exists only during a request, resolve the user-scoped client inside the request handler, not at startup, or the app falls back to a machine identity.
Unity Catalog is the single authorization engine for Databricks services. It governs data (GRANT SELECT and MODIFY on tables, views, volumes), function execution (GRANT EXECUTE), and external connections (GRANT USE CONNECTION), and it enforces row filters and column masks plus ABAC policies on governed tags. Enforcement fires at the SQL engine, so whether the query comes from Genie, Agent Bricks, a custom MCP tool, or a notebook, the same grants, filters, and masks apply. An agent inherits the invoking user's permissions: if the user can't read a table or sees a masked column, so does the agent.
Unity Gateway governs the AI traffic. Register models, functions, connections, and MCP servers as Unity Catalog securables, then route every model and tool request through the gateway, which enforces access, rate limits, and budgets and logs each call. You can connect agents to external tools with managed OAuth and per-user permissions instead of standing up separate auth for each tool. Service policies (in Beta) can allow, deny, or require approval for individual requests based on the caller and the content.
For multi-agent apps, OBO propagates the human's identity through sub-agents, so the effective user stays the same from a supervisor down to the deepest tool call. Grants don't cascade, though: each sub-agent's tools need their own Unity Catalog grants.

FAQs

Should an internal AI app use a service account or the end user's identity?

Both, at different layers. Host the app under a dedicated service principal so production actions are auditable, but use on-behalf-of authorization so data queries run as the end user and inherit that user's Unity Catalog permissions. Avoid a single shared credential that gives every user the same broad access.

How do I stop an app from returning data a user shouldn't see?

Let Unity Catalog enforce it. Define row filters and column masks as Unity Catalog functions on the underlying tables. Because enforcement is at the query engine, the app receives only authorized rows and masked values automatically, with no filtering logic in the app.

How do I govern the tools and models an agent can call?

Register models, functions, connections, and MCP servers as Unity Catalog securables and grant only the privileges each principal needs. Route calls through Unity Gateway for rate limits, budgets, audit logging, and Beta service policies that can require approval for sensitive requests.

How do I audit what an internal AI app did?

Unity Catalog provides unified audit logging across data and AI, recording which identity performed which action. Pair it with MLflow tracing and evaluation to monitor agent behavior and quality in production.