Governance & audit

Sharing goes through Ops

A builder’s app is visible to the builder alone until they request sharing with an Entra group. Ask Claude, in either role: “share this with the claims team” / “anything waiting for me?”. The request lands in a queue owned by your Ops team. On approval, the platform adds the group as a member of the app’s viewers group: no redeploy, no config change; on rejection, nothing changes. Either way the decision is recorded: who asked, for which app, which group, who decided, when.

For a db-delegated source (the default, and the only mode Azure SQL Database supports), data access rides on the viewer’s own identity all the way to the database. For a gateway-enforced source (currently only Fabric Warehouse and lakehouse sources), a service identity reads the source instead, and the gateway and the data API’s own policies do the per-viewer filtering above it; see Data access for what that split means. Either way, this approval governs who can open the app, not who can see data: the data question is already answered by the source’s own permissions, or the data API’s policies for a gateway-enforced source, and the groups Ops mapped when exposing it. That’s what keeps the queue small and the decision simple: Alex sees exactly which data sources the app reads before deciding.

Provenance on every resource

Everything the platform creates is attributable: publishes, provisioning, and source exposure all record the acting identity and the app or source they touched in the metadata store. An operator can answer “what is this, and whose is it” without opening a ticket.

The audit trail

Platform mutations write an immutable attempt record before the operation and an immutable succeeded or failed outcome record afterwards. This covers publishes, source registration and exposure, share requests, approvals, rejections, and builder onboarding. If an outcome record is missing, the admin console shows the operation as Incomplete.

Reading or exporting either audit view is itself audited. The view or export fails closed if its own access record cannot be persisted.

Data-access audit is availability-first. Data requests continue when audit recording is unavailable, so individual access rows can be missed. After recovery, detected queue or write gaps appear as gap records in the admin console. A process failure can also lose a pending gap marker before it is persisted. A stronger fail-closed option is tracked in #433 feat(gateway): add a fail-closed data-access audit mode.

Use the admin console’s Audit pages to filter, inspect, and export the retained product audit records.

Spend control

• The installer creates a subscription budget with notification thresholds (80% / 100%) to addresses you choose.
• The platform’s cost is flat regardless of app count: one always-warm gateway and one shared data layer, not a resource per app. Apps that provision their own database add a small serverless Azure SQL cost that auto-pauses when idle.

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