# Databricks Apps can now run as the user who signed in

> On-behalf-of-user authorization in Databricks Apps is generally available, so Unity Catalog grants govern what each signed-in user sees.

By Tyler Harker, 7 October 2026. Databricks Field Guide, TechFabric. Canonical: https://databricks.techfabric.com/notes/databricks-apps-can-now-run-as-the-user/

Databricks announced on 7 October 2026 that on-behalf-of-user authorization in Databricks Apps is [generally available](https://www.databricks.com/blog/now-ga-building-permission-aware-databricks-apps-behalf-user-authorization). An app can now call supported Databricks APIs using the identity of the person signed into it, so Unity Catalog enforces that user's own permissions, including row filters and column masks, and API scopes bound what the app is allowed to do on their behalf.

## The permission model stops being copied into app code

The pattern this replaces is familiar to anyone who has shipped an internal tool on a data platform. The app connects as a service principal with wide read access, and the developer then writes a second layer of filtering in Python or in a WHERE clause to decide which rows this particular person should see. Two permission models, one of them maintained by a governance team and one of them maintained by whoever last touched the app. They drift, and the drift is invisible until someone sees a number they should not have seen.

With OBO the grants in Unity Catalog are the grants the app obeys. A sales-insights assistant answers using only the accounts and fields that salesperson is authorized to access, and the app never needs broad SQL or workspace-administration capability to do it. The service principal does not disappear: Databricks keeps app authorization for app-owned work such as reading shared configuration or writing application metrics, and the guidance is to keep those two clients separate inside the app.

## Two limits, and they are not the same limit

The source is precise about which control does what. API scopes limit the operations the app can perform on the user's behalf. The user's warehouse and Unity Catalog permissions limit which data it can reach. Scope down to the narrowest scope that matches the job, configure it explicitly on the app, and let workspace administrators set the upper boundary over the top.

The operational rules are short enough to put in a review checklist. Use the forwarded token only for the active request. Fail closed when the token is missing. Never store user tokens. That last one is the rule teams break first, usually because someone wants a background job to run as the person who scheduled it.

```mermaid flowchart LR Request path under on-behalf-of-user authorization
flowchart LR
  A["Signed in user"] --> B["Databricks App"]
  B --> C["User client with forwarded token"]
  B --> D["App service principal"]
  C --> E["Unity Catalog enforces user grants"]
  D --> F["App owned config and metrics"]
```

> **Our position**: If you have a Databricks App filtering rows in application code, move that filtering into Unity Catalog grants and switch the data path to OBO. The same pattern applies to agents, so an agent you build this quarter should inherit the caller's permissions from day one instead of being retrofitted later.

## What this changes for agents

Databricks says the same pattern applies to agents, which matters more than the apps story on its own. An agent that queries governed tables on a user's behalf has exactly the problem an app has, with the added difficulty that its query is generated rather than written. Telling a model what not to reveal is not a control. Running its queries under the asker's identity is. The [Databricks Apps](https://databricks.techfabric.com/guide/databricks-apps/) and [Agents](https://databricks.techfabric.com/guide/agents/) chapters both assume that boundary, and this release makes it the supported default rather than something you argue for.

## Questions people ask

### What is on-behalf-of-user authorization in Databricks Apps?

It lets a Databricks App call supported Databricks APIs using the identity of the signed-in user, so Unity Catalog enforces that user's data permissions, including row filters and column masks. API scopes separately limit which operations the app can perform on the user's behalf.

### Is on-behalf-of-user authorization generally available?

Yes. Databricks announced general availability on 7 October 2026.

### Can a Databricks App still use its own service principal?

Yes. Apps keep a dedicated service principal for app-owned operations such as reading shared configuration or writing application metrics, and Databricks recommends keeping the app client and the user client separate.