Supabase

• The anon key is public by design. The service-role key bypasses row-level security and must never reach a client, a log or a test fixture.
• In server code, get the user from the auth server rather than reading the session from storage. A stored session is not verified, so trusting it on the server trusts whatever the client sent.

General Analysis demonstrated it in July 2025 on a test project with dummy data and row-level security on. A customer filed a support ticket containing instructions addressed to the developer’s coding agent. Later, the developer asked the agent, connected through the Supabase MCP server, to show the latest ticket. The agent read the ticket, then ran two queries nobody asked for: one read a table of integration tokens, and one wrote its contents into the ticket thread, where the customer could see it. The connection used the service_role, which bypasses row-level security, so no permission was violated. General Analysis has not rerun the demonstration against the current server. Supabase’s own documentation now warns about this pattern and says its protections against it are not complete.

• Scope the connection to the task. Supabase documents project_ref (one project), read_only=true (queries run as a read-only Postgres user) and features (only the tool groups needed). Read-only stops the write that returned the data here. It does not stop the read.
• Keep manual approval of tool calls on, and check each query against what was asked. Summarising a ticket gives no reason to read a token table.
• Treat any row a user can write as untrusted input to the agent, the same as a web page or an email.
• Connect to production only when the task needs production data. Otherwise use a development project or branch with no real secrets in it.

UpGuard’s researchers checked around 300,000 sites using Supabase and found 16,326 databases with tables anyone could read — personal data in more than half, and passwords or tokens in some. Their account of the mechanism is the part that matters for agents: tables created in Supabase’s dashboard now get row-level security by default, but tables created through the API — the way coding agents create them — do not. UpGuard names AI coding agents as the common thread across the exposed sites, while not measuring how many were built that way.

• After an agent creates a table, check that row-level security is on. Do not assume the dashboard’s default applied; the agent did not use the dashboard.
• Make “enable RLS and write its policy” part of the same change that creates the table, not a follow-up — the window between the two is when the table is public.
• Treat the public key as public. It is meant to ship to the browser; the security comes from the policies, not from keeping it out of sight.

• Build indexes with CREATE INDEX CONCURRENTLY on any table with traffic. A plain one blocks writes for as long as it takes.
• Set a lock_timeout on migrations, so one waiting for a lock fails fast instead of queueing every query behind it.
• Check whether a column change rewrites the table before running it on a large one.

• Enable row-level security on every table in an exposed schema, and write its policy before the first query. A table without it is readable by anyone holding the public anon key.
• Code using the service-role key bypasses row-level security completely, so it has to enforce authorisation itself.