Effective 8 August 2026

How we hold your access

You are being asked to connect a production database to a company you just met. That is a real thing to ask, so this page states exactly what Lockvane can do with what you grant it, and what it deliberately cannot. Everything here is a property of how the product is built, not a promise about intentions.

01

Read-only until you say otherwise

A connection starts read-only. Lockvane can look at your schema, your policies, and what an unauthenticated request gets back. It cannot change any of it.

We do not store a key that can write to your systems. When you press Apply for me, you authorise that one change at that moment, we run it inside a transaction, we rescan to check it held, and the elevated grant does not persist. The statement that undoes the change is shown to you before you agree to it.

02

Nothing deep happens without proof you own it

The free scan reads only what your application already serves to every visitor. Anything that queries your database is gated behind a DNS record you publish or an account you connect.

Verification is re-checked on a schedule. If the record disappears, deeper assessment pauses rather than quietly continuing on an asset you may no longer control. Verification proves control. It is not a security state, and Lockvane never displays it as one.

03

Your findings cannot be read by another account

Isolation is enforced by the database with row-level security, evaluated on every query against the signed-in identity. It is not a filter in application code that a missing where clause could skip.

This is the same class of control Lockvane checks for on your systems, which is a reasonable thing to hold us to.

04

Where your data sits

In transit
TLS on every connection, between you and us and between us and anything we read.
At rest
Encrypted by our database provider. Access tokens are stored as secrets, not in ordinary columns.
Credentials
Passwords are handled by our authentication provider and stored hashed. Lockvane never sees one.
Card details
Entered on the payment provider's own pages. They never reach a Lockvane server.
05

What we deliberately do not build

Some capabilities would make the product more powerful and make a breach of Lockvane far worse. We have chosen not to have them:

  • No stored credential that can write to your database on a schedule.
  • No proxying of your production traffic.
  • No agent installed inside your infrastructure.
  • No copy of your source code beyond what is needed to run a scan and show you the evidence.

The reasoning is simple. The blast radius of compromising Lockvane should be closer to “an attacker learns what your app already tells the public” than to “an attacker owns every customer’s database”.

06

Turning it off

Disconnect an asset in the app, or revoke Lockvane at the provider. Either ends our access on the next check, and you do not need to ask us. Deleting your account removes the account, its connections, and its findings.

07

What we do not claim

Lockvane holds no third-party security certification today. When that changes this page will say so, with the report available under the usual conditions. We would rather say nothing than imply an audit that has not happened, which is the same standard we apply to your scan results.

08

Found something?

Report it to security@lockvane.com. The disclosure policy sets out what is in bounds for testing us, how quickly we respond, and how we credit you.

For anything else, support reaches a person: support@lockvane.com.