Verigrant › Institutions

Candidates arrive as data, not documents.

Right now every applicant hands you a file, and the first thing you do is take it in and start pulling it apart. You become the custodian of everybody who applied, including everybody you were never going to advance. Verigrant turns that round, and the thing it changes is when custody begins. Applicants come to you as structured, portable data, you look at the fields you asked for before you take anything, and you become the custodian of a record at the point you decide somebody matters.

The board and the postings are free. You pay for the applications you decided to take.

Zero documents to parse
Only the fields you asked for
Free to post and to shortlist
Structured fields, not files Named values over an interface, so there is nothing hostile to parse.
Preview before you ingest Sort a round on the fields you asked for, and take in only who advances.
Liability you can explain You cannot lose the records of people you never took in.
Free to post, free to shortlist You pay only when a full application goes into your systems.

You are absorbing documents from thousands of strangers, and then sorting them.

The order is the problem. Everything arrives first and gets judged second, so by the time you decide somebody is not a fit you are already holding their address, their history and their identity documents, with a retention policy to write and a breach to worry about. That is a lot of risk to take on before you have learned anything.

How it works today

You own everybody's data by default

  • Every applicant in the round lands in your systems on day one.
  • Files from strangers, opened by parsers, on your infrastructure.
  • Consent is a checkbox somebody ticked on a page you cannot reproduce.
  • The people you rejected are still your problem, for years.

With Verigrant

You own the data you chose to have

  • Applicants sit on Verigrant until you decide to advance one.
  • You pull named fields, so there is no attachment to open.
  • Consent is a signed statement you can produce two years later.
  • The round you did not shortlist leaves nothing behind with you.

How receiving works, in as much detail as you want

Four steps either way. The first level is the one to send to the person who owns the hiring process, and the second is the one to send to the person who owns the systems.

  1. Register once, and post for free. You do it on the Institution tab of the employer portal: name your domain, let the browser generate your keys, and publish the small file it hands you at that domain. From then on applicants can see that a request really came from you. Posting roles and running the board costs nothing and will keep costing nothing.
  2. Ask for a preview, and sort the round. You say which fields you need to make a first decision. Applicants approve, and you get those fields and nothing else. The portal shows you the part we can still read, which is how to reach them and which of their claims somebody checked. The rest arrives encrypted, and a recruiter opens it in your browser with your institution's private key, once somebody at your institution has put that key into that browser. Nobody has to build anything to read one candidate. The people you do not advance never entered your systems at all.
  3. Take in the ones you advance. When somebody moves forward you ask for the fuller application, they approve again, and you pull it into your own systems as structured data. That is the moment your custody of it begins, and the only point at which an application costs you anything.
  4. Keep the proof of what they agreed to. Every pull carries a statement the applicant signed, naming the fields and the date. Two years later, when somebody asks why you hold a record, the answer is a document rather than a memory.
  1. You publish a public key, and we never hold the private one. Registration binds your organization to a domain you prove you control, and your public key is written into an append only log. An applicant's browser checks that key against both before it will seal anything to you, and refuses if either check fails.
  2. A grant is a scope list, a counter and an expiry. You request named scopes rather than a document. The applicant issues a grant that names them, names you, counts the reads and carries a date. Every request you make reads that row again, so a withdrawal takes effect on your next call, with no cache to wait out.
  3. You receive ciphertext plus keys sealed to you. The pull returns the encrypted fields together with their record keys sealed to your published key with X25519. Decryption happens where your private key is: your own software pulls the same bundle and opens it on your own servers, and a recruiter reading one person opens it in the browser with the same key held there. There is no route that returns readable personal data to anybody, including us, so an integration built on that assumption is built on a mistake.
  4. No route takes a subject parameter. You can only read against grants issued to you, so there is nothing for a hostile string in an application to redirect. The consent statement is signed by the applicant over the scopes and the date, and you keep it, so your evidence does not depend on us being around to confirm it.

There are two ways in and both are supported properly. The interface is the production one, and it is what Workday, an applicant tracking system, a student information system or your own software reads with a key that belongs to your institution. Where you would rather not open an integration project at all, the same service answers the Model Context Protocol at one address, so an assistant your staff already use can be handed a token and start reading today. The addresses, the scopes and the failure behavior are written out in full for whoever is going to build it. Read the integration guide

Pull as late as you can.

The pull is the moment your custody of somebody's record begins, so where you put it is wherever your institution decides its risk starts. That is your policy rather than our product. There are three sensible places to put it, all three run on the same routes, and choosing between them is not a different integration.

At interview

You take a record in when somebody reaches a conversation. It is the earliest of the three, and the rest of the round still never enters your systems.

At offer

You take a record in when you are ready to make an offer, so the people you talked to and did not choose never become rows you have to keep and explain.

At hire

You take a record in once, for the person joining you. This is the one we recommend when you have no reason of your own to prefer another.

The pattern to copy is to hold everything on our side until the hire and then ingest one record instead of many. Here is what that does to a real round.

242 applications received and reviewed
15 records ingested, or thereabouts
94% less data you have to defend

Every one of those 242 was received, read and sorted in full, so waiting costs you no reach and no candidate. It costs you nothing in money either. Receiving is free, sorting a round is free at any volume, and you pay only for the records you decided to take, so a later pull leaves you holding less and paying less at the same time.

One thing a late pull does not buy you, said here rather than left to be discovered. What you ingest is yours from that moment under your own retention, and a withdrawal reaches your next read rather than the one you already made. Late is better because less of it ever crosses, and never because what crossed can be undone.

The applications you did not take never entered your audit scope

Scope is most of what an audit costs, and scope follows custody. The population you have to bring inside your own boundary, name in your own inventory and account for in your own report is the population you took in, not the population that applied. That is the same 242 and 15 as above, read from the auditor's side of the desk.

Where we stand today, stated here rather than in an answer to a questionnaire. SOC 2 Type II with the Security criterion is being pursued and is not held yet. This page says so until a report exists, and it will say what that report covers on the day one does.

The narrow claim we make in the meantime rests on the architecture rather than on a report, and it is the only one we will ever make. Applications stay inside Verigrant's zero knowledge environment until you ingest them, sealed in the applicant's own browser under keys we never hold, so we carry the bytes and cannot read them, and once you pull them the data is your responsibility. We shrink your audit scope. We do not cover you, nothing of ours is yours to present as your own, and no part of your audit is done for you by us.

What this does, and what it does not

  • It shrinks what you defend A record you never pulled is not in your systems, so it is not in your scope.
  • It does not transfer A certification covers the environment it was written about. It never travels to yours and it never stands in for it.
  • It does not answer for you Your controls, your retention and your report stay yours, and so does everything you ingested.
  • It is being pursued, not held SOC 2 Type II with the Security criterion is in progress, and you will hear about it from us when it is finished rather than before.

If you run admissions

You are a relying party in exactly the same sense an employer is, and the mechanics above are the mechanics you get. What changes is what it is worth. An applicant holds one application containing their transcripts, their essays and their forms, and they send it to you and to everywhere else on their list without entering it again. Any check they asked for travels with it as a signed note naming what was reviewed and by whom, so it reads the same at the tenth institution as at the first.

Every application also carries a consent the applicant signed at the moment they made it, which is a harder thing to fake than a form somebody filled in for them. It ends the keying in again, on both sides of the desk, because what arrives is fields rather than a form to transcribe. You pull a preview to sort a round, and you pull the full application only for the people who advance, so the applicants you did not take leave nothing behind on your servers.

What changes for a registrar

  • A signature you can check yourself A check arrives as a signed note you read with a published key, not as a scan somebody could have edited.
  • Ghost students get harder An application carries a real person's consent, signed at the moment they made it.
  • Keying it in again stops Structured fields arrive as fields, so nobody transcribes a form into your system.
  • You hold the admitted, not the applied Preview to sort the round, pull in full only when somebody advances.

Landlords and lenders are the same shape again. Address history and references for a tenancy, and the fields a credit decision needs for a loan, are requests for named parts of the same application, scoped and dated the same way.

The pitch is not better candidates. It is a smaller blast radius.

Every applicant document you accept today is an untrusted file from a stranger, opened by a parser, on your infrastructure. Remove the documents and that entire class of problem goes with them. What you pull instead is named fields with known types, and the thing you decrypt them with is a private key we have never held and cannot be compelled to produce.

The second half is quantity. Holding an application you never wanted is a cost whichever way the regulation goes, and the cheapest way to reduce it has always been to hold less. Preview first and ingest late, and the population of people whose data you are responsible for shrinks to the population you actually did something with.

Where the attack surface went

  • No documents from strangers Nothing to open, so nothing to open badly.
  • No subject parameter on any route You read against grants issued to you, so nothing can be pointed elsewhere.
  • No readable copy in the middle A compromise of Verigrant does not produce a second copy of your pipeline.
  • No consent you cannot evidence A signed statement you keep, rather than a log line we keep.

What you get, and what you never get

The limits are as much a part of the offer as the features, so they are stated at the same size.

What you ingested is yours

Once you have pulled an application into your systems it is under your own retention rules, exactly as it would be if it had arrived any other way. We do not reach into your database and we never claim to.

Proof of consent, kept for you

The applicant signs a statement naming the fields, naming you and dating it. You keep a copy, so the evidence that you were allowed to hold something does not depend on us still being here.

No browsing, ever

There is no search across people, no way to look at somebody who did not apply to you, and no route that takes a subject. You see the applications that were granted to you and nothing else exists as far as you are concerned.

No judgement from us

We do not screen, score, rank or summarise anybody. We cannot, because we cannot read them. Every decision about a candidate is yours to make and yours to defend, which is where it belongs.

You pay for the applications you decided to take

Nothing about finding people costs money here. What costs money is the moment you choose to bring somebody's full application into your own systems, which is also the moment it starts being worth something to you.

Free

Posting roles, running the board, posting over an interface, and previewing the fields you asked for so you can sort a round. None of that is billed and none of it is going to become billed.

Per application you take

When you pull a full application into your systems, that one is what you pay for. You are paying for the people you advanced rather than for the size of the round, which is the only version that rewards taking less.

A yearly agreement

Sized to your volume, and it covers the support and the terms your legal team is going to want in writing. Talk to us before you build anything and we will tell you what it would cost you.

We do not sell advertising and we do not sell better placement for a listing. A layer that can be paid to favor somebody is no longer a neutral one, and neutrality is the whole product.

Questions institutions ask first

Including the two that decide whether this ever gets through procurement.

What do we actually receive?

Named fields you pull over an interface, in the scopes the applicant granted, plus a signed statement of what they agreed to. There are no attachments to open and no documents to parse. Decryption happens wherever your private key is, which Verigrant has never held: a recruiter reads a candidate in your browser with your institution's private key, and your own software pulls the same bundle and opens it in your own environment when you are ingesting a queue.

Does this work for admissions as well as hiring?

Yes. An admissions office is a relying party in exactly the same sense an employer is. The applicant holds one application containing their transcripts, their essays and their forms, and grants a preview scope to sort a round and a fuller scope when somebody advances. Landlords and lenders sit on the same rails, because the shape of the request is identical.

How does this reduce our liability?

You cannot lose what you never took. Today you ingest every applicant in a round and then sort them, which means you are the custodian of thousands of people you rejected. Here you preview on the fields you asked for and pull the full application only for the people you advance, so the records you hold are the ones you can explain holding.

When should we pull an application in?

Wherever your risk starts, and that is yours to decide rather than ours. At interview, at offer and at hire are all sensible, they run on the same routes, and choosing between them is not a different integration. The pattern we recommend when you have no reason of your own to prefer another is the last one: hold everything on our side until the hire and then ingest one record instead of many. A round of 242 applications ingests about 15 that way, which is roughly a 94 percent reduction in the data you have to defend, with all 242 still received, read and sorted in full.

Does your SOC 2 report cover us?

No, and nobody should tell you that it does. Start with where we stand, because it is the part a questionnaire gets last: SOC 2 Type II with the Security criterion is being pursued and is not held yet, and this page says so until a report exists. The narrow claim we make in the meantime rests on the architecture rather than on a report. Applications stay inside Verigrant's zero knowledge environment until you ingest them, sealed in the applicant's own browser under keys we never hold, so we carry the bytes and cannot read them, and once you pull them the data is your responsibility. That shrinks your audit scope and it does not cover you, because a certification covers the environment it was written about and never travels to another one.

Is the job board free?

Yes. Posting roles, running the board and posting over an interface are all free, and they stay free. You pay when you take a full application into your systems, plus a yearly agreement sized to your volume. We do not sell advertising and we do not sell better placement, because a layer that can be paid to favor somebody is no longer a neutral one.

What happens when an applicant withdraws access?

Your next read is refused. Anything you already pulled and wrote into your own systems is yours, and your own retention rules govern it from that point, exactly as they would for data collected any other way. We are honest about this in both directions: withdrawal is a real control over future reads and it is not a remote delete of your database.

Can Verigrant read the applications passing through it?

No. Applications are encrypted in the applicant's browser and stored as ciphertext. When somebody grants you access, their browser seals the relevant keys to the public key you published, so you can open them and we cannot. That is worth something to you as well as to them: the middle layer is not a second copy of your candidate pipeline sitting somewhere readable.

Does Verigrant screen or score candidates for us?

No, and it could not. We cannot read applications, we never tell you that a record is true, and we are not a consumer reporting agency. What we carry is the applicant's own data, plus any check they asked for and attached themselves. A check is reviewed by Verigrant staff today, with outside verification vendors to follow, and what it produces is a signed note saying a review happened rather than a verdict on the person. Every judgement about a candidate stays yours, which is also where the law expects it to be.

How long does integration take?

You can start without one. Register a domain, let the browser publish your keys, and a recruiter reads candidates in the employer portal with your institution's private key held in their own browser. When you want a pipeline rather than a person, the interface is the production way in and you publish nothing new for it: your own software, your applicant tracking system or your student information system reads from two addresses with a key that belongs to your institution, and opens the same bundles with the same key. Where opening an integration project is itself the obstacle, the same service answers the Model Context Protocol at one address, so an assistant your staff already use can be handed a token and start reading today. There is no document pipeline to build on any of those paths, because there are no documents.

Post a role. Take in only the people you chose.

Posting is free and stays free. If you want the applicant's side of it first, the page for people applying is the same story told from the other end.

Free to post and free to shortlist. You pay for the applications you take in.