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.