multi-tenant-safety-checker

Enforces tenant isolation in PostgreSQL using Row Level Security policies, tests, and audits.

2|Updated Jun 5, 2026
One-click install
npx skills add https://github.com/sathishssj3/NexVR-Engine --skill multi-tenant-safety-checker-sathishssj3
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: multi-tenant-safety-checker
Source: https://github.com/sathishssj3/NexVR-Engine/tree/main/.agents/skills/multi-tenant-safety-checker
Command: npx skills add https://github.com/sathishssj3/NexVR-Engine --skill multi-tenant-safety-checker-sathishssj3

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @prisma/client.

What problem does it solve? Multi-tenant applications risk leaking one tenant's data to another through missing query filters, misconfigured database policies, or SQL injection. This Skill provides a complete framework for enforcing tenant isolation at both the database and application level, preventing cross-tenant data access. ## Core Features & Use Cases - Row Level Security Setup: SQL templates to enable and force RLS on PostgreSQL tables with tenant isolation policies based on session settings. - Tenant Context Middleware: TypeScript/Prisma middleware that injects tenant_id into every query and sets per-transaction tenant context. - Automated Security Testing: Test suites covering cross-tenant reads, updates, deletes, transaction rollbacks, and SQL injection bypass attempts. - RLS Audit Script: Scans all database tables to verify tenant_id columns, RLS enablement, forced enforcement, and policy existence. - Use Case: A SaaS team building a multi-tenant order management API uses this Skill to configure RLS policies, add Prisma tenant middleware, and run regression tests proving Tenant A can never read Tenant B's orders. ## Quick Start Audit my Prisma/PostgreSQL schema for tenant isolation gaps and generate the RLS policies, middleware, and security tests needed to prevent cross-tenant data leakage.

Frequently Asked Questions about multi-tenant-safety-checker

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up Row Level Security in PostgreSQL for multi-tenancy?▼

Enable RLS on each table with ALTER TABLE ... ENABLE ROW LEVEL SECURITY, then create policies filtering rows by tenant_id against a session setting like app.tenant_id. Use FORCE ROW LEVEL SECURITY so table owners cannot bypass the policies.

How to enforce tenant isolation with Prisma middleware?▼

Register Prisma middleware that injects tenantId into where clauses for findMany and findFirst, and into data for create and createMany operations. Combine this with per-transaction SET LOCAL app.tenant_id so database-level RLS also applies.

Does Row Level Security work with Prisma transactions?▼

Yes, use SET LOCAL app.tenant_id inside a Prisma $transaction so the tenant context applies only to that transaction's queries. SET LOCAL automatically resets when the transaction commits or rolls back, preventing context leakage between requests.

How do I test that tenants cannot access each other's data?▼

Write automated tests that set the tenant context to one tenant, then attempt reads, updates, and deletes against another tenant's rows and assert zero results. Also test transaction rollback behavior and SQL injection attempts that try to bypass tenant filters.

Why is application-level filtering alone not enough for tenant isolation?▼

Application filters can be forgotten in new queries, bypassed by raw SQL, or broken by refactors. Database-level RLS enforces isolation for every query regardless of application code, and forcing RLS prevents even table owners from bypassing it.

What indexes should multi-tenant tables have for performance?▼

Create composite indexes with tenant_id as the leading column, such as (tenant_id, user_id) or (tenant_id, created_at DESC). Since RLS filters every query by tenant_id, leading with it ensures filtered queries remain fast.