About
Your database is on the internet. The policy is the only door.
RowShield tests the row-level security your Supabase project actually enforces, and keeps testing it as the schema moves underneath, once a project is connected.
Why it exists
Supabase is reachable directly from the browser. That is the point of it, and it means the anon key in your frontend is a public credential by design. What stands between that key and every row in the table is row-level security — a set of policies that has to be right on every table, for every operation, for every role.
Policies are written once and then left alone. Schemas are not. A column is added, a table is split, a join gets a new path, and a policy that was correct in April quietly stops covering what it was written to cover. It still exists, still parses, still runs. Nothing errors.
Once a project is connected, RowShield runs the tests continuously against the live project rather than reading your migrations, watches for schema drift as it happens, and reports the specific query that returns a row it should not.
Every finding is a query
A report names the table, the role and the statement that reproduces it. You can run the same query yourself and see the same rows.
Drift is a first-class event
A new table with no policy, or a column that widens what an existing policy exposes, is reported the moment it appears — not at the next quarterly review.
The audit runs before you connect anything
The free audit works against what your project already exposes publicly. Credentials come later, if you want monitoring.
Least privilege, always
Continuous monitoring uses the narrowest credential that can run the checks, and nothing it does not need is ever requested.
Security & data handling (before you connect)
The Instant Check asks for nothing. Continuous monitoring asks for a Postgres connection string, which is treated as the most sensitive thing the product holds. The security page has the full detail.
The connection string is encrypted
Envelope-encrypted at rest with AES-256-GCM, and decrypted only inside the scan worker for the length of a scan.
Catalog-only queries
A fixed set of statements against
pg_catalogand storage metadata. No inserts, updates or deletes, and none of your rows are read into storage.Revoke it yourself
Drop the database role, or disconnect the project from your settings. Either stops access immediately, without a request to us.
The Instant Check stores nothing
The URL and the optional anon key are used for one request and then discarded.
Team and Growth customers can request a DPA and the subprocessors list from legal@teamveristria.com.
Questions we get asked
- My Supabase dashboard says the table is protected. Why is it still readable?
- Because the dashboard reports configuration and the anon key exercises behaviour. Three things routinely separate them: row-level security enabled with a policy that evaluates to true unconditionally, a table shipped with RLS never enabled at all, or a policy that was correct for the old schema and no longer covers a column or join path added later.
- What is a tautological RLS policy?
- A policy whose condition is always true — USING (true) being the clearest example. It satisfies every tool that checks whether a policy exists, and it permits every row to every caller. It is decoration rather than protection, and it is one of the most common findings on an AI-generated Supabase project.
- Why do RLS policies stop working over time?
- They do not stop working; the schema moves and they keep doing exactly what they were written to do. A column is added, a table is split, a join gets a new path. The policy still exists, still parses, still runs — and no longer covers what it was written for. Nothing errors, which is why drift is only visible if something tests the live project.
- Is the Supabase anon key safe to expose?
- Yes, by design — it is meant to be public, and it is already in your frontend bundle. What makes it safe is row-level security actually covering every table. Without that, a public anon key is a public read of your database, which is why the anon key being safe and your data being safe are two different questions.
- Why does the same Security Advisor warning keep coming back?
- Usually because the fix was applied to the database and the migration that recreates the object was never updated, so the next deploy restores the original state. That is a drift problem rather than a fix problem, and it is the reason a one-time audit is worth less than a scheduled one.
Part of Veristria
RowShield is a Veristria product
Veristria builds verification infrastructure for teams shipping software faster than they can review it. It was founded by Lars O. Horpestad, the author of Å ta smartere beslutninger med AI (2023), a practical guide to large language models.
All three Veristria products work the same way: look at what actually shipped rather than what the source intended, prove the finding, and say plainly what to change. RowShield applies that to the backend you expose.
KeyDrift
Finds the API keys and secrets that AI coding tools leave behind in client-side JavaScript bundles.
keydrift.devFeeGuard
Finds the Stripe Connect application fees a refund leaves behind, from an export you paste — read-only, no credentials. 90-day lookback. Detection stays free.
feeguard.devWho runs this
RowShield is built by Veristria (Norway), founded by Lars O. Horpestad. Veristria is a Norwegian aksjeselskap (AS) under incorporation (filed 24 August 2026); the organisation number is published on veristria.com/imprint when registration completes. Veristria is separate from AI ThinkLab AS (org.nr. 933 078 523), the founder’s prior company.
Address: Veristria, Sofie Steinnes'veg 9A, 4352 Kleppe, Norway.
The full company details are on the imprint and on Veristria’s About page. Sales, support, security, legal, press and billing each have a desk at @teamveristria.com, or call +47 988 36 369. We only email from @teamveristria.com, @useveristria.com, @meetveristria.com, @veristriagroup.com, @veristriahq.com, @veristriaworks.com and @withveristria.com.