Trust model

sprig’s security argument rests on three identities with sharply bounded rights. Nothing in the system holds broad power; every capability is scoped to the smallest surface that makes the product work.

The three identities

1. Builders — Entra only, zero Azure

Builders authenticate to the platform with their normal Entra account (device-code flow against a dedicated public client). They hold no Azure RBAC roles, no service principals, no secrets. They cannot create, modify or even see Azure resources. Everything that happens in Azure happens because the platform did it on their behalf, inside their sandbox, with an audit record naming them.

2. The platform — a managed identity with deliberately narrow rights

The publish API runs as a user-assigned managed identity. Its entire permission set:

• Contributor on each builder’s resource group only — granted one resource group at a time, at onboarding. It holds no subscription-scope role. If it were compromised, it could touch builder sandboxes and nothing else.
• Application.ReadWrite.OwnedBy on Microsoft Graph — the constrained variant: it can only manage app registrations it created itself. It cannot read or modify any other application in your tenant.
• Table-data access on its own metadata store.

There is no deployment credential on builder machines, no shared secret in the plugin, and no standing credential with data access anywhere in the system.

3. Published apps — one registration each, locked to the owner

Every published app gets its own Entra app registration with assignment required enabled. Until Ops approves a share, exactly one person can open the app. App client secrets (used only by the static web app’s built-in auth) live in that app’s settings — never in metadata, never on builder machines.

Why this shape

• The agent can’t outrun the user. Claude drives publishes, but the platform authorizes every call against the builder’s Entra identity, and the blast radius is the builder’s own resource group — which Azure Policy pins to static web apps only.
• No copies of data, anywhere. See Data access: apps read data as the viewer, so sharing an app can never leak data beyond what each viewer could already query themselves.
• Everything attributable. Every resource carries provenance tags (owner, app, timestamp); every platform operation writes an audit event naming the actor.

What we ask you to trust, explicitly

1. The installer, which runs once under your Ops account and supports a preview mode showing everything it will create (exact list).
2. The platform code deployed into your subscription — reviewable before deployment; you build and deploy it from source.
3. Microsoft Entra, Azure RBAC and Fabric permissions — the same primitives the rest of your estate already relies on.