Aller au contenu principal

End-user data isolation

A shared physical database is supported. Dataira authorizes the subject first, then constrains every query, API call, saved result, and asset operation to that subject. An end user cannot select or widen these constraints from the browser, chat prompt, SQL, or tool arguments.

Enforced boundary​

  1. Your backend authenticates the user and derives the stable endUserId, endUserOrgId, datasource allowlist, roles, and customer attributes.
  2. Dataira locks that five-part membership and signs a short-lived token carrying policy identity and authorization generations, not mutable policy rules.
  3. SQL execution requires a row rule for every referenced table occurrence, injects the resolved customer predicate, and parses the final statement to verify aliases, joins, branches, and permitted columns. Unknown or unsupported shapes fail without executing.
  4. OpenAPI execution accepts only approved operations. Customer parameters come from verified identity or policy bindings; browser and model arguments cannot replace them.
  5. Authorization and datasource/schema generations are checked before and after execution and again before finite, streamed, cached, or historical evidence is released. Revocation makes stale work unreachable.

Use defaultColumnAction: "deny" and explicitly allow safe columns for the strongest policy. A table without a matching row rule is not queryable.

Trusted edge​

Dataira cannot infer which account in your product owns an authenticated user. Your backend is the identity authority and must derive customer attributes from its trusted session or database. Never accept endUserId, organization, role, policy, datasource, or customer scope directly from an untrusted request body.

Database-native RLS​

Dataira's governed policy is mandatory. Database-native row-level security (RLS), security-barrier views, or per-customer credentials are an independent second boundary and are recommended for sensitive shared PostgreSQL deployments. Dataira does not install partner database policies or automatically configure a per-request PostgreSQL RLS session in the current preview. Always use a read-only connector role even when native RLS is not available.

Required launch test​

Create fixtures for users A and B in the same datasource and prove all of these:

  • A receives A's rows and never B's rows; B receives only B's rows.
  • Swapping browser IDs, datasource IDs, policy values, or API parameters fails.
  • Aliases, joins, saved results, exports, dashboards, and chat preserve isolation.
  • Revoking A during a request prevents the pending response and future requests.
  • OpenAPI identity and policy bindings cannot be supplied as model arguments.

Run this test against the exact production schema and policy. Preview availability does not replace a partner-specific conformance test or security review.