OneLake Shortcuts Are an Authorization Boundary, Not a Storage Convenience — A Security Model for Microsoft Fabric

OneLake shortcuts look like a storage convenience — a pointer that makes data in one location appear in another without copying. That framing is wrong for anyone responsible for access control. A shortcut is a federated identity and authorization construct: it splices two independently governed permission domains together and forces you to reason about which identity reaches the target, which security model enforces the target, and where the two disagree.

This article treats shortcuts as an identity-and-authorization boundary, traces how identity flows across it, and maps where enforcement silently changes hands between OneLake security, SQL security, KQL RBAC, and semantic-model security. It assumes you already know OneLake, lakehouses, the SQL analytics endpoint, Direct Lake, and Entra identities.

What you’ll learn

• Why every shortcut is evaluated at two permission layers, and how most-restrictive-wins actually resolves
• How identity flows to the target under pass-through vs delegated authentication
• The Direct Lake over SQL / T-SQL exception where the caller’s identity is not passed through — verified against current docs
• Which engine enforces which security model, as a data-location → model table
• The concrete failure modes, and the blast radius of each

1. The two-layer permission model

Every shortcut has two paths. The shortcut path is where the shortcut appears (the consumer-side lakehouse); the target path is what it points to. Authorization is evaluated at both, and OneLake applies the most restrictive of the two:

A combination of the permissions in the shortcut path and the target path governs the permissions for shortcuts. When a user accesses a shortcut, the most restrictive permission of the two locations is applied.

That intersection cuts both ways. A user with read+write in the consumer lakehouse but only read at the target cannot write to the target; a user with only read at the shortcut path but read+write at the target also cannot write (Secure and manage OneLake shortcuts). Neither path can grant more than it holds, and neither can rescue a deficiency in the other.

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.

The permission required is not uniform across operations. Note the asymmetry: create and delete accept item Write on the shortcut side, delete needs nothing at the target, but writing through a shortcut demands a ReadWrite-equivalent on both sides.

Matrix source: Secure and manage OneLake shortcuts; cloud-connection binding: OneLake shortcuts. A second, more granular table on the same page frames the shortcut-path requirement for OneLake-security-managed operations as Fabric Read and OneLake security ReadWrite (Create/Update/Delete) or Fabric Read and OneLake security Read for listing shortcuts. When you cite exact permission strings, distinguish the two tables — they describe the same operations at different granularity.

One escape hatch: workspace Admin, Member, and Contributor roles read all shortcut data regardless of OneLake data-access roles — but they still need access on both the shortcut path and the target path. OneLake data-access roles only bind Viewers and item Read-permission users (OneLake security).

2. Authentication models: pass-through vs delegated

Shortcuts use two authentication models, and which one applies depends on shortcut type. Internal OneLake-to-OneLake shortcuts default to pass-through and may opt into delegated; external (multicloud) shortcuts are delegated only (Secure and manage OneLake shortcuts).

Pass-through

The shortcut carries the calling user’s Entra identity to the target:

When a user accesses data from another OneLake location through a shortcut, OneLake uses the identity of the calling user to authorize access to the data. This user must have permissions in the target location to read the data.

Each consumer is evaluated individually against the target. The producer keeps full control and never replicates its access model (OneLake shortcuts). This is the correct model when you want the source system to remain the single source of authorization truth.

Delegated

The shortcut reaches the target using an intermediate credential “such as another user’s identity, a service principal, or an account key” instead of the caller’s (Secure and manage OneLake shortcuts). External shortcuts to S3 or GCS always work this way. For internal shortcuts, delegated must be chosen explicitly at creation time, and switching an existing shortcut between the two modes requires deleting and recreating it — there is no in-place toggle (Create a OneLake shortcut).

Which identities can back a delegated internal shortcut? The security page names another user’s identity, a service principal, or an account key. The Delegated OneLake Shortcuts announcement (a Preview feature) states the configurable connection identity “can be an organizational account, a service principal, or a workspace identity” (Fabric Community). The current Create-shortcut UI walkthrough exposes only Organizational account and Service principal as authentication kinds — treat workspace identity as a rolling/preview addition to verify against the live product. External S3/ADLS connections additionally support credentials such as account keys, with SAS and other secret types documented on the per-source connection pages.

The permission consequence is the crux. Under pass-through, each caller needs their own permission at the target path. Under delegation, the configured connection identity needs target access, not each user; the caller instead sees “the intersection of their security and the security that applies to the delegated identity” (Delegated OneLake shortcuts). Row-level security is enforceable on the producer side of a delegated shortcut but cannot be set on the consumer side; column-level security is supported on both sides.

3. Identity-passthrough exceptions

Pass-through is the default rule, not a universal one. Certain query engines substitute a different identity before reaching the target, and this is where a naive mental model breaks.

The documented exception:

When users access shortcuts through Power BI semantic models using Direct Lake over SQL or T-SQL engines in Delegated identity mode, the calling user’s identity isn’t passed through to the shortcut target. Instead, the calling item’s owner’s identity is passed.

The concrete consequences: the target is accessed with the item owner’s permissions (not the end user’s), OneLake security roles still filter what the end user reads, and “any permissions configured directly at the shortcut target path for the end user are bypassed” (Secure and manage OneLake shortcuts).

Be precise about the trigger. This is not a blanket property of “Direct Lake over SQL.” It is conditional on the SQL analytics endpoint’s access mode. In User identity mode, the endpoint passes the signed-in user’s Entra identity to OneLake and read access is governed by OneLake rules. In Delegated identity mode, the endpoint “connects to OneLake using the identity of the workspace or item owner” — the item account, not the signed-in user (OneLake security for the SQL analytics endpoint). Newly created items with a SQL endpoint start in User identity mode by default, and Admins or Members can change the mode at any time in the endpoint settings. Because the mode is a per-endpoint setting an administrator can flip — and older endpoints may predate that default — treat the current mode as something to verify, not assume.

The security implication is a delegation of the item owner’s reach to every downstream caller. If the owner has broad access at the target and the endpoint is in Delegated mode, the querying user’s own permissions on the target are never consulted — only OneLake security roles filter the result. There is a matching failure in the other direction: in Delegated mode, shortcuts whose source carries OneLake RLS/CLS are blocked entirely through the SQL endpoint rather than silently over-exposed. Microsoft’s remedies are explicit: use Direct Lake over OneLake mode, or set the endpoint to User identity mode. Direct Lake over OneLake reads OneLake directly and preserves the caller’s identity at the target; Direct Lake over SQL inherits whatever mode the endpoint is set to.

4. Security-model boundaries

OneLake security “is the data plane security model for data in OneLake” and enforces consistently across compute engines (OneLake security) — but it is not the enforcing model for every location in Fabric. As James Serra puts it, “OneLake security is not the native security model for every data location in Fabric. Some data stores use SQL security, some use KQL/Kusto RBAC, some use Power BI semantic model security” (jamesserra.com). Which engine enforces which model is the single most consequential thing to get right, because a shortcut can move data across an enforcement boundary without moving the policy.

Sources: OneLake security model (Learn); SQL endpoint modes and Warehouse non-translation (Learn); Kusto RBAC (Learn); Power BI RLS (Learn); Direct Lake (Learn); location → model mapping (jamesserra.com).

Two cross-cutting rules matter. First, rules defined only inside a Direct Lake semantic model apply only within that model’s scope — other engines reading the same data do not honor them, so a user with OneLake access can still retrieve data the model would restrict. Second, engines that cannot enforce OneLake RLS/CLS are blocked from that data rather than served unfiltered rows (OneLake security integrations). Microsoft’s guidance is to enforce data-access rules in OneLake security, since it is the only layer that applies uniformly across engines (Direct Lake security integration).

5. Architecture patterns

The durable pattern is a domain-owned curated lakehouse as producer, with shortcut-only consumer workspaces that hold no copy of the data and no direct grant on the source.

When pass-through is correct

The producer wants each consumer evaluated individually against source authorization, the consumer population is bounded, and every consumer is a resolvable Entra principal in the producer’s tenant. Pass-through keeps the source as the authorization system of record and requires no credential to store or rotate.

When delegated is correct

Fan-out to many consumers, where “when a curated dataset must be served to thousands of downstream users across multiple teams, the data owner becomes responsible for granting and maintaining every individual user’s permission on the source” (Fabric Community). Delegation collapses that N-grant problem to a single connection identity, with the producer defining RLS/CLS at the source and consumers seeing the intersection of their own security and the delegated identity’s. Cross-tenant and multicloud targets force delegation regardless — external shortcuts are delegated-only, and the binding user must hold permission on the cloud connection.

The cross-tenant caution: with delegation you must treat the connection identity as a shared, standing credential whose blast radius is every consumer of the shortcut. Scope it to exactly the source data the shortcut exposes, and enforce differentiation through producer-side OneLake RLS/CLS rather than assuming the delegated identity is narrow.

6. Where this breaks

Source authorization not aligned with OneLake permissions. A shortcut to a Warehouse table inherits none of the Warehouse’s SQL security. “Warehouse SQL RLS/CLS/OLS is enforced in the Warehouse SQL execution context and is not automatically translated into OneLake security policies” (jamesserra.com) — reconfirmed in the Learn docs: when warehouse data is reached through OneLake shortcuts, “these SQL security semantics are not translated into OneLake security policies.” Blast radius: RLS that hid rows in the warehouse silently disappears for anyone reading the shortcut through OneLake or Spark.

Inconsistent enforcement across access paths. The same lakehouse table can enforce OneLake roles through Spark and Direct Lake over OneLake, yet enforce a completely different SQL model through a SQL endpoint in Delegated mode — where “any security rules defined in OneLake … will not apply when the same data is queried through the SQL analytics endpoint” (Learn). A user blocked in one tool sees everything in another. Model-only DAX rules have the same gap: they do not extend beyond the model. Blast radius: the same identity gets different row/column visibility depending on which engine it happens to use.

Shortcuts to unmanaged external targets. An external shortcut may require “source-system authorization plus OneLake security on the shortcut path” (jamesserra.com). If the S3 or ADLS bucket’s own IAM is coarse, the delegated connection inherits that coarseness — and a write through the shortcut can delete target directories in the external account. Blast radius: Fabric-side permissions become a facade over whatever the external ACL actually allows.

Delegated identity over-privilege. The Direct-Lake-over-SQL-in-Delegated-mode exception means the item owner’s identity, not the caller’s, reaches the target, bypassing any target-path grant set for the end user. Blast radius: a broadly privileged owner delegates that breadth to every report consumer, filtered only by whatever OneLake roles happen to exist.

Stale connection credentials. A delegated shortcut is only as trustworthy as its stored connection identity. Because you cannot toggle a shortcut’s auth model in place — it must be deleted and recreated — an over-scoped or unrotated service principal or account key persists as a standing grant behind every consumer until someone rebuilds the shortcut. Blast radius: credential lifetime is decoupled from access reviews; nobody notices the standing grant.

Design checklist

• Enforce at the OneLake layer for lakehouse data — it is the only model that applies across every engine; treat model-only DAX rules as scoping, not security.
• Pin the SQL analytics endpoint’s access mode deliberately. Use User identity mode wherever callers must be evaluated at the shortcut target; know that Delegated mode substitutes the item owner’s identity.
• Prefer Direct Lake over OneLake when caller-identity passthrough at shortcut targets is required; Direct Lake over SQL inherits the endpoint’s mode.
• Choose pass-through for bounded, same-tenant consumers; choose delegated for fan-out, and expect it as mandatory for external / cross-tenant targets.
• Scope every delegated connection identity to least privilege and enforce differentiation with producer-side RLS/CLS; audit that no consumer inherits more than intended.
• Never assume Warehouse or KQL security carries into OneLake — a shortcut crosses the enforcement boundary and drops the source policy.
• Verify both paths on every shortcut — shortcut path and target path — remembering most-restrictive-wins and that Admin/Member/Contributor bypass OneLake data-access roles.
• Track connection-credential lifecycle — rotate secrets, and remember that changing a shortcut’s auth model means delete-and-recreate.
• Treat delegated-shortcut and third-party-engine features as evolving (both are Preview) and re-verify behavior against the live product before relying on it.

References

Verified against Microsoft Learn documentation current as of July 2026 (Secure and manage OneLake shortcuts, last updated 2026-07-23), the Fabric Community announcement of Delegated OneLake Shortcuts (Preview), and James Serra’s overview. Preview features and rolling capabilities should be re-checked against the live product before you rely on them.

1. Secure and manage OneLake shortcuts — Microsoft Fabric (Microsoft Learn)
2. OneLake shortcuts overview — internal shortcuts & cloud connections (Microsoft Learn)
3. OneLake security and Get started with OneLake security (Microsoft Learn)
4. OneLake security for the SQL analytics endpoint — user vs delegated identity mode (Microsoft Learn)
5. Direct Lake and OneLake security integration (Microsoft Learn)
6. Create a OneLake shortcut — authentication kinds (Microsoft Learn)
7. Kusto role-based access control (Microsoft Learn)
8. Row-level security with Power BI semantic models (Microsoft Learn)
9. Simplifying secure data access with Delegated OneLake Shortcuts, Preview (Fabric Community)
10. Understanding Microsoft Fabric OneLake Security — James Serra