Make the dataset a reviewed product
A data product gives an application a defined interface to a dataset. Its fields and source capabilities are the starting point for a request. The data owner can review what the app needs without giving the builder an unrestricted source credential.
The route is source, data product, application identity, approved grant, gateway and result. Source credentials stay on the server. The app uses its own identity to ask for a product in its environment.
- Define the dataset and permitted fields.
- Request access for a named app and environment.
- Approve a scope before the app uses the gateway.
Review the permission, not just the connection
A connection says where data lives. A grant says what this application may use. Review requested fields, row scope, maximum rows, query rate and expiry together with the business purpose.
For a synthetic queue dashboard, approve team, region, open cases and overdue cases. Exclude personal contact details that the dashboard does not need. Keep the app's data classification and intended audience consistent with the approved result.
Check each query against the grant
The data-product gateway checks the active grant and approved fields, validates the query plan against source capabilities, executes it and scrubs the result. Row ceilings, query rate and configured masking are part of that path.
Natural-language queries require a configured planner. Available operations depend on the source adapter and product definition. Validate allowed and denied fields, row scope, masking and limits on the source you plan to use rather than assuming every connector behaves identically.
Data-product grants and connector grants are different paths. A connector grant may inject approved credentials into an app runtime; it is not the same as field- and row-scoped gateway enforcement.
Change future access without a redeploy
A data owner can revoke a grant. The gateway checks grant status and expiry on subsequent requests, so future access can stop while the app's deployed release stays the same.
Revocation does not retrieve data the app already read, exported or stored. Plan application retention and caching separately. Test a request before and after revoke or expiry, including the app's response to a denied request.
Start with one source and a clear acceptance check
Choose one dataset and a narrow read-only use case first. Confirm the source setup, planner configuration and supported query operations with your workspace administrator. Then use synthetic records to verify the precise grant you intend to issue.
An adapter in a registry is implementation evidence, not proof that a source is ready in your service environment. Discuss the required source and query pattern so the setup and acceptance checks can be specific.
- Allowed fields return only the intended result.
- Excluded fields and out-of-scope rows are denied.
- Expiry, revoke and rate limits are handled by the app.
- No source password or token is exposed in browser content.