Building on exposed data

Corporate data reaches your app through data Ops has exposed: an existing Azure SQL Database that Ops has registered and selected tables from, read-only by default, with sensitive columns hidden before you ever see them. Ask Claude for an app “using data from …” and it works from what’s actually been exposed to you:

1. Discover. Claude calls list_sources and describe_source to see what’s exposed to your groups: which sources, which entities, their served API names and paths, and which fields are readable. It follows the linked REST OpenAPI or GraphQL schema resource when it needs the full protocol contract. Excluded columns do not appear in any of these results.
2. Query. The app you’re building queries the gateway’s data endpoint (/data/graphql or REST, same-origin) under your own identity while it’s still a draft, the same call path the published app uses for viewers later, so nothing behaves differently once it ships.
3. Generate. Claude writes the frontend to call that endpoint directly. Paged grids fetch page-by-page; charts aggregate server-side where the API supports it.

Nothing you need is browser-direct to a source: every read goes through the gateway and the shared data layer (Data API builder), on your behalf, whether you’re mid-build or the app is live.

If nothing shows up in list_sources, that’s not a bug: it means Ops hasn’t exposed anything to your groups yet. Ask them; see Expose an existing database for what that looks like on their side.

Honest gap: no conversational query tool yet

There’s no query_records/try this filter loop today - Claude works from describe_source and its linked API schemas rather than running sample queries against the source before writing code. In practice this means Claude writes the query directly into the app and you see results once it runs, rather than iterating on a query in chat first. A dedicated data-exploration tool is planned but not built.

The rules that hold regardless

• No data in artifacts. Claude won’t put query results directly into a document or message as a substitute for building the app against live data - your teammates should only ever see what their own permissions allow, computed at the time they look.
• Viewer identity by default. For a db-delegated source (the default, and the only mode Azure SQL Database supports), there are no service accounts to request and no secrets to manage - every read is attributed to the real, signed-in caller (on-behalf-of), all the way to the source. A source can instead be gateway-enforced (currently only Fabric Warehouse / lakehouse sources): a service identity reads it and sprig filters per viewer above the source, an explicit, audited exception rather than a default.
• Read-only by default. Ops exposes tables read-only unless they deliberately choose otherwise; write access to an exposed source is not part of the pilot.
• A published app needs its own grant. Your own group membership carries your session, but a published app presents its own group per source. Ask for access when the app is provisioned (“using data from …”) or request it later; the request waits for Ops approval unless the source auto-approves. See App access to sources for the whole workflow and what each status means.

Limits worth knowing

See Limits for what’s currently known about publish and app-name constraints. Source-side query limits (page sizes, response caps) depend on which engine Ops exposed: Azure SQL family limits apply; there isn’t yet a sprig-specific ceiling on top of the source’s own.

“Why is my grid empty?”

Because you (or the viewer looking at it) aren’t in a group Ops mapped to that entity, or a row-level rule is filtering rows to their own. That’s the product working, not a bug: ask Ops to check who’s mapped to the source, and the app fills in on the next query, no republish needed.