Databricks Apps User Authorization Is Now GA, but Identity Boundaries Still Matter
Databricks made Databricks Apps user authorization generally available on October 7, after more than 18 months in public preview. The feature lets an application call supported platform services using the signed-in user's identity. That changes a central security decision for data applications and AI agents: whose permissions govern each request?
Until now, developers often relied on an application's service principal, which is a nonhuman identity assigned to one app instance. Every user could receive results through that shared identity unless developers recreated user-level access rules inside the application. The new model lets existing Unity Catalog policies follow a user into an app request.
That promise carries an important qualification. On-behalf-of-user authorization, or OBO, does not make an application safe by default. Developers must separate user-driven actions from background work, request narrow scopes, protect forwarded tokens, and reject requests when the expected identity is missing.
The announcement places Databricks in a broader contest between platform-managed authorization and application-managed permission logic. Microsoft supports delegated identity through its own OBO flow, while other cloud platforms offer separate identity and policy components. Databricks is tying that pattern directly to governed enterprise data, SQL warehouses, agents, and applications running on its platform.
Databricks Apps User Authorization Changes Who Governs Each Request
The GA release gives developers a supported way to preserve a user's existing data permissions throughout an application request.
Databricks Apps hosts data applications, operational tools, dashboards, and custom agents on serverless infrastructure. Each deployed app receives a dedicated service principal that can access resources granted to that application. This app authorization remains available and continues to suit shared or automated operations.
User authorization adds a second identity path. When a signed-in person initiates a supported action, Databricks forwards an access token to the application runtime. The app can then call an approved Databricks API under that person's identity and permissions.
The platform's authorization model uses OAuth 2.0, the standard protocol for delegated access. It distinguishes user-to-machine authorization from machine-to-machine authorization. The first represents an interactive user, while the second represents an application or automated workload.
Unity Catalog then evaluates the user's existing grants when the app accesses governed data. Row filters can restrict which records appear, while column masks can hide or transform sensitive fields. Warehouse permissions also determine whether the user can execute the requested query.
The result depends on the person making the request. A regional sales manager might receive data for one territory, while a national leader sees every region. Both people can use the same application and request path without receiving identical access.
That behavior matters because the app does not need a separate copy of each governance rule. When an administrator changes a Unity Catalog policy, later app requests are evaluated against the updated policy. Developers avoid maintaining a parallel authorization system that can drift away from the platform's controls.
Databricks first introduced OBO authorization for Apps in public preview on March 26, 2025. The preview release covered resources such as Unity Catalog tables and model-serving endpoints. General availability signals that Databricks now considers the pattern ready for production adoption within its documented limits.
GA does not eliminate app authorization. Databricks explicitly presents the two models as complementary. An application can use its own identity for shared configuration, telemetry, or routine maintenance, then use the current person's identity for a governed query.
Consider a sales-insights assistant that answers questions about account performance. Its app identity might read common configuration and record operational metrics. Its user identity path would query customer and sales records available to the requesting employee.
That division is the foundation of the release. The app still has an identity, but that identity no longer needs to become a universal gateway for every interactive action. Developers can decide which principal governs each operation.
The change therefore addresses more than login. Authentication establishes who is present, while authorization determines what that identity can do. Databricks Apps user authorization carries the second decision into downstream data and service calls.
The Real Pressure Falls on Application-Managed Access Control
Databricks is challenging the practice of rebuilding enterprise data permissions inside each application.
An app that uses only a shared service principal often sees one consistent permission set. Developers must then decide which results each employee may receive. That usually requires custom roles, policy mappings, filtering logic, or another authorization service.
Those controls can work, but they introduce a second source of truth. A governance team might update a Unity Catalog grant while an application's local role mapping remains unchanged. The resulting mismatch can expose information or deny legitimate access.
User authorization reduces that duplication for supported Databricks resources. The requesting person's established permissions become part of the execution context. Application code can focus on the requested task while the platform evaluates governed access.
This matters increasingly for AI agents. A conventional dashboard exposes predefined views and queries. An agent can interpret open-ended language, choose tools, assemble queries, and retrieve information across several steps.
That flexibility expands the number of paths through which protected data can be reached. A developer cannot reliably anticipate every question an employee might ask. Preserving the employee's authorization context gives the downstream platform another enforcement boundary.
The pressure is especially clear when organizations move prototypes into production. Early demonstrations often run under a developer credential or broadly permitted service account. That shortcut becomes difficult to defend when an app reaches employees with different roles, territories, and confidentiality requirements.
A single application may serve sales, finance, operations, and executives. Those groups should not automatically inherit the same view of customer details, forecasts, or employee information. Central policies become more valuable as the audience expands.
Databricks is also reducing friction between governance administrators and application teams. Security teams can continue managing data privileges through Unity Catalog. Developers do not need to translate every policy into framework-specific middleware.
That does not remove development work. Teams must still decide whether a particular operation belongs to the user or the app. They must also understand which Databricks APIs support OBO and which authorization scopes each action requires.
The alternative platforms are not missing delegated identity. Microsoft's OBO flow passes a user's identity and delegated permissions from an upstream API to a downstream API. Google Cloud provides identity-aware application access, while AWS offers fine-grained authorization components for custom applications.
Databricks differentiates itself through integration with its data governance environment. The authorization decision is attached to Unity Catalog permissions, SQL access, and supported platform services. That can reduce integration work for applications whose data already lives inside Databricks.
The tradeoff is greater platform dependence. Applications built around Unity Catalog rules and Databricks-specific scopes inherit useful controls, but they also become closely aligned with one platform's identity model. Multicloud teams may still need another authorization layer for resources outside Databricks.
For enterprise buyers, the question is therefore not whether delegated identity exists elsewhere. It is whether Databricks can make governed application development simpler enough to keep more data and AI workloads within its platform.
How On-Behalf-of-User Authorization Creates Two Permission Boundaries
An OBO request succeeds only within both the user's permissions and the application's approved API scope.
The first boundary concerns data and resources. A user cannot reach a Unity Catalog table, SQL warehouse, or supported service merely because an app requests it. The person must already hold the necessary permissions.
The second boundary concerns the application. Developers declare API scopes, which define the classes of operations an app may perform for a user. A scope does not grant the person new data access, but it limits how the application can exercise existing access.
For read-only SQL analysis, Databricks documents a sql:restricted-query scope. The app can submit restricted queries as the current user without receiving broad authority to manage warehouses or perform unrelated administrative work.
These intersecting boundaries support least privilege, the practice of granting only the access required for one task. A highly privileged user might reach many datasets directly. A narrowly scoped app should still be unable to exercise every privilege that user possesses.
Workspace administrators control an additional upper limit. They can determine which user-authorization scopes developers may add to apps in the workspace. The allowlist can include all supported APIs, selected scopes, or no user authorization.
That structure divides responsibility. The developer requests the minimum capabilities required by the product. The administrator decides which capabilities application developers may request within the workspace.
An administrator cannot rely on configuration alone, however. Databricks says account administrators can add scopes even when a workspace allowlist excludes them. Existing apps can also continue running after an allowed scope is removed.
According to the announcement, an affected app cannot subsequently start, deploy, or update until the disallowed scope is removed. That behavior avoids an immediate outage, but it creates a period when current execution and current policy do not fully match.
Teams should therefore treat scope changes as governed operational events. Administrators need an inventory of deployed apps, requested scopes, responsible owners, and business dependencies. Removing a capability without that context can delay remediation or strand an application during its next deployment.
The application code must also keep the two identities separate. A user-scoped client should handle governed interactive operations. An app-scoped client should handle shared configuration, metrics, and work that must continue without a user session.
This is more than a naming preference. A generic client can conceal which identity is executing a sensitive path. Separate dependencies, tests, and request handlers make unintended credential use easier to detect.
The strictest rule concerns missing user tokens. If a route requires user authorization but no forwarded token is present, the application should fail closed. It should reject the request instead of silently switching to its service principal.
A fallback might produce a technically valid answer under entirely different permissions. The user would have little reason to suspect that the app accessed broader or narrower information than expected. That makes silent identity changes particularly dangerous.
The forwarded token should exist only for the active request. Databricks advises developers never to print, log, or persist it. Background jobs should use app authorization instead of retaining a user's token after the interactive session ends.
For teams building internal AI tools, this identity separation belongs alongside other engineering controls. A searchable technical knowledge base can preserve authorization decisions, threat models, and review evidence beside implementation documentation.
AI Agents Make the Identity Boundary Harder to Maintain
Agents benefit from user-specific permissions, but their multi-step behavior makes identity mistakes more consequential.
Databricks says custom agents deployed through Apps can use the same authorization model. The user-scoped workspace client must be initialized inside the active invoke or stream handler. The forwarded token is available only while the request is running.
That timing constraint prevents developers from treating user identity as global application state. An agent process can serve many people, and application startup does not belong to any one user. Creating a user-scoped client too early risks missing or mixing request context.
Agent workflows also combine different kinds of work. One step might retrieve shared instructions through the app identity. Another might query governed financial data as the user. A third might write general telemetry without retaining the user's credential.
Each transition creates an authorization decision. Developers need to identify the principal, scope, resource, and expected failure mode for every tool call. A single generic agent client can blur those distinctions.
The challenge grows when an agent calls another service. OBO can preserve the user context only where the downstream integration supports that model. External APIs may require separate credentials, consent, scopes, and audit controls.
The agent must not assume that authorization transfers automatically across the entire tool chain. A token is issued for a particular audience and purpose. Microsoft's OBO guidance similarly warns against relaying middle-tier tokens to unintended recipients.
This means user authorization should not be described as blanket impersonation. The application acts for the user only within configured scopes and supported request paths. That wording matters because "acting as the user" can otherwise suggest unrestricted access.
Prompt injection creates another reason for caution. An attacker might place instructions inside content that an agent retrieves, encouraging it to call tools or disclose information. OBO limits the accessible data to the current user, but it does not determine whether a requested action is sensible.
The user's own permissions may also be extensive. An executive, administrator, or analyst could possess access to sensitive datasets across many business functions. A compromised app using that person's valid identity still presents a serious risk.
Scopes provide an important second boundary in that situation. A read-only query scope can prevent unrelated administration, but it cannot decide whether every permitted query serves the user's intention. Applications still need input handling, tool constraints, output controls, and monitoring.
Consent also deserves scrutiny. Users may approve requested permissions without understanding how an agent will combine services or process results. Clear scope names help, but consent is not a substitute for administrative review and constrained application behavior.
Auditability becomes essential. Security teams need to distinguish actions performed by the app identity from actions performed for a person. Logs should identify the relevant principal and operation without recording bearer tokens or sensitive response content.
Testing must involve users with different permissions. A test performed only with an administrator account can hide mistakes because that account rarely encounters access denials. Databricks recommends repeating tests after governance policies change.
Useful test cases include a user with regional access, a user with broader access, and a person who lacks the queried table entirely. Teams should verify both returned data and rejection behavior. They should also confirm that missing tokens never trigger an app-identity fallback.
The central limitation is therefore clear. Databricks Apps user authorization can enforce existing platform permissions, but it cannot repair overly broad grants. Organizations must still maintain accurate groups, catalog privileges, warehouse access, row filters, and column masks.
The Security Promise Depends on Operational Discipline
The strongest part of the design is its layered control model, while the weakest part remains implementation and governance around that model.
Databricks can forward the appropriate identity and enforce declared scopes. It cannot ensure that every development team assigns the correct identity to every code path. That decision remains inside application architecture.
A team might correctly use OBO for a SQL query but accidentally employ the app identity for a related file request. The user interface could combine both responses without revealing the different authorization contexts.
Background processing presents another boundary. A user might initiate a long-running task that continues after the request ends. Because the forwarded token belongs to an active request, developers cannot simply preserve it for later execution.
The safer design is to determine whether delayed work belongs to the application or requires another supported delegated pattern. If it belongs to the app, the service principal needs carefully limited permissions. If it requires user context, developers must follow documented platform behavior rather than retaining the token.
Availability across environments also requires confirmation. Databricks documentation changes as services and compliance configurations expand. Teams should verify cloud, region, workspace, and security-profile support before treating GA as universal availability.
Apps themselves cannot be anonymous public applications. Databricks says users must authenticate, and external collaborators require onboarding through supported identity federation. That makes the model most natural for workforce and partner scenarios with managed identities.
The separation between app permissions and data authorization can confuse reviewers. CAN USE and CAN MANAGE determine who can run or administer an app. They do not determine which tables or records a person can access through it.
A person could hold permission to use an app while lacking permission to query its underlying data. That request should fail or return limited results. Conversely, data access alone does not necessarily grant permission to open the application.
The documented permission levels therefore need separate reviews from Unity Catalog grants. Treating them as one control can create false assurance during audits.
Administrative scope allowlists introduce another governance task. The default can include all supported APIs, according to the announcement. Security-conscious organizations should decide whether that default matches their development model before broad application adoption.
Narrowing the allowlist can reduce risk, but it can also block legitimate products. The right process combines a constrained baseline with a documented exception path. Otherwise, teams may seek broader app identities to avoid scope restrictions.
There is also a detection challenge. An app may request only approved scopes and still behave incorrectly within them. Runtime monitoring should examine unusual query patterns, repeated denials, unexpected data volumes, and changes in application behavior.
No independent benchmark currently establishes how much development time the feature saves or how effectively enterprises avoid permission defects. The GA announcement explains the mechanism and recommended practices, but adoption results remain to be demonstrated.
Databricks also has an incentive to make its governance layer the default foundation for internal applications and agents. Buyers should evaluate that strategic benefit alongside portability, integration effort, and the maturity of their existing authorization systems.
The relevant comparison is not a simplistic Databricks-versus-Microsoft contest. Microsoft's delegated identity pattern is mature and broadly applicable across APIs. Databricks is packaging a related principle around its own data, compute, governance, and application runtime.
Google's identity-aware access focuses on controlling access to hosted applications and contextual policies. AWS offers authorization components that developers can combine with identity providers and application resources. Each approach assigns different work to the platform and the application team.
Organizations should compare where policies live, which resources they cover, how identities cross service boundaries, and how denials appear to users. They should also test whether audit records clearly connect an action to both the application and initiating person.
The GA label lowers one adoption barrier, but it does not settle those architectural questions. The feature is most convincing when data governance already resides in Unity Catalog and the application primarily calls supported Databricks services.
Three Signals Will Show Whether the GA Release Delivers
The next test is whether enterprises can adopt user-aware applications without expanding token risk, policy complexity, or platform lock-in.
The first signal is production adoption among internal agents and operational applications. Databricks has described a clear sales-insights scenario, but real deployments will involve more complicated mixes of SQL, models, files, dashboards, and external services.
Evidence of mature adoption would include repeatable architecture patterns, reference implementations, and clear audit workflows. It would also include applications that serve users with meaningfully different permissions without duplicating those rules in code.
Weak adoption would suggest that supported scopes, downstream services, or organizational processes remain too limited. Teams might continue using broadly permitted service principals or separate authorization products despite the GA option.
The second signal is the expansion and refinement of supported API scopes. Narrow scopes make least-privilege design easier because developers can request one capability without receiving unrelated authority.
Broader but coarse scopes would weaken the second permission boundary. More granular scopes, better administrative controls, and clearer consent experiences would strengthen Databricks' claim that apps can act for users without overreaching.
Changes to compliance-profile support also matter. Databricks indicated that user authorization would reach workspaces with the compliance security profile in late September 2026. Customers should confirm availability and limitations in their own environments.
The third signal is how competitors integrate delegated identity into their agent platforms. Microsoft already documents OBO for conventional APIs and newer hosted-agent scenarios. Other platforms are also connecting user identity, tool use, policy engines, and managed application runtimes.
If those alternatives require substantial custom integration, Databricks gains an advantage for applications built around governed enterprise data. If competitors provide equally direct policy inheritance across data and agent tools, buyers will focus more heavily on portability and ecosystem reach.
Developers should watch operational evidence rather than announcement language. Token-handling incidents, confusing consent flows, scope sprawl, and identity fallback bugs would weaken the case. Clear audits and lower authorization maintenance would support it.
The immediate engineering task is straightforward to state, even if it takes discipline to execute. Map every application operation to either the app identity or the current user's identity. Assign the narrowest scope, reject missing credentials, and test with genuinely different users.
Teams should also review existing Unity Catalog permissions before exposing them through an agent. OBO faithfully enforces those permissions, including permissions that are already broader than intended. Delegation cannot improve a weak source policy.
Databricks Apps user authorization is therefore meaningful because it moves identity-aware governance closer to the data and application runtime. It replaces some duplicated permission logic with platform enforcement, while preserving an app identity for shared work.
Its success will depend on whether developers maintain that boundary once applications become complex. Before deploying the next internal assistant, ask one question for every request path: should this operation run as the application, or as the person using it?
