Whose Identity Reaches the Target? OneLake Shortcut Security
Most conversations about OneLake shortcuts are about storage: no copies, less pipeline code. For anyone accountable for access control, that framing misses the point. A shortcut joins two separately governed permission domains, and every read through it answers a question nobody wrote down: whose identity reaches the target, and which security model judges it? Get that wrong and row-level security you carefully defined at the source is either bypassed or blocks the report everyone depends on.
I’ve covered the operational side before: treating shortcuts as dependencies you inventory and handing features to AI teams without over-sharing. This post is the security model underneath both, updated for where Fabric stands at the end of July 2026. Microsoft said at FabCon 2026 in March that OneLake security would reach general availability within weeks. It went GA in April, with the automatic rollout to supported items finishing by the end of May, and delegated OneLake-to-OneLake shortcuts are now in preview.
Two paths, most restrictive wins
Every shortcut has a shortcut path (where it appears, usually the consumer’s lakehouse) and a target path (what it points to). OneLake evaluates both and applies the more restrictive result. A user with read and write in the consumer lakehouse but only read at the target can’t write through the shortcut; a user with read-only on the consumer side can’t write either, even with full rights at the target (Secure and manage OneLake shortcuts).
effective(user, shortcut) = min(
onelake_perm(user, shortcut.path), # layer 1 — where the shortcut lives
onelake_perm(user, shortcut.target) # layer 2 — what it points to
)
# write requires ReadWrite on BOTH sides;
# a Read-only target caps the result at Read, whatever the shortcut path grants.
| Operation | Shortcut path | Target path | Notes |
|---|---|---|---|
| Create shortcut | Item Write or OneLake security ReadWrite | OneLake security Read (ReadAll for items without OneLake security) | Internal: caller needs Read at the target. External (S3/ADLS): target read is delegated via a cloud connection — only a user with permission on the connection can bind it. |
| Delete shortcut | Item Write or OneLake security ReadWrite | N/A | Deleting the shortcut object does not touch the target. A write/delete through the shortcut is a different operation and can delete target data. |
| Read through shortcut | OneLake security Read | OneLake security Read | Both sides. External reads via Spark/API also require Read on the item holding the shortcut path. |
| Write through shortcut | Item Write or OneLake security ReadWrite | Item Write or OneLake security ReadWrite | Both sides. For external targets this is gated on write permission in the external system, not blocked categorically. |
Two details matter more than they look. Deleting the shortcut never touches the target, but deleting a folder inside the shortcut deletes it at the target if you have write permission there, including in an external ADLS or S3 account.
The second detail is about who the roles bind. If your restricted consumers are Contributors in the producer workspace, OneLake roles won’t contain them. The roles bind Viewers and people the item was shared with; Admins, Members and Contributors read through Spark and direct OneLake access unfiltered. The main exception is a SQL analytics endpoint in user identity mode, which applies OneLake RLS to every caller, and even unfiltered, those roles still need access on both the shortcut and target paths. Restricted readers belong in the Viewer role or on item sharing.
Passthrough and delegated: the identity decision
Shortcuts authenticate one of two ways, and the type of shortcut decides which options you have. Same-tenant OneLake-to-OneLake shortcuts default to passthrough and can now opt into delegated (preview). Cross-tenant OneLake shortcuts (also preview) are always delegated, through a connection identity in the producer’s tenant. External shortcuts to ADLS, S3, GCS and the rest are always delegated too, through the cloud connection’s credential.
Passthrough carries the caller’s Entra identity to the target. Each consumer is evaluated against the source’s rules, and there’s no credential to store or rotate. The cost is that the producer must grant every consumer, or every consumer group, read at the target.
Delegated reaches the target with an intermediate credential: an organisational account or service principal on a connection, or a key for some external sources. The Delegated OneLake Shortcuts preview brings this to internal shortcuts. The caller sees the intersection of their own OneLake security on the consumer side and whatever the delegated identity can see at the producer. The security rules split by side:
- Column-level security works on both the producer and consumer side.
- Row-level security can only be set on the producer side.
- If the producer has RLS, each consumer can sit in only one CLS role on the consumer side.
Two constraints shape how I’d use it. You choose the model when you create the shortcut, and switching later means deleting and recreating it. And the connection identity becomes a standing grant whose blast radius is every consumer of every shortcut that uses it.
The exception that breaks the mental model
Passthrough is the default rule, not a universal one. The shortcut security page buries this in a footnote: when shortcut data is read through Power BI semantic models using Direct Lake over SQL, or through T-SQL engines in delegated identity mode, the caller’s identity is not passed to the target. The engine reads with the item owner’s identity, then applies OneLake security roles to filter what the caller sees. Any permission set for the end user directly at the target path is bypassed.
Through Direct Lake over SQL, and through T-SQL in delegated identity mode, the querying user’s own permissions on the shortcut target are never consulted: the item owner’s identity reaches the data and only OneLake security roles filter the result. Use user identity mode for T-SQL, and Direct Lake on OneLake for semantic models, when callers must be evaluated at the target.
Those are two separate triggers, and it’s worth being exact about each.
The SQL analytics endpoint access mode
Every SQL analytics endpoint runs in one of two modes (OneLake security for SQL analytics endpoints):
| Aspect | User identity mode | Delegated identity mode |
|---|---|---|
| Identity used against OneLake | The signed-in user | The workspace or item owner |
| Table access governed by | OneLake security roles | SQL GRANT/REVOKE only |
| RLS and CLS defined in | OneLake security roles | SQL security policies and column grants |
| Dynamic data masking | Not supported | Supported |
| Shortcuts to tables with OneLake RLS or CLS | Work, evaluated as the caller on both sides | Blocked |
New SQL analytics endpoints start in delegated identity mode, and an Admin or Member has to switch each one to user identity mode once before OneLake security roles apply. The switch briefly takes every SQL analytics endpoint in the workspace offline and cancels running queries. In user identity mode, table-level GRANT/REVOKE is ignored and SQL RLS and CLS on tables no longer govern access. User identity mode is an action you take on every endpoint, not a default you inherit.
Delegated mode fails closed for shortcuts: if the source table has OneLake RLS or CLS, the endpoint blocks the shortcut rather than serving unfiltered rows through the owner’s identity. For source tables without OneLake rules, though, the owner’s reach is what every SQL user inherits, governed only by whatever SQL grants exist in the consumer endpoint.
Direct Lake over SQL
The owner-identity behaviour here isn’t a side effect of the endpoint’s mode. The Direct Lake security integration docs describe it directly: Direct Lake first checks that the effective identity (the user under SSO, or a fixed identity on the connection) can access the table through the SQL endpoint, then, for internal shortcuts, reads the Delta table through the shortcut with the data source owner’s identity. For external shortcuts the owner also needs Use permission on the cloud connection. So the owner’s access at the target is the ceiling for every report reader.
There’s a second cost. Once the endpoint is in user identity mode, OneLake security roles become SQL access rules and Direct Lake on SQL falls back to DirectQuery for every query, so each read goes through the SQL endpoint and you lose Direct Lake performance. Any query touching a table with SQL endpoint RLS, or a view, falls back too. That is a second reason to move semantic models to Direct Lake on OneLake.
Direct Lake on OneLake behaves differently. It skips the SQL endpoint, resolves OneLake security roles for the effective identity, and for an internal shortcut requires that identity to have read at the target. If you need caller identity honoured at the shortcut target in a semantic model, Direct Lake on OneLake (GA since FabCon 2026 in March) is the option that does it.
Which engine enforces what
OneLake security is the data-plane model for lakehouses and mirrored items, enforced across Spark, the SQL endpoint in user identity mode, and Direct Lake on OneLake. It isn’t the native model everywhere, and shortcuts move data across those borders without moving the policy.
| Data location / access path | Enforcing security model | Notes |
|---|---|---|
 Lakehouse via Spark |
OneLake security roles, RLS/CLS filtered | Roles bind Viewers / Read-permission users, not Admin/Member/Contributor. |
| Direct OneLake API or file access |
OneLake security roles | Tables with RLS/CLS are blocked rather than served unfiltered. |
| Lakehouse via SQL endpoint, user identity mode |
OneLake security roles | Enforces OneLake roles natively and ignores table GRANT/REVOKE. |
| Lakehouse via SQL endpoint, delegated identity mode |
SQL permissions only | Governs by SQL alone and does not carry OneLake roles for table data; shortcuts to tables with OneLake RLS or CLS are blocked. |
 Warehouse |
SQL security, within the SQL engine only | Enforced only within the SQL/TDS execution context; not translated into OneLake policies. Warehouse is not among the items that support OneLake security roles. |
 Direct Lake on SQL |
SQL endpoint permissions, then owner identity at shortcut targets | Internal shortcut targets are read with the data source owner's identity whatever the endpoint mode; falls back to DirectQuery under SQL endpoint RLS, views, or user identity mode. |
| Direct Lake on OneLake |
OneLake security roles, then the model's own roles | Resolves OneLake roles for the effective identity, which needs Read at internal shortcut targets; errors instead of falling back to DirectQuery. |
Two rules fall out of that table.
First, warehouse security doesn’t travel. Warehouse RLS, CLS and object permissions live in the SQL engine’s execution context, and nothing translates them into OneLake roles. A shortcut reads the Delta files underneath, so I assume a reader through a shortcut sees the full table unless OneLake itself restricts it. Secure that data in a lakehouse with OneLake security, or keep consumers on the warehouse’s SQL surface. Lakehouses, mirrored databases and Azure Databricks mirrored catalogs support OneLake security roles; Eventhouse support (RLS only) arrived in preview at FabCon 2026; Warehouse does not yet.
Second, rules defined only inside a semantic model stay inside that model. Anyone with OneLake access can read the same data through Spark and skip them. Engines that can’t enforce OneLake RLS or CLS are blocked rather than handed unfiltered rows. That’s the right default, but it shows up as a failing third-party query.
Where it goes wrong
- Same user, different rows. A table enforces OneLake roles in Spark, but a consumer endpoint left in delegated mode applies only SQL grants. The user blocked in a notebook sees everything in SSMS. Standardise on user identity mode unless you need SQL-only features like dynamic data masking, and accept that any Direct Lake on SQL models over that endpoint will then run as DirectQuery.
- An over-privileged owner behind Direct Lake over SQL. The lakehouse owner is a platform admin with broad reach, so every Direct Lake over SQL report inherits that reach at shortcut targets, filtered only by OneLake roles that may not exist. Own items with scoped identities, or use Direct Lake on OneLake.
- External targets with coarse IAM. A delegated connection to an ADLS account is only as narrow as that account’s own permissions, and a delete through the shortcut deletes in the external account. Scope the connection credential to the exact container or prefix.
- Standing connection credentials. Delegated shortcuts decouple credential lifetime from access reviews. Track connections as first-class assets with owners and rotation dates.
- Group mismatch across the boundary. Until late July 2026 the docs required the exact group named in the producer role to hold Fabric Read on the consumer, because nested membership wasn’t resolved, and queries failed closed with an access error. The SQL endpoint page now says effective group membership is evaluated, but the troubleshooting guide still describes the literal-match rule, so I’d still grant the same groups on both sides and test with a nested member before relying on it.
How I’d decide
My default for same-tenant consumers is passthrough, with OneLake security roles on the producer lakehouse assigned to Entra groups, SQL endpoints pinned to user identity mode, and semantic models on Direct Lake on OneLake, because user identity mode pushes Direct Lake on SQL models into DirectQuery anyway. The safest discipline is granting Fabric Read on each consumer item to the exact groups named in the producer’s roles, not to their members or parent groups. That keeps one authorisation system of record and evaluates every reader as themselves.
I’d reach for delegated shortcuts when the grant count is the real problem: a curated dataset served to many teams who should manage their own readers, or a cross-tenant source where passthrough isn’t an option. In those cases, scope the connection identity to exactly what the shortcut exposes, put RLS on the producer side because the consumer side can’t hold it, and remember delegated OneLake shortcuts, same-tenant and cross-tenant, are still in preview, so I’d pilot it before it fronts anything sensitive.
When not to bother with any of this: one team producing and consuming in the same workspace, with Contributors on both sides. Workspace roles already decide everything there, and OneLake roles would only add sync lag and configuration to maintain. The model above earns its keep the moment the producer and the reader are different people.