Data access
The principle
Section titled “The principle”A published app never contains data. It contains code that fetches data at view time, authenticated as the person viewing — not as the builder, not as a service account, not as the platform.
This one decision does most of sprig’s security work:
- Sharing an app shares nothing. When Ops approves sharing with a team, team members can open the app — but each of them sees only what their own Microsoft Fabric permissions return. An analyst with row-level security scoped to one region sees one region.
- Revocation keeps working. Remove someone’s Fabric access and every sprig app goes dark for them instantly — there is no cached copy, no snapshot, no export to chase.
- No new data governance surface. Your existing Entra + Fabric permission model is the data authorization layer. sprig adds no parallel ACL system to maintain or audit.
How it works technically
Section titled “How it works technically”The generated frontend uses the app’s own Entra registration to acquire a delegated token for the signed-in viewer (standard authorization-code flow with PKCE in the browser), then calls Microsoft Fabric’s API for GraphQL directly. The security boundary is the bearer token plus the Fabric item and workspace permissions — the same boundary Microsoft documents for first-party applications.
Notably, there is no middle tier: no sprig service sits between the browser and Fabric, so there is nothing to compromise that could see everyone’s data. (A gateway becomes part of the roadmap only for sources that structurally require a confidential client — and it will hold delegated scopes only, never standing data access.)
What builders must have — and viewers must have
Section titled “What builders must have — and viewers must have”- The builder needs Run Queries and Mutations on the Fabric GraphQL API item they build against, plus normal read access to the underlying data — granted by your data team through Fabric, not by sprig.
- Each viewer needs their own Fabric access to whatever the app queries. No access → empty results. This is the designed behaviour: an app can never be a way around your data permissions.
What sprig refuses to do
Section titled “What sprig refuses to do”The publish tooling rejects apps that would deploy without authentication, and the builder-facing skills are instructed never to bake query results into artifacts. The honest limitation: a determined builder could still hand-paste data into HTML — the same way they could paste it into an email. What sprig removes is the systemic pattern where copying data is the only way to share an app.