Can I run this from CI?

Yes. The CLI exits 0 when clean, 1 at or above your `--fail-on` threshold, and 2 when the scan itself could not run, so a pipeline can tell an unsafe schema from a broken scanner.

Does it check the auth and storage schemas?

It deliberately skips them. Supabase platform schemas ship RLS-disabled tables by design; reporting them buries the one real finding under thirty fake ones.

Guides

Bolt.new shipped tables without RLS

Bolt scaffolds schema fast, and schema is where security lives. A generated migration that creates a table rarely creates the policies to go with it.

There are two distinct end states and they need different fixes: RLS never enabled, and RLS enabled with no policies behind it.

Rules that check this

criticalRow Level Security disabledRLS_DISABLED
highRLS enabled but no policiesRLS_NO_POLICIES
criticalservice_role key shipped to the browserSERVICE_ROLE_KEY_EXPOSED

RLS off: everything is readable

The table is world-readable to the anon key. Critical, and the fix is to enable, force, and add policies in one go.

ALTER TABLE public.your_table ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.your_table FORCE ROW LEVEL SECURITY;

RLS on with no policies: everything is denied

Postgres denies every row to every non-owner role. Your data is safe and your app is quietly broken — a list that renders empty, a form that fails without an error.

This one is high rather than critical, because nothing is exposed. It usually means someone enabled RLS and stopped there.

Generated policies use your columns

VibeGuard reads the table definition and infers the ownership column — `user_id`, `owner_id`, `created_by`, `author_id` and similar — then generates SELECT, INSERT, UPDATE and DELETE policies scoped to it.

When it cannot find one, it says so and emits a marked TODO rather than inventing a column. A policy referencing a column that does not exist fails to run, which is worse than no policy at all.

Frequently asked

Can I run this from CI?: Yes. The CLI exits 0 when clean, 1 at or above your `--fail-on` threshold, and 2 when the scan itself could not run, so a pipeline can tell an unsafe schema from a broken scanner.
Does it check the auth and storage schemas?: It deliberately skips them. Supabase platform schemas ship RLS-disabled tables by design; reporting them buries the one real finding under thirty fake ones.

Check your project in about ten seconds

Paste a URL. No signup, no writes, nothing stored.

Run the free audit