How to secure Supabase when Windsurf's agent writes the code

Where do I add the Supabase MCP server in Windsurf?

docs.windsurf.com now redirects to docs.devin.ai/desktop, so look there for current MCP instructions.

1. Open the Customize > MCPs page, or edit .devin/mcp_config.json.
2. Add Supabase's hosted server, https://mcp.supabase.com/mcp, and sign in with OAuth.
3. Scope the server to one project and turn on read-only mode, as Supabase's MCP guide describes.
4. Point it at a development project. Connect production only for a task that needs it.

What access should Windsurf's agent never have?

• A service_role or sb_secret_ key in .devin/mcp_config.json or in a chat message.
• Write access to production during routine work.
• Broad rights while it reads user-submitted text. In a General Analysis research demo, hidden instructions in a support ticket made a Cursor agent with service_role access copy a private table.

How do I keep Supabase secret keys out of Windsurf-built client code?

The browser gets the publishable key (sb_publishable_) and nothing stronger. Supabase answers a secret key sent from a browser with HTTP 401, but the key still works from any script that copies it out of your bundle. Fail the build if a secret key appears in the output.

# Stop the deploy if a secret key reached the build output.
if grep -rqE "sb_secret_|service_role" dist/ build/ .next/static/ 2>/dev/null; then
  echo "Secret Supabase key found in the build" >&2
  exit 1
fi

How do I make Windsurf's agent write migrations with RLS?

State the rule in the request: enable RLS in the same migration that creates the table, and add policies for the authenticated role. Supabase also notes that RLS can be enabled automatically on new tables with an event trigger.

create table public.tasks (
  id bigint generated always as identity primary key,
  user_id uuid not null references auth.users (id) on delete cascade,
  title text not null,
  done boolean not null default false
);
alter table public.tasks enable row level security;

create policy "tasks: owner reads" on public.tasks
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "tasks: owner updates" on public.tasks
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

What should I check before I merge an agent-written migration?

1. Run the RLS-off query on a development project and expect zero rows.
2. List what anon and authenticated may do on each public table. Every grant should be one you meant.
3. Open Security Advisor and fix every ERROR, including lints 0013 and 0010.

-- 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;

-- Table privileges held by the API roles.
select table_name, grantee, string_agg(privilege_type, ', ') as privileges
from information_schema.role_table_grants
where table_schema = 'public' and grantee in ('anon', 'authenticated')
group by table_name, grantee
order by table_name, grantee;