Governance & audit

Sharing goes through Ops

A builder’s app is visible to the builder alone until they request sharing with an Entra group. The request lands in a queue owned by your Ops team (visible via the platform API or the ops tooling). On approval, the platform assigns the group to the app’s Entra registration; on rejection, nothing changes. Either way the decision is recorded — who asked, for which app, which group, who decided, when.

Because data access rides on viewer identity, this approval governs who can open the app, not who can see data — the data question is already answered by your Fabric permissions. That’s what keeps the queue small and the decision simple.

Provenance on every resource

Everything the platform creates is tagged: owning builder, app name, managed-by-sprig marker. An operator can answer “what is this resource and whose is it” from the Azure portal without opening a ticket. Orphaned-resource sweeps and chargeback reports fall out of the same tags.

The audit trail

Every platform operation appends an event to the metadata store: publishes (create and update), deployment-token issuance, share requests, approvals, rejections — each with the acting identity and timestamp. The store is a plain Azure Table in your subscription: queryable, exportable, retained on your terms.

Spend control

• The installer creates a subscription budget with notification thresholds (80% / 100%) to addresses you choose.
• Published apps run on Static Web Apps — flat-rate resources with no runaway-compute failure mode.
• For Fabric capacity protection, we recommend enabling workspace-level surge protection on the capacity that backs vibe-coded apps, so a badly written query loop cannot starve production workloads. Guidance is included in the install runbook.

Azure budgets alert rather than enforce; hard enforcement automation (deallocate on threshold) is on the roadmap and is honestly labelled as such.