All packsMulti-Tenant Auth & RBAC CoreSolve
postgres row level security silently disabled table owner
RLS does not bind the table owner -- and managed hosts default to it
Neon and Railway both hand you an owner connection string by default, and row-level security does not bind the table owner -- so RLS is silently a no-op.
What goes wrong
Postgres row-level security has one hard exception: the table owner bypasses it, always, regardless of any ENABLE or FORCE setting -- unless you specifically FORCE it and the owner isn't a superuser. If the application connects to the database as the owner role (the default connection string managed Postgres hosts hand you), every RLS policy silently does nothing, and the app appears to work correctly because the app's own WHERE clauses happen to filter correctly in every test anyone wrote.
Why agents get it wrong
Neon and Railway both provision one connection string by default, and it's the owner. Nothing in the connection process warns that this role is exempt from the security feature you just wrote nineteen policies for -- the failure is invisible until a test specifically tries to read another tenant's data as this exact role, and most tenant-isolation test suites test through the app's own filtered queries, not by connecting directly as the app role and trying to break it.
What Multi-Tenant Auth & RBAC Core pre-decides
The pack creates a dedicated app_user role (NOSUPERUSER NOBYPASSRLS, not the table owner) in a migration that runs separately from the app's own schema migrations, and the app refuses to boot if its own connection turns out to own a tenant table. The verify suite's iso-db-posture check asserts owner != current_user on the exact connection the app uses, so a regression here fails the build, not a security review.
Source: ARCHITECTURE.md core decision 8-9, 'Traps this pack pre-empts'