RowShield for agencies: every client backend, one pane
An agency's Supabase problem is arithmetic: dozens of client projects, each one migration away from a world-readable table, and nobody able to remember which client had the permissive bucket. Monitoring has to work across a roster, route the right alert to the right channel, and produce evidence a client can read without a translator.
This page walks that workflow: organising many projects under one roof, tuning alert routing per destination, handing clients evidence instead of assurances, and the boundaries of what any monitor can honestly do for an agency. It is hand-written guidance about product workflows, and it marks where automation stops.
RowShield does not detect this yet. This guide gives you the catalog queries to check it yourself. The nine rules that do ship are listed on the rules index.
The roster problem
Audits bill by the hour and decay by the sprint: the report you delivered in March describes a project that four deploys have since revised. Memory fails across clients for the same reason it fails inside one team — posture is invisible until probed, and nobody probes seventeen backends weekly by hand. Meanwhile the cost of a miss lands in your client's production, which is the most expensive place an agency learns about Row Level Security. The arithmetic points at scheduled, centralised checking; the rest of this page is what that looks like in practice.
Organising many projects
Each client backend connects as a project inside your organisation, using a catalog-read credential you generate per project and can revoke independently. The dashboard lists every project with its health score, so the roster reads at a glance and the weakest backend identifies itself before a client email does. Scale maps to plans: pilot on Free with one project at daily scans; Team carries fifteen projects on fifteen-minute scans with unlimited seats, so engineers can join and leave without touching client connections; Growth is quoted individually above that. Rates are on the pricing page, which takes an email until checkout opens; the free audit runs today with nothing but a URL.
Routing alerts to the right room
Destinations are per-project and plural: Slack Block Kit, Discord embeds, HTML email, or a generic webhook for anything else. Each destination carries its own severity threshold, so the pager channel takes critical-only while the ops room receives everything — the agency-specific trick being that different clients route to different rooms entirely. Alerts fire on transitions — created, regressed, resolved — rather than on every scan, so a project sitting broken pages once and a quiet channel means unchanged. Retried scans stay idempotent, and webhook URLs are stored masked.
Evidence you can forward
Every finding names the rule, the table or bucket, a plain-language rationale, and remediation SQL generated from the client's actual columns — handable to whoever maintains their migrations. Leaked-data reports carry column names and counts, never contents, so forwarding a finding forwards no data. Scan diffs read as change reports for client meetings: what appeared, what came back, what resolved since last month. And the CLI gates their pipelines too — exit codes 0, 1 and 2 distinguish clean, findings-at-threshold and broken-run, so a client-side deploy can refuse to ship a naked table.
Boundaries, and getting started
Marked honestly: RowShield does not automate agency operations — no ticketing integration, no client reporting decks, no timesheets — and it monitors only projects you are authorised to watch, which for client workloads means the agreement says so before the connection string moves. It reads pg_catalog and bucket metadata only, never rows, produces engineering evidence rather than legal or compliance advice, and is an independent product, unaffiliated with and not endorsed by Supabase. The handover query below is the one worth running before accepting any new client backend:
SELECT n.nspname AS schema, c.relname AS table_name,
c.relrowsecurity AS rls_enabled, c.relforcerowsecurity AS forced
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'p') AND n.nspname = 'public'
ORDER BY c.relname;Frequently asked
- Can I monitor several client projects under one login?
- Yes. Projects attach to your organisation and seats are unlimited on the Team plan, so engineers join and leave freely without touching any client's connection.
- Will monitoring expose client data to my team?
- No. Scans read pg_catalog and bucket metadata only, the probe reports tables by column name and count, and row contents are never selected, stored or displayed.
- What happens when a client engagement ends?
- Remove the project and its scans stop immediately; revoke the catalog-read credential on your side at the same time. Disconnecting touches nothing in the client's infrastructure.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit