rls-security-enforcer

Enforce RLS policies with tenant_id guards across database and application layers.

Updated Dec 26, 2025
One-click install
npx skills add https://github.com/theeabrarrr/LPG-Connect --skill rls-security-enforcer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rls-security-enforcer
Source: https://github.com/theeabrarrr/LPG-Connect/tree/main/.agents/skills/rls-security-enforcer
Command: npx skills add https://github.com/theeabrarrr/LPG-Connect --skill rls-security-enforcer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill ensures strict multi-tenant isolation by consistently applying Row Level Security policies across both database and application layers, preventing cross-tenant data exposure.

Core Features & Use Cases

  • Enforce per-table RLS policies with tenant_id guards on SELECT, INSERT, UPDATE, and DELETE.
  • Enforce server-side tenant_id handling in Server Actions to avoid trusting client input.
  • Useful during new table creation, server action implementations, or security debugging to uncover data leaks.

Quick Start

Configure your data model to require tenant_id guards, fetch the tenant_id on the server, and verify queries enforce proper tenant filtering in all code paths.

Frequently Asked Questions about rls-security-enforcer

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

FAQPage Schema
How do I enforce strict Row Level Security for multi-tenant data isolation?

To enforce Row Level Security for multi-tenant data isolation, apply RLS policies with tenant_id guards across database and application layers, ensuring server-side tenant_id fetching and explicit query filtering.

Why do server actions leak cross-tenant data in a multi-tenant SaaS and how do I prevent it?

Cross-tenant data leaks in server actions occur when trusting client-side tenant_id input, which you prevent by fetching tenant_id server-side and applying explicit filtering on all database queries.

What RLS policies do I need on new database tables for a multi-tenant SaaS?

New database tables in a multi-tenant SaaS require non-public RLS policies with tenant_id guards applied to SELECT, INSERT, UPDATE, and DELETE operations to prevent cross-tenant exposure.

How do I debug cross-tenant data exposure in server actions?

Debug cross-tenant data exposure by auditing server actions to verify tenant_id is fetched server-side rather than trusted from client input, and confirming all query code paths enforce strict tenant filtering.

Do I need RLS configured on all tables to use server-side tenant_id filtering?

Yes, properly configured RLS on all tables is required alongside non-public policies to ensure server-side tenant_id fetching and explicit query filtering effectively isolate tenant data.

What is the best way to isolate tenant data without trusting client input?

The best way to isolate tenant data without trusting client input is fetching tenant_id exclusively on the server and applying strict Row Level Security policies with explicit filtering across all queries.