For Cursor projects
Cursor writes your migrations. We prove they don’t leak.
Your code is already in git, and your schema is already in supabase/migrations. That’s exactly what we need: we rebuild the database, test who can read what, and hand back a migration your normal review process can take.
Independent: PatchLabs is not affiliated with Cursor.
{
"mcpServers": {
"patchlabs": {
"url": "https://api.patchlabs.dev/mcp"
}
}
}Will it work?
Check this before you paste your repo.
Works today when
- Your project uses Supabase with migrations in
supabase/migrations - The repo is public on GitHub (private repos come with our GitHub App)
- Access control uses RLS with Supabase Auth
Not covered yet
- Backends without Supabase migrations, such as an ORM on another database
- Checking a pull request before it merges (needs our GitHub App)
- API routes and server code
The common leak
A policy that looks right and still leaks.
AI assistants are good at writing a policy that makes the feature work. The typical miss: a rule that lets the signed-in user through without checking the row is theirs, or an UPDATE policy with no with check. The lab catches the first by reading as a stranger; the free RLS check flags the second.
No Cursor-specific numbers yet. Our study sampled public Lovable and Supabase repos, so we don’t publish figures for Cursor apps. The access rules work the same way on any Supabase database, which is what we test.
-- after: owner-only reads, and owners can't reassign rows
create policy "Users read own notes"
on public.notes for select to authenticated
using (auth.uid() = user_id);
create policy "Users update own notes"
on public.notes for update to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);Illustrative SQL. Your report contains the real migration for your tables, and it only counts as proven once the anonymous visitor and the signed-in stranger are denied and the owner still reads their own rows.
How the fix lands
From proven fix to your live app.
Cursor is your editor, so the fix lands the way every migration in your project already does.
We never push to your repo or touch your database. Nothing changes until you, or your engineer, applies the migration. Automatic pull requests need our GitHub App, which is coming.
Pull it into your branch
Download the migration, or commit it on GitHub in one click, then pull.
Review it like any change
The report shows the proof for each identity and a risk note. Ask Cursor to explain anything you’re unsure about.
Ship it your usual way
supabase db push, your CI, or Supabase’s GitHub integration if you use it.Re-check after the merge
From the dashboard, on a schedule, or from CI with an API key. Monitoring.
Does the MCP server cost anything?
The free RLS check and starting a check work without an account. Listing and running checks for monitored apps needs your workspace API key. MCP docs.
Will Cursor’s agent see my findings?
Only if you add the MCP server and ask it to check. Reports are otherwise shared by link.
Do you run my code?
No. The lab only applies the SQL in your migrations; nothing from your repo is executed.
Is PatchLabs part of Cursor?
No. PatchLabs is independent and not affiliated with Cursor or Anysphere.
Free check
Can a stranger read your users table? Find out in minutes.
You’ll get the leaks, the fix and the proof on one page. How it works.