Security

Section 01What we do not claim

Some of that will change as the company grows, and when it does it will be because an assessor said so, not because a page said so. What follows is what the software actually does today, described specifically enough that you could ask us to prove any of it.

Section 02Agencies are kept apart

Every record in the database carries the agency it belongs to, and the database itself refuses to return a row belonging to another agency. It is enforced at the data layer rather than by the application remembering to filter, because an application forgets and a database does not.

That separation is covered by automated tests that run on every change and block it from shipping if one fails. A leak between two agencies in criminal-justice data is the failure that ends this company, so it is treated as a test surface rather than something to check in review.

There is no feature that shows one agency anything about another’s cases, and there is not going to be one.

Section 03The sensitive fields are encrypted

Social security number, date of birth and driver’s licence number are encrypted in the database, and the key lives in a separate vault rather than beside the data. Everything travels over an encrypted connection.

Uploaded documents sit in private storage. Nothing is served from a public address, and a link to a document is generated on demand and expires within minutes.

Section 04Reading a sensitive field leaves a record

Reading an encrypted field is not an ordinary database read. It goes through a function that writes the log entry first and decrypts second, and it will not run without a stated purpose. So there is a permanent record of who read what, when and why, including reads that were refused.

That is what makes it possible to notice somebody looking up a person who is not connected to any of their cases, which is both a privacy problem and, in this industry, a safety one.

The money ledger, the case status history and the audit log are append-only. Entries are added and never edited or removed, and that is enforced in the database rather than by convention, so it holds even for our own administrative access.

Section 05Our own access to your data

Our support staff can look at an account when there is a reason to. Read-only by default. Anything more needs a stated reason and expires on its own. Every action is written into your own audit log, where you can see it.

We did not build silent impersonation into this product. If we were in your file, you can see that we were.

Section 06Accounts and sign-in

Staff sign in with an email address and a password, with a second factor available and required for owners. Co-signers and defendants never get a password at all: they get a one-time code by text and short-lived links that expire, because a password is one more thing to lose and one more thing to steal.

Section 07What we have not done

A security page that lists only strengths is marketing. These are the honest gaps as of the date at the top.

• No third-party audit or certification of any kind, as stated above.
• No published uptime commitment.
• No independent penetration test has been commissioned yet.
• No bug bounty programme, though a report is very welcome and we will answer it.
• Formal incident response and breach notification procedures are being written, and they are one of the things counsel is reviewing.

OPEN FOR COUNSEL · breach notification obligations across the states we operate in, notification timelines, and whether a customer-facing commitment on them belongs in the terms.

Section 08Reporting something

If you have found a security problem in Bondskeeper, write to hello@bondskeeper.com with "security" in the subject line. A person reads it, we will answer, and we will not threaten anybody who reports something in good faith.