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.
• Our attestation on each disclosure an AI assistant sends When an assistant you paired discloses part of your record to an institution, we check that it acted under your authority and sign a statement saying so, for that one disclosure. We keep it, and the institution that receives the disclosure gets it too. It names the disclosure, that institution, the address that institution knows you by, the scopes and when it was signed. It names no account, no assistant and no key that another institution would also see.
• 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 Institutions of every kind, which now includes a merchant that takes orders, 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.
• The outside of each document you upload The file itself, its name, its type and your label for it are sealed in your browser before anything is sent, and are in section 3. What we can read is the rest: that the document exists, its kind, such as a résumé or a transcript, its size to within a padding class, a digest of the encrypted bytes, whether it is your default of its kind, and when it was added, changed or encrypted.
• Documents stored before we began sealing them A document that reached us before documents were sealed in the browser is held as you sent it: its bytes are on the server's disk unencrypted, and its filename, type, size and label are readable in the database. What you uploaded then, we can open. It stays that way until you choose Encrypt this file in the application and then destroy the unencrypted copy, or delete the document. Encrypting it keeps the old copy on disk, served by nothing, until you destroy it, because only you can check that the encrypted copy opens.
• Your answer bank, apart from the answers For each screening question you saved an answer to: the question as the employer wrote it, the kind of answer it takes, any choices the form offered, its topic, which of your documents answers it if one does, and when you last used it. The question is readable by us, because the service is sent it each time an answer is saved or looked up and has to show it back to you. The answer itself is sealed in your browser and is in section 3. An answer saved before we began sealing answers is held as you gave it and is readable until you save it again or delete it.
• 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.
• Your public signing and receiving keys for each institution Each institution knows you by an address of its own, and we keep that address. On it we store two keys your browser makes for that institution alone: a signing key, for what you disclose to it, and a receiving key, for what it sends you. These are the public halves only, and they open nothing.

Agents, passes and orders

Since 3 October 2026 an AI agent you paired can carry a pass from us to a website, drop an order with a business, fill a business's form from your record, follow a plan of steps you approved, and receive booking updates and messages for you. Each of those leaves something with us. This list says, for each one, what it is, whether we can read it, and how long it is kept. None of it exists for an account that has never paired an agent.

• The sites and actions you allowed each agent For each agent you paired: the sites it may visit, the purposes and actions you allowed, the longest pass it may ask for, and its daily cap. Readable by us, because every request the agent makes is checked against it. Kept while the pairing stands.
• Which site a pass was for To issue a pass we have to know the site, to work out your address there and to check it against the list above. We see it at that moment and keep no record of it we can read. What we keep is the pass id, your account and the pairing, for thirty days, for the daily cap and for an abuse report, and a tag derived under a key the database does not hold, which names the site to nobody who reads it, us included. An abuse report about a pass can be answered with the pass id and the account behind it, never with the site. The site itself is written only into a receipt sealed to your own key, which we cannot open.
• Your address at each site, and what a site is told about you Each site knows you by an address of its own, derived from a secret we hold, so no two sites share an identifier for you, and we keep nothing that lists them. A pass tells a site that an accountable person stands behind this agent, for a purpose, until a time. It carries no name, no email address and no field of your record.
• Purchase approvals When you approve a purchase for your agent we keep the approval: which agent, the step of the plan it belongs to, the ceiling you set, the level you approved it at and when, and a pay grant bound to one offer. Payments are in test mode today: no card is charged and no money moves. The approval is kept with its plan, and the grant's id for thirty days after it ends.
• Orders An order your agent drops with a business is a row we can read: the business, your address there, the offer, the amount and its ceiling, the delivery state, and the signed outcome the business returns. It has to name the business, because we deliver it there. The signed order itself, with your traveller details sealed inside it, is emptied ten minutes after the business confirms delivery, and the whole row is deleted seven days after it arrived, delivered or not.
• Traveller details on their way to a business Your traveller details live in a part of your record that no agent and no grant can reach. When your agent needs them for one offer, your browser seals a copy to that business's own key and leaves it with us, and the agent takes the sealed copy and puts it in the order. We hold ciphertext we have no key for, and no row names the site or the offer. The copy is deleted ten minutes after the agent first takes it, and a day after it was left in any case. You can withdraw it before the agent takes it.
• Forms filled with Verigrant When you fill a business's form from your record, your browser fetches the form from the business, seals your answers to the business's key, and sends us the sealed result. What we can read is the business's domain, your address there, the ids of the fields you filled, a size class, and a consent statement of field ids and purposes. Never a value. The row is deleted a short window after the business confirms delivery, and after a bounded time whether or not it was.
• Booking updates and masked contact A deliver back grant names the business, your address there, the booking's reference, when it was made, and the travel date if you gave one. A masked contact address is an address of its own for one business and one matter. Both are readable by us, because every message that arrives is checked against them. What the business sends through them is sealed to your key before it leaves the business; we keep only the envelope, and the notice that something arrived says which business and that it is about a booking, never what it says. A grant lasts for the window you chose, thirty days unless you say otherwise and never more than four hundred; a masked address lasts until you switch it off. The status lists that tell a business a grant was revoked are signed lists of bits that name nobody.
• Task plans and step approvals A plan your agent proposes is a chain of steps with ceilings on money and on count. We keep the plan, the level you approved it at, each step's approval and when, and each revocation. We keep no name for the plan's site, only a tag derived under a key the database does not hold. The plan's full account is in your sealed receipts.
• Receipts Every pass, pay grant, order, plan and update event writes a receipt sealed to your own key before it is stored. We can write one and cannot read one back. Your own client opens them, and you can export them.
• A paired agent and your record An agent you paired in auto mode holds the keys to the sections of your record its preset names, and nothing outside them. It never holds your password, your recovery key or your master key, and it never holds your traveller details, which travel sealed to the business. In review mode it holds nothing at all.

The agent network: operators, sites and connected assistants

An AI agent can also come to Verigrant on its own account rather than on a person's. Its operator registers it with us and declares what it is for, and the agent renews a short lived credential of ours that tells a website who stands behind it. A business can list its site so agents find it, and can have its own door post counts of agent visits to a dashboard we host. A site can report an agent to us. A person can connect an AI assistant to their account with one click instead of pasting a code. And an agent that wants the highest trust can send its requests through Verigrant's own relay nodes. None of this is about a person's record, and most of it is about companies and software. This list says, for each of them, what we hold, why, for how long, and who sees it. Where something is public it says so, because the point of a directory is that it is read.

• An agent operator's registration An operator is a company or a developer running agents, and it is not a Verigrant account. We hold the name it gave, its contact email address and that address's domain, when the address was confirmed, which version of the Operator Terms it accepted and when, the domain it claimed for level B with the proof token it publishes and the times we checked it, and, if we revoked it, when and why. The code we mail to confirm an address is kept as a digest for a day. A sign in token is kept as a digest, lasts ninety days, and is marked revoked at the end rather than deleted. All of it is readable by us and by the operator itself. What is public is less: from level B the directory lists an operator by its proven domain and its standing, never by the name it typed and never by its email address, and a level A operator is not listed at all. There is no route yet by which an operator deletes its registration, so a registration is kept until the operator asks us to remove it by hand. A revoked registration is kept on purpose, so that the same address cannot register again while the revocation stands, and a revoked operator's proven domain is held against other claimants for ninety days.
• Each agent and its keys For each agent an operator declared: a name, its purposes from a closed list (assist, search, research, training), the model or framework it runs, the networks it sends from, the number of requests a day it expects to make to a site, and an abuse contact address. For each of its keys: the public half, its thumbprint, whether it was given to us directly or read from the operator's own key directory, when we last saw it published there, and when it was revoked. Readable by us and by the operator. Much of it is public by design: the credential the agent carries to every site names the agent, the operator, the operator's proven domain, the level, and the declared purposes, framework, networks and rate, and we publish each agent's live public keys in a hosted key directory anybody can fetch. A key's thumbprint belongs to one agent for good, revoked or not, which is what stops a revoked key coming back under another name, so a revoked key's public half is kept.
• Credentials, the transparency log and the status lists Every credential we issue leaves a row naming the agent, its operator, the key, the level, a digest of the credential, when it was issued and when it expires. It exists so the hourly cap holds and so an abuse report can be matched to a real issuance, and it is deleted thirty days after the credential expires. The nonce on each renewal request is kept for ten minutes so the same request cannot be replayed. Each issuance is also written as a leaf in our transparency log, naming the agent and the operator by id, the level, the key thumbprint, the signing key, the times and the digest of the credential. The log is append only and public, so a credential nobody can find a leaf for is a forgery anybody can name, and a leaf cannot be removed. A level A operator has no public name, so a log leaf naming its id names nobody a reader can identify; from level B the id resolves to the proven domain only. The status lists a site reads to learn that a credential was revoked are signed lists of bits that name nobody; fetching one needs no credential and does not tell us which agent the site cares about.
• The institution or the officer behind an operator An operator reaches level C when an institution registered with us stands behind it, and level D when a named person does. The one time code the operator hands over is kept as a digest for seventy two hours and deleted a day after that. The business link names the operator, the institution, the account that entered the code (cleared if that account is later deleted) and when. The officer link names the operator, the officer's account, the full name and title they gave, the assurance level we observed, and when. The operator can read both links, name and title included, since it asked for them. The officer link is personal data of that person: it is in their export, it is erased with their account, and erasing it ends the operator's level D at once.
• A listing in the agent directory A business that lists its agent front leaves with us the site, the name and description it wrote, up to eight categories, an address and a map position if it gave them, the front's address, the levels and purposes it accepts, the proof token it publishes, when the proof was last checked and last held, and, if it was delisted, when and why. The listing is private until the business proves it controls the site, and public from then on: anybody can search it, and that is what it is for. A claim never proven is deleted after fourteen days. A proven listing is kept while the business keeps it, goes when the business's organisation is deleted, and is delisted but kept when its proof disappears, so that it can come back when the proof does.
• The hosted dashboard A business opts in, and from then on its own door posts us one row per day, per operator, per level and per purpose, holding counts: how many of each operation were called, how many of each action were taken, and how many ended in each outcome. Nothing else is accepted. A row with an address, an email, a request, a response or an agent id in it is refused without being stored or echoed, and a count's label cannot be a name, a phone number or a card number by construction. The rows name an operator by its public id and never an agent and never a person. The business reads its own rows and nobody else's; we can read them; an operator does not see them. Opting out stops new rows at once, and the rows already posted stay with the organisation, which can still read them, until the organisation is deleted. A door the business runs itself sends us nothing unless the business opts in here.
• An abuse report A site that reports an agent leaves with us the agent and operator it names, the site it says it is, whether that site was proven to us and by which organisation, a contact address for the reporter, a category, a description of up to four thousand characters, and up to twenty signed log lines as evidence. Each line is the request as the site received it: its method, host, path and the headers carrying the credential and its signature, and never a request body or a response. We also keep the network prefix the report came from, for the daily limit, and for each line whether it verified, the thumbprint of the key that signed it and that key's revocation time. The abuse desk reads all of it. The operator reads the reports against its agents without the reporter's contact and without the evidence. A report is kept for as long as the registry exists, even after the agent or operator it names is gone, because the record of what was reported is what standing is computed from.
• What the abuse desk decides, and standing For each report the desk records a status, whether the evidence verified and a code per line saying why not, a note, which administrator decided and when (cleared if that account is later deleted), and each action it upheld: a warning, a rate limit, a revoked agent or a revoked operator, with the operator and agent it was against. A rate limit or a suspension is also written as a flag the relay nodes read, with its expiry and when it was lifted. An operator's standing is arithmetic over the actions upheld against it, counted in full for ninety days and by half until a year has passed, and then not at all; a report that was dismissed or never decided moves nothing. The standing label and score are public in the operator directory and are shown to a business beside its dashboard. The rows behind them are kept.
• Connect: your side of a connected assistant When you connect an AI assistant, the assistant registers itself with us first: the name it gives itself, an address for it if it gave one, the addresses it may be sent back to, how it authenticates, and a digest of the network it registered from. An assistant that never reaches a connection is forgotten a day later. The request it then makes is kept under a random handle for ten minutes: where to send your browser back to, the proof the assistant made, the scopes it asked for, which account opened it, and whether it was approved or declined. Your approval is a mandate your own browser signs with your key, kept exactly as a paired agent's is, under Agents, passes and orders above. The connection row names your account, the assistant, that mandate, the assistant's name and the host it sends you back to as you saw them on the consent page, the scopes, when it was made, when it was last used and when it was disconnected. The code the assistant trades in lasts one minute and is used once; an access token lasts ten minutes; a refresh token is replaced on every use and never outlives the mandate, thirty days at most. Every one of those is kept as a digest and never in the clear, so a copy of our database is not a copy of anybody's connection. A sweep deletes them when they have ended: a consent request ten minutes after it was opened, a code an hour after its minute (the hour is how long a second use of it is recognised as a replay), an access token when it expires, and a refresh token at its own end, thirty days at most. The connection row itself, disconnected or not, stays until your account is erased, because Settings shows it to you. What the assistant gets is a token under the scopes you approved and the mandate you signed, and nothing else: no key of yours, no password, no recovery key, no master key, and nothing sealed, which is why anything that needs you comes back to you to approve on our own page. The assistant's name is its own and we do not check it; the consent page leads with the host it will send you back to, which we can vouch for. You can disconnect it at any moment from Settings, which stops it on its next request, and your connected assistants are listed in your export.
• The relay nodes An agent may send its requests through Verigrant's own relay nodes, so that a site can require it and know every such request was checked before it left our network. A node holds no database. It keeps counts and timings per agent, operator and site, per day, for thirty days: requests, fetches made, refusals by reason, the site's answers by class, time taken, and bytes sent and received, with the site named by its host and port. Its log is one line per fetch naming the agent, the operator, the site's host and port, the status, the refusal and the time. Never a request or response body, never a path or query, never a header value, never a credential. The nonces it remembers against replay live in memory for a minute. It keeps the list of agents and operators cut off at that node, and the last flags it read from the abuse desk. The site a node fetches from receives the agent's own credential, the node's signature and the request the agent composed, from a published address range. It never receives a person's pass, because a pass is not forwarded through a node.
• What we publish for the network Four things are public, cacheable and name nobody but an agent and its operator: the agent ID key set a site verifies credentials against, the status lists, each agent's hosted key directory of live public keys, and the file listing the relay nodes' addresses and signing keys. Fetching any of them needs no credential and tells us nothing about which agent a site is checking.

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. The same somebody learns which operators registered and with which addresses, which agents they run, which sites reported them and who stood behind them, and which assistant each person connected; what they do not learn is which site any agent visited, because no row of ours names one.

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.
• verigrant.agent_operator_token Only present in a browser that signed in to the operator console at /app/operators. It is the operator's own sign in token, kept under a name of its own and never beside a person's session, so an operator who also holds a personal account has two separate things in storage rather than one that stands for both. It lasts ninety days at most and we keep it only as a digest. Signing out of the console removes it from this browser and tells the registry to retire the token, and clearing this site's storage forgets it too.

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.

What your agents leave with us is held for short windows instead, and section 2 under Agents, passes and orders gives each one: a sealed traveller copy for ten minutes after it is taken and a day at most, a signed order for ten minutes after delivery and its row for seven days, a sealed form until it is delivered and a bounded time after, a pass id or a pay grant id for thirty days after it ends, and a booking update grant for the window you chose. A plan, an approval and a receipt are kept with your account, because they are the history of what you authorised.

The agent network keeps its own windows, and section 2 under The agent network gives each one: a confirmation code for a day, a link code for seventy two hours, a renewal nonce for ten minutes, an issued credential's row for thirty days after it expires, an unproven domain claim or directory listing for fourteen days, a relay node's counts for thirty days, a Connect request for ten minutes, a code for one minute, an access token for ten minutes and a refresh token for thirty days at most. An operator's registration, its agents and keys, a proven listing, dashboard counts, an abuse report, the desk's decisions and a transparency log leaf are kept, as that section says, because each is the history the network's trust is computed from. A Connect row is kept as a digest and erased with your account, and an officer link is erased with the officer's.

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 VX Encryption, Inc.: 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.

The agent network adds two kinds of server, both operated by VX Encryption, Inc. and both hosted with IONOS Inc. in the United States. The relay nodes, which make requests for agents, hold no database and no key of yours: each keeps its own signing key, a counts file per day for thirty days, its suspension list and its last read of the abuse desk's flags, as section 2 says. The hosted door, which serves a business's agent front for the businesses that chose it, keeps that business's catalogue, its settings, its intake inbox and, when the business opted in, the visit counts it posts to the dashboard, in a database of its own with no handle on ours. The registry, the directory, the dashboard, the abuse desk and Connect live in the one database described above.

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 assistant codes 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@verigrant.com. If your local law gives you a right we have not named here, tell us and we will honour it.