Databricks — AI Governance: Overview
01 / 10

Navigation

→ / SpaceNext slide
←Previous slide
HomeFirst slide
EndLast slide
SwipeTouch navigation
Click anywhere or press Esc to close

AI Governance on Databricks

Overview: identity, authorization, and tool governance for enterprise AI

One governance model for business users and AI agents alike, whether access originates internally or through a partner or customer's own identity provider.

The entry point. The domain decks that follow go deep on each governance area referenced here.

Agenda

What this overview covers

1
The issue

Business users and AI agents both need governed access to the same data, internally and through external partner/customer identity providers, without a separate trust model per surface.

2
The governance model, at a glance

One trust boundary, three token paths, seven enforcement layers, and a resource lens for what's being accessed.

3
Why it matters

Consistent governance regardless of surface, a single control plane for audit and compliance, and faster delivery of new AI surfaces.

4
Where to go deeper

A map to the 11 topic decks (02 through 12) that cover implementation detail for each domain.

The issue

Business users and AI agents both need governed access to the same data, without a separate trust model per surface.

Business users

Ask plain-English questions, build dashboards, and work through Genie Agents, copilots, and agents. Each expects to see only the data their own permissions allow.

AI agents

Orchestrate tools and call data on a user's behalf. Partners and customers need the same capabilities, reached through their own portals and their own identity providers.

Same data, same AI, same governance expected, whether the requester is an employee or an external partner or customer authenticating through their own IdP.
What: the model, at a glance

One authorization engine, however authentication arrives

Databricks enforces authorization in exactly one place: Unity Catalog. Authentication can originate from the workspace identity provider for internal users, or from an external IdP via token federation for partners and customers. Every path converges on UC before any data or tool is touched.

Internal IdPEntra ID · Okta · SAML/OIDC
→
Unity Catalogsingle trust boundary
←
External IdPpartner / customer, via federation
↓

Same governance, regardless of which door the identity walked in. Data, tools, and agents all check the same UC privileges.

What: token paths

Three token paths, one identity model

U2M, OBO, and M2M are token acquisition paths, not separate authentication systems. What changes is whose identity Unity Catalog sees.

PathWho authenticatesIdentity in UC
U2MThe human, directlyThe human
OBOThe human, via an app that forwards the tokenThe human
M2MThe application itself (service principal)The service principal
Human calling directly: U2M. Human going through an app: OBO. App itself with no human present: M2M.
What: enforcement layers

Seven layers, checked on every call

LayerGoverns
1 · IdentityAgent service principal, user OBO, token federation
2 · PermissionUC privileges on tables, functions, and services (MCP, model)
3 · DataRow filters, column masks, ABAC, BROWSE privilege
4 · ExecutionModel Serving, Apps, serverless sandboxing
5 · Service PolicyABAC governance: who calls what tools, on which data (guardrails built-in, enforced ON CALL/ON RESULT, fail-closed)
6 · ContentAI Gateway guardrails: hallucination detection, safety, PII handling
7 · Auditsystem.access.audit, MLflow traces, inference tables
No design should rely on a single layer. Service Policies are the superset governing content and tool execution.
What: the resource lens

Authorization differs by what's being accessed

Model Servingendpoints, foundation models, custom
Genie Agents
UC Functions
Vector Search
ServicesMCP, model (UC securables)
Tables & Volumes
PostgreSQLPG-native auth, the exception

MCP Services and model services are UC securables with governed tags, role-based access, and service policies. PostgreSQL (Lakebase) uses native PG authorization (roles, GRANT, RLS) — the exception to the UC model.

Why this matters

One model, not one per surface

Consistent governance

The same rules apply whether the surface is Genie Agents, Teams, a custom app, or a partner portal. No per-integration reinterpretation of who can see what.

Lower audit burden

One control plane to prove compliance against: system.access.audit and MLflow traces cover every surface, not a bespoke log per integration.

Velocity

New AI surfaces plug into the same identity and authorization model instead of re-solving it, so teams ship faster without reopening the trust question.

How: where to go deeper

For implementation detail, see:

DeckCovers
Unity AI Gatewayunity-ai-gateway.htmlRouting, rate limits, guardrails, spend caps, MCP Services
Identity & Auth Foundationsidentity-auth-foundations.htmlU2M/OBO/M2M in depth, one authentication layer
Authorization by Resource Typeauthorization-by-resource.htmlThe full resource-authorization matrix
Orchestration & Tool Governanceorchestration-tool-governance.htmlAgent Bricks, MCP, service policies
Cross-IdP Federationcross-idp-federation.htmlToken exchange across identity providers
SP & M2M Identitysp-m2m-identity.htmlGovernance for service principals and machine identities
UC Connectionsuc-connections.htmlUnity Catalog HTTP Connections to external services
UC Governanceuc-governance.htmlRow filters, column masks, ABAC
Agent Cost Governanceagent-cost-governance.htmlCost control for agentic workloads
AI/BI Dashboard Embeddingaibi-dashboard-embedding.htmlEmbedding dashboards for foreign identity providers
Teams/Copilot Studio → Genie Agents OBOteams-copilot-genie-obo.htmlPer-user identity from Teams and Copilot Studio
UNITY CATALOG. THE TRUST BOUNDARY. GOVERNANCE FOLLOWS IDENTITY.
Identity · Permission · Data · Execution · Service · Content · Audit
OBO · M2M · Federation · MCP Services · Multi-Provider LLMs
Databricks Applied AI Governance Series · AI Governance Overview