How RowAttest handles your credentials

A service role key ignores every Row Level Security policy in your project — it can read, change, or delete any row in any table. Handing it to anyone is the most sensitive thing you can do with a Supabase project. This page says exactly what we collect, where it lives, what touches it, and how you take it back.

When you connect a project by hand we ask for exactly four things: your project URL, the anon key your app already ships to every browser, a service role key, and a database connection string. If you connect with Supabase instead, we ask for two: your approval on Supabase's consent screen and your database password. Nothing else. We never ask for your Supabase account password — no security tool needs it, and you should not give it to one.

The connect form sends your credentials over HTTPS, only when you submit. The service role key and connection string are masked on screen and built so browsers and password managers never offer to save them — secrets do not belong in an autofill list.

Your keys and connection string are encrypted before they ever touch a database row. The encryption key is not in the database — it lives only in the server environment, so a stolen copy of our database is just ciphertext. The project reference stays readable so your dashboard can tell projects apart — it is the same identifier your app already exposes in every request. And the table that holds your credentials is locked down the way we tell you to lock down yours: RLS enabled, zero policies, deny by default. No browser session can read or write it — only our backend gets through.

Your secrets are decrypted only while they are being used: inside our worker, while a run or a fit check is executing (a fit check runs when you connect a project, save its database password, ask for one, confirm your access model or start a run), and, for Supabase-connected projects, on our server for the moments it takes to save the project you picked or check a database password you entered. Nowhere else. They never go into logs, never appear in reports, and are never shown back to you after saving — if you cannot see them, neither can anyone looking at your screen.

We never resell or share your credentials, never pass them to third-party services, and never move them out of our infrastructure. Outside your runs we touch your project only when you act: a connectivity and size check when you give us the database connection details — that is how we catch production-scale projects before any test runs; a fit check, which reads your schema and policies, when you connect a project, save its database password, ask for one or confirm your access model; and, for Supabase-connected projects, a read of your organization's project list when you connect or reconnect. There is no analytics pipeline, error tracker, or partner with a copy.

Connecting a project happens on this website only. Our API and MCP tools cannot submit, read, or return credentials — by design, not by policy. An AI assistant using RowAttest never holds your keys in its context, because keys that enter an assistant's context can end up in places you did not intend. We removed the possibility instead of asking you to be careful.

Delete a project from your dashboard at any time and its stored credentials are hard-deleted with it — gone the moment you confirm, no soft delete, no recycle bin, no recovery window that is really just retention. For a project connected with Supabase, that destroys our copy of the authorization; the RowAttest entry in your Supabase organization's authorized apps stays listed until you revoke it there. Closing your account hard-deletes every credential we stored.

You do not have to trust our delete button — and you should not have to. For a project connected by hand, rotate the service role key or change the database password in your Supabase dashboard, and our runs stop working that instant. For a project connected with Supabase, revoke RowAttest in your Supabase organization: the authorization we hold is dead from that moment, and no run can start until you reconnect. Either way the next run fails loudly with an error; nothing degrades silently. Revoking at the source always beats deleting at the destination.

RowAttest is built for staging and test environments. Point it at a staging project, not production. Our tests sign in as their own synthetic users and write only rows they created, but a service role key is still the most powerful credential your project has — treat it that way. If a project looks production-scale, we stop and require an explicit confirmation before continuing.

If we ever have reason to believe stored credentials were exposed, we email affected account owners with what we know, what we did, and what to rotate — without undue delay. Not a line buried in a changelog.

If you connect with Supabase, RowAttest stores no API keys. It keeps the Supabase authorization and, once you add it, your database password, both encrypted. Each test run and each fit check uses the authorization to get the project's API keys and database address from Supabase for that run or check only. Revoking RowAttest's access in Supabase stops all further runs.

Questions about credential handling: info@rowattest.com. Changes to this policy are announced the same way as changes to our terms.

← Back to RowAttest