How it works
The actors
Section titled “The actors”| Actor | What they touch | What they need |
|---|---|---|
| Builder | Claude (claude.ai connector, Claude Code, or Desktop) | An Entra account and no Azure access. A Claude tenant administrator uploads the release-matched Builder skills from Admin > Setup > Skills. |
| Viewer | Published app URLs | An Entra account and their existing data permissions. |
| Ops | Installer, source exposure, share approvals | Subscription Owner + Entra admin rights, once, at install. |
| Platform | Publishing, app access, and authorized data access | A managed identity and a handful of narrowly scoped Entra app registrations. |
The publish flow
Section titled “The publish flow”- Build. A builder describes an app in a Claude session. Claude writes a self-contained SPA, calling exposed data through the gateway as it goes.
- “Share this solution.” Claude makes the small
begin_publishandcomplete_publishcontrol calls over the gateway’s MCP server, authenticated as the builder. A bundled helper sends both archives in resumable 4 MiB blocks throughtransfer.apps.<yourdomain>with short-lived transfer tokens. Storage-account hostnames and credentials are never exposed to the client. Neither archive is base64 inside an MCP request. No separate sign-in step is needed; the connector or Claude Code already holds the builder’s token. - Store and flip. The platform verifies both archives, durably retains the source next to the new immutable bundle version, and flips the app’s active-version pointer: there’s no per-app Azure resource and no per-app Entra registration to create. The same always-warm gateway that served every other app now serves this one too. Because the source is retained per version, the builder can resume the app from any retained version in a later session.
- Live. The app runs at
<app>.apps.<yourdomain>, behind the gateway’s own sign-in. Only the owner can open it; anyone else is blocked before the gateway serves a single byte. - Share. The builder asks to share with a team (an Entra group). The request waits in the Ops queue; on approval, the group is added to the app’s viewers, no redeploy. Viewers still only see data their own permissions allow.
Data at build time and view time
Section titled “Data at build time and view time”Apps read data through the gateway’s data proxy, which forwards to a shared Data API builder instance in front of the source Ops exposed, the same path whether the app is still a draft or fully published. For a db-delegated source (the default), the proxy validates the caller’s token and passes it through so the database itself authenticates the real, signed-in caller (on-behalf-of); row-level security and revocation keep working because every query runs as the person actually asking. For a gateway-enforced source (currently only Fabric Warehouse and lakehouse sources), a service identity authenticates instead, and the per-viewer filtering happens at the gateway/data-API layer, an explicit and audited exception rather than a default. Either way, sprig doesn’t store or cache the data it proxies. Details: Data access.
What Ops installed, once
Section titled “What Ops installed, once”One platform resource group containing the application runtime, operational state, monitoring, and a subscription budget. The signed release is first copied into an ACR in your subscription, then all runtime pulls stay within your Azure environment. Operator control access is internet reachable, protected by Entra authentication, and restricted to the Ops role. The install is previewable and idempotent. See Install.