DEV Community: Muhammed Semri

I built a Supabase RLS audit that's just SQL wrapped in a prompt

Muhammed Semri — Thu, 13 Aug 2026 16:15:24 +0000

Every AI coding agent will happily "audit your RLS" if you ask it to. Mine did. It
found three issues, declared the rest fine, and on the second run found two
different issues and declared the rest fine.

That's the problem. An agent asked to go look enumerates what it happens to
notice, then phrases everything it never checked as an all-clear. The finding
isn't deterministic, so the all-clear is worthless.

So I inverted it: the prompt doesn't ask the model to investigate anything. It
hands the model the exact SQL, tells it not to substitute its own, and leaves it
doing the one part it's genuinely good at — explaining what a row in the result
means. I put it up at defencecore.com/audit with
no signup wall.

Why it's safe to paste into a production database

Every query reads a Postgres catalogue view — pg_tables, pg_policies,
storage.buckets. Those describe the shape of your database: table names, policy
definitions, bucket settings. There is no statement in the prompt that selects
from an application table, and none that writes.

That's a property of the SQL, not a promise you're asking a model to keep. You
can read all of it before you paste it.

The prompt

You are auditing the Row Level Security configuration of my Supabase project.

STEP 1 — Run this query exactly as written. Do not modify it, and do not
substitute your own queries. It reads only Postgres catalogue views
(pg_tables, pg_policies, storage.buckets): it cannot read a single row of my
application data, and it changes nothing.

with findings as (
  select 1 as rank, 'CRITICAL' as severity,
         'Table has no Row Level Security - readable by anyone with the anon key' as finding,
         tablename as object
  from pg_tables
  where schemaname = 'public' and not rowsecurity

  union all
  select 1, 'CRITICAL',
         'Policy grants read access to everyone (USING true)',
         tablename || ' -> ' || policyname
  from pg_policies
  where schemaname = 'public' and qual = 'true'

  union all
  select 2, 'HIGH',
         'Policy accepts any new row (WITH CHECK true) - records can be reassigned',
         tablename || ' -> ' || policyname
  from pg_policies
  where schemaname = 'public' and with_check = 'true'

  union all
  select 2, 'HIGH',
         'Storage bucket is public - any object URL downloads without auth',
         name
  from storage.buckets
  where public

  union all
  select 3, 'REVIEW',
         'RLS enabled but no policy - table returns nothing to my own app',
         t.tablename
  from pg_tables t
  left join pg_policies p
    on p.schemaname = t.schemaname and p.tablename = t.tablename
  where t.schemaname = 'public' and t.rowsecurity and p.policyname is null
)
select severity, object, finding from findings order by rank, object;

STEP 2 — Report the results as a table, most severe first, naming the exact
table, policy or bucket. If the query returns no rows, say so plainly instead
of looking for something else to report.

STEP 3 — For each finding, state in one sentence what someone holding my
public anon key could actually do with it.

STEP 4 — Describe the fix for each finding in words. Do NOT run, apply, or
offer to run any statement that modifies my database — no ALTER, no CREATE
POLICY, no DROP, no migration. I will make the changes myself.

STEP 5 — Finally, list which of these findings could silently come back after
a future migration or a future prompt, and explain why a one-time audit cannot
catch that.

Paste it into Claude Code, Cursor, or anything else connected to your project. No
agent handy? Copy the with findings as (…) block straight into the Supabase SQL
editor — the SQL is the audit, the prompt is only the part that reads it back
to you.

What the five checks actually catch

Tables with no RLS. Readable by anyone holding your anon key, which ships in
your frontend bundle by design. This is the one everybody knows about and still
the one that shows up most.

Policies where qual = 'true'. RLS is on, a policy is attached, and it
returns every row to everybody. This passes any audit that only asks is RLS
enabled — including most dashboard checkmarks and most agents.

WITH CHECK (true). A user can reassign a record they own to somebody else.
Almost always added to silence an insert error, not to deliberately grant
anything.

Public storage buckets. Correct for avatars. Wrong for the invoices and
scanned documents that end up in the same bucket because public buckets are where
uploads work on the first try.

RLS on with no policy. Not a breach — but it's why a feature quietly returns
an empty list instead of an error, and it's the usual prelude to somebody
disabling RLS to "fix" it.

Step 5 is the point

The interesting step isn't 1 through 4. It's 5: which of these can come back
silently?

All of them. A migration re-creates a table without its policy. A prompt adds
USING (true) to unblock a broken query. Someone flips a bucket public to debug
an upload at 1am. Your audit output looks identical the next time you run it,
because you don't run it again.

That gap is why I ended up building
Defencecore in the first place. A catalogue snapshot
tells you a table is open; it can't tell you who already read it. That's in your
Supabase logs, and on the lower plans those expire in days —
Defencecore reads them as they arrive and keeps the log
lines plus the incident built from them, so the evidence outlives the retention
window that would have deleted it. Read-only, so it can explain a problem and
never cause one.

Run the prompt first though. It's free, it takes thirty seconds, and roughly
everyone I've handed it to has found at least one REVIEW row they didn't expect.

The audit page →

Your AI-Built App Passed a Security Scan. Production Is Where the Story Starts.

Muhammed Semri — Wed, 12 Aug 2026 14:43:54 +0000

AI app builders are adding serious security features.

That is a very good thing.

Lovable recently announced AI-powered penetration testing for applications built on its platform. Its existing security tooling already checks areas such as source code, dependencies, secrets, and Row Level Security configuration before an application is published.

This is an important shift. Security is moving closer to the moment software is generated rather than being treated as something teams add months later.

But passing a security scan does not mean the security problem is finished.

It means the application passed a particular assessment at a particular moment.

Production begins immediately afterward.

A security scan is a snapshot

Pre-deployment security tools answer valuable questions:

Does the code contain a known vulnerability?
Are dependencies outdated?
Are database policies missing or overly permissive?
Is sensitive configuration exposed?
Can a tester bypass authentication or authorization?
Is the deployed application vulnerable to common attack techniques?

Every team should perform these checks.

The limitation is time.

A scan evaluates the application as it exists during the scan. The application will continue changing after that:

A coding agent generates another migration.
A developer temporarily relaxes a policy while debugging.
A new Edge Function is deployed.
An integration receives more privileges.
A secret is accidentally used in the wrong environment.
Real users begin exercising workflows nobody tested.
Automated traffic discovers an exposed endpoint.
A valid account starts behaving in an unexpected way.

None of these changes has to crash the application.

In fact, many security failures make an application appear to work better.

Removing a permission check can fix an empty response. Using an administrative key can make a failed request succeed. Making a storage bucket public can fix a broken image. Disabling Row Level Security can make missing rows reappear.

The feature works.

The boundary protecting the data no longer does.

The production backend is the real security boundary

A modern Supabase application is more than its frontend.

A project can include:

Authentication and session handling
Auto-generated data APIs
PostgreSQL and Row Level Security
Storage buckets and object access
Realtime subscriptions
Edge Functions
Service credentials and third-party integrations

Supabase records activity across these services in its platform logs. Those logs provide the production evidence of what the backend is actually doing—not what the code, prompt, or deployment summary says it should be doing. Supabase documents these log sources directly.

That distinction matters for AI-built applications.

A coding agent can tell you that it implemented authorization. A pull request can show a policy. A test can confirm that one expected request succeeded.

Production activity answers a different question:

What is happening to the application now?

That includes legitimate users, automation, developers, coding agents, integrations, misconfigurations, and attackers. Once their actions reach the backend, the backend sees the result without caring which tool generated the code.

Code review, pentesting, and monitoring solve different problems

These security layers are complementary.

Code and configuration scanning

This examines what has been written.

It is useful for finding vulnerable dependencies, leaked secrets, dangerous patterns, and incorrect configuration before deployment.

Penetration testing

This actively exercises the application like an attacker.

It is useful for finding exploitable endpoints, authorization failures, injection paths, exposed data, privilege escalation, and business-logic weaknesses.

Lovable’s move to make this more accessible is meaningful precisely because “the application builds” and “the application resists attack” are different outcomes. Lovable describes that gap in its pentesting announcement.

Continuous production monitoring

This observes what happens after deployment.

It is useful when:

The application changes after its last assessment.
A valid credential is used in an unsafe context.
Authentication traffic becomes suspicious.
A data-access boundary changes.
Production behavior differs from the expected application flow.
An attacker begins exercising a weakness that was previously unknown.

A scan asks, “Can this be exploited?”

Monitoring asks, “What is happening right now?”

A production application needs both answers.

The AI development loop makes continuous visibility more important

Traditional development usually creates friction between an idea and a production change.

Someone writes code. Someone reviews it. Tests run. A deployment is prepared. The change reaches production.

AI coding compresses that loop.

A developer can describe a feature, approve the result, and deploy it within minutes. That speed is valuable, but it also means security-sensitive changes happen more frequently.

Consider a common Supabase debugging sequence:

A query returns no rows.
The coding agent assumes the table or query is incorrect.
It changes an access policy so the expected data appears.
The feature starts working.
The change is deployed.

An empty result and a denied result can look similar from the application side. A broader policy may therefore look like a successful fix.

The agent completed the task it was given. The developer saw the feature work. The application may continue operating normally.

The security regression becomes visible only when someone deliberately reviews the policy—or when production activity exposes its consequences.

This is not an argument against coding agents.

It is an argument for giving fast-moving development teams an independent view of the backend.

Where Defencecore fits

Defencecore is a continuous security monitor for Supabase applications.

It connects to a Supabase project with read-only access and watches the platform activity the project already produces across Auth, Postgres, API traffic, Storage, Realtime, and Edge Functions.

When something requires attention, Defencecore opens an incident that includes:

A plain-language explanation
The affected part of the project
Relevant production evidence
A recommended investigation or remediation plan

That plan can be handled manually or passed to a coding agent such as Claude Code or Cursor.

Defencecore does not modify the database, deploy code, rotate credentials, or automatically rewrite production. Read-only operation is intentional: the system watching production should not have the ability to become the production incident.

You do not need to instrument every generated feature or depend on a particular AI builder. If the application uses Supabase, the relevant backend activity reaches the same production surface whether the frontend was created with Lovable, Bolt, Replit, Claude Code, Cursor, or by hand.

The security stack for AI-built apps

A sensible workflow now looks like this:

Generate quickly.
Review security-sensitive code and configuration.
Scan before publishing.
Pentest important releases and workflows.
Monitor the production backend continuously.
Give developers—or their coding agents—enough evidence to respond safely.

AI has dramatically reduced the cost of creating software.

The next step is reducing the cost of understanding what that software is doing in production.

That is what we are building at Defencecore.