Privacy Policy

2. What we store and can read

This list is meant to be exhaustive. If something about you is not on it and is not in section 3, we do not have it.

• Your email address It has to be readable, because it is how a sign in is routed and how a message reaches you.
• Your display name The name you chose to be called in the application. It is plaintext today, and moving it into the encrypted half is planned work rather than a thing we have already done, which is why it is listed here.
• Your account status and its dates Whether the account is active or suspended, when it was created, and when it was last changed.
• Session records, as hashes A session is 32 random bytes, and what we keep is a SHA 256 digest of them rather than the token itself, along with when the session was created, when it expires, when it was last seen, whether it was signed out, and the address the sign in came from. A copy of that table hands nobody a working credential.
• Grants, and the whole trail of their use Every delegation you issued: its id, the scopes it carries, the institution it names, when it expires, how many times it has been used and when it was last used, and the signed statement behind it. A grant statement names records by id and by scope and never by content.
• Your audit trail Account creation, every sign in and every failed attempt, sessions opening and closing, grants minted and revoked, every shared read, every regulated disclosure, every write to the encrypted store and every agent draft. Each entry holds the action name, the delegation it happened under, the address it came from, the time, and a small object of identifiers and counts. It deliberately never holds a value out of your record: an audit log that copies the data it audits is a second place to breach.
• Organisation and posting data Companies, their rosters, their job postings, the matches computed between a posting and a record, pipeline notes, and the access requests an institution made of you. None of it is user data in the sense the rest of this list is, and all of it is readable.
• Applications Which institution, which posting, when it was sent, and what stage it reached.
• Notifications What the service told you and when you read it.
• Uploaded documents, as bytes on disk A document you upload is written to the filesystem of the server as the bytes you sent, and its filename, type, size and label are stored beside it in the database. These are not encrypted, and that is the plainest exception on this page: what you upload, we can open.
• The regulated sections you chose to fill in Work eligibility, the sensitive identifiers, which are a date of birth and the last four digits of a social security number and never the whole number, the voluntary self identification answers, and your consent trail. Each sits outside the record document, each answers to a scope of its own, and each is absent entirely from a read that did not delegate it. They are readable by us.
• Verification rows Which kind of check, its status, who reviewed it, their reference and their notes, and the dates. The evidence behind a check never enters this service at all.
• Record metadata For each encrypted record: which scope it belongs to, its type label such as work_history or education, its version, roughly how big it is to within a padding class, and the times it was written. The label is not the content.
• Key material that is already ciphertext Wrapped keys, sealed keys, public halves, salts, key derivation parameters and nonces. They are stored in the clear because they are ciphertext, and they open only with something we do not have.

What that adds up to is worth stating rather than glossing. Somebody with our database learns who has an account and when they signed up, how many records they hold in each scope and roughly how big each one is, when they edit, which institutions they applied to and which advanced them, which agents they paired, how often each grant is pulled, and their addresses. That is a real social graph. It is not the record, and the difference matters, but a page that listed what is encrypted without listing what is inferable would be marketing rather than a privacy policy.

4. What your browser keeps, and why there are no cookies

No cookies are set. Not by the marketing site, not by the application, and not by the interface they call. Authentication is a bearer token on a request header rather than an ambient credential a browser attaches by itself, so there is nothing here that could be sent along with a request another site made on your behalf. There is no analytics script, no advertising tag and no outside embed on any page of this site.

The application keeps a small number of values in this browser's local storage.

• verigrant.token Your session bearer token, so a reload does not sign you out. Signing out removes it.
• verigrant.v2.<your address> The salt, the key derivation parameters and the account id this browser needs in order to derive your keys from your password. It is not a key and it opens nothing on its own.
• verigrant.log.key and verigrant.log.head The transparency log's publication key this browser recorded the first time it saw it, and the newest signed tree head it has accepted. They exist so that a later answer claiming a different key is refused rather than believed.
• verigrant.onboarding A flag saying the new account guide is still running.
• verigrant.rpkey.<organization>.<key> Only present for a recruiter whose institution reads shared records in this browser. It is that institution's own private key, sealed under a passphrase the recruiter chose, so that a candidate's disclosure can be opened here rather than only by their software. We were never sent that key and never sent the passphrase, what is stored is unreadable without it, and the control that put it here can forget it again.
• verigrant.api_base Only present if you pointed the application at a different service by hand.

One further value is kept in session storage, which the browser empties when the tab is closed.

• verigrant.demo.depth Whether the example account explains itself plainly or shows you how it works. It is set by the control that asks, it is about the example rather than about you, and no account is needed to have one.

What is deliberately not there is the key that opens your record. It lives in memory for as long as the tab is open and is never written to storage, which is why a new tab asks for your password again. The institution key in the list above is the one private key this browser stores at all, it is stored sealed rather than in the clear, and it is opened the same way: in memory, for one tab, after a passphrase. Clearing your browser's storage for this site signs you out and forgets the derivation parameters; it does not delete anything we hold, and section 8 is how you do that.

6. How long any of it is kept

Your record is kept while your account exists, and the audit trail is kept the same way: it is the history of your own custody, it is yours to read, and trimming it would take away the evidence it exists to provide. A revoked or expired grant stays in the trail as history rather than disappearing, because the fact that it was issued remains true after it is withdrawn.

Erasure is the end of all of it. Destroying your account destroys every row held under it, your documents on disk included, and the service counts what it deleted before and after and refuses to commit if anything survived. One record is written and kept: a row saying an erasure happened, carrying the time, the counts, and a hash of the address rather than the address. It has no link to the account it is about, because the account no longer exists. A service that could not account for its own deletions would be asking you to take them on trust.

Background work is queued as identifiers rather than as data. A queued job says which user and which document or record it concerns; it does not carry the profile, the bytes or any secret, so the queue is not a second copy of anything, and a job whose subject has erased their account simply finds nothing.

8. Where it lives, how to take it, how to end it

Everything is held on a server operated by Verigrant: one Postgres database behind an internal service that is not exposed to the internet, with uploaded document bytes on that machine's own filesystem. The public front door for institutions and agents is a separate small process that holds no database handle and no key material, and decides nothing about who may read what.

To take it out. In the application, ask for your export, which calls GET /me/export. It hands you everything we hold about you in one document and names every table it drew from, so the claim of completeness is one you can check rather than one you have to accept. Three things are deliberately not in it: the hashes of your session tokens, which are the one part of that table an attacker would want, your stored model provider key, which leaves once and never comes back, and the Vera IDs themselves, which were shown once and stored as hashes. The encrypted half comes out through the record and keyring routes, in a form your own client can open.

To end it. In the application, delete your account, confirmed with your own credential. It is irreversible, it takes the sessions and the grants with it, and you are handed a receipt saying how many rows went from each table. Take the export first if you want one.

To correct it. Every field is yours to edit in the application, at any time. A consent record is the one thing that cannot be edited or deleted, and that is deliberate: it is evidence of an act, and evidence that can be rewritten afterwards is evidence of nothing. Withdrawing a consent adds a record saying so, and both stay.

We do not sell or share personal information and do not use sensitive personal information for any purpose beyond providing the service; you may still write to us to limit it.

To ask us something. Write to support@vxctrl.com. If your local law gives you a right we have not named here, tell us and we will honour it.