DEV Community: Przemysław Kujda

Fabric Apps: Row-Level Security — The Silent Hero

Przemysław Kujda — Tue, 21 Jul 2026 20:55:23 +0000

Row-Level Security: The Silent Hero of Fabric Apps

In my first article, I walked through the "hybrid architecture" for Fabric Apps: a custom React frontend layered on top of native Semantic Models and Power BI visuals, with an AI assistant added on top. The response was great, but it surfaced the one question every enterprise architect asks the moment they see a slick demo: "Okay, but is it secure?"

Here's the uncomfortable truth: a beautiful React dashboard is worthless if it fails a security audit. You can nail every animation, every micro-interaction, every pixel, and still get shut down in week one of a compliance review because a regional sales rep can query global revenue numbers.

This is where Row-Level Security (RLS) comes in. It doesn't get a keynote slot, it doesn't trend on social media, but it's the thing that actually makes a Fabric App enterprise-ready. Let's talk about why.

The Nightmare of Custom Web App Security (The "Old Way")

If you've ever built a custom analytics app from scratch (Node backend, React frontend, some flavor of SQL warehouse), you know the drill. Security isn't a feature, it's a project unto itself:

You build a user-mapping table that ties application logins to business dimensions (region, department, cost center).
You write middleware that intercepts every query and injects a WHERE clause based on that mapping.
You maintain a token/session layer that has to stay perfectly in sync with your identity provider.
You duplicate this filtering logic in every downstream service that touches the data: API, exports, scheduled jobs, the AI chatbot someone added in month six.

The real risk isn't that this is hard to build once. It's that it's hard to keep consistent. Every time someone adds a new endpoint or a new report, they have to remember to re-implement the filter. Miss one spot (a debug endpoint, a CSV export, a cached query) and you've got a data leak. Security logic that lives in application code is security logic that will drift from the source of truth.

The Fabric App Paradigm Shift (Entra ID & Semantic Models)

Fabric Apps flip this model entirely. Instead of building authorization from scratch, you inherit it.

Identity is native. The app runs inside the Microsoft ecosystem, so every user is already a known identity in Microsoft Entra ID. No shadow user table, no custom login flow to maintain.
The frontend stays dumb (on purpose). The React layer doesn't carry any filtering logic. It simply passes the authenticated user's context along when it queries the Semantic Model via Fabric REST APIs, or hits a Lakehouse SQL endpoint directly.
The engine does the enforcing. RLS rules defined once in the Semantic Model are applied server-side, before a single row of data leaves Fabric. The frontend never sees data it isn't entitled to, so there's nothing to accidentally expose.

This gives you what I'd call "one version of the truth, one version of security." The same RLS rule that governs a native Power BI report also governs your custom React dashboard, your export job, and your AI assistant. No duplication, no drift.

A conceptual look at what this means on the frontend. Note there's no filtering logic here, just identity propagation:

// Conceptual: querying a Semantic Model via Fabric REST API
// In a real React app, you'd get the userToken via @azure/msal-react
// The frontend never constructs a WHERE clause, it just forwards identity.

async function queryModel(daxQuery: string, userToken: string) {
  const response = await fetch(
    `https://api.fabric.microsoft.com/v1/workspaces/${workspaceId}/semanticModels/${modelId}/query`,
    {
      method: "POST",
      headers: {
        // Entra ID token identifies the user to the engine.
        // RLS is resolved server-side based on this identity.
        Authorization: `Bearer ${userToken}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ query: daxQuery }),
    }
  );

  // Whatever comes back is ALREADY row-level filtered.
  // The React component just renders it.
  return response.json();
}

Compare that to the "old way" snippet you'd write for a custom backend: a buildFilterClause(user.region, user.department) helper that you'd have to call in every single query path. That function simply doesn't exist here. It can't drift because it was never duplicated in the first place.

Why This Is a Game-Changer for AI Copilots

This matters even more once you bring an AI assistant into the picture, which, if you followed the first article, you already have.

Text-to-SQL and natural-language Q&A features are notoriously risky from a security standpoint. An LLM doesn't inherently know that "show me the highest-paid employee" should be scoped to the analyst's own department. If your AI layer talks directly to raw tables and then summarizes whatever comes back, you've built a very articulate data leak.

With native RLS, the sequencing changes completely:

The AI assistant sends a query (or a generated DAX/SQL statement) to the Semantic Model on behalf of the authenticated user.
The Fabric engine applies RLS first, filtering the result set down to only what that user is entitled to see.
Only the already-filtered, already-safe aggregate is handed to the LLM (Gemini, OpenAI, whatever you're using) for summarization into natural language.

The LLM never touches unfiltered data. It can't leak the CEO's salary to a curious analyst because it never received it in the first place. The security boundary sits below the AI layer, not inside a prompt or a system message you're hoping the model respects. That's a structurally stronger guarantee than anything you'd get from prompt engineering alone.

Conclusion & Call to Action

Put together, this is the real pitch for Fabric Apps: you get to spend your engineering time on product UX (animations, interactions, the AI assistant, the things that make an app feel good to use) without reinventing authorization, and without praying that every query path respects the same filtering rule.

The frontend stays thin. The security model stays centralized. And your audit conversation gets a lot shorter.

I'd love to hear how the community is handling this in other embedded or custom-app scenarios. Are you relying on native RLS, or still bridging gaps with custom middleware? Drop your approach in the comments.

Code for this series (evolving as I go): https://github.com/przemq99/first-fabric-app

What Microsoft Fabric Apps unlocked for me (and why I am writing about it)

Przemysław Kujda — Thu, 16 Jul 2026 13:05:30 +0000

The latest wave of Microsoft Fabric updates made a strong impression on me. Not because of another feature checkbox on a roadmap, but because it became clear that Fabric is no longer "just" a platform for warehouses, pipelines, and notebooks.

It is becoming a place where you can ship real analytical applications that feel like products, not only reports.
That realization is why I decided to write this article, and why I started building my first Fabric App.

This is still an early version of the work. I am learning the surface area of Fabric Apps as I go, and I am sure that with deeper exploration we will be able to build even stronger solutions. Even at this stage, though, the pattern already feels powerful enough to share.

What Fabric Apps give us

For a long time, if you wanted a custom analytics experience (not only Power BI pages, but also your own UI, navigation, workflows, and AI copilots), you often ended up designing a full-stack product:

frontend
backend
authentication
APIs
hosting
permission plumbing

That path still works. It is also heavy.

Fabric Apps change the trade-off.
Because the experience lives on Fabric and can talk to your semantic model (and other Fabric capabilities) through the platform, you can focus much more on the frontend layer: the product surface your users actually touch. You do not need to reinvent an entire backend just to answer a business question.

In practice, that means:

one shared semantic model as the source of truth
the ability to combine native Power BI visuals with custom React interfaces
room for UX patterns that classic report pages do not express well: guided navigation, AI chat, storytelling, interactive showcases

This feels less like "publishing a report" and more like delivering a product: one connected experience, built on a single source of truth, tailored to the business case.

Why this matters for reporting

To make that concrete, here is how I think about the split:

Situation	Recommended surface
Existing Power BI report already works well	Embed native report inside the app
Users need guided navigation or onboarding	Build a custom React page
AI Q&A or conversational interface	Custom page with semantic model queries
Operational briefing for non-analyst users	Custom page with curated KPIs
Ad-hoc exploration by analysts	Native Power BI report

The interesting part is the mix:

where Power BI is already excellent → embed the native report
where the experience needs to feel more like a product → build a custom page
and everywhere → keep both sides connected to the same semantic model

Depending on the business case, you choose the right surface, without splitting the truth across multiple disconnected systems.
That is what excited me most: Fabric Apps make this hybrid model feel natural.

What I built (first version)

I built a multi-page Fabric App around a Sales & Logistics semantic model.
Below is a walkthrough of the modules. I will keep this high-level for now. If useful, I can go deeper on specific capabilities in follow-up posts.

1) Home: the entry point

A launchpad that introduces the experience and routes users into each module.

2) Custom Dashboard: live semantic-model analytics

A custom React dashboard that queries the Fabric semantic model directly:

KPI cards
monthly trends
customer ranking with cross-filtering
logistics views
CSV export
auto-generated "quick insights"

This is the hand-built product UI side of Fabric Apps — a custom React layer querying the semantic model directly via the Fabric REST API, but sharing the same business logic as the native reports. No duplicated measures, no separate data source.

Implementation note: querying the semantic model

const result = await getFabricClient()
  .semanticModel("model")
  .query(dax, { bypassCache: true });

KPIs and charts are driven by live queries against the Fabric semantic model.

3) Native Power BI Reports: chromeless Power BI inside the app

A native Power BI report embedded inside the app (without the usual chrome), with page selection for the pages we want users to see.

This shows the complementary pattern: keep strong Power BI work where it already shines, and deliver it inside the same app shell.

4) AI Assistant: questions against real numbers

An AI analyst that answers questions about KPIs and trends using results computed from the semantic model.
It also adapts to the language of the question (English or Polish).

One design choice that shaped the whole assistant: the AI does not freely generate DAX for every question.

The pattern I used instead:

A set of pre-defined, safe queries covers the core KPIs and trends
The language model receives the computed results (not raw data) and interprets them in natural language
Only for questions outside that scope does the assistant fall back to a templated response

Why does this matter? Letting an LLM generate arbitrary DAX looks impressive in a demo and breaks in production. Computed metrics first, language last — that order makes the assistant actually usable outside a controlled environment.

Implementation note: keeping AI grounded in real numbers

const metrics = await fetchCoreMetrics();
return generateGeminiText({
  userPrompt: buildPrompt(question, metrics),
});

Safe queries first, language model only for the answer.

5) Product Showcase and Visual Lab: what custom UX can feel like

Two showcase pages focused on interaction and visualization (mock data on purpose):

product drill-down panels
animated charts
KPI rings
heatmaps
other custom visuals

These pages are a proof of concept for one idea: the UI ceiling in Fabric Apps is much higher than in classic Power BI. Animated charts, KPI rings, drill-down panels — all of it is standard React, which means you are not limited to what the Power BI visual marketplace offers.

A note on tools (and Cursor)

Even with React experience, building this kind of app still involves a lot of moving parts:

layout and navigation
embedding and tokens
semantic-model querying
UX polish
iteration speed

Cursor made a huge difference.
From shaping the report layout and page structure to implementing features and debugging edge cases, it significantly accelerated the work.
The areas where it helped most: scaffolding the React component structure, debugging token and embedding errors, and iterating on layout without losing context across files.
For me, it is not a replacement for understanding the stack — it is a force multiplier, especially when the platform itself is still evolving fast.

This is only the beginning

Everything above is a first version. The more I dig into Fabric Apps, the clearer it becomes that this is a foundation for richer solutions — still with the same core idea: frontend-first delivery on top of Fabric.

This is still an early build. The next post will go deeper on one specific capability — most likely the semantic model querying pattern from the React side.
If you are exploring Fabric Apps, Power BI embedding, or AI copilots on top of a semantic model — drop a comment. I would love to hear what you are building.

💻 GitHub repository: https://github.com/przemq99/first-fabric-app