How to secure your own Supabase project in an Emergent app

Should an Emergent app use Supabase?

Only if you have a reason. Emergent's managed MongoDB keeps preview and production data apart, and you can bring your own MongoDB Atlas. Supabase is not in the integrations catalogue, so any Supabase use is a custom setup the agent builds.

How do I tell Emergent's agent to set up Supabase safely?

Give the agent the rules before it writes code. A prompt like this one sets them.

Connect this app to my Supabase project.
Use only the publishable key (sb_publishable_) in frontend code.
Use the secret key only in backend code, never in the frontend.
Enable row level security on every table you create.
In backend code, check the signed-in user before every Supabase query.

Where does the Supabase secret key go in an Emergent app?

• Emergent says integration secrets are injected at runtime and never exposed in logs or client-side code. Supabase is not a listed integration, so confirm where the agent put the key.
• The secret key (sb_secret_) belongs in backend code only. It maps to service_role and bypasses RLS.
• The frontend may hold the publishable key and nothing else.

How do I enable RLS on tables Emergent's agent creates?

Enable RLS on every table. With RLS on and no policy, the Supabase API returns nothing to anon and authenticated, so only backend code with the secret key can read the data.

alter table public.orders enable row level security;

create policy "orders: buyer reads" on public.orders
  for select to authenticated
  using ((select auth.uid()) = buyer_id);

create policy "orders: buyer creates" on public.orders
  for insert to authenticated
  with check ((select auth.uid()) = buyer_id);

-- Every table in public without RLS. Expect zero rows.
select c.relname
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r' and not c.relrowsecurity;

What should I check before I publish an Emergent app?

1. Run Emergent's pre-publish health check.
2. Run the RLS-off query on the Supabase project and expect zero rows.
3. List what anon and authenticated may do on each public table, and revoke what you did not mean.
4. Open Supabase's Security Advisor and fix every ERROR.

select table_name, grantee, privilege_type
from information_schema.role_table_grants
where table_schema = 'public' and grantee in ('anon', 'authenticated')
order by table_name, grantee, privilege_type;