Establish trusted tenant context
Tenant context begins with an authenticated identity, membership, and a trusted server-side request path. A client-supplied tenant identifier is input to validate, not authority to accept.
Protected mutations keep the tenant or workspace scope explicit so API handlers, background jobs, and integrations cannot silently resolve the wrong customer boundary.
Carry the boundary through data access
Repositories, cache keys, files, queues, and reporting queries must preserve the same scope. PostgreSQL row-level security can add a defense layer, but it does not replace correct application authorization or operational configuration.
Platform treats signed transaction context, forced RLS where applicable, and negative cross-tenant tests as parts of the wider application boundary.
Separate customer and operator access
Product users and global operators do not share an implicit permission model. Administrative access should be authenticated, authorized, audited, and limited to the operational task.
Demo data and production customer data also require distinct environments. A public product preview must never become a shortcut around tenant or role checks.
Keep negative tests permanent
For every protected resource, test that one tenant cannot read, update, delete, enumerate, or infer another tenant’s data. Repeat the test for jobs, cache entries, exports, uploads, webhooks, and administrative workflows.
The valuable artifact is not a one-time security checklist. It is a regression suite that grows with the product boundary.