Design-time and audit agent for Postgres/Supabase row-level security, CRUD permissions, and cascade-delete rules. Write down who can select/insert/update/delete what, in plain YAML — rls-guard turns it into real SQL, and checks your live database against it.
Misconfigured Row Level Security is currently one of the most common real-world data exposure bugs in Postgres/Supabase-backed apps. In one 2025 disclosure (CVE-2025-48757), 303 endpoints across 170 apps were found fully readable by anyone holding the public anon key, because RLS was off or misconfigured. This happens because RLS policies are easy to get subtly wrong and easy to forget entirely as a schema grows — especially in fast-moving, AI-assisted app builds.
rls-guard exists so that:
- You describe your permission model once, in a format a non-DBA can read and review.
rls-guard generate
turns that into an actual SQL migration (policies + cascade rules).rls-guard audit
checks a live database against the spec and flags drift — RLS disabled, overly permissive policies, cascade behavior that doesn't match intent.
v0.1 — early scaffold. The core loop (spec → generate SQL, live DB → audit) works.
Not yet battle-tested; review generated SQL before applying it to anything real. See
PLAN.md
for what's next.
npm install
cp .env.example .env # fill in ANTHROPIC_API_KEY and DATABASE_URL
npm run build
Generate a migration from a spec (works with or without a live DB connection):
npx tsx src/index.ts generate --spec spec/example.spec.yaml --out rls-guard.generated.sql
npx tsx src/index.ts generate --spec spec/example.spec.yaml --db $DATABASE_URL --out rls-guard.generated.sql
Audit a live database — fast deterministic checks always run; add --spec
to also get a Claude-written comparison against your intended permission model:
npx tsx src/index.ts audit --db $DATABASE_URL
npx tsx src/index.ts audit --db $DATABASE_URL --spec spec/example.spec.yaml
See spec/example.spec.yaml
for the spec format: roles, per-table CRUD rules, and
cascade-delete behavior (cascade
/ restrict
/ set_null
).
Most existing tools here are either general-purpose policy engines you write yourself (Open Policy Agent), heavyweight enterprise DB-access platforms, or external scanners that probe a live app from outside without knowing what access was actually supposed to look like. rls-guard starts from your intended design (the spec) and both generates the implementation and checks reality against that intent — closer to a linter + codegen tool than a black-box scanner.
- CI mode: fail a PR/build when a new table has no RLS policy or a cascade rule drifts from spec (this is the planned paid tier — see below).
- Prisma/Drizzle schema readers, not just live Postgres introspection.
- Generated test suite (not just SQL) that proves unauthorized access actually fails.
- Policy diffing between spec versions for change review.
Core CLI is MIT-licensed and will stay free. The plan is an open-core model: a hosted CI gate + PR bot + compliance report generation as a paid tier on top of this free, inspectable core. GitHub Sponsors is on from day one regardless.
Early days — open an issue before a large PR. See PLAN.md
for the current build plan.