Supabase prompt workflow for secure Auth and Postgres without CI agents

Step-by-step Supabase prompt workflow for auth, Postgres schema and RLS using ChatGPT/Claude, with tests and MAU cost impact.

Supabase prompt workflows for shipping a secure auth + DB backend

It is possible to safely use ChatGPT or Claude to design a Supabase Auth + Postgres backend if they are treated as schema co-pilots, not security authorities. The core move is to keep LLMs in a tight loop: model identity around Supabase Auth and JWT roles, have the model draft schemas and RLS, turn everything into migrations and supabase test db tests, and only trust what passes. This guide walks a small SaaS app from blank repo to secure multi-tenant backend using that workflow, without CI/CD agents or leaked secrets. If you want a broader Supabase review for AI builders or a focused Supabase vs Firebase comparison, those are covered separately; here we stay concrete and workflow-focused.

The example app is a simple multi-tenant project management SaaS: users sign up, join organisations, create projects and tasks. The goal is to ensure users only see data for organisations they belong to, with clear anon vs authenticated behaviour and predictable MAU and auth costs.

Why pair Supabase with LLMs at all?

Supabase combines Postgres, Auth, storage and APIs in one managed stack. Supabase Auth integrates directly with a project’s Postgres database and is designed to work with Row Level Security (RLS) for authorisation according to the official Auth docsAuth | Supabase Docs. That makes it a strong default backend for AI-assisted apps and general SaaS, as covered in more detail in the broader Supabase review for AI builders and in the Supabase pgvector RAG backend workflow if you are adding AI search.

Where LLMs help:

Designing schemas around auth.users and multi-tenant relationships.
Drafting RLS policies tied to JWT roles (anon, authenticated) and custom claimsJSON Web Token (JWT) | Supabase Docs.
Translating behaviour specs into idempotent SQL migrations and tests.
Interpreting Postgres errors (e.g. 42501 insufficient_privilege) and suggesting fixes.

Where LLMs must never be the authority:

Final RLS semantics. Every policy must be verified with supabase test db, which, as of September 30, 2026, the Row Level Security docs show as part of the recommended pattern for asserting allow/deny behaviour for anon and authenticated rolesRow Level Security | Supabase Docs.
Secrets or production access. Supabase emphasises that the service_role key bypasses RLS and must never be exposed to untrusted clientsAPI keys | Supabase Docs. The same rule applies to LLM prompts and to any AI coding agents wired into your CI/CD, like the Hardened HarnessAgent patterns described in this GitHub + Vercel hardening workflow.

What you will build in this workflow

The rest of this guide delivers a concrete, repeatable workflow:

Supabase pricing table showing included Monthly Active Users and per-MAU overage fees on paid plans. — The Supabase pricing page highlights Monthly Active Users quotas and per-MAU overage, grounding the article’s point that auth and tenancy design choices drive real billing outcomes.

A multi-tenant schema anchored on auth.users: organisations, memberships, projects, tasks.
Least-privilege RLS policies using Supabase Auth JWT roles and membership checks.
SQL migrations generated with LLM help, applied via supabase db push or SQL files.
supabase/tests/ RLS tests asserting which operations each role can perform.
An LLM-driven debugging loop for failed tests and 42501 errors.

The code examples assume a TypeScript/Next.js frontend, but the backend pattern works for any client that can supply Supabase access tokens. If you want a concrete front-to-back example of Supabase in a production stack with Vercel and Cloudflare, the Supabase + Vercel + Cloudflare support chatbot build log shows that end-to-end.

What is safe to share with ChatGPT or Claude?

For this workflow, the LLM is treated as an external contractor. It does not see secrets or real user data.

Safe to include in prompts

Plain English requirements and user stories.
Schema snippets: CREATE TABLE, ALTER TABLE, CREATE POLICY, indexes.
Supabase-reported error messages and codes (e.g. 42501 from Postgres).
Test SQL using obviously synthetic identifiers and emails.
Anonymised data examples with changed emails, IDs, and names.

Never include in prompts

Supabase project URL with access tokens baked into it.
Service role keys, anon keys, database passwords or any API keysAPI keys | Supabase Docs.
Real user PII, production JWTs or entire database dumps.
Direct connections to production (no plugging the LLM into an agent that can call Supabase).

Concretely: copy out just the relevant SQL, schemas and error messages into ChatGPT or Claude. Run all database commands in a terminal or SQL editor, not via the LLM.

Step 1: model identity and tenancy explicitly

Supabase Auth issues JWTs that include a role claim, which is commonly configured to use Postgres roles such as anon and authenticated so that RLS policies can use those roles, according to the JWT docs as of September 30, 2026JSON Web Token (JWT) | Supabase Docs. For a small SaaS, a typical starting point is:

Supabase documentation section describing how a JWT role claim like anon or authenticated is mapped to a Postgres role for authorization. — Supabase’s auth docs show how the JWT’s role claim is mapped to a Postgres role, grounding the article’s explanation that Supabase Auth tokens carry anon and authenticated roles used by RLS policies.

anon: unauthenticated users (e.g. marketing site, signup).
authenticated: logged-in users; all tenant scoping is handled by RLS.

Tenancy model for the example app:

Each organisation has many memberships.
Each membership links auth.users.id to an organisation with a role (owner, member).
projects belong to organisations; tasks belong to projects.
Users see only rows where they have a membership in the parent organisation.

Prompt template: identity and tenancy design

Use this with ChatGPT or Claude to get a first-pass model:

System: You are a senior Postgres and Supabase architect.

User: I'm building a small multi-tenant SaaS on Supabase.

Supabase Auth issues JWTs with a `role` claim mapped to Postgres roles `anon` and `authenticated`.
I want each authenticated user to belong to one or more organisations and only see data
for organisations where they are a member.

Design a Postgres data model around auth.users with:
- organisations
- organisation_memberships (linking auth.users to organisations with a role: owner, member)
- projects (belong to organisations)
- tasks (belong to projects)

Output:
1) ERD description in text (tables and foreign keys).
2) Notes on how RLS will determine which rows an authenticated user can access,
   referencing auth.uid() and memberships.
Don't write any SQL yet.

Review the response and adjust until the relationships and roles match the product. Only then move on to SQL.

Step 2: have the LLM draft the schema SQL

Once the conceptual model is stable, ask the LLM for concrete CREATE TABLE statements, but keep control of naming and constraints.

Prompt template: schema SQL draft

System: You are a senior Postgres and Supabase architect.

User: Using the following identity and tenancy model, draft SQL for Supabase:

[PASTE the approved textual ERD from the previous step]

Requirements:
- Reference auth.users with auth.uid() semantics where needed.
- Use UUID primary keys.
- Include created_at and updated_at timestamptz columns defaulting to now().
- Add NOT NULL constraints and reasonable unique indexes.
- Do NOT enable RLS yet; that will be a later step.
- Output a single SQL migration file, idempotent where possible.

Only output SQL inside one code block.

Paste the output into a migration file, for example supabase/migrations/202410010001_init_schema.sql. Apply it to a local Supabase instance using the Supabase CLI.

# Initialise if needed
supabase init

# Start local stack
supabase start

# Apply migrations
supabase db push

Adjust any syntax issues manually or with further prompting, keeping the LLM away from actual database connection details. If you prefer designing schema changes from inside your editor with a coding agent, you can also run this step through a Git-driven workflow like the Cursor + Supabase safe migration guide, then use the prompts here to refine RLS behaviour.

Step 3: wire Supabase Auth to the schema

Supabase Auth is already linked to a project’s Postgres databaseAuth | Supabase Docs. For the schema to enforce tenancy, tables must reference auth.users and rely on auth.uid() in RLS policies later.

Common patterns:

organisation_memberships.user_id uuid references auth.users(id).
Use auth.uid() in policies to compare against organisation_memberships.user_id.
Optionally, mirror certain Auth metadata (e.g. email) to a public profile table, but keep Auth as the source of truth.

In the Supabase dashboard Auth settings page (screenshot suggested here), confirm:

JWT expiry is reasonable for the app.
Default role claim is set to authenticated for signed-in users and anon for unauthenticated traffic.

This screenshot should show JWT-related configuration and available roles to anchor the explanation of how role flows into RLS decisions.

Step 4: enable RLS and draft least-privilege policies

Supabase projects use Postgres Row Level Security to secure data at the row level, and the current API security guidance recommends revoking default grants and enabling RLS on every table exposed via the Data API, as of September 30, 2026Row Level Security | Supabase Docs Securing your API | Supabase Docs.

Supabase Row Level Security guide showing example policy SQL and explanation of how RLS is enabled per table. — The official Row Level Security guide shows how Supabase represents RLS configuration and policy SQL, mirroring the article’s workflow of turning LLM-generated policies into concrete RLS settings on key tables.

For each table, define behaviour for these role × action combinations:

anon: usually deny all CRUD except maybe inserts on public tables (e.g. public feedback).
authenticated: allow only rows linked to the user’s organisations.

Prompt template: RLS policy draft

System: You are a senior Postgres and Supabase RLS specialist.

User: We have this schema (simplified):

[PASTE relevant CREATE TABLE statements only]

Rules:
- Supabase Auth provides auth.uid() for the current user.
- Each authenticated user can see organisations where they have a membership.
- organisation_memberships.user_id references auth.users.id.

Design RLS for these tables:
- organisations
- organisation_memberships
- projects
- tasks

Requirements:
- Enable RLS on each table.
- For anon (role = 'anon'): deny all access.
- For authenticated (role = 'authenticated'):
  * organisations: user can select organisations where a membership exists.
  * organisation_memberships: user can select their own memberships; only org owners can invite new members.
  * projects: user can select/insert/update/delete projects belonging to orgs where they are a member.
  * tasks: user can CRUD only tasks under projects in their organisations.

Output:
- ALTER TABLE ... ENABLE ROW LEVEL SECURITY;
- REVOKE ALL ON TABLE ... FROM PUBLIC; where appropriate.
- One or more CREATE POLICY statements per table, with clear names.

Use auth.uid() to filter rows.
Only output SQL.

Place the resulting SQL in a new migration file such as supabase/migrations/202410010002_rls.sql and apply it locally.

In the Supabase dashboard table editor (second suggested screenshot), RLS should now be enabled and a list of policies for each table should be visible. That view is useful for sanity-checking names and conditions, but the migration files remain the source of truth.

Step 5: codify behaviour with `supabase test db`

As of September 30, 2026, the Row Level Security docs show supabase test db and SQL tests under supabase/tests/ as the recommended pattern to assert allow/deny behavior for roles such as anon and authenticated for each tableRow Level Security | Supabase Docs. This is where LLM suggestions are upgraded from ideas to enforced contracts.

Supabase testing overview docs showing CLI example using supabase test db and a tests directory under supabase. — The testing overview page demonstrates the supabase test db command and the expected supabase/tests folder structure, visually reinforcing where RLS tests live in the workflow.

Set up the tests harness

# Ensure CLI is installed and project initialised
supabase init

# Create tests directory if missing
mkdir -p supabase/tests

A typical test file (e.g. supabase/tests/rls_organisations.sql) contains SQL blocks annotated with expectations. The exact syntax may vary with CLI versions, so it should be aligned with current docs; the pattern below illustrates the idea.

Checklist: tests per table

Table	Role	Operation	Expected result
organisations	anon	SELECT, INSERT, UPDATE, DELETE	Denied
organisations	authenticated (member)	SELECT	Allowed only for orgs with membership
organisation_memberships	authenticated (non-owner)	INSERT new membership	Denied
organisation_memberships	authenticated (owner)	INSERT membership for their org	Allowed
projects	authenticated	SELECT	Allowed only for projects in user organisations
tasks	authenticated	SELECT	Allowed only for tasks under user projects

Prompt template: generate initial RLS tests

System: You are a senior Supabase and Postgres testing specialist.

User: For this schema and RLS (SQL below), write SQL-based RLS tests
for use with `supabase test db` under supabase/tests/.

Schema:
[PASTE relevant CREATE TABLE statements]

RLS policies:
[PASTE the CREATE POLICY statements]

Test behaviour:
- anon role cannot select/insert/update/delete any row in any table.
- authenticated user who is a member of organisation A and not B:
  * can see organisation A and its projects and tasks
  * cannot see organisation B, its projects or tasks
- only an organisation owner can insert or delete memberships for that organisation.

Output:
- A single SQL test file content with setup (insert test users/orgs/projects/tasks)
  and assertions for allow/deny per above.
- Use comments to indicate which statements should succeed vs fail
  (e.g. -- expect: allowed, -- expect: denied with 42501).

Only output SQL.

Adjust the test SQL to match the current supabase test db assertion semantics. Run the tests locally:

supabase test db

The third suggested screenshot should show the supabase/tests/ directory and a sample test file, anchoring where these checks live in the project.

Step 6: use the LLM to debug RLS failures

Two main failure modes will surface via tests or via the app:

Over-permissive policies: tests or manual queries show data from other tenants.
Over-restrictive policies: Postgres returns 42501 insufficient_privilege when an operation should succeed.

Debugging over-permissive access

Example symptom: a user from organisation A can see organisation B’s projects.

Workflow:

Add or update a test in supabase/tests/ that demonstrates the problem.
Run supabase test db and capture the failing query and its result.
Prepare a prompt with:

System: You are a senior Postgres and Supabase RLS engineer.

User: I have a multi-tenant schema and RLS. A user from organisation A
can see organisation B's projects. Here's the simplified schema, RLS, and
failing test query and result.

Schema:
[PASTE relevant CREATE TABLE]

Policies:
[PASTE CREATE POLICY statements for projects]

Failing test query and result:
[PASTE SQL and the rows returned, with anonymised IDs]

Explain why this policy lets users see other organisations' projects,
and propose a corrected least-privilege policy for the projects table only.

Output just the corrected CREATE POLICY/ALTER POLICY statements, no prose.

The diff should then be reviewed carefully. Only the affected policy should be replaced in a new migration, tests should be rerun, and the process repeated if needed.

Debugging over-restrictive access (`42501`)

Example symptom: a legitimate user cannot insert a task and the client library returns an error with code: '42501'.

Workflow:

Capture the exact SQL the client is issuing (e.g. from logs or a reproducer query).
Add a test case that recreates this insert under the appropriate role.
Paste schema, policies and error into ChatGPT or Claude with:

System: You are a senior Postgres and Supabase RLS engineer.

User: This INSERT should be allowed but returns 42501 insufficient_privilege.

Schema (tasks and related tables):
[PASTE]

RLS policies on tasks and parent tables:
[PASTE]

INSERT statement:
[PASTE]

Explain which policy or missing policy is causing 42501 and propose a minimal fix
that only grants access to tasks under projects in organisations where the user
has a membership.

Output:
- Short explanation.
- Updated policy SQL.

Again, changes go into migrations, not the dashboard directly, so every fix is reviewable.

Step 7: connect auth + DB design to Supabase costs

As of September 30, 2026, Supabase bills by organization with subscription plans named Free, Pro, Team, and Enterprise, each with documented quotas for items such as database disk, storage, egress, Monthly Active Users (MAU), Realtime messages, and Edge Function invocationsAbout billing on Supabase. Supabase bills by organization on these plans, each with explicitly documented quotas for database disk, storage, egress, Auth and Third-Party MAU, SSO MAU, Realtime, and Edge Functions, as of September 30, 2026.

Plan quotas and overage rates

Plan	Base price	Included DB size	Included storage	Included egress	Included MAU	Realtime messages
Free	$0 / org / month	500 MB per project	1 GB	5 GB	50,000	2,000,000 / month
Pro	$25 / org / month base	8 GB per project	100 GB	250 GB	100,000	5,000,000 / month
Team	From $599 / org / month	8 GB per project	100 GB	250 GB	100,000	5,000,000 / month

Interpreting the table above in light of current docs: Free – $0 per organization/month; includes up to 2 active projects, each with 500 MB database size, plus 1 GB storage, 5 GB egress, 50,000 Auth MAU, 50,000 Third-Party MAU, 2,000,000 Realtime messages, and 200 concurrent Realtime connections, as per Supabase’s billing docs as of September 30, 2026. Pro – $25 per organization/month base subscription; each project includes 8 GB of database disk, 100 GB storage, 250 GB egress, 100,000 Auth MAU, 100,000 Third-Party MAU, 50 SSO MAU, 2,000,000 Edge Function invocations, 5,000,000 Realtime messages, and 500 concurrent Realtime connections before overage charges, per Supabase’s billing docs as of September 30, 2026. Team – from $599 per organization/month; core usage quotas match Pro as of September 30, 2026: 8 GB database disk per project, 100 GB storage, 250 GB egress, 100,000 Auth MAU, 100,000 Third-Party MAU, 50 SSO MAU, 2,000,000 Edge Function invocations, 5,000,000 Realtime messages, and 500 concurrent Realtime connections, with higher support and security featuresAbout billing on Supabase Pricing & Fees | Supabase.

Key overage rates from the billing docs:

On Pro and Team plans, database disk beyond the included 8 GB per project is billed at an effective rate of $0.125 per GB-month for provisioned disk (prorated hourly), as per Supabase’s database disk changelog and billing docs as of September 30, 2026About billing on Supabase.
Managed storage overage is billed at $0.021 per GB-month beyond included storage on Free (1 GB) and Pro/Team (100 GB), according to the billing docs as of September 30, 2026.
Outbound data transfer (egress) overage is billed at $0.09 per GB beyond 5 GB on Free or 250 GB on Pro/Team, as of September 30, 2026.
Auth Monthly Active Users (MAU) overage is billed at $0.00325 per MAU beyond plan quotas (50,000 included on Free with no overage billing, 100,000 included on Pro and Team with $0.00325 per MAU beyond that), per the MAU usage docs as of September 30, 2026Manage Monthly Active Users usage.
Monthly Active SSO Users beyond the 50 SSO MAU included on Pro and Team are billed at $0.015 per SSO MAU per billing cycle, according to the SAML SSO docs as of September 30, 2026Single Sign-On with SAML 2.0 for Projects.
Advanced Multi-Factor Auth – Phone is a paid add-on on Pro and Team, priced at $75 per month for the first project and $10 per month for each additional project, as listed on the pricing page as of September 30, 2026Pricing & Fees | Supabase.

If you want a narrower, numbers-first breakdown of Supabase vs other backends from a cost perspective, the Supabase vs Firebase comparison for AI-built apps walks through concrete MAU and storage scenarios on both platforms.

Original cost analysis: scenario breakdowns

These scenarios use only numbers from Supabase’s pricing and billing docs, interpreted as of September 30, 2026.

Scenario 1: solo builder on Free with <5,000 MAU

Assumptions:

Single project.
5,000 MAU, all via core Auth.
Postgres under 500 MB, storage under 1 GB, egress under 5 GB.

From the billing docs, the Free plan includes 500 MB database, 1 GB storage, 5 GB egress and 50,000 MAU per project with no MAU overage billingAbout billing on Supabase Manage Monthly Active Users usage.

Arithmetic:

DB, storage, egress all within quotas → $0 overage.
5,000 MAU < 50,000 MAU included → $0 MAU overage.

Result: Supabase-side cost is $0/month. Good schema and RLS design mainly reduce future migration pain.

Scenario 2: early SaaS on Pro with 20,000 MAU

Assumptions:

Pro base at $25 per organisation/monthAbout billing on Supabase.
One project using up to 8 GB DB, 100 GB storage, 250 GB egress, 20,000 MAU.

Arithmetic:

MAU: 20,000 < 100,000 included → 0 × $0.00325 = $0 MAU overage.
DB disk <= 8 GB included → $0 DB overage.
Storage <= 100 GB, egress <= 250 GB → $0 overage.

Result: roughly $25/month. Careful schema design (no redundant per-user blobs, normalised tenancy) keeps usage inside that envelope for a long time.

Scenario 3: growing SaaS on Pro with 120,000 MAU

Assumptions:

Pro base $25/month.
120,000 MAU.
Postgres 12 GB (4 GB over 8 GB included).

Arithmetic:

MAU overage: 120,000 − 100,000 = 20,000 MAU over quota. 20,000 × $0.00325 = $65.00.
DB disk overage: 4 GB × $0.125/GB = $0.50.

Result: Supabase-side backend cost ≈ $25 + $65 + $0.50 = $90.50/month before any storage/egress or Realtime/Edge overages.

Auth design impacts MAU: for example, creating additional machine users that log in frequently will count towards MAU according to Supabase’s MAU usage docsManage Monthly Active Users usage. Prompt workflows should explicitly check that patterns like one user per device or anonymous visitors becoming MAU unnecessarily are not inflating counts.

Scenario 4: same app adds SSO and advanced phone MFA

Assumptions (on top of scenario 3):

500 of the monthly active users sign in via SSO.
Advanced MFA phone add-on enabled for the first project on Pro.

From Supabase’s SSO docs, Pro/Team include 50 SSO MAU then bill $0.015 per additional SSO MAUSingle Sign-On with SAML 2.0 for Projects. The pricing page lists Advanced MFA phone as $75/month for the first project and $10/month for each additional projectPricing & Fees | Supabase.

Arithmetic:

SSO MAU overage: 500 − 50 = 450 SSO MAU over quota. 450 × $0.015 = $6.75.
Advanced MFA: $75/month for the first project (additional projects would add $10/month each).

Result: additional $81.75/month on top of the ≈$90.50 from scenario 3 → ≈$172.25/month total (before other overages).

For products targeting enterprises that require SSO and strong MFA from day one, LLM prompts should explicitly explore SSO flows, MFA rollout, and the MAU/SSO MAU accounting rather than treating auth as a free add-on.

Step 8: a full end-to-end prompt workflow

Putting it all together, this is a minimal, repeatable workflow that can be run for each new project or major schema change.

Phase 1: design

Requirements dump. Write a short text spec for identity, tenancy and critical access rules.
LLM: identity and tenancy model. Use the identity and tenancy design prompt to get an ERD and RLS notes. Iterate until stable.
LLM: schema SQL. Use the schema SQL draft prompt for CREATE TABLE statements, then review and hand-edit.
Migration. Save as a migration, apply locally with supabase db push.

Phase 2: security layer

LLM: RLS policies. Use the RLS prompt to draft ENABLE ROW LEVEL SECURITY, REVOKE, and CREATE POLICY statements.
Migration. Add RLS SQL in a separate migration, apply locally.
Dashboard check. Verify in the Supabase UI that RLS is enabled on each exposed table and policies match expectations.

Phase 3: tests

LLM: initial tests. Use the RLS tests prompt to generate supabase/tests/*.sql files covering anon vs authenticated behaviours.
Run tests. supabase test db; record failures.
LLM: debug. For each failure, feed schema, policies and failing queries into the debugging prompts. Apply minimal policy changes as new migrations.
Repeat until green. Loop until all expected allow/deny scenarios pass.

Phase 4: integration

Client integration. Wire the frontend or API server to Supabase Auth and Data APIs using only anon and user JWTs; never the service role client-side.
Manual smoke tests. Use two browser sessions or test accounts to ensure isolation across organisations.
Version control. Commit migrations and tests to Git; review them like any other backend change. If you are already running AI coding agents in CI, align those reviews with a proof-gated workflow like the one in this AI agents + GitHub + Vercel guide so that schema and policy changes are always tested before deployment.

The fourth suggested screenshot—a Supabase billing page snippet showing MAU and DB/storage quotas and overage rates—can be referenced when deciding which plan to start on and when to upgrade.

When to change the workflow

The workflow above assumes a small but real production app with real users and some sensitivity around data.

Lightweight prototypes

If an app is an internal tool or throwaway prototype with a handful of test users and no sensitive data, the cost of fully modelling multi-tenant RLS and exhaustive tests may outweigh its value. In that case it can be reasonable to:

Use the LLM to design a simple schema and a couple of basic policies.
Write only a few smoke tests instead of full matrices.
Rely more on manual testing and accept more shortcuts.

Strict SSO/MFA or compliance requirements

If SAML SSO, advanced phone MFA and formal security review are needed from day one:

Plan for the SSO MAU and advanced MFA pricing in prompts and budgeting.
Use LLMs to generate schemas and policies but have a specialist review them.
Consider starting on Pro or Team with SSO and MFA enabled explicitly.

Existing heavy Git-based workflows

If there is already a per-branch migrations and GitHub review workflow:

Keep using that process; drop LLM proposals into PRs as patches.
Run supabase test db in local or pre-merge stages, but do not grant agents write access to the repo or Supabase.

Very high MAU or realtime usage

At hundreds of thousands of MAU or heavy Realtime, Supabase costs become more material. In that case:

Use prompts that explicitly estimate MAU distribution, DB size growth and message volume.
Have the LLM propose schema and access patterns that reduce redundant rows and chatty queries.

When you must reason about live sensitive data

If it is not possible to avoid working with real production or highly sensitive data, external LLM sessions are the wrong tool. Work locally with psql or Supabase’s SQL editor and restrict AI usage to anonymised or schema-only discussions.

How this workflow reduces risk without CI/CD agents

The core idea is simple: LLMs do not get to touch the Supabase project directly, and they do not get the last word on security. They draft, humans verify.

Security posture: Identity is anchored to Supabase Auth and JWT roles, and every policy is exercised by tests for anon and authenticated roles.
Workflow robustness: All LLM output is captured as migrations and supabase test db files under version control, not pasted ad-hoc into the dashboard.
Verification depth: Behaviour is checked via machine-executable tests and explicit allow/deny expectations, not just clicking around the UI.
Cost awareness: Auth and schema decisions are grounded in Supabase’s MAU and storage pricing, with simple arithmetic showing when Free vs Pro vs SSO/MFA add-ons make sense.
LLM discipline: Only abstract schemas, synthetic data and error messages are shared; secrets and live PII stay out of context entirely, in line with Supabase’s service role and API key guidance.

For a solo founder or small team, this is usually enough to ship a real, password-and-RLS-protected Supabase app into production with confidence, while still taking full advantage of ChatGPT or Claude for the heavy lifting on SQL and policy drafting. If you are also using AI to design your overall development stack, the broader AI coding stack guide and the AI development workflow from prompt to production can help you plug this Supabase pattern into the rest of your tooling.