Database security and tenant isolation
Treat policies as code to verify, not as proof of safety.
Server-side authorization comes first
The V1 runtime uses a restricted, server-only database login. Controllers verify the caller and enforce access rules. MasterRecord carries the verified identity inside a request-local transaction. Row Level Security adds a database boundary; it does not replace controller checks.
Management tokens, database passwords and service-role keys must never enter generated browser bundles, public environment variables, source exports or logs. Public Auth configuration is different from a privileged server credential.
Automated gates and their limits
The new database gate inspects the live PostgreSQL catalog for missing RLS and known overly permissive policies. Source and artifact scanning looks for privileged credentials. These checks can reject known problems; they cannot prove that every business rule or policy is correct.
This gate is part of the managed V1 rollout. The existing source security check alone is not a live database audit.
Test with two users before release
Create Alice and Bob plus an unauthenticated session. For each tenant-owned table, verify Alice can create and read her records, Bob cannot read or change them, anonymous requests are denied, and Alice cannot submit Bob's owner ID to create a record for him. Repeat for update and delete, and run concurrent requests to check identities cannot leak between transactions.
Use real Auth tokens against the running backend. Save the expected result and actual response for each test. A passing compile or a frozen prototype review cannot establish this isolation.