Free tool · Runs in your browser · @aegiskit
See whether your RLS stops at “authenticated” — instantly
Paste your RLS policy SQL. This tells apart a policy that only proves the caller is logged in (so every user reads every row) from one that correctly scopes rows to the owner. Not an existence check — a correctness check.
Your SQL never leaves this browser (no network request)
Results
Paste one or more CREATE POLICY statements above, or load an example. Analysis runs instantly, right here in your browser.
“Not owner-scoped” ≠ “vulnerable”: a genuinely shared or lookup table legitimately uses an authenticated-only policy. This is a medium “verify intent” signal, not a confirmed exploit. The classifier is conservative (fail-secure) — a predicate it cannot verify is never flagged. The authoritative analysis is npx @aegiskit/cli scan (cross-code + CI).
How it works
It reads correctness, not existence
Most scanners only check whether RLS is enabled. This one classifies what the predicate means, telling an authenticated-only policy apart from a genuinely owner-scoped one.
- 1
A positive gate
The gap is defined as ONLY auth.uid()/auth.jwt() IS NOT NULL or auth.role() = 'authenticated'. service_role, JWT claims, quoted identifiers and custom functions are all suppressed.
- 2
Owner bindings recognized
auth.uid() = user_id, casts, the (select auth.uid()) performance wrapper, IN (col, col) participant bindings, and case-insensitive email identity all classify as safe.
- 3
When unsure, stay silent
Any predicate it cannot verify is suppressed, fail-secure. Not crying wolf is the whole reason a scanner earns a team's trust.
Privacy
Your SQL never leaves this browser
- Classification runs 100% client-side, on your device. Nothing is sent to a server, stored, or logged.
- It never touches a deployed app — this is static text analysis only, with no contact to any running system.
- It's a lightweight port of the Aegis CLI's classifier (the one that held precision 1.0 across 1,000 public repos).
Check your whole repo, continuously, in CI
This preview looks at one policy. The CLI scans all of supabase/migrations and your Next.js code together, emits SARIF to GitHub code-scanning, and blocks CI on high-confidence findings only. When you need the design itself verified, book the audit.
npx @aegiskit/cli scanNo install, no config. Runs locally and never touches a deployed app.
FAQ
Is my pasted SQL sent anywhere?
No. Analysis runs entirely in your browser; your SQL never goes over the network, and no deployed app is ever contacted (static analysis only).
What's wrong with auth.role() = 'authenticated'?
It only proves the caller is logged in, which means every authenticated user can read every row. To scope by owner, bind the auth identity to the owner column: using (auth.uid() = user_id). For deliberately shared tables, authenticated-only is fine.
Does “authenticated-only” mean “vulnerable”?
No. For shared/lookup tables it's the correct design. The verdict is a medium “verify this is intended” signal, not a confirmed vulnerability.
How is this different from the CLI?
This is a lightweight preview of a single predicate. npx @aegiskit/cli scan analyzes all of supabase/migrations plus your Next.js code, emits SARIF, integrates with CI, and inspects the INSERT/UPDATE/DELETE write side too. The CLI is the authoritative tool.