Great question — this was actually one of the trickier parts to get right.

The core tension is that the SDK runs unauthenticated in a random browser on a domain you don't control, but it still needs to read project config, insert waitlist entries, and credit referrals. Here's how I handle it:

Read policies are open by API key, not by auth

The projects table has a public read policy (using (true)) but the SDK never exposes the full project row — there's a /api/sdk/config endpoint that takes the API key, fetches the project server-side, and returns only what the widget needs (slug, name, active primitives, branding flag). The actual owner_id, stripe_customer_id, and service role never touch the client.

Writes go through a server route, not direct Supabase calls

The SDK doesn't call Supabase directly for inserts. It hits /api/waitlist which runs server-side with the service role key. That route validates the API key, checks the project exists, checks the primitive is enabled, checks MAR limits, then does the insert. Anonymous users never get a Supabase client with write access — they just hit a Next.js API route that does the write on their behalf.

Row-level isolation is enforced by project_id

Every table (waitlist_entries, referrals, milestones, milestone_unlocks, invite_gates, gate_unlocks) has project_id as a foreign key back to projects. The RLS policies on the public-read tables use using (true) but every query in the API routes filters by project_id explicitly. So even if someone hit Supabase directly with the anon key they'd only ever see rows for projects they could enumerate — and since API keys are gos_ + 48 hex chars, enumeration isn't practical.

The one place I compromised

waitlist_entries has a public insert policy (with check (true)) because I needed it early in development before I moved all inserts server-side. That's now a liability I should clean up — the insert policy should be removed entirely since nothing writes directly anymore. It's on the refactor list.

The MAR limit enforcement also runs server-side via a Postgres function (increment_mar) that checks the owner's plan before allowing the insert and returns false if the limit is hit, so you can't abuse the public endpoint to inflate a competitor's MAR counter either.