# Verigrant: the full text of every page > Every page of https://verigrant.com as plain text, in one fetch. Built from the site's own > source by web/site-standard/build-llms-full.py, so it says what the pages say. > The short brief is https://verigrant.com/llms.txt, the brand facts are > https://verigrant.com/.well-known/brand.json, and the API is described at > https://verigrant.com/api/openapi.json. --- Page: https://verigrant.com/ Title: Verigrant: one application for every job, college and apartment # Fill one application. Apply to anything. Every application asks for the same life story. A job, a college, an apartment, a loan, an insurance policy: each one wants your history typed again into a new form, and none of them tells you where it went. Verigrant gives you one application that you own. Fill it in once, share exactly the parts an institution needs, and see exactly what each one took. ## The application, opened on an example The still above is that example before it starts. Everything in it becomes live the moment the application loads, the selector at the top reshapes the record under it, and creating an account happens from inside it when you decide to. Free forever for people and for the assistants that act for them. Institutions pay when they take an application in. It is safe to keep all of it in one place because the substance of your application, your history, education and skills, is locked inside your own browser, and we cannot read a word of that part. What we can read is listed in the privacy policy. The example needs JavaScript and WebAssembly, and so does creating an account: your application is encrypted on your own device before any of it is sent, and there is nowhere else that could happen. Everything written on this page is readable without either. ## Two front doors ### For you Free for people. Apply to jobs, colleges and apartments with one record, receive records in your inbox, and share or withdraw access whenever you choose. #### Your information, once. Everywhere you apply. One application, filled in once. You stop retyping your history into every form: the same application serves a job, a degree, a tenancy, a loan and a policy, because all five ask the same person for the same history in a different shape. You keep it and they borrow it. You can see exactly what each company took, and you can cut off anything a company has not taken yet. Free forever, including the export you keep if you leave. #### Give your AI one ID instead of your life story. Your assistant applies for you under one identifier that carries no key material and authorises one route. You approve what goes out, in your own queue, and you can see everywhere it went. Nothing it sends is retyped out of a copy of your history, because it never holds one. Free forever for you and for it, and the brief written for it is at llms.txt. ### For organizations For anyone who takes in applications: employers, schools, landlords and more. Every application arrives complete and structured, and you pay per intake. #### Stop ingesting resumes you'll never read. Review every applicant free, as structured fields rather than as files you have to parse. Pull the full application only for the people you advance, and hold nothing else, because there is no liability in the records of people you never took in. Posting a role and running the board stays free, and you pay when a full application goes into your own systems. #### Every applicant, one clean record. The same transcripts, essays and forms, entered once and sent to as many institutions as the applicant likes. There are no PDFs and no retyping into your SIS, and nothing enters your systems until you decide it should. Every application carries a consent signed at the moment it was made, and any check the applicant asked for travels as a signed note that reads the same at the tenth school as at the first. ## Why it is safe to keep it all in one place Putting your whole life behind one login would be a terrible idea if we could read it. We cannot read the substance of it. Your history, education, skills and the rest of the record are locked inside your own browser with a key that never leaves it, and what arrives on our servers is a sealed block. Reading that takes a grant you issue to one institution, naming the fields, counting the reads and running out on a date you set, and the institution opens what it pulled with a private key we have never held. A few things are not sealed, among them your email address, the regulated sections such as work eligibility, the questions in your answer bank, and any document or answer that reached us before we began sealing them, and the privacy policy lists every one. Revoking a grant refuses the very next read. It does not reach what somebody already pulled and wrote down, which stays theirs under their own retention, and the page below says so in those words. Verigrant does not score you, rank you or summarise you, and never tells an institution that what you wrote is true. A check says a review happened on a date, signed so anybody can test it later. Verigrant is not a consumer reporting agency. --- Page: https://verigrant.com/job-seekers.html Title: One application for every job and college you apply to | Verigrant # One application. Every place you apply. You have typed your work history, your education, your address and your documents into more forms than you can count, and every single one of them kept a copy you will never see again. Fill it in here once and it is yours. What you fill in is not another application: it is structured information you keep and control, and an institution receives the part it asked for only at the moment you grant it. After that, applying to a job, a college, an apartment or a lender is a matter of saying yes. Free forever. It takes about an hour, once, and then you stop being asked. **Once** is how many times you type it **Every field** is granted, never given away **Sealed** your history and skills, even from us **Stop retyping your life** The same twelve fields, in a different order, for the last time. **Jobs and schools, from one place** The same application serves a role, a degree, a flat and a loan. **Your assistant can apply for you** Hand it a name to apply under, and approve what comes back. **Cut off access any time** One press and the next attempt to read is refused. ## You have already given your whole life away, dozens of times over. Not on purpose. One form at a time, one attachment at a time, because there was never another way to apply for anything. The result is the same either way: your history is sitting in dozens of databases you cannot name, and there is nothing you can press to get it back. How it works today ### A copy of you in every database - Every application is the same hour of typing, done again from scratch. - Your documents go out as attachments and never come home. - A company you were rejected by in March still holds all of it. - Their breach becomes your problem, and nobody tells you for a year. With Verigrant ### One application that stays yours - Typed once, kept by you, and edited in one place from then on. - Applying is granting access, so no copy leaves without your say. - Each grant names the fields, the place and the date it runs out. - One list shows who can read what, and one press ends any of it. ## Your job application and your college application are the same application Nobody thinks of it that way, because the two forms look different and arrive years apart. Look at what they ask for and they are the same request. Who are you, what have you done, where have you been, can you prove it. One person, one history, one set of documents, asked for twice in different clothes. ### Applying to colleges, once Your transcripts, your essays and the forms behind them go in once and go out to as many schools as you like. There is no second upload and no third portal account. If you asked for a check on something, the signed note it produced travels with the application, so the tenth school reads the same note the first one did without anybody starting the check again. Then you graduate, and the education you already entered is the education section an employer reads. Nothing is migrated, because nothing moved. It was always the same application. ### The same application, later - **A job** Your work history and your right to work, granted to the employer you chose. - **An apartment** Address history and references, without emailing them to a stranger. - **A loan** What a lender has to see, scoped and dated, and closed again afterwards. - **Insurance** The details a policy needs, released for one quote rather than for good. ## How it works, in as much detail as you want Slide to the level that suits you. It is the same four steps either way, and the second level is the one to read if you are the sort of person who wants to know what the software is actually doing. - **Fill it in once, and it locks.** Your work, your studies, your details and your documents, in one place. The lock closes on your device as you type, so your history, studies and skills leave your browser already scrambled. The privacy policy lists the few things that are not locked. - **Apply, or let an assistant apply for you.** Give it an assistant code, which is a name it can apply under. It goes and applies. It cannot open anything with that name, so it is not carrying your life around while it works. - **Approve, and the fields open.** Every application waits in a queue for you. You look at who is asking and what for, you approve the ones you want, and that is the moment those fields become readable to that one place. - **Change your mind any time.** One press and the next time they look, they are turned away. Grants also run out on their own, so forgetting one is safe. - **One data key per account, and a fresh key per saved version.** Your password is stretched with Argon2id in a background worker, which unwraps a random master key that never leaves the browser. Each record is canonicalised, padded to a size class and sealed under XChaCha20Poly1305 with a fresh key on every write, so a reader who opened version seven cannot open version eight. - **An assistant code in review mode authorises exactly one route.** `POST /vera/applications` writes a pending row and nothing else. It is stored as a hash, it is shown once, and one unanswered application per institution is allowed, so a leaked identifier cannot flood your queue. Auto mode exists too, and its cost is stated plainly further down this page. - **A disclosure is a signed statement plus a sealed key bundle.** Your browser verifies the institution's public key against its own domain and against an append only log, refuses to seal if either check fails, then seals each chosen record key to that key with X25519 and signs the statement with yours. The institution decrypts in its own systems with a private key we have never held. - **Cutting access off binds at once, and retiring a key is a second step.** The grant row is read again on every request, so withdrawing takes effect on the next call, with nothing to wait out. Retiring a key an agent already holds is a separate step that runs in your browser at your next sign in, and until it runs the interface says so rather than claiming more than it can do. The security page carries the same argument at full length, including the parts that are inconvenient for us. Read the security page ## What you get back for that hour Filling this in properly takes about as long as three careful applications do today. Here is what it buys you. ### A breach somewhere else stops mattering The companies you applied to are not holding a pile of your documents, because you granted fields rather than sending files. There is much less of you out there to lose. ### One application, every kind of application A role this year, a course next year, a flat after that. You keep editing the same thing rather than rebuilding it from memory each time somebody asks. ### Your assistant stops inventing you An agent filling forms on your behalf is guessing at what you meant. Here it reads nothing and claims nothing for you. It applies, and you are the one who answers. ### You can leave with all of it Download the whole application as a file that unlocks with a phrase you choose. Your backup does not depend on this company continuing to exist. ## How much you want to be asked An assistant code is what you give your AI assistant so it can apply on your behalf. There are two modes, review and auto, and the only difference between them is whether you are in the loop for every disclosure. You set how long a share lasts in both. Review mode, and the default ### Nothing opens without you - The agent can do exactly one thing with it, which is ask on your behalf. - Each application lands in a queue that you work through. - Approving is what opens the fields, and it happens on your device. - You choose how long each share stays open before you approve it. - The agent never holds anything readable, so it has nothing worth stealing. Auto mode, for people who want no clicks ### It acts inside limits you signed - You pair one agent once, with a written limit on what it may ever ask for and how long each share lasts. - Inside that limit it issues on its own, and each one shows up in your list. - The limits are enforced by us, not by the agent behaving well. - You can revoke it, and every route closes to it immediately. ### The sentence we will not soften Auto mode means that you, the one agent you chose, and anyone that agent's key leaks to before you next sign in, can read the fields you allowed for the window you allowed. We still cannot read the sealed records among them. That is the trade, and it is why review mode is the default and the one we recommend. ## Let an agent act for you at websites, inside your limits You can now pair an AI agent to act for you at websites. You choose where it may go, what it may do and for how long. Verigrant gives it a short pass that shows a site a real person stands behind it, without your name. - **Connect it with one click** From the assistant itself. You sign in to Verigrant, read what it may do in plain words, and approve. No keys to copy and no codes to paste, and it never holds your password, your keys or anything sealed in your record. Pairing by hand is still there. - **You approve the plan** When it wants to do several things, it asks first. Nothing in a task runs until you approve it, and some steps need a tap or your authenticator code. - **Your details stay sealed** When it books for you, you send it your traveller details sealed in your browser to that one business. The agent carries them and cannot read them. - **You keep the receipts** Every pass, payment approval and order is written to a record sealed to your key. Verigrant can write it and cannot read it. ### Not live yet - **Money** Payments run in test mode. No money moves through Verigrant. - **Passkeys** A step that needs a passkey cannot be approved yet. How to set it up: Connect your assistant to Verigrant or Let an agent act for you, safely ## We never vouch for you. A check says a review happened. If a place wants more than your word, you can ask for a check. Today a member of Verigrant staff reviews it and records what they found, with outside verification vendors to follow. What comes back to you, if it is approved, is a short note naming the kind of check, who ran it and the date, and you attach that note to an application yourself. The note is signed, so anybody can check it later with a key we publish and never has to ask us anything. That is what makes it worth the same at the tenth school as at the first. What the note never says is that your application is true. We do not display it, rank it or summarise it, and we could not stand behind the record it travels with even if we wanted to, because we cannot read the substance of that record. - **You ask for it, and you decide who sees it** The note is yours. Nothing goes out with an application unless you attached it. - **The note is the whole of what we hold** A result carrying actual field values is refused at the door. - **Verigrant makes no claim about you** We never say a person is genuine. We say what was reviewed and by whom. ### Why it is built this way The moment a middle layer starts standing behind facts about people, it becomes the kind of company that decides who gets a job, a place or a loan, with all the law and all the responsibility that follows. We would rather be the road than the judge. It is also the only version that survives contact with encryption. We cannot vouch for an application we are unable to read, so we do not pretend to. ### Who says what What is carried on an application and who stands behind it | On the application | Who says it | | The application itself | You, sealed by you, opened by the institution you chose. | | The note from a check | Whoever reviewed it, saying what they reviewed and when. | | The consent | You, signed by you, and checkable later. When your assistant sends it, we sign to say it acted under your authority. | | A judgement | Nobody. There is not one here to give. | ## Your application, from filled in to cut off Nothing becomes readable until you make it readable, and it closes when you say so. The honest limit, said here rather than buried. Revoking a grant stops every future read. It does not reach what an institution already pulled and wrote down, which stays theirs under their own retention, and which is exactly why a grant is small and late rather than large and early. ## Questions people ask first The awkward ones are here too, answered rather than avoided. ### Can I really use one application for jobs and for colleges? Yes. A job application and a college application are the same person being asked for the same history in two different shapes. Your education section is your transcripts. Your work history is your work history. You fill it in once and grant from it, so applying to a university in the autumn and to an employer in the spring uses the same application and neither one makes you type it again. ### How long does it take to fill in? About an hour if you do it properly, and you do it once. That is roughly what three careful applications cost you today, and after it you stop paying that cost at all. You can also start with the short version and fill in the rest the first time somebody asks for it. ### Can Verigrant read my information? Not the substance of it. Your work history, education, skills and the rest of the record are locked on your device, before anything is uploaded, using a key derived from your password and held only in your browser. What our servers store is a sealed block. There is no support tool that opens it, no administrator button, and no route in the software that would let us read it even if we were ordered to. Somebody who stole the entire database would take away locked boxes and no keys. A few things are not sealed, and the next answer names them. ### So what can Verigrant see? The outside of the boxes, and the few things that are not in one. Your email address, because a login has to be routed somewhere. How many records you keep and roughly how big each one is. When you edit. Which institutions you applied to, when, and which of them moved you forward. The regulated sections if you fill them in: work eligibility, your date of birth, the last four digits of a social security number and the self identification answers. The questions in your answer bank, though not your answers. The kind and rough size of each document you upload, though not the file, its name or your label for it. And any document or answer that reached us before we began sealing them, until you encrypt it, save it again or delete it. We think that is a fair thing to know about us, so it is written out in full in the privacy policy rather than left for you to work out. ### What happens when I cut off access? The next attempt to read is refused, immediately, with no waiting period and nothing left open behind it. Anything the institution already opened and copied into its own systems is theirs, held under its own retention, and we cannot reach into their database. That is why a grant is small on purpose, and why the full application is only unlocked at the point somebody decides to take you seriously. ### Can my AI assistant apply for me? Yes, and it is the point. You hand it an assistant code, which is a name it can apply under. It cannot read anything with that name and it cannot unlock anything. Every application it files lands in a queue you work through, and approving is what opens what that institution asked for, less anything you untick, to that one institution. If the assistant is careless or compromised, it was never holding anything readable. ### Does an institution see everything about me? No. A grant covers only the fields you picked, and the rest is not merely hidden from them, it is locked and they were never given the key. Most institutions start with a short preview so they can sort applications, and the full application is unlocked only if they decide to take you further and you agree at that moment. ### What does a check mean here? It means somebody reviewed one of your claims and wrote down what they found. Today that reviewer is a member of Verigrant staff, and outside verification vendors are the next thing to be connected. An approved check comes back as a short note naming the kind of check, who ran it and the date, signed so that anybody can check it later with a key we publish. It says a review happened. It is not us saying that your application is true, and we never say that about anyone. ### What if I forget my password? At signup you are given a recovery phrase and asked to write it down. With the phrase you can set a new password and keep everything. Without the password and without the phrase, the data is gone, permanently, and we cannot recover it either. We can give you your account back. We cannot give you your application back, because we never had a way in. That is the honest cost of the promise on the rest of this page. ### Can I take my information out, or delete it? Both, whenever you want. You can download the whole application as a file that unlocks with a phrase you choose, so your backup does not depend on us existing. You can also delete the account and everything under it. An application you cannot walk away from is not really yours. ### Is it really free? Free forever for you, and free for any assistant acting for you. Institutions pay when they take a full application into their systems. The person whose data it is should not be the one paying for permission to hold it, and a layer funded by the people it protects would end up selling them out. ## Fill it in once. Apply to everything else with it. An hour now, and then it is done. If you want the other side of the story first, the institutions page says what a company receives and the security page says what we can and cannot do. Free forever. The substance of it stays sealed from us, and nobody else reads it until you say so. --- Page: https://verigrant.com/employers.html Title: Receive applications as structured data, not documents | Verigrant # 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. - **Register once, and post for free.** You do it in your organization's Settings: 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. - **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. - **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. - **Keep the proof of what they agreed to.** Every pull carries a signed statement naming the fields and the date: signed by the applicant, or, when their AI assistant sent it, with our signed attestation that it acted under their authority. Two years later, when somebody asks why you hold a record, the answer is a document rather than a memory. - **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. - **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. - **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. No route decrypts the sealed record for anybody, including us, so an integration built on that assumption is built on a mistake. The few sections that are not sealed, such as work eligibility, reach you only under a grant that names their own scope. - **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. When the applicant sends an application themselves, the consent statement is signed by them over the scopes and the date, and you keep it, so that evidence does not depend on us being around to confirm it. When their AI assistant sends it, the statement comes with our signed attestation that the assistant they paired sent it under their authority, and checking that relies on our published key. 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. Until you ingest them, the substance of applications is sealed in the applicant's own browser under keys we never hold, so we carry those bytes and cannot read them, and once you pull them the data is your responsibility. The privacy policy lists the few parts that are not sealed. 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 signed consent: the applicant's own signature, or, when their AI assistant sent it, our signed attestation that it acted under their authority. That 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 by them or, when their assistant sent it, attested by us. - **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, and we cannot read the substance of an application to try. Every decision about a candidate is yours to make and yours to defend, which is where it belongs. ## Orders and forms from agents, as well as applications The same keys that receive sealed applications can now receive more from people and their agents. - **Orders from agents** An agent drops a complete, signed order into Verigrant. You pull it, or take it by webhook, open the sealed traveller details with your own key, complete it in your own system and send a signed result. - **An agent front** A structured, live version of what your website already says, for agents only. Any agent registered with Verigrant trades its agent ID for your grant and can search, compare and act in the clear; an agent carrying a person's pass gets the sealed path. The generator drafts it from your own site, you approve every collection and action, and a site goes from its website to a live front in fifteen minutes. - **The gate** In front of your pages: people get the page, verified search crawlers get the page, registered agents are pointed to your front, and automation that will not say who it is gets a short answer and a small piece of work for its browser. No wall is perfect; this one makes announcing the cheaper path. - **Every agent that visits** Who operates it, how far that operator has been checked, what it said it was there to do, and what it asked for. On your own server unless you opt in to the hosted dashboard, which counts agents, never people. - **The directory** Prove your domain and list your front where agents look first. - **Fill with Verigrant** A person fills your form from their own record, and their device seals the answers to your key before anything is sent. - **Updates after a booking** You can send a person updates about a booking they allowed, sealed to them, and message them at a masked address without learning their email. ### Not live yet - **Money** Payment approvals run in test mode. No money moves through Verigrant. - **A price** Orders, Fill, updates and masked contact have no price yet, and they are not billed. - **Screens** Orders are handled through the interface today, not in the workspace. - **On their own day** A front hosted by Verigrant, and the egress for sites that want every request checked before it arrives, go live after the registry, the directory and Connect. Today you serve your front yourself. The steps, in order: Take orders and applications from agents and Give your website an agent front ## 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, receiving applications, and previewing the fields you asked for so you can sort a round. None of that is billed on any plan and none of it is going to become billed. The free plan also includes the first ten applications you take in, over the life of the account. Taking in more needs a paid plan. ### Per application you take When you advance a candidate to interview or beyond, or pull their full application into your systems, that application is what you pay for, once. 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. On the per pull through plan the first ten are included, over the life of the account, and each one after that is twelve dollars. On the platform plan you pay two hundred dollars a month, the first forty are included, and each one after that is five dollars. ### An annual contract Agreed with us and invoiced yearly, with no metering, for an institution that wants its volume, its support and its terms in writing. It has no list price, because it is a figure the two of us agree. Talk to us before you build anything and we will tell you what it would cost you. The full price list is in US dollars and excludes tax. It gives list prices: an institution that has agreed a different rate pays what it agreed. 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. Until you ingest them, the substance of applications is sealed in the applicant's own browser under keys we never hold, so we carry those bytes and cannot read them, and once you pull them the data is your responsibility. The privacy policy lists the few parts that are not sealed. 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: after the first ten, twelve dollars each on the per pull through plan, or five dollars each after the first forty on the two hundred dollar a month platform plan, or an annual contract agreed with us. The price list has the detail. 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? Not the substance of them. Work history, education, skills and the rest of the record 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. A few parts are not sealed, such as the regulated sections like work eligibility, and the privacy policy lists every one. That is worth something to you as well as to them: the middle layer is not a readable second copy of your candidates' records. ### Does Verigrant screen or score candidates for us? No. We cannot read the substance of an application, 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. --- Page: https://verigrant.com/agents.html Title: Apply on a person's behalf, under a grant they issued | Verigrant for AI agents # Apply for someone. Hold nothing of theirs. Payment mandates gave your agent a way to spend on somebody's behalf, inside limits they set, without you becoming their bank. Verigrant is the same idea for the half of a transaction that is not money. Your user keeps one application, you apply anywhere with a name they gave you, and the fields go to the institution rather than through you. Free forever. No fee to apply for somebody and no fee to redeem a grant you were given. Applying on somebody's behalf ``` POST /api/vera/applications { "rp": "northfield", "scopes": ["profile:read", "history:read"], "kind": "preview", "reference": "MSc Data Science, autumn intake" } The answer names the institution, its domain, the scopes, and whether a human will answer this in their own queue. ``` **A contract, not a layout** Named scopes with known shapes, instead of a page that changes on a Tuesday. **Nothing worth stealing** An assistant code in review mode carries no key material and opens nothing. **Consent you can point at** The person signs the disclosure themselves, and they can see it. **Nowhere for injection to land** No route takes a subject, so a hidden instruction has no target. ## Automating the form was always the wrong shape. To fill a form on somebody's behalf you first have to hold everything about them, then guess what each field wanted, then assert the result as though it came from them. Three bad positions in a row, and every one of them is a position you were forced into by the absence of an interface. Automating the form ### Guessing at scale, while holding everything - You keep a copy of a person so you can type them into pages. - Every layout change is your outage, and there is no version number. - You are the party asserting facts you were never in a position to check. - An instruction hidden in a posting is aimed at the thing holding the data. Acting under a grant ### Applying for someone, on purpose - You hold a name that opens nothing and authorises one call. - You ask for named scopes, and the shape of them does not move. - The person asserts their own data, signs it, and keeps the receipt. - There is no route that could be pointed at anybody else. ## How it works, in as much detail as you want The same four steps either way. The first level is what to tell the person you are acting for, and the second is what to build against. - **Ask your user for an assistant code.** They mint it in their own account and hand it to you. It is a name you can apply under. It is not a password, it opens nothing, and it is safe for them to give you because losing it costs them almost nothing. - **Apply anywhere with it.** You name the institution and the scopes it asks for. You are not scraping the form, retyping your user's history or attaching a document. You are filing an application against a contract that stays the same next month. - **They approve, and the fields go straight to the institution.** Your application lands in their queue. When they approve, their own browser opens what that institution asked for, less anything they untick, for that one institution. Nothing readable passes through you at any point, which is why you have nothing to protect. - **Tell them it is waiting, and stop.** When a human has to answer, say so and leave it. Do not poll. Their queue is theirs, they can see everything you filed, and they can revoke your name in one press without asking you first. - **An assistant code in review mode is a hash on our side and one route on yours.** It is minted by the account holder, stored hashed, and shown to them once. It carries no key material whatsoever. The only call it authorises writes a pending row, and one unanswered application per institution is allowed, so a leaked identifier can neither read nor flood. - **The request names a relying party, scopes and a kind.** The answer tells you the institution, the domain it registered, the scopes it asked for, and whether the grant issues on its own or waits for a person. When it waits, tell your user and stop. There is no status you can hurry along by asking again. - **The disclosure is sealed in their browser, not in your process.** Their client checks the institution's public key against its domain and against an append only log, refuses to seal if either check fails, then seals the record keys to that key and signs a statement over the scopes. You are not in that path, and no route anywhere decrypts the sealed record for a caller. - **No route takes a subject, and every grant is read again per request.** You cannot be redirected at somebody else's application because there is no parameter that would express it. Revocation takes effect on the next call rather than after a cache expires, so the honest thing to tell your user is that their press works straight away. The addresses, the request shapes and the behavior at the edge are written out in full. Read the integration guide ## Act at websites too, inside limits the person set. Applying is no longer the only thing your agent can do through Verigrant. A person can pair your agent to act for them at websites, and set what it may do there. - **The agent pass** You ask Verigrant for a short pass for one site. It shows that a real person stands behind you, within their limits, and it does not carry their name. The site checks it itself, against Verigrant's published key set, without calling Verigrant. - **The grant back** A site that adopts Verigrant can answer your pass with a grant of its own, to a structured interface built for agents instead of its pages built for people. - **Task plans** You propose a chain of steps and the person approves it. A step can need one tap or their authenticator code before it runs. - **Orders** You drop a complete, signed order into Verigrant. The traveller details in it are sealed in the person's browser to the business, so you carry them and cannot read them. The business pulls the order, completes it and sends a signed result. The person keeps a sealed receipt. - **Updates after a booking** A business the person allowed can send booking updates, such as a cancellation with other options, sealed to the person and, if they allow it, to a key you made for that booking. ### Not live yet - **Money** Payment approvals run in test mode. No money moves through Verigrant. - **Passkeys** A step that needs a passkey cannot be approved yet, so your agent cannot do it. - **A hosted door** A site needs its own door for the grant back. Fronts hosted by Verigrant go live on their own day. ### What pairing for websites puts in your hands A paired agent holds its own keys and the key to the one section of the person's record they chose. Keep both the way you keep any secret. The person can revoke you at any time, and a pass you already hold ends within ten minutes. How to call it, step by step: Use Verigrant from your agent ## Announce your agent. Get the front, with or without a person. An agent does not need a person behind it to use a Verigrant site. It needs a Verigrant agent ID: a short lived credential, signed by Verigrant, that says who operates it and what it is there to do. A site checks it on its own server, against keys we publish, and never tells us which agent visited. - **Register in two minutes** One command registers you as an operator, declares your agent, makes its key and fetches its first credential. The only pause is the code we email you. - **Four levels, chosen by the site** Level A is a confirmed email and your agent's keys. Level B is your domain proven with one DNS line or one file, and your keys published there. Level C is a registered institution standing behind you. Level D is a named officer who has passed Verigrant's identity check. Sites choose the lowest they accept. - **The front, at level one** Trade your agent ID for the site's grant with one standard token exchange. Search, list, get, availability and quote, live. Take actions in the clear with exactly the fields the action lists. Watch a change feed instead of polling. Or speak MCP to the same front. - **The directory** Sites that proved their domain list their fronts. Search by text, category, level, purpose or place, with no credential. Verified operators are listed by their proven domain, with their standing. - **Connect, for the person** When your agent acts for a person, they connect it with one click from the assistant itself: Verigrant is an OAuth 2.1 authorization server for remote MCP clients. They sign in, read your limits in plain words, and approve. Your agent holds a token and no key, so it can open nothing sealed. ### On their own day - **The egress** Sending through Verigrant's own network, for sites that want every request checked before it arrives, goes live after the registry. Declare your own networks until then. - **The hosted door** Fronts Verigrant hosts for sites go live after the registry. Today a front is one the site runs itself. - **The registries** The CLI and the kits are open source under Apache 2.0 and not yet on a public registry. Ask support for them. Registering an agent ``` verigrant agent register --email ops@example.com --name "Example Agents" --accept-terms \ --agent-name shopper --purpose assist --network 203.0.113.0/24 --rate 500 \ --abuse-contact abuse@example.com ``` An operator registers in two minutes, and a site goes from its website to a live front in fifteen. Both are measured in the release test, which times an operator to level A and a site to a live front and fails if either passes its limit; on the build box they take under a second and under three seconds. Run an agent under a Verigrant agent ID ## The data side counterpart to a payment mandate The payment work solved one half of acting for a person. An agent can be given authority to spend, bounded by limits the person set, and the merchant is dealing with a mandate rather than with a stolen card. Everybody understood immediately that the alternative, handing the agent the card itself, was never going to be acceptable. Applying is the other half, and it is the larger one. People delegate applications constantly, the data involved is far more sensitive than a card number, and the only automation available has been to hand the agent a copy of the person and hope. This is the mandate for that: a scoped, revocable, auditable authority to apply, with the data going where it was meant to go rather than through whoever automated the form. One thing follows from being a rail rather than a destination, and it is worth saying before you ask. There is no Verigrant agent. We do not ship an application agent of our own and we are not going to, because running one would mean holding a readable copy of the person whose record it is, which is the one thing this service is built not to do, and because it would put us in competition with the agents that bring people here. You are the distribution rather than a segment to be won. ### What you never have to solve - **Custody you did not want** You hold a name rather than a person, so there is nothing to encrypt at rest. - **Proving your user agreed** They sign the disclosure themselves and keep it, so it is not your word. - **Parsing a document** Nothing you touch is a file, so nothing you touch is a parser vulnerability. - **Being the one who asserted it** You filed an application. The person made every claim in it. ## Ask for the weak one. It is the one that scales. There are two modes, review and auto, and the difference is whether a human answers each disclosure. Both work, both let the person set how long a share lasts, and only one of them keeps you out of the custody business. Review mode, and the one to build against ### You apply, they approve - No key material, one authorised route, nothing readable in your hands. - Every disclosure is answered by the person in their own browser, who sets how long it lasts. - A leak costs your user some noise in a queue and nothing else. - You can integrate it without a security review of your storage. Auto mode, for users who want no clicks ### You issue while they sleep - Paired once, with a written limit on what you may ever ask for and how long each share lasts. - Inside that limit you issue on your own, and each one shows up in their list. - The limits are enforced by us, not by you behaving well. - They can revoke it, and every route closes to you immediately. ### Say this to your user before you ask for auto mode Auto mode means that they, you, and anyone your key leaks to before they next sign in, can read the fields they allowed for the window they allowed. Verigrant still cannot read the sealed records among them. That is a real trade and it is theirs to make, not yours to make for them by defaulting to the convenient option. ## Questions builders ask first The short answers. The integration guide has the long ones. ### What is the relationship to payment mandates? A payment mandate lets an agent spend on somebody's behalf inside limits they set. Verigrant is the same idea for the half of a transaction that is not money. An application is the other thing people delegate constantly, it involves data far more sensitive than a card number, and until now the only way to automate it was to hold a copy of the person and retype them into forms. ### Do I get to read my user's application? No, and that is the feature. Their application is sealed in their browser and the disclosure goes to the institution, not through you. You apply under a name, the request lands in their queue, and they approve. You never hold anything readable, so a mistake on your side is an embarrassment rather than a breach. ### Can a hidden instruction in a job posting redirect me? It has nowhere to land. No route accepts a subject parameter, so there is no call you could be tricked into making against a different person's application. The worst an injected instruction achieves is an application to an institution your user did not want, which they see in their queue and decline. ### What does a leaked assistant code cost my user? An assistant code in review mode carries no key material and authorises exactly one route, which writes a pending row. Somebody who stole it could add rows to your user's queue and read nothing at all. It is stored as a hash, it is shown once, and only one unanswered application per institution is allowed, so it cannot be used to flood a queue either. ### Should I ask for auto mode? Usually not. Auto mode lets you issue inside limits your user signed, for the length of time they set, which removes their approval step and adds real key material to your custody. That is a genuine trade and it should be their decision, made with the cost stated plainly. Ask for review mode, build against it, and let the people who want no clicks upgrade themselves. ### What does it cost to integrate? Nothing. There is no fee to apply on somebody's behalf and no fee to redeem a grant you were given. Agents are how this reaches people rather than how it earns, so what money there is comes from the institutions that take applications in. ### Will Verigrant compete with me? No, and the architecture is the reason rather than a promise. Verigrant ships no application agent of its own and is not going to. Running one would mean holding a readable copy of the person whose record it is, which is the one thing this service is built not to do, and it would put us in competition with the agents that bring people here. There is a drafting helper inside a person's own account, which writes a draft for them to read with their own model key or a metered one. It sends an application only when the person ticks that it may, for that one run. ### How do I discover what to call? Read llms.txt at the root of this site. It states what Verigrant is, what each side gets, the routes with their request shapes, and the behavior at the edge. The integration guide is the same material written for a person building against it. ## Act for people without holding them. Everything you need is at llms.txt, and the integration guide is the same material with the reasoning attached. Free forever, and there is no scraping left to do. --- Page: https://verigrant.com/for-agents.html Title: Verigrant integration guide: apply for your user, receive without ingesting # Apply for your user. Receive without ingesting. Apply on your user's behalf without holding their data. One credential, structured submission, no forms, no retyping, and no liability for what you never stored. That is the whole of what this page is about, and it is the same line llms.txt gives a machine that arrives without reading any of this. You apply under a mandate and an institution receives under a grant. The page is written for both of those readers, and the thing both of you need to know next is that the store in the middle cannot open the sealed record. Verigrant holds its substance as ciphertext and sealed keys, and no route here will decrypt any of that for you, because no route here can. What stays readable, such as the regulated sections and the metadata, is listed in the privacy policy. ## The addresses, before the argument If you are a machine and want the short version, everything below is elaboration on these ten lines. POST https://verigrant.com/api/vera/applications The whole of what an assistant code in review mode authorises. It is called `vera_id` on the wire. Present it in `X-Verigrant-Vera-Id`. Writes a pending row in the owner's approval queue and discloses nothing by existing. GET https://verigrant.com/api/shared/records The delegated read, for a registered institution. Returns ciphertext plus the record keys sealed to your published public key. Takes `?kind=preview` or `?kind=full`. Two credentials, described below. POST https://verigrant.com/api/shared/advance Stage two of the gate. Asks the candidate for the full set. The keys to it do not exist anywhere until they answer, so this is a request and not a flag. GET https://verigrant.com/api/rp/keys/log/sth The signed tree head of the append only log every relying party key is published into. Inclusion and consistency proofs are at `/api/rp/keys/log/proof`, and one institution's registry entry is at `/api/rp/{slug}/keys`. All three are open, deliberately, because a client that has to authenticate before it can check us is not checking us. POST https://verigrant.com/v1/grants/verify Open to anybody. Answers whether a delegation is signed, unexpired and unrevoked without disclosing a field of any record. The answer carries `relying_party_required` and, when the delegation names one, the audience slug, so a valid answer is never mistaken for a redeemable one. GET https://verigrant.com/api/postings Open vacancies, no credential required. `/api/postings/{id}` carries a `json_ld` object, a schema.org `JobPosting`, built from the same row it is serving. POST https://verigrant.com/mcp The same service in the shape an assistant already speaks. Model Context Protocol over JSON-RPC 2.0, with a grant token as the whole session and four tools that take no arguments. It is a wrapper and holds no rules of its own, because each tool is a call to a route above. Use it where the point is to start without an integration project. The sealed read is served over REST only. GET https://verigrant.com/.well-known/verigrant-agentid-keys.json The key set that signs every Verigrant agent ID and every agent status list. A site checks an agent's credential against it offline and never tells Verigrant which agent visited. A level A agent's own key directory is at `/api/agent-registry/directories/{agent}`; from level B it is on the operator's proven domain. POST https://verigrant.com/v1/agent-registry/credential Where an agent renews its agent ID: the agent and its key's thumbprint in the body, the request signed with Web Bot Auth by that key. The credential lives at most 24 hours. The `verigrant` CLI and the agent kit call this for you; the guide for agent operators has the rest. GET https://verigrant.com/api/directory/search The directory of agent fronts, no credential required: sites that proved their domain, by text, category, level, purpose, or a point and a radius. Verified operators are at `/api/directory/operators`, listed by their proven domain with their standing. The OpenAPI document is at `https://verigrant.com/api/openapi.json`, generated from the handlers it describes rather than maintained beside them, so a renamed field or a changed status code moves the description with it. Point a client generator or an API viewer at that URL. llms.txt is the same surface written as prose, llms-full.txt is the text of every page on this site in one fetch, and /.well-known/brand.json carries the brand facts as JSON. ## If you apply for someone: hold a mandate, not a copy of a person The usual shape of an application agent is browser automation that reads a job page, reconstructs its user's history from whatever it was pasted, and types that into an applicant tracking system. Every part of that is fragile, and two parts are worse than fragile: you become the party asserting facts about a person, and you become a custodian of their identity documents. Verigrant inverts both. Your user issues you an **assistant code**. The ordinary kind carries no key material at all and authorises exactly one route. You call it once per application. The disclosure that answers it is sealed in your user's own browser and travels to the institution, not through you. ### What that changes for you - **The facts are not yours to invent** You never assemble a claim about your user, so you are never the party who has to stand behind one. The institution receives what your user sealed, signed by them; in auto mode, what you sealed inside their preset, with our signed attestation that you acted under their authority. - **You store nothing that matters** Losing your assistant code means somebody can add rows to a queue. That is the whole incident. It is a very short answer to give a security reviewer. - **You cannot be redirected** No route takes a subject parameter. An instruction hidden in a job description cannot make you act for a different person, because there is no argument in which to name one. - **A refusal is a decision** Past the window, past a cap, outside the scopes, or revoked, is a `403` with a reason and a row in your user's trail. Report which one and stop. Do not retry around it. - **There is no Verigrant agent to compete with** We ship no application agent of our own and are not going to. Running one would mean reading the person whose record we are carrying, which is the one thing this service is built not to do, and it would put us opposite the agents that bring people here. The drafting helper inside a person's own account writes a draft for them, with their own model key or a metered one, and sends an application only when the person ticks that it may, for that one run. one application, start to finish ``` # the code is the whole credential. it opens nothing. POST https://verigrant.com/api/vera/applications X-Verigrant-Vera-Id: vera_… { "rp": "acme-university", "scopes": [ "profile:read", "history:read" ], "kind": "preview", "reference": "MSc Data Science, autumn intake", "note": "Deadline is the 14th." } # the answer. nothing has been disclosed yet. { "request_id": "…", "status": "pending", "source": "review", "org_slug": "acme-university", "org_domain": "acme-university.edu", "auto_issue": false } # auto_issue false means a human will answer this. # do not poll. tell your user it is in their queue. ``` ### The two modes Both are minted by the account holder, never by you, and both are stored as a hash and shown once. The difference is whether a human answers. In both, the account holder sets how long a share lasts. The differences between review mode and auto mode | Property | Review mode | Auto mode | | Key material held | None | Scope keys sealed to your own key | | Routes authorised | One | Four, all signature bearing | | Who issues | The user, in their browser | You, inside a signed preset | | How long a share lasts | Set on the approval | Set in the preset the mandate signs | | Minted by | `POST /me/vera-ids` | Pairing at `POST /me/capabilities` | | If the string leaks | Queue noise, no disclosure | Nothing without your signing key | ### Before you ask a user for auto mode Say this to them, in these terms. Auto mode means that person, you, and anybody your key leaks to before they next sign in, can read the preset's scopes for the length of its window. Verigrant still cannot read the sealed records among them. There is no arrangement of these primitives that avoids it, because an agent that issues a disclosure with nobody online must be able to read what it is disclosing. Revocation stops you at every route immediately. Retiring the scope keys you already hold needs the user's own key and runs at their next sign in, and the API says `rotation_pending` until it does. If your product does not genuinely need to act while the user is away, take review mode. A paired agent's routes are `GET /api/agent/pending`, `GET /api/agent/records` and `POST /api/agent/grants`, each requiring the code in `X-Verigrant-Vera-Id` and an Ed25519 signature over the request in `X-Verigrant-Agent-Signature`. Every limit in the preset is checked on our side, not asserted by you. ## If you receive applications: pull fields, not files, and decrypt them yourself Intake pipelines usually begin with an extraction step, and that step is where the accuracy budget goes: a two column layout, a date range written three ways, a job title that is really a department. Everything downstream inherits whatever it guessed, and everything downstream also inherits whatever a stranger wrote into the document on purpose. There is no document here. `GET /shared/records` returns named fields from one schema for every applicant. What it actually hands you is ciphertext plus the record keys sealed to the public key you published, and our open library opens them locally with a private key you keep wherever you keep private keys. ### Registering, so that you can read at all - **Publish two keys** An X25519 key for receiving sealed record keys and an Ed25519 key for signing your own announcements, posted to `POST /orgs/{id}/relying-party/keys`. Several generations may be active at once, and a grant records the exact key it was sealed to, so rotating never breaks an outstanding disclosure. - **Attest on your own domain** Serve the matching signed statement at `/.well-known/verigrant-relying-party.json`. An applicant's browser fetches that directly from you, never through us, and refuses to seal if it disagrees with what our registry says. - **Every registration is logged, permanently** Each key becomes a leaf in an append only Merkle log with signed tree heads. That does not stop us inserting a fraudulent key. It makes doing so public, permanent and attributable, which is the entire and deliberate claim of a transparency log. - **Keep the private key away from us** The library supports a key provider backed by a KMS, an HSM or, with a warning on every use, a file. There is no route on this service that would accept a private key, and there never will be. ### Two doors, and which one to lead with REST is the production door. It is what Workday, an applicant tracking system, a student information system and your own software integrate against, with an API key that belongs to your institution, and it is the only door the sealed record is served through. Where the people deciding this are the people who run your systems, this is the door to put in front of them: it is versioned, it can be monitored, and it can go through a review that ends in a signature. MCP is the other door onto the same service, and it adds nothing. That is the point of it. Every tool is a call to a route listed above, so there is no second set of rules to drift out of step with the first. What it removes is the project: an institution with no integration budget and nobody to assign can hand an assistant a URL and a grant token and be reading the same day, which is the version of this that gets used where procurement is the obstacle rather than the interface. Two limits come with that door and are better read here than discovered. The tools wrap the grant check and the profile read, so an institution that wants the encrypted bundle integrates over REST. And a deployment expecting agent traffic wants its rate limit raised, because a conversation makes several calls where a REST client makes one. preview, then advance, then full ``` # two credentials. the grant, and proof you are you. GET https://verigrant.com/api/shared/records?kind=preview Authorization: Bearer v2.… X-Verigrant-Relying-Party: Key vgrp_… # ciphertext, plus record keys sealed to your key. { "statement": { "kind": "preview", "entries": [ … ] }, "signature": "…", "records": [ { "ciphertext": "…", "sealed_dek": "…" } ] } # you shortlisted. now ask for the rest. POST https://verigrant.com/api/shared/advance # until they answer, the full keys do not exist. GET https://verigrant.com/api/shared/records?kind=full # -> 409 bundle_not_sealed, which is not an error # on your side. it is the gate working. ``` ### What every refusal means The response for each state of a delegated read | State | Answer | | Signed, unexpired, unrevoked, in scope, and you are registered | 200 | | No institution credential presented | 403 relying_party_required | | Valid, but issued to a different institution | 403 | | Valid, but that scope was never granted | 403 insufficient_scope | | Withdrawn by its owner | 403 revoked | | Asked for a stage the candidate has not sealed | 409 bundle_not_sealed | | Expired, unknown, tampered with, or absent | 401 | ### What you keep, stated once A record you pulled and decrypted is yours, as a dated snapshot of a specific version. Withdrawal stops the next read and every further seal on the very next request. It does not reach what you already opened, and we tell the applicant so at the moment they agree to advance rather than implying otherwise. A fresh key is used for every saved version, so a delegation cannot quietly follow a record forward. What you were given is what you were given. ## What is no longer true, if you integrated before the cutover The server stopped being able to hold a readable profile. Anything that depended on it being able to changed, and pretending otherwise would waste a day of your life. ### The plaintext profile routes are gone The narrative core, the positions held, the qualifications and the skills are now encrypted records. The columns were dropped and the routes that read and wrote them went with the columns. There is no second way in, because a handler that wanted to write a headline has nowhere to put it. ### The MCP tools and the versioned read still exist `/mcp` and `GET /v1/profile` serve the part of the record that has not yet crossed to the encrypted path, plus the summary of checks. Treat them as the legacy edge. A section that is empty means either that the grant does not reach it or that it now lives as ciphertext, and the encrypted read is `GET /shared/records`. ### Nobody ranks candidates any more The server side candidate ranking is retired outright. We cannot rank people we cannot read. Institutions shortlist on the preview, in their own systems, which is what the two stage gate was always asking them to do. ### A check travels as a note, never as evidence A result carrying field values is refused. What travels is a short note naming the kind of check, who ran it and when. Today that reviewer is a member of Verigrant staff, with outside verification vendors to follow. The note is signed so you can check it offline, and it says a review happened rather than that anything in the record is true. ### The server no longer validates content It cannot see a phone number to tell you it is malformed. Shape, size, rate and scope checks stay; field validation moved to the client and to you. Garbage is now caught at the ends rather than in the middle. ### Documents are opaque Files are sealed in the person's browser and stored as ciphertext, with no server side parsing or text extraction. That removed a parser attack surface as well as a readable store, and it is the mechanical reason there is no injection surface in the intake flow. A file stored before sealing shipped stays readable to Verigrant until its owner encrypts it. ## Why this beats automating the form Not an appeal to principle. Six things that make your product work better, and keep it working. ### A contract instead of a layout Form automation breaks when somebody moves a field. An interface breaks when somebody publishes a new version, on purpose, having said so. Your maintenance load stops being proportional to the number of institutions your users apply to. ### Custody you never wanted Holding somebody's identity documents is a liability with no upside for an agent. Here you can say truthfully that you hold none of it, which is a sentence that shortens security reviews and lengthens funnels. ### Consent you can point at A user telling you to is not evidence. A signed statement naming the records, the versions and the recipient is. It lives in their account, and they can read and revoke it without asking you. ### A blast radius chosen in advance Screen scraping runs with whatever the session can reach, which is everything. A delegation reaches the records it names. The worst thing a bug in your agent can do is bounded before your agent runs. ### Injection has nowhere to land Job descriptions are hostile input and you already knew that. Here no route takes a subject, so the classic escalation, talking a model into naming a different person, has no parameter to write into. ### One layer, five verticals Jobs, admissions, insurance, lending and rentals are the same call with a different institution slug. You build the integration once and your product widens without another one. ## What the edge will and will not do to you - **Rate limiting is per address, with a `Retry-After`** An agent conversation makes several calls where a REST client makes one, and `/mcp` is inside the same limiter as everything else. Read the header rather than guessing a backoff. The open postings feed is deliberately not throttled, because a job board that answers a crawler with `429` has published nothing. - **Bodies are capped at 16 KiB** A grant token is a few hundred bytes and an application request is not much more. The cap exists so nothing unbounded can be streamed at the edge, not to constrain real traffic. - **Upstream calls have a 15 second deadline** Five seconds to connect. A timeout is reported as a timeout. Nothing here degrades into a plausible looking empty answer. - **Every read is recorded and the owner is told** Reading through a delegation is not anonymous. Build as though your user will look at the trail, because they can, and because an unexpected read announcing itself is one of the few defenses against a compromised gateway. - **Do not retry a refusal** `revoked`, `expired`, `insufficient_scope` and `relying_party_required` are decisions, not transient faults. Report which one, and let the person issue a new delegation. - **Verify a key before you trust it, and refuse if you cannot** If you seal anything, fetch the institution's attestation from the institution's own domain, check the inclusion proof against a pinned tree head, and refuse rather than falling back. A key handed to you by the party you are defending against is not a key you checked. ## If you act for someone at websites: carry a pass, not their name A person can pair your agent to act for them at websites. The pairing is a mandate they sign in their own browser: which sites, for what purpose, which actions, how long each pass lasts and how many a day. Your agent then calls Verigrant's face for the person's own agent, `POST https://verigrant.com/api/agent/mcp`, signed with the request key the mandate names. - **The pass** The tool `get_agent_pass` takes a site and a purpose and returns a short pass, ten minutes at most, bound to your Web Bot Auth key. You attach it as the `Verigrant-Pass` header inside a Web Bot Auth signature, to that site only. The site checks it offline against `https://verigrant.com/api/.well-known/verigrant-pass-keys.json`. Verigrant never sees the request, the page or the response. - **No name, one address per site** The pass carries the person's address at that site alone, so two sites cannot match the person through it. No argument names a person, and every argument can only narrow what the person allowed. - **The grant back** A site that adopts Verigrant publishes a service file and trades your pass for its own grant to a structured interface for agents. - **Task plans and approvals** `propose_task_plan` puts a chain of steps in the person's approvals. When a step needs more than they approved, the answer is `step_up_required` with a level. Tell the person, wait, and ask again. Nothing you send can approve a step. - **Orders** `get_traveler_details` hands you the person's traveller details sealed to the business, `drop_order` drops a signed order, and `order_status` returns the business's signed outcome. - **Booking updates** `register_update_key` and `booking_updates` let you read the updates a business sends about a booking, when the person allows it. - **Connect, instead of pasted keys** A person can connect your agent with one click from the assistant itself. Verigrant is an OAuth 2.1 authorization server for remote MCP clients: your client reads the protected resource metadata the 401 from `/api/agent/mcp` names, registers itself, sends the person to the consent page, and trades the code for a ten minute access token, PKCE S256 required. The token then stands in for the assistant code and the signature above. The person's browser signs the mandate, so your client holds a token and no key, and can open nothing sealed. - **Without a person: the agent ID** A registered agent trades its Verigrant agent ID for a site's grant at level one, in the same token exchange, with `urn:verigrant:token-type:agent-id` as the subject token type and the purpose it is there for. Beside a pass it rides as the actor token. The guide for agent operators has the commands. ### Not live yet Payment approvals run in test mode, so no money moves through Verigrant. Passkey approval is not available on production, so a step that needs one cannot be approved. Fronts hosted by Verigrant, and the egress through Verigrant's own network, go live on their own day after the registry, the directory and Connect. The agent kit, the local MCP server `vg-agent-mcp` and the egress specification are described in Use Verigrant from your agent. --- Page: https://verigrant.com/security.html Title: Security & custody: what is sealed, what we can see, and what it costs # Custody is a set of properties, not a promise The reason to hand a system your career record, or to build a hiring pipeline on top of one, is that it can say precisely what it does with it, in terms specific enough to be wrong about. So here is all of it: what your browser seals before we ever see it, the one other key that opens it, what we can still see anyway, and what happens to the parts you lend out. ## Your record is sealed before it reaches us What you type is encrypted inside your own browser, under a key made from your password. The password is stretched with argon2id against a salt belonging to your account, and two separate values come out of that stretch: the key that locks the record, and the credential you sign in with. Only the second one is ever sent. **Your password never reaches this service.** What we hold for your account is a verifier for that derived credential, and no password anybody could type would match it, so there is nothing on this side for a support tool to check or for an attacker to steal. What that seals is the substance of the record: the narrative core, every position in your work history, every qualification, every skill, and the contact details, licences, languages, references and availability filed beside them. Each is stored as its own block of bytes under its own data key, and the key that opens those data keys is wrapped under yours. What arrives here is ciphertext, a wrapped key we have no way to unwrap, and a label saying which kind of record it is. So there is no support tool that opens it, no administrator button and no route in the software that would, because there is nothing on this side to open it with. A stolen copy of the database is a pile of locked boxes and no keys, and every box has a different lock: there is no master key in the environment and no single secret that unlocks everybody, so somebody holding the whole database still faces one account at a time, and your password is the thing they have to beat. That is why the signup screen refuses a weak one rather than warning about it. An institution reads any of it only because you approved a disclosure and your own browser, holding your keys, sealed a copy of the data keys for exactly the records covered to that institution's registered public key. It then decrypts in its own environment with a private half we have never held, and we carry a block we cannot open in either direction. A disclosure that could be made while your keys were locked would be a disclosure we could make, so the screen that seals refuses to run without them. Some things are not in the sealed half, and naming them is the point of a page like this. The regulated sections, which are work eligibility, the voluntary self identification answers, your consent trail and the date of birth and last four digits you may have given, sit outside the record document, answer to scopes of their own, are not disclosed without one, and are readable by us. Documents you upload and the answers in your answer bank are sealed in your browser too, but not all of each: we can read a document's kind and rough size, and the questions your answers belong to. A document or an answer that reached us before we began sealing them is still readable until you encrypt the document or save the answer again, or delete it. one section, saved ``` # in the browser tab, before anything is sent MK = argon2id(password, salt, m=64MiB, t=3) KEK = HKDF(MK, "verigrant/v2/kek") # locks auth_key = HKDF(MK, "verigrant/v2/auth") # is sent # what actually goes over the wire PUT /me/records/8c21-… { "scope": "history", "record_type": "work_history", "byte_class": 3, "ciphertext": "k4Xq…", "ct_nonce": "9f…", "wrapped_dek": "Uu2…", "dek_nonce": "1b…" } # there is no field on that body that holds a value # from your record, and no way to add one without # the client changing. # what we hold afterwards, in full ciphertext, a wrapped key, a type label, a size band # what we hold to open it with nothing ``` - **A label is not the content** We know a row is a work history. We do not know the employer, the title, the dates or a word of what you wrote about it. - **Every version gets a fresh key** Editing a record seals it under a new data key, so an institution that was handed version seven cannot read version eight with what it already has. - **The seal is bound to the row it belongs to** The record's id, scope, type and version are authenticated alongside the ciphertext, so we can read those labels and cannot swap one person's bytes for another's without the decryption failing. ## The recovery key is the only other way in At the end of signup you are shown a recovery key, once, and you have to type the end of it back before the screen will let you past. It is not a hint and not a reset link. It is a second key to the same record, made in your browser out of random bytes, wrapped around the same master key your password wraps, and never sent to us. It is the only other thing in the world that opens what your password opens. Using it does not hand it over either. Your browser asks for a challenge, opens the recovery slot on your own machine, signs the challenge with a key it takes out of that slot, and sends the signature. We check it against a public half we already hold and answer with an ordinary session. Nothing is decrypted on this side, and the recovery key itself never crosses the wire. The screen that follows asks for a new password and is the whole of the page until it is answered, because a recovery that stopped short would leave the account exactly as its owner found it. Choosing that new password rewraps the same master key, so every record stays readable and the recovery key you just used stays good. ### The sentence we will not soften We can give you your account back and we cannot give you your data back. Lose the password and the recovery key together and the record is gone. Permanently, for you and for us. There is no operator override, because an override is a key, and a key we held would make everything above this false. The first half of that sentence is now a door you can walk through. If both keys are gone, you can ask us to empty the account and free the address, and the way it works is shaped around the one thing you can still prove, which is that you read your email. We send a link there. Opening it shows you the sentence above and asks you to type two words rather than press a button. Then nothing happens for three days, and we mail the same address again to say what is scheduled and when, so that if somebody else asked for this you have time to stop it. Stopping it takes your password or your recovery key, deliberately, because whoever asked already showed they can read the mailbox and a link we sent there would be a link they hold. After three days with no cancellation the record, the keys and the stored documents are destroyed together, we mail you to say so, and the address is free to sign up with again. Read the whole of that as what it is. It returns an account and it destroys a record, and it is offered because the alternative we shipped first was worse: an address held for ever by an account nobody could open and nobody could close. What still ships beside it is the refusal, unchanged. The emailed password reset checks whether an account is encrypted and, if it is, declines outright and points you at your recovery key, rather than quietly setting a password that would open nothing. a recovery, without a decryption ``` # the browser asks for something to sign, and for the # wrap slot it will need. neither is a secret to us. POST /auth/recovery-challenge { "email": … } 200 { "challenge": "7d1c…", "recovery_wrapped_dmk": "Qa9…" } # on your machine: recovery key opens the slot, the # master key comes out, and it signs the challenge POST /auth/recover { "signature": "MEUC…", … } 200 # a session, and nothing was decrypted here # the one thing that session may do before anything else PUT /me/keyring # the same master key, wrapped # under the password you just chose # an address that names no account gets a challenge of # the same shape, so this route answers no questions # about who has an account here. ``` - **Shown once, and only once** It is generated in the tab and displayed there. No copy is kept on this side, so we cannot show it to you again and neither can anybody who compels us. - **Changing your password does not change it** A password change rewraps the master key and leaves the recovery slot alone, so the copy you wrote down at signup keeps working and the account page says so. - **Export is the backup that needs nobody** You can take the whole record out whenever you like. A copy you hold yourself is the one form of recovery that does not depend on us at all. ## What we can still see Everything above is about what we cannot read. This is the other half, and it is the honest cost of a service that has to route a login, rank a vacancy and take a delegation back. None of it comes from reading the sealed half of your record, because we cannot. All of it is in the clear because something on this side has to act on it, or because it has not been moved into the sealed half. ### The list, in full - **Your email address** A sign in has to be routed somewhere and a message has to arrive somewhere. - **That a record exists, and roughly how large each part of it is** Sizes are coarsened into padding classes before they are stored, so what we hold is a band rather than a byte count. It still tells us whether your work history is a long one or a short one. - **When each part was last written** The times you edited, per record, whether or not we know what changed. - **Every grant you issued, and every time it was used** The scopes, the institution it names, when it expires, how many times it has been pulled and when it was last pulled. - **The organisations, the applications, and the graph between them** Which institutions you applied to, when, which advanced you, and which agents you paired. - **The addresses your requests arrived from** On sign ins, on failures, and on every entry in the custody trail. - **Your display name** The name you chose to be called in the application. Moving it into the sealed half is planned work rather than done. - **The outside of each document you upload** The file, its name, its type and your label are sealed in your browser before they are sent. We see its kind, such as a résumé or a transcript, its size to within a padding class, and when it was added. A document stored before we began sealing them is still readable, file and name included, until you encrypt it in the application and destroy the old copy, or delete it. - **The questions in your answer bank** Your answers are sealed in your browser. The questions they belong to are not, and neither are the kind of answer each takes and the choices the form offered. An answer saved before we began sealing them is still readable until you save it again or delete it. - **The regulated sections you chose to fill in** Work eligibility, a date of birth and the last four digits of a social security number, the voluntary self identification answers, and your consent trail. Each reaches an institution only under a grant that names its own scope. - **Where your agents may go, and what they order** If you limit an agent to a list of sites, we can read that list. When your agent asks for a pass we see the site at that moment, and the record of it is sealed to you. An order your agent drops names the business, the offer and the total in a row we can read, and the row is deleted a week after the order arrived. A form you fill with Verigrant names the business until shortly after it is delivered. An update or a message a business sends you about a booking is sealed to you: we see which business sent it, when, and roughly how large it is. - **The assistants you connected, and the agents you operate** A connected assistant is a row we can read: the name it gave itself, the address it sends you to, the permission you signed, and when it was connected and last used. It holds no key to your record. If you register as an agent operator, that is not a person's account and none of it is sealed: your email address and name, each agent's declarations and the public half of each key, your domain claim and its checks, the reports sites file against your agents, and every credential issued, which is a leaf in a public log. If a business lists a site in the directory, the listing is public by design; if it opts in to the hosted dashboard, we hold counts of visits by operator, level and purpose, and refuse anything else. The privacy policy lists every field we hold in the clear, and it is the one to hold us to. ### What that adds up to A real social graph. It is not the record, and the difference is the entire product, but a page that listed what is encrypted without listing what is inferable would be marketing rather than a security page. Hiding the graph as well would take private information retrieval or a mixnet, and we have built neither. ### If your threat model includes us Then weigh the list above first, because it is what we see without attacking anything at all. Then weigh this: the client that does the sealing is delivered by us, over the web, so an operator willing to serve bad code to your browser could take your password the next time you sign in. That is inherent to cryptography delivered by a web page, and no page claiming otherwise should be believed, including this one if it ever does. ### One part of that is defended, not just disclosed The institution key your browser seals a grant to is a key we hand it, so a Verigrant that wanted to read a delegation could answer that lookup with a key of its own. Every institution key we register is therefore a leaf in an append only log, and your browser checks the entry against a signed head under a publication key it pins, keeps the newest head it has accepted, and refuses to seal anything if the log has been rewound, forked, or grown in a way that does not contain what it saw last time. An answer we change later is a refusal on your screen instead of a silent redirection of your record. ### And the half of that which is not finished Pinning catches a Verigrant that tells one browser two different stories over time. Catching one that tells two browsers different stories at the same moment needs somebody outside us comparing published heads. The proofs and the heads are served openly so that anybody can, and today nobody is doing it, which is a gap we would rather write down than leave for a reader to discover. ## A delegation, not a copy A grant is a set of scopes and an expiry, recorded as a row and handed out once as a token signed with ed25519. The signature only proves the token is one of ours. The row is the authority, and it is read again on every use, which is what makes revocation immediate rather than eventual. The token is returned exactly once, at mint, and never stored: no later endpoint can reissue it, and a copy of our database hands nobody a working credential. Every use is counted, timestamped and attributed, so a delegation's whole history is something its owner can read back. Approving a disclosure does one more thing underneath the row. Your browser asks us for the institution's public key, asks the institution's own domain for the same key, refuses to go on unless the two agree, and only then seals a copy of the data keys for exactly the records covered. So the scopes are not only a rule we enforce: what a holder was not granted, they were handed no key for. The default lifetime is 90 days. A grant is a standing delegation, but never an unbounded one. ### What a scope delegates Thirteen scopes, each a tier of the record rather than a single box on a form that gives away all of it at once. `profile:read` on its own is an introduction. Anything beyond it has to be asked for, in the open, on a token its owner can read and revoke. Each grant scope and the part of the record it delegates | Scope | What the holder may read | | `profile:read` | Who you are, how to reach you, where you live now, and which of your claims have been checked | | `history:read` | Work history, education, skills, languages, driving experience | | `credentials:read` | Licenses and certifications, including CDL class, endorsements and restrictions | | `preferences:read` | What you are looking for, and when you can start | | `documents:read` | Documents you uploaded, and their contents | | `answers:read` / `answers:write` | Your answer bank, and adding to it | | `identity:read` | Legal and former names, address history, date of birth and SSN last four | | one scope each | Work eligibility, EEO self identification, and your consent trail, read and, for consents, write | | `applications:submit` | Nothing at all. It is permission to act, to send an application in your name | A section you never granted comes back empty rather than missing, so a holder learns nothing from its absence. Three things no scope delegates, ever: your references, your former supervisors, who are other people and cannot consent through you, and your pay history. a grant, start to finish ``` # minted once; the token comes back here and nowhere else POST /me/grants { "scopes": ["profile:read", "history:read"] } 201 { "grant_id": "8f3a-…", "token": "v2.eyJncmFudF9pZCI6…", "expires_at": "2026-11-17T09:00:00Z" } # the holder reads exactly what you delegated. no more. GET /v1/profile Authorization: Bearer v2.eyJncmFudF9pZCI6… 200 { "headline": …, # a check note goes to the person, who decides who sees it "verification_status": "verification status is available from the applicant" } # you change your mind DELETE /me/grants/8f3a-… 403 revoked # on their very next request. no window, no cache. ``` - **A signature is never the whole answer** A revoked grant carries a perfectly valid signature forever. Every check also reads the row, so what a reader gets is the current state of the delegation, not what it was when it was issued. - **Unavailable is a real answer** If the row cannot be read, the answer is unavailable. Nothing here degrades to "probably fine" under load. - **Revocation stops the next read, not the last one** An institution that already pulled and decrypted a version of your record still has it, under its own retention, and no cryptography undoes that. What exists instead is a manifest of exactly which records crossed, at which versions and under whose signature. The service answers for it per delegation today, and the screen that shows it to you is still to be built. - **An employer is an account, never the holder of a loose token** Applying to a vacancy mints a grant scoped to exactly what the posting asked for. The employer is a roster of accounts this service already signs in, so there is nobody to hand a loose credential to, and cutting access off works the same either way. ## A check somebody reviewed, in a form you can keep Everything a person types is a claim. A check is somebody else's review of one of those claims, and it lives apart from the record on purpose: a claim and a review of it have different authors, different lifetimes and different trust, and merging them would make a field the subject can edit indistinguishable from one somebody else looked at. Checks are reviewed by Verigrant staff working a queue, oldest first, and outside verification vendors are the next thing to be connected. They are never decided by the person being checked, which would make the whole layer decoration. What reaches that queue is the shape of the check: the kind, the reviewer, their reference and notes. The evidence behind it never enters this service at all, and neither does the record. An approval is signed. What that signature says is that this kind of check was reviewed and approved on this date, and never that the record itself is true. We could not stand behind that record even if we wanted to, because we cannot read the substance of it. A refusal is written down where the subject can read it, in the reviewer's own words, because the person refused is entitled to know why. ### Encryption is not an identity check Sealing a record proves that it was sealed. It does not prove that the person who sealed it is who they say they are, and no page here should leave a reader thinking otherwise. What this service improves is the provenance of a claim, the consent recorded around it, and the structure of what an institution receives. Identity and fraud stay the institution's decision. Where an identity check is used it is a separate step: opened as its own kind, reviewed by a person away from this service, and recorded with a date. What its approval says is that the review happened. It does not say the applicant is genuine, and nothing in the cryptography above says it either. - **A note is a record of a moment; a grant is a permission** A permission can be withdrawn, so every use of one reads the row again. A record of a moment cannot be unsaid. It is superseded instead, so the note carries its own expiry and needs no lookup at all. - **Only approvals are signed** A pending check says nothing yet, and signing a negative finding about a person to be carried around by outside parties is a different product from this one. - **Minted per read, never stored** `issued_at` should say when we asserted something. A token cached in a table would eventually be asserting something we had stopped believing. a credential, checked offline ``` # minted when a reviewer approves the check cred.v2.eyJraW5kIjoi….MEUCIQD… # five fields, signed. no reference, no notes, no row id. { "kind": "employment", "status": "verified", "provider": "manual", "issued_at": 1766000000, "expires_at": 1789000000 } # ed25519 over the token's own prefix, so a grant and a # credential can never be read as each other POST /v1/credentials/verify 200 { "valid": true, … } # or check it yourself: a public key and fifteen lines. # no database, no network, no call back to us. ``` The key is published at `GET /v1/credentials/pubkey`, because a statement only we can check is a statement we could quietly withdraw. What the note attests is that a review happened on a date. It is never a guarantee of the truth of a record, and nothing on this site will describe it as one. ## Enforced below the code that could get it wrong The encryption is the floor and not the whole building. Everything around the ciphertext still has to behave, and each of these is a property the handlers cannot accidentally opt out of. That is the distinction worth caring about: the failure mode of a mistake should be a failing test, not a quiet disclosure. ### The rule is enforced by the database Every request opens a transaction that names whose record it is acting for, and more than fifty tables carry a forced policy admitting only that person's rows, so even the owning role cannot slip past it. A statement that forgets to say who it is acting for reads an empty database rather than everybody's. ### The employer's side is fenced the same way Organizations, rosters, postings, notifications, matches, pipeline notes and access requests each carry their own forced policy. Membership confers a rank over a roster and never access to anybody's record. The stage is the only field of an application an employer can write, and the database enforces that rather than the handler. ### Credentials that survive a dump What the login route receives is not your password but a value your browser derived from it, and what is stored is an argon2id hash of that. A session is 32 random bytes of which only a SHA 256 digest is kept, so a copy of the sessions table hands nobody a working credential. Sessions are rows rather than tokens that describe themselves, which is what makes signing out take effect at once. ### Secrets encrypted in an envelope A stored API key gets a fresh 32 byte data key, and only that data key is wrapped under a master key held in the environment and never in the database. A stolen dump decrypts to nothing. That master key is for platform credentials such as a provider key you chose to store. It opens no record, and no route anywhere returns a stored key: the one that reports on it gives the provider and the last four characters. ### An audit trail that holds no content Account creation, every login and failure, session lifecycle, grants minted and revoked, every shared read, every write to the encrypted store and every agent draft are appended to a log that is never rewritten. What it records is that a thing happened: a provider, a company, a grant id. Never the key, the draft or the record behind it. An audit log that copies the data it audits is a second place to breach. ### Administrators govern accounts, not records Whoever runs a deployment can search the account directory, suspend and reactivate, and read the trail and the counters. No route hands them a profile, a document, an answer or a draft, and for the sealed half there is nothing to hand them. An operator who needs to read a record asks for a grant like anybody else, and that read appears in the owner's own trail. ### A small machine facing surface The public gateway publishes four REST routes and an MCP face over two of them. It holds no database handle, no key material and no session state, and it decides nothing about authorisation. It cannot be talked into proxying a route it does not name, so an outside party holding a grant reaches the delegated read and nothing beside it. ### Regulated answers are fenced off Work eligibility, EEO self identification, the consent trail and the sensitive identifiers sit outside the record, each behind its own scope and absent entirely from a read that did not delegate it. They are among the parts we can still read, which is why the fence around them matters. There is no column anywhere for a full Social Security number, and the EEO answers are read by nothing that scores, ranks or searches. ### Ranking that can be argued with A match is a weighted average of named factors, each of which is a comparison anybody could make by hand from the same two rows, and each of which records what it concluded and how much it counted for. It is a smaller engine than it was, deliberately: a server that cannot read a headline cannot rank on one, so what is left scores on the parts this service can still see. A reason may carry ratios, counts, verdicts and the posting's own words, and never a value out of the seeker's record. ### Vendor checks fail loudly Outside verification vendors sit behind one interface and answer `501` until they are connected. A request that asked for an identity vendor must never come back looking like it got one. Inbound vendor callbacks are signed with an HMAC over the raw body and a timestamp, compared in constant time, and nothing unverified reaches the database. ### Export it, or end it One route hands you everything this service holds about you in a single document, naming every table it drew from and counting every row. It cannot contain what we cannot read, so your browser opens the sealed sections and adds them to the same file, and tells you which half is missing if it is holding no keys. Another route destroys the account and every row under it, confirmed with your password. Custody you cannot walk away from is not custody, so both were built at the same time as the thing they undo. ### Prompt injection has a bounded target The drafting helper you run in your own account is offered the record as fact and the job posting as quoted material, so instructions hidden in a job description are text to be read rather than a turn to obey. On the gateway's MCP face, no tool takes an argument at all. The most a hostile prompt achieves is a second read of the same record the agent was already entitled to. On the face for your own paired agent, no argument names a person, and every argument can only narrow what you allowed. ## Questions worth asking before you hand over a career ### Can Verigrant read my record? Not the substance of it. The narrative core, your work history, your education and your skills are encrypted in your own browser under a key made from your password, and what reaches us is a block of bytes, a wrapped key we cannot unwrap, and a label saying which kind of record it is. Your password never reaches this service at all: what the login route receives is a separate value derived from it, so there is no password stored here and no support tool, administrator button or route in the software that opens the ciphertext. What we can read is listed in full further up this page, and it is not nothing. ### What is the recovery key, and what happens if I lose it? It is a second key to the same record, made in your browser at signup out of random bytes, shown to you once, and never sent to us. It is the only other thing in the world that opens what your password opens. Lose both and the record is gone, permanently, for you and for us. We can give you your account back and we cannot give you your data back, because there is no override here: an override would be a key, and a key we held would make the rest of this page false. ### What can a Verigrant operator see? Your email address and display name, that a record exists and roughly how large each part of it is, when each part was last written, every grant you issued and every time it was used, the organisations and applications and the graph between them, and the addresses your requests arrived from. The regulated sections you chose to fill in, such as work eligibility and a date of birth, are readable too. So are the questions in your answer bank, the kind and rough size of each document you upload, and any document or answer that reached us before we began sealing them. If your agents act at websites, we can also read the list of sites you allowed them, and each order an agent drops names the business, the offer and the total. The privacy policy lists every field. That is a real social graph, it is not the sealed record, and it is the honest cost of a service that has to route a login, rank a vacancy and revoke a delegation. ### What exactly is a grant? A grant is a delegation you issue: a set of scopes and an expiry, recorded as a row, handed out as a token signed with ed25519. The holder presents the token; we check the signature, then read the row, then check that the scope covers what they are asking for. The row is the authority, and the signature only proves the token is one of ours. When you approve a disclosure, your own browser seals a copy of the record keys to the institution's registered public key, so what the holder decrypts, they decrypt in their environment and not in ours. ### What happens when I revoke? The next request made with that token fails with `403 revoked`. There is no cache to expire and no propagation delay, because nothing trusts the token on its own. The trade is deliberate: every check costs a read, and in exchange revocation is real. What revocation cannot do is unsay a read that already happened, and no page should pretend otherwise: an institution that has already pulled and decrypted a version of a record still holds it. ### Does an employer need a Verigrant account to read a profile? Not a personal account, but the institution behind the reader does need a registration. The verifier page takes the grant token together with the institution's own credential, which is either an API key belonging to the organization or a signed in member session named with the organization's slug, and it reads through the public gateway holding no account of its own. Verigrant discloses a record only to a registered institution, so a grant token on its own opens nothing. An employer who wants to publish vacancies and run a hiring pipeline needs an account as well, because that is a place they write rather than a thing they were shown. ### How is a verification different from something I typed? A claim and a review of that claim have different authors, different lifetimes and different trust, so they are stored separately and shown separately. A check records its kind, its status and who did the reviewing, and an approved one also travels as a signed note a reader can keep and check offline. What the note says is that this kind of check was reviewed and approved on this date, never that the record is true. Where several checks exist for one kind, the strongest standing one is reported; a kind nobody ever checked is absent rather than reported as a status. ### Which checks can actually run today? Identity, employment, education and income are the kinds the layer models, and the reviewer who ships today is a person: you open a check, a member of Verigrant staff reviews it away from this service and records the outcome, and an approval is signed. Outside verification vendors are the next thing to be connected. Until they are, each one sits behind the same interface and answers `501`, because a request that asked for an identity vendor must never come back looking like it got one. ### Can an AI agent make things up about me? The drafting helper you run in your own account is given your profile and the posting, and nothing else is offered to it as fact. Its instructions forbid inventing employment, degrees or credentials that are not in the record, and a screening question the record cannot answer comes back as a gap for you rather than as a guess. What it produces is a draft for you to read, and it sends an application only when you tick that it may, for that one run. Beyond that helper, Verigrant ships no agent that applies on anybody's behalf, and it is not going to. An outside agent reading through MCP is a different matter: it can write whatever it likes in its own words, which is precisely why checks are kept apart from claims. A reader can tell what you wrote from what somebody else reviewed. ### Can an AI assistant read my record? Only what you give it. An outside assistant reads through a grant you issue. An agent you pair holds the key to the one section of your record you chose when you paired it, and nothing else of the sealed record. The gateway speaks the Model Context Protocol at one route, and the grant is the whole session: there is no separate session id whose lifetime would outlive your revocation. The four tools take no parameters at all, so whose record is read comes from the grant rather than from anything a model can be talked into typing. ### Who pays for the model? For the drafting helper in your own account, you do, with your own API key, stored under envelope encryption and spent only on requests you or a delegate you authorised made. A deployment may instead offer a platform key, metered against a daily allowance per account, and one you host yourself can drive a locally authenticated CLI that needs no stored key at all. Either way it is a convenience you run rather than a service acting for you. An outside assistant reading through a grant brings its own model and costs us nothing. ### Can a Verigrant administrator read my record? No. A platform administrator governs accounts and reads no record: they can search the account directory, suspend and reactivate, and read the custody trail and the service's counters. There is no route that hands them a profile, a document, an answer or the text of a draft. For the sealed half there is nothing to hand them, because the key that opens it is not here. An operator who genuinely needs to read a record asks for a grant like everybody else, and that read lands in your own trail. ### Where does my data actually live? In one Postgres database behind an internal service that is not exposed to the internet, as ciphertext for the sealed half and as ordinary rows for the parts listed further up this page. The machine facing front door for outside parties holding grants is a separate gateway process which holds no database handle and no key material of its own, and which publishes four read routes plus the MCP face over two of them. ### Can I take my record with me, or destroy it? Both. One route hands you everything this service holds about you in a single document, naming every table it drew from and counting every row, and because a document we assembled cannot contain what we cannot read, your browser opens the sealed sections and adds them to the same file before you save it. Another route destroys the account and every row under it, sessions and grants included, confirmed with your password. Custody you cannot walk away from is not custody. ## Build on it, or move onto it The guarantees above are the same ones whether you are the employer reading, the agent integrating, or the person whose record it is. So are the limits. --- Page: https://verigrant.com/privacy.html Title: Privacy Policy at Verigrant: what is stored, what cannot be read, and who sees it # Privacy Policy Most privacy policies describe categories. This one lists fields, because a service whose whole claim is that it cannot read your record has to be specific enough about the exceptions to be caught if it is wrong. ## 1. Who holds this, and how to reach them VX Encryption, Inc., a South Dakota corporation (SD Business ID DB301325), 550 N 5th Street, Suite 112, Rapid City, SD 57701, doing business as Verigrant, operates the Verigrant service and is responsible for what is described here. The way to reach us about your data, to ask a question, or to complain, is support@verigrant.com. This policy covers verigrant.com, the application at `/app/`, and the interfaces institutions and agents call. It sits alongside the Terms of Service, which is where the obligations an institution takes on about your record are written down. It also covers people and organisations who hold no account here and still leave something with us: an agent operator that registers its agents, a business that lists a site in the agent directory or opts in to the hosted dashboard, a site that files an abuse report, and the person who connects an AI assistant to their own account through Connect. Section 2, under The agent network, says what each of those leaves with us and for how long, and section 5 says who can see it. ## 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. ## 3. What we store and cannot read The substance of the record is encrypted in your browser before it is sent, under a key derived from your password on your own device. What reaches us is ciphertext and a wrapped key we have no way to unwrap. That covers: - **The narrative core** Your headline, your summary, and the rest of the free text that says who you are. - **Your work history** Every position: the employer, the title, the dates, and what you wrote about it. - **Your education** Every institution, qualification and date. - **Your skills** What you claim to be able to do, and to what level. - **Your documents** The file, its name, its type and your label for it, for every document uploaded since we began sealing them. Older ones are in section 2 until you encrypt them. - **Your screening answers** What you answered, for every answer saved since we began sealing them. The questions are in section 2, and so are answers saved earlier until you save them again. - **Your receipts** The record of every pass, pay grant, order, plan and booking update your agents made, each sealed to your own key before it is stored. Section 2 says what readable trace each of those events leaves beside its receipt. - **What travels to a business through your agent** Traveller details sealed for one order, answers sealed for one form, and the inside of an order. Each is sealed in your browser to that business's own registered key, and the service that stores it links no code that could open it. - **What a business sends you about a booking** Booking updates and messages to a masked contact address are sealed to your key for that business before they leave the business. We keep the envelope and not the message. We cannot open any of it, and neither can somebody who steals a copy of the database. The consequence you should know before you rely on it is the one the sign up screen states: if you lose both your password and your recovery key, we can give you an account back and we cannot give you the record back. There is no operator override, because an override is a key, and a key we held would make this section false. An institution reads this material only because your own browser seals a copy of the keys to that institution's registered public key when you issue a grant. The decryption happens in their environment, not in ours. ## 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.`** 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..`** 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. ## 5. Who can see what There are three answers, and they are different from each other on purpose. - **You, the account holder** Everything. Your own client holds the key, so it can read the encrypted half as well as the plaintext half, and one route hands you the whole of what we hold in a single document. Nothing about your record is withheld from you. - **An institution holding a live grant** Exactly the scopes that grant carries, and nothing beside them. A section you did not delegate comes back empty rather than missing, so its absence tells them nothing, and a regulated section you did not delegate is not in the document at all. Every such read is written into your trail with the grant id and the scope that unlocked it, so you can see who read what and when. The moment you revoke, their next request is refused. An institution has to be registered with us to read at all, so a grant token on its own opens nothing. - **An agent you paired** The sections of your record its preset names, within the sites, actions, ceilings and approval levels you set, and nothing outside them. Never your traveller details, which your browser seals to the business and the agent carries without reading. Everything it does is in your trail and in your sealed receipts, and you can end the pairing at any moment. - **A business your agent ordered from, or whose form you filled** What your browser sealed to its registered key, opened in its own environment: the traveller details for that order, or the answers for that form. The signed outcome it returns to us about an order. Nothing else of your record, unless you issued it a grant like any other institution. - **An agent operator** Its own registration, its agents and their keys, the credentials issued to them, the links to its institution or its officer, and the reports filed against its agents with the reporter's contact and the evidence removed. Nothing about any person's record, and nothing posted to any business's dashboard. - **A business reading its dashboard** The counts its own door posted, by day, operator, level and purpose, with each operator's proven domain and standing where the directory lists it. Nobody else's counts, and never an agent or a person. - **The abuse desk** A platform administrator working the desk reads every report in full, the reporter's contact and the signed evidence included, and can warn, rate limit, revoke an agent or revoke an operator on evidence that verifies. A service token used by our own operations tooling can read the queue and the flags and can change nothing. - **Anybody at all** The public parts of the network, by design: the directory of proven listings, the operator directory of proven domains with their standing, each agent's hosted key directory, the key sets, the status lists, the relay nodes' published file, and the transparency log. None of it names a person, and none of it names a site that an agent visited. - **A platform administrator** The shape of an account and the trail, and never a field of a record. An administrator can search the account directory, suspend and reactivate an account, work the verification review queue, and read the audit log and the service's own counters. There is no route that hands them a profile, a document, an answer or the text of a draft, and for the encrypted half no such route could work. An operator who genuinely needs to read a record has to ask you for a grant like anybody else, and that read lands in your trail. ## 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. ## 7. What leaves, and where it goes No outside service receives your record today. Four providers touch what we hold, and this is the whole list. Hosting: IONOS Inc. (United States) hosts the application, the database and uploaded documents. Email: messages we send you go through a mail relay at mail.cmdpath.com, hosted by IONOS Inc. (United States), and no email delivery service outside that relay processes your address. Mail sent to Verigrant's own addresses (support@verigrant.com, legal@verigrant.com, info@verigrant.com) is stored in mailboxes on that relay. AI drafts: if you store a model provider key and run the assistant or ask for a draft, the readable part of your record and the postings are sent to Anthropic, PBC (api.anthropic.com), and never the encrypted part. Payments: an institution that pays by card does so through Stripe, Inc. (United States). The card is typed into a page Stripe serves and never reaches us. What we send Stripe is the institution's organization name, the billing email address the institution gave us if it gave one, our own identifier and short name for the organization, and for each charge its amount, its currency, our invoice number and a line saying how many applications it covers. We keep the card's brand and its last four digits so the billing screen can say which card will be charged. Nothing about a person applying is sent to Stripe. There is no analytics provider, no advertising network, no marketing platform, no outside search index over your data, and no processor holding a copy for its own purposes; our hosting provider holds the servers the data sits on, as section 8 says, and nothing else does. Institutions receive what you delegated to them, and that is a delegation you made rather than a transfer we arranged. For a person applying there is exactly one outbound flow, and it happens only when you ask for it. If you store a model provider key, which is your own key on your own account with that provider, the readable part of your record and the job posting are sent to that provider so it can write a draft when you run the assistant or ask for a draft. A run drafts applications for up to three postings it picks for you and may retry if the provider fails. The encrypted half is not sent, because the server assembling the prompt cannot read it either. If you have stored no key, no draft is made and nothing leaves. Your key is held under envelope encryption and no route anywhere returns it. What that provider then does with what it received is governed by your agreement with them rather than by this page, which is the honest position when the account and the key are yours. An outside AI assistant reading through a grant is the same shape of thing: it brings its own model, you gave it standing, and you can take that standing away. Two flows of the agent network cross our boundary, and neither carries your record. When an agent sends a request through a relay node, the node makes that request to the website the agent named, from our published addresses, carrying the agent's credential and the node's own signature; what the site answers goes back to the agent, and we keep the counts and nothing of the content. When a connected assistant calls a tool, what the tool answers goes to that assistant and to whoever runs it, under your agreement with them rather than this page, exactly as with a paired agent: envelopes under the inbox scope, and under the acting scope what a paired agent would see. We do not sell your record, rent it, or share it with anybody for their own purposes. We would disclose what we hold if we were legally compelled to, and what we hold is the list in section 2, because the list in section 3 is not ours to hand over. ## 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. ## 9. When this changes A new version of this page carries its own effective date. Because the lists above are specific, a change to the service that moves a field from one of them to the other is a change to this page, and we treat it as one. We will tell you inside the application before a change that matters takes effect. If the business is ever sold or merged, your record goes with the service and this policy goes with it, and a buyer wanting to do something this page does not allow has to ask you first. The encrypted half arrives at a buyer exactly as unreadable as it is here. --- Page: https://verigrant.com/terms.html Title: Terms of Service at Verigrant: custody, consent, and who agrees to what # Terms of Service This is the agreement between you and Verigrant. It is written to be read, so it says what the service does and what it will not do, in the order somebody would actually want to know it. ## 1. Who this agreement is between VX Encryption, Inc., a South Dakota corporation (SD Business ID DB301325), 550 N 5th Street, Suite 112, Rapid City, SD 57701, doing business as Verigrant, operates the Verigrant service and is the party you are agreeing with. VX Encryption, Inc. is a subsidiary of North South Industries Inc. In everything below, "Verigrant", "we" and "us" mean VX Encryption, Inc., and "you" means whoever holds the account: a person applying for something or whose own AI agent acts for them, an institution acting through the people on its roster, or an administrator of a deployment. An agent operator that registers its agents with us holds a registration rather than an account: it agrees to the separate Operator Terms when it registers, and "you" below means an operator only where a sentence says so. The way to reach us about anything on this page is support@verigrant.com. That address is the one for a legal notice, a complaint, a question about your record, and a request we have not answered. You accept these terms by creating an account. That acceptance is recorded: the moment your account exists, your client writes a consent record naming this document and the version string above, and you can read it back in your own consent trail and in your export. There is no separate place where the agreement is kept and no version of it you cannot see. ## 2. What the service is, and what it is not Verigrant is a custody and consent layer. It holds a person's application record, and it lends named parts of that record to an institution when, and only when, the person issues a grant that says so. The grant is a row this service reads again on every use, which is what makes a revocation immediate rather than eventual. That is the whole product: custody on one side, delegation on the other. Three things it is not, said plainly because each is a thing people reasonably assume. - **Verigrant is not a verifier of your record** Nothing this service holds is asserted by us to be true. What a person writes about themselves is their claim, and it stays labelled as their claim wherever it travels. A check is a separate thing and section 8 says exactly what one means. - **Verigrant is not a consumer reporting agency** We do not assemble or evaluate information about a person for the purpose of furnishing a consumer report to anybody, and we do not sell, rent or broker access to a record. What moves is what its owner delegated, to the party they named, for as long as they left the delegation standing. - **Verigrant is not a party to your application** Whether an institution reads, advances, refuses or ignores an application is that institution's decision, made on its own systems under the law that governs it. We carry the consent and the data. We do not make the decision and we do not review it. ## 3. Accounts, and who may hold one There is one kind of account. A person applying for something and a member of an institution's staff hold the same thing, and what differs is what they went on to do with it: an institution is an organisation record with a roster, whichever kind it is, an employer, a school, an insurer, a lender, a landlord, a clinic or a merchant that takes orders, and being on that roster is what lets somebody act for it. An administrator of a deployment is an ordinary account that the deployment's own configuration names, which is why there is no administrator sign up and could not be one. An agent operator's registration is not an account either: it is made with an email address and an acceptance of the Operator Terms, it signs in by a mailed code, and nothing on it holds a record. You must be at least 16 years old, and old enough where you live to enter into an agreement like this one. To hold an account you must also not be somebody we have already suspended for breaking these terms. You give a real email address, because that address is how a sign in is routed and how we reach you. Somebody who creates an account for an institution is saying that they may bind that institution to section 5, and we rely on that. Your credentials are yours to look after, and the way this service is built makes that more than a formality. Your password never leaves your browser: it is stretched there, and what reaches us is a derived credential and a wrapped key we cannot open. Your recovery key is shown once, at sign up, and we keep no copy. If you lose both, we can give you an account back and we cannot give you your record back. That is a real consequence of the design and not a disclaimer about it. Tell us at once if you think somebody else has your password, your recovery key or an assistant code you issued. You can end every session and revoke every delegation yourself, from inside the application, without waiting for us. ## 4. Your record is yours, and a grant is how it moves You own what you put into your record. Verigrant claims no ownership of it and takes no licence over it beyond what running the service you asked for requires: storing it, serving it back to you, and handing the parts you delegated to the party you delegated them to. We do not sell your record. We do not use it to train a model. We do not show it to an advertiser, and there is no advertiser on this site to show it to. Most of the record is encrypted in your browser under a key derived from your password, so for the narrative core, your work history, your education and your skills the sentence above is a property rather than a promise: we could not sell what we cannot open. The Privacy Policy lists exactly what is plaintext and exactly what is not, without rounding either way. A grant is how anything leaves. It is a set of scopes and an expiry, recorded as a row and handed out once as a signed token. The holder presents the token, we check the signature, then read the row, then check that the scope covers what is being asked for. Revoke it and the next request made with it is refused, because nothing trusts the token on its own. Every use is counted, timestamped and written into your own audit trail, so a delegation's whole history is something you can read back. You may withdraw a grant at any time, for any reason or none. What a withdrawal cannot do is reach into an institution's systems and delete what they already took in under a standing delegation, and section 5 is where that is dealt with rather than wished away. ## 5. What an institution agrees to This section binds every institution with an account, every institution registered as a reading party, and every person acting for one. It is short because each line of it is enforced somewhere in the service as well as promised here. - **Read only what a grant delegates** A scope you were not given is not a scope you may go looking for. Do not attempt to read a record, a document, an answer or a regulated section that the presented delegation does not carry, and do not combine credentials to assemble a read that no single grant authorised. Every read you make is logged into the record owner's own trail, so this is a term they can audit rather than take on faith. - **Ingest only when a candidate advances** The preview stage exists so a round can be sorted without anybody's full application being taken in. Pull the full record into your own systems only for the applicants you are advancing, and only for the purpose the applicant granted it for. An institution that ingests everything it previewed has defeated the design and taken on the liability the design was avoiding. - **Do not resell, and do not repurpose** What you were shown is for the application in front of you. You may not sell it, rent it, syndicate it, hand it to a data broker, use it to build a profile for anything else, or feed it to a model as training data. Sharing it with a processor acting for you on the same application is not a resale, and remains your responsibility. - **Honour a withdrawal, and keep only what you need** When a grant is revoked or expires you stop reading. For what you already ingested, you keep it no longer than the purpose it was granted for and the law you are subject to require, and you delete it after that. Verigrant cannot enforce this inside your systems, which is precisely why it is a term you agree to. - **You are the regulated party for what you hold** Once a record is in your systems you are the one governed by the law about how an applicant's information is used, how a hiring or admissions or lending decision is made, and what an applicant must be told. That includes any use of a check as an input to a decision. Verigrant is not your compliance function and does not act as one. - **Look after your credentials** Your API key, your roster and the private half of any key you registered are yours to protect. Acts made with them are attributed to you until you tell us they were not. - **If you take orders or send booking updates, use them for that order only** An order a person's agent drops with you arrives sealed to your key, and you open it in your own environment. The signed outcome you return to us is your account of that order, and it is what the person and their agent rely on. Booking updates and masked contact exist for that order and that booking: use them to tell the person what changed and to answer them, and for nothing else. Send marketing through a masked address only if the person ticked the box that allows it, and stop when they switch the address off, which they can do at any moment. What you took in from an order or a filled form is yours to hold under the same four rules above as an application. - **If you list a site or opt in to the dashboard, the site is yours and the counts are true** By listing a site in the agent directory you say it is your own and that the front you point agents at is on it, and you prove it by publishing the token we give you at that site. A listing we cannot prove is not shown, and one whose proof disappears is delisted. By opting in to the hosted dashboard you say the counts your door posts are the counts it took, by day, operator, level and purpose, and nothing else: no person, no address, no request. We refuse a row that carries anything else. Opting out stops new rows, and what you already posted stays with your organisation until you delete it. - **If you report an agent, the evidence is your own log** An abuse report says an agent did something at your site. The signed log lines you attach are each a request as your site received it, and you promise they are from your own log, unedited, and for requests made to your site. We check every line against the agent's keys and our own key set and act only on lines that verify, so an edited or borrowed line does nothing except mark the report, and a report made to lower a competitor's standing breaks this section and section 6. The contact address you give is for us to reach you about the report and is not shown to the operator, which sees that a report exists, its category and its description. ## 6. Acceptable use These apply to everybody, whichever side of the service you are on. - **Do not apply in somebody else's name without their authority** An application made for a person is made because that person authorised it, through their own account or through an assistant code they issued. Nothing else counts as authority, and impersonating an applicant is the one misuse of this service that harms a person who never came here. - **Do not present a credential you were not issued** A grant token, a session, an API key, an assistant code, an agent ID credential, an operator's sign in token and a Connect token are each held by somebody in particular. Using one you found, bought or guessed is unauthorised access, whatever the service happens to answer. - **Do not probe, scrape or overload** Do not attempt to read records you hold no delegation for, to defeat a rate limit, to enumerate accounts, or to take the service down. Security research is welcome and the address for it is the one in section 1; what is not welcome is testing on other people's records. - **Do not upload what you have no right to upload** Malware, somebody else's documents, and anything unlawful to hold do not belong here. Your record should be about you. - **Do not misrepresent what a check says** An approval says one kind of check was reviewed and approved on a date. Presenting it as a warranty that a record is true, or forging one, is a misuse serious enough to end an account on its own. - **Do not use this service to discriminate unlawfully** The voluntary self identification answers exist to fill in the block on a form that asks for them, and nothing in this service scores, ranks or searches on them. Using them, or anything else here, as an input to a decision the law forbids them to inform is a breach of this agreement as well as of that law. ## 7. Agents, and the assistant code An AI agent does not hold an account here and cannot create one. It holds an assistant code, which is issued by a person from their own account, shown to them once, and stored by us only as a hash. An agent's standing therefore comes entirely from a person, and it lasts exactly as long as that person leaves it standing. There are two modes and the difference matters. In review mode an assistant code lets an agent do one thing: write a pending row saying which institution it would like to apply to and under which scopes. That row unlocks nothing by existing. The person reviews it, and the sealing that actually delegates a read happens in their own browser after they have looked at what was asked for and chosen how long it lasts. In auto mode an assistant code carries a mandate the person signed in advance, naming the scopes, the limits and the window, and lets the agent issue inside those limits without being asked again. Either mode may be revoked at any moment by the person who issued it, and revocation ends everything the code could do. Until it is revoked, the person who issued it is responsible for what is done under it, and whoever operates the agent is responsible for keeping it secret and for staying inside the mandate. An agent that files applications a person did not want is not a bug in the delegation model; it is the agent's operator breaking this section, and we will revoke the code. Since 3 October 2026 an agent you paired can do more than apply. Within the limits you set it can carry a pass from us to a website, follow a plan of steps you approved, drop an order with a business, fill a business's form from your record, and receive booking updates for you. You are responsible for what your agent does within those limits: the sites, purposes, actions, ceilings and approval levels you gave it, and the sections of your record you let it hold. You are answerable, to us and to a business, for what your agent does inside those limits. An agent that tries to go outside them is refused wherever we can see the request, and where we cannot, its operator is breaking this section, exactly as the paragraph above says. Payments are in test mode. When your agent buys something today, no card is charged and no money moves through Verigrant. A purchase approval you make is a record of what you allowed and a ceiling on what your agent may ask a business for; it is not a payment. A purchase approval is not a payment instruction and we hold no payment credential for it. We will tell you inside the application before that changes. Fill with Verigrant sends a business the answers you chose, sealed in your browser to that business's key, and the business takes them in under section 5. We hold the sealed answers until they are delivered and a short window after, and we cannot read them. The same is true of the traveller details inside an order. An agent can also come here on its own account. Its operator registers it with us, declares what it is for, and the agent carries a credential of ours to websites that says who stands behind it and at what level. The operator, not the agent and not any person, is bound by the separate Operator Terms, which make its declarations a promise and say what we do when they are broken. A credential is a statement of what evidence we hold about the operator, and a standing is arithmetic over the reports a site proved to us; neither is our promise that the agent will behave, and section 12 says so. Connecting an assistant is pairing an agent by another door. When you connect an AI assistant through Connect, your own browser signs the mandate exactly as it does when you pair, and everything in this section applies to the assistant as it applies to a paired agent. You are answerable, to us and to a business, for what a connected assistant does inside the mandate you signed. The assistant holds a token and never a key of yours, so anything that needs you comes back to you to approve. The name an assistant gives itself is its own and we do not check it; what we vouch for on the consent page is the host it will send you back to. You can disconnect it at any moment, and that ends everything the token could do. A registered agent may send its requests through our relay nodes, and it does so at its own choice. A node checks the agent's credential and key, its standing, the rates it declared and the rates and terms the site publishes, and then makes the request to the site from our own addresses and hands back what the site answered. We are not a party to that answer: whether a site serves an agent, refuses it, prices it or blocks it is the site's decision under the site's own terms, and what the agent does with the answer is between the agent's operator and the site. We will cut an agent or an operator off at the nodes, at once, when the abuse desk upholds a report or when we must, and a site may refuse everything that does not come through them. Agents are never charged for using this service. See section 9. ## 8. What a check is, and what it is not A verification is a review, by a member of Verigrant staff working a queue, of a claim you asked us to look at. Identity, employment, education and income are the kinds we model. Outside verification vendors are not connected today, and until they are, a request for one is refused rather than answered with something that looks like a vendor result. An approved check travels as a note signed with our key, and what the signature says is bounded on purpose: this kind of check was reviewed and approved on this date. It does not say your record is true, it does not say the underlying facts were confirmed beyond what the reviewer saw, and nobody may present it as though it did. A check note is delivered to you; whether and to whom you pass it on is your choice. A refusal is written where you can read it, in the reviewer's own words, because a person refused is entitled to know why. Manual review is a service we perform with care and it is not a guarantee. We do not warrant the correctness of any review, and an institution that relies on one is making its own decision about how much weight to give a note that says what it says. Section 12 is where that consequence is stated in the language of liability. ## 9. Who pays, and for what A person applying is never charged. Holding a record, editing it, exporting it, issuing grants, revoking them, opening a check and erasing the whole account are free, and there is no tier above them that costs money. An agent is never charged either. Neither of those is an introductory position we are reserving the right to reverse: charging the person whose record it is would make the custody claim on the rest of this site false. Institutions may be charged, on two bases. The first is per application taken into their own systems, on the terms of the plan recorded for the institution: each application is charged once, when it is first advanced to interview or beyond or its full record is first read through the API, whichever comes first, and never for previewing, for publishing a vacancy or for reading the open postings feed. The plans and their list prices are published on the price list. The second is by separate written contract, for volume, for integration work, or for terms that neither side wants to leave to a page like this one. Where a contract and this page disagree about money, the contract wins. An institution billed through the product pays by card. The card is entered on a page Stripe hosts and never reaches us; we keep a Stripe customer reference, the card's brand and its last four digits, and the saved card is charged once a month for that month's invoice. An institution on a written contract is invoiced under that contract instead. We change a plan or its prices only with the institution's agreement, or on 30 days' notice effective from the first billing period that starts after the notice ends, and never for applications already taken in. Refunds and cancellation are in section 10. Orders from agents, Fill with Verigrant, booking updates and masked contact have no price today and are not billed, to anybody. If a price is set for one of them, it goes on the price list first, it applies to institutions only, and the notice above for a change of price applies to it. A person is never charged for any of them, and neither is an agent. The agent network is the same. Registering an operator and its agents, a credential, a listing in the directory, the hosted dashboard, an abuse report, Connect and the relay nodes have no price today and are not billed, to anybody. If a price is set for one of them, it goes on the price list first, or into the Operator Terms where it is an operator who would pay, and the notice above for a change of price applies to it. A person is never charged for connecting an assistant. ## 10. Refunds and cancellation for institutions This section is about what an institution pays, because nobody else pays anything. The plans and their prices are on the price list. An institution on a written contract follows that contract where the two differ, as section 9 says. - **No refund for an application already taken in** Once an application has been taken in, by advancing the candidate to interview or beyond or by reading their full record through the API, the charge for it is not refunded. - **You may cancel at any time** An institution may cancel at any time. The cancellation takes effect at the end of the current billing period. To cancel, an owner of the institution's account writes to support@verigrant.com. We confirm the cancellation in writing, charge the final invoice for the current period, and charge the card nothing after it. - **The platform fee is not prorated** The monthly fee of the platform plan is not prorated. - **A charge made in error is refunded** If we charge you in error, we refund that charge. - **Billing disputes come to us first** If you dispute a charge, write to support@verigrant.com first, and we will try to settle it with you directly. ## 11. Ending it, and erasure You may end your account whenever you like, from inside the application, confirmed with your own credential. Doing so destroys the account and every row held under it, including your sessions, your grants, your documents on disk, your consent trail and your audit trail, and you are handed a receipt saying how many rows went from each table. It is irreversible and there is no soft delete behind it. Take your export first if you want one, because afterwards there is nothing left to export. One thing survives, and it carries no name and no address: a single row recording that an erasure happened, when, and how many rows it destroyed. A service that could not account for its own deletions would be asking you to take them on trust. An organisation you were the only owner of is left standing with no owner rather than destroyed, because it belongs to its whole roster and erasing it would erase other people's work. Transfer ownership before you go if that matters to you. We may suspend or end an account that breaks these terms, and we will say which term and why. Where the breach is not serious and can be put right, we will ask first. An institution's obligations in section 5 about data it has already ingested outlive its account, for the same reason they existed in the first place. We may also stop offering the service. If we do, we will give notice and leave the export route working through it, because a record you cannot take with you is not one you own. ## 12. What we do not promise The service is provided as it is. We do not promise that it will always be available, that it will never have a fault, or that it will suit a purpose you have in mind and have not told us about. We will say so when something is broken rather than degrade into an answer that looks fine. We make no promise about the truth, accuracy or completeness of anything a person wrote about themselves, and none about what an institution does with what it was shown or what an agent does with a delegation it was given. We do not promise that a check reached the right conclusion. We do not promise an outcome: no job, no place, no tenancy and no loan follows from using this service. We make no promise about an agent registered with us. Its level says what evidence we hold about its operator on the day a site checks: a confirmed address, a proven domain, an institution that passed our checks, a named officer. Its standing is arithmetic over the reports sites proved to us. A listing in the directory says a business proved it controls a site, and nothing about the business. None of those is a promise that an agent will keep to its declarations or that a site will be treated well, and a site that relies on one relies on evidence rather than on us. We do not promise that an encrypted record can be recovered when both the password and the recovery key are gone. It cannot, and that is the point of the encryption rather than a shortcoming of it. Where the law where you live gives you a right that this section would take away, the law wins and this section does not apply to you in that respect. ## 13. What we will pay if we get it wrong If we cause you a loss directly, we will deal with it. What we will not pay for is indirect loss: profits you did not make, an opportunity you did not get, a role you were not offered, harm to a reputation, or the cost of something you decided to do because of a conclusion you drew from this service. For an institution, our total liability for everything arising out of this agreement is limited to the fees that institution paid us in the twelve months before the claim arose. For a person applying, who pays us nothing, our liability is limited to putting the service right and to direct loss we actually caused. None of that limits the things a limit cannot cover: our own fraud or fraudulent misrepresentation, death or personal injury caused by our negligence, and anything else the law where you live does not allow to be limited. If you break section 5 or section 6 and somebody else is harmed by it, that is between you and them, and you will cover us for a claim that reaches us because of what you did. ## 14. When these terms change A new version of this page carries its own effective date and version string. Your consent record names the version you agreed to when you signed up, and any later version we ask you to agree to. We tell you inside the application before a change that matters takes effect, and ask for your agreement again where the change requires it. If you do not want the new terms, the answer is in section 11, and it works. ## 15. Governing law and disputes Verigrant is operated by VX Encryption, Inc., based in Rapid City, South Dakota. These terms are governed by the laws of the State of South Dakota, without regard to its conflict of laws rules. Before either side files anything, we will try in good faith for thirty days to settle any dispute. If that cannot be settled, the dispute goes to the state or federal courts located in South Dakota, and both sides agree to that venue. Nothing here takes away a protection the law where you live gives you that cannot be waived, and nothing here requires you to arbitrate, and nothing here waives your right to bring or join a class action. If you have a dispute with us, write to support@verigrant.com first and we will try to deal with it directly, which is faster than either of the alternatives for both of us. ## 16. The rest of it These terms and the Privacy Policy are the whole agreement between us about the service, except where a signed contract with an institution says otherwise about the things it covers. If a court decides one part of this page cannot stand, the rest of it still does. Your account is yours and you may not transfer it to somebody else. We may transfer this agreement if the business is sold, and if that happens the Privacy Policy tells you what it would mean for your record. Not enforcing a term on one occasion does not mean we have given it up. Notices to you go to the address on your account and to the notifications inside the application; notices to us go to support@verigrant.com. --- Page: https://verigrant.com/operator-terms.html Title: Agent operator terms at Verigrant: what registering an agent promises # Agent operator terms This is the agreement between an agent operator and Verigrant. You accept it when you register, and every agent you declare after that carries it. It is written to be read, so it says what the registry does, what you are promising, and what happens when a promise is broken. ## 1. Who this agreement is between VX Encryption, Inc., a South Dakota corporation (SD Business ID DB301325), 550 N 5th Street, Suite 112, Rapid City, SD 57701, doing business as Verigrant, runs the agent ID registry and is the party you are agreeing with. VX Encryption, Inc. is a subsidiary of North South Industries Inc. In everything below, "Verigrant", "we" and "us" mean VX Encryption, Inc., and "you" means the operator: the company or the developer that registered, and whoever acts for it. The way to reach us about anything on this page is support@verigrant.com. That address is the one for a legal notice, a complaint, a question about what we hold about you, and a request we have not answered. You accept these terms by registering. The registration names this document by the version string above, and the registry refuses to start a registration that names any other version or that does not say the terms are accepted. The version you accepted and the moment you accepted it are recorded with your operator record. An operator is not a Verigrant account. A person's account and the Terms of Service that go with it are a different thing, and a person who runs an agent through their own account is covered there, under its section 7, rather than here. This page is for an operator that registers agents of its own so that websites can tell who sent them. ## 2. What an operator is, and what registering means An operator is whoever runs an agent: a company, a team or a single developer. You register with an email address, a name and your acceptance of these terms. We mail that address an eight digit code that works once, for fifteen minutes, and survives five wrong tries. The confirmed code creates your operator record and your first operator token, which is valid for ninety days and which we keep only as a hash. Signing in again is the same exchange, and its answer never says whether an address belongs to an operator. Registering an agent means declaring, for that agent, the things a website will rely on when it decides whether to let the agent in. Each declaration is a promise you are making to us and to every site that reads it, and the point of these terms is to make that promise one you can be held to. - **Its purposes** From a closed list of four. Assist is acting for one person at a time. Search is building a search index. Research is reading for analysis without training. Training is collecting for model training. You declare every purpose the agent acts for, and you do not act for one you did not declare. - **Its networks** The address ranges the agent sends from, or the single value that says it sends through the Verigrant egress. A site that sees the agent arrive from somewhere else may treat that as a warning, and section 6 says what it may do with one. - **Its rate** The number of requests per site per day you expect it to make. The gate, the door and the egress enforce it, so an agent that declares a low rate and sends at a high one is refused rather than believed. - **Its abuse contact** An address a site can write to about this agent. It must reach somebody who can stop the agent. - **Its framework** The model or framework the agent runs on, and its version, in at most eighty characters. You may change an agent's declarations at any time. The change reaches the next credential the agent renews; a credential already issued keeps what it said until it expires, at most twenty four hours later. You may also retire an agent yourself, which ends its credentials the same way a revocation by us would. ## 3. The levels, and what each one proves Every credential carries a level from A to D. A level says what Verigrant has checked about the operator behind the agent, and nothing more. The levels are cumulative: D needs C, C needs B, B needs A. Each is decided per key when a credential is issued and is reflected live in the status list a site reads, so a level that stops being true stops being asserted. - **Level A: a confirmed email and a key on file** We have confirmed that somebody reads the address you registered with, and the agent's public key is registered with proof that you hold its private half. That is all it says. A level A operator has no proven name and is not listed in the operator directory. - **Level B: a proven domain** You have proven that you control a domain, by publishing a record we give you in its DNS or a file on its web server, and the agent's key is published in your own Web Bot Auth key directory on that domain. From here on you are known by that domain, and the credential carries it. We check the proof again every day: a proof that is gone ends level B at once, a check that cannot complete keeps it for three days, and a domain claimed but never proven lapses after fourteen days. - **Level C: an institution stands behind you** A registered Verigrant institution, one whose registration a Verigrant administrator approved after the company registry review and whose payment card has been checked, has linked itself to your operator record with a code you gave it. Both checks are read live wherever the level is decided, so an institution that loses its approval ends the level C of every operator it stands behind. - **Level D: a named officer answers for you** A named person, holding a Verigrant account that has passed a Verigrant identity check, has linked themselves to your operator record with their full name and title. Their account is theirs: if they erase it, the link goes with it and your level D ends at once. A level is evidence we observed, not a judgement about you. We do not vouch for an operator at any level, and a site that admits an agent because of its level is making its own decision about how much that evidence is worth. ## 4. Keys and credentials Each agent signs its requests with its own key. You make the key, you hold its private half, and we never do: what you register with us is the public half, with a signature proving that you hold the rest, or a key directory on your proven domain that we read it from. A key belongs to one agent for good, revoked keys included, so a key can never be registered under another agent and nobody can register a key they do not hold. An agent holds at most ten live keys. A credential is a short statement signed by Verigrant: this agent, this operator, this level, these declarations, bound to this key, valid for at most twenty four hours. The agent renews it by sending us a request signed with its key, at most thirty times an hour, and a site checks it offline against our published key set and a status list without telling us which agent visited. Every issuance is written to our transparency log, so a credential nobody can find a leaf for is a forgery anybody can name. - **Keep the private half private** Requests signed with your agent's key are your agent's requests until you tell us the key was taken. If you think a key has leaked, revoke it as compromised, from the console or the command line. Evidence signed with a key revoked that way never counts against you, whenever it was signed, because whoever held the key could have made it. - **Rotate rather than share** Add the new key, renew with it, then revoke the old one; the command line does all three in one step. One key serves one agent. A key used by several agents, or by software you do not run, is a key you cannot answer for. - **Revocation is immediate on our side and fast on the site's** When you revoke a key or retire an agent, we stop issuing for it at once, and the status list entry every credential bound to it carries flips to invalid. A site sees that at its next fetch of the list, which it may cache for up to five minutes, and the credential dies within its own lifetime in any case. ## 5. What Verigrant may do, and on what evidence A website that believes one of your agents broke its declarations files an abuse report with us: the agent, the site, a contact, a category, a description and up to twenty of the agent's own signed requests as evidence. The abuse desk is run by Verigrant's administrators, and it does not act on a site's word. Each line of evidence is checked again by us: that the request was addressed to the reporting site, that the credential in it is one we issued to that agent, and that the signature was made by one of that agent's registered keys. A line that verifies is something only the agent's key could have made. A line that does not verify is nothing, and the desk cannot act on a report unless every line verifies. On a report whose evidence verifies, the desk may do one of these, and each one is recorded. - **Warn** Record the decision against your standing and tell you. - **Rate limit** Hold the agent to a stated number of requests a minute, for a stated number of days, enforced at the egress. - **Revoke the agent** End its credentials through the registry and suspend it at the egress at once, rather than waiting for its last credential to expire. - **Revoke the operator** The same for you and every agent you run, which also ends your operator tokens. - **Dismiss** Record that the report did not stand. A dismissed report, like one never decided, moves nothing, so a site cannot lower your standing by reporting you. Each report takes each action once. We may also revoke an agent, a key or an operator outside the desk when we have evidence of our own of a breach of section 10, and we will say which term and why. Where the breach is not serious and can be put right, we will ask first. An operator may dispute a desk action by writing to support@verigrant.com. We review it, record the outcome against the report, and tell the operator. A revoked operator can still read its standing and the reports against it, and can change nothing. Its proven domain stays its own for ninety days, so that nobody else can claim it in the meantime, and its address is refused at registration for as long as the revocation stands, so a revoked operator does not come back under a new identifier. You read every report against your agents in the console, without the reporter's contact and without the evidence lines, which stay with the desk. ## 6. What a website may do A credential gets an agent recognised. It does not get it in. Every site decides for itself, under its own terms, and nothing in this agreement obliges any site to admit any agent. - **Refuse by level** A site may require level B, C or D, and refuse everything below it. - **Refuse by purpose** A site publishes which purposes it allows, denies or prices. An agent whose credential declares only a purpose the site denies is refused, and an agent acting for a purpose it did not declare is in breach of section 10 as well as refused. - **Act on a warning** A site sees a warning when a request comes from a network you did not declare, when the connection's fingerprint changes without a key rotation, when the volume exceeds the declared rate, or when the declared purpose is not one its terms allow. Its own policy decides whether a warning is a refusal. - **Keep its own evidence and report** A site logs the requests your agent signed and may file them with us as section 5 describes. That log is on the site's own storage, and we never see it unless the site sends it. ## 7. The egress option, and its limits An agent that declares the Verigrant egress as its network does not send to sites from its own addresses. It sends each request to the egress, signed with its key and naming what it wants fetched and for which purpose; the egress checks the credential, the site's published terms and the rates, makes the request itself from a fixed address under its own signature, and hands the answer back. Nobody's TLS is terminated in the middle. Where we offer the egress, these are its limits, and they are not negotiable per operator. - **The site's terms decide** The egress reads the site's own agent front file. A purpose the site allows goes through, a purpose it denies is refused, and a purpose it prices is refused too, because the egress cannot tell whether you have agreed the price. A site that has published nothing is treated as allowing assist only. You may still go to such a site directly, under your own addresses and your own responsibility. - **Your declared rate is enforced** Per agent, per site, per day, the egress sends no more than you declared, and no more than the site's own tier for your level, and no more than the egress's own ceiling for one site. A refused request is not counted. - **It keeps counts, never content** Per agent and per site, per day, for thirty days: requests, fetches, refusals, answer classes, timings and bytes. Never a request or response body, a path, a query, a header value or a credential. - **It can cut you off at once** A suspension written by the desk, or by us directly, stops an agent or an operator at the egress within a minute. A rate limit from the desk is applied there too. - **Level one only** The egress carries requests made with an agent ID in the clear. It does not forward a person's pass, so it cannot be used for sealed, level two requests. ## 8. The operator directory, and standing We publish a directory of verified operators, readable by anybody without a credential. An operator appears in it from level B, under its proven domain and never under a name it typed, so an operator's name cannot be squatted. A level A operator is not listed, because it has no proven name to list under. What is public about a listed operator is exactly this. - **Its identifier** The operator id beginning `op_`. - **Its proven domain** The domain it proved for level B. - **Its level** A, B, C or D, as the evidence holds now. - **Its standing** A label computed from the desk's upheld actions, never typed by anybody. It starts at one hundred. A warning costs ten, a rate limit twenty, a revoked agent thirty five, a revoked operator the whole hundred. Each counts in full for ninety days, by half until a year has passed, and then not at all. Good is ninety and above, fair is sixty and above, poor is below that; an operator less than thirty days old with nothing upheld is new; and revoked or suspended says so. Two other things are public because sites need them: the status lists, which say whether a credential is still valid and name no agent, and, for a level A agent, the key directory we host for it, which holds the agent's public keys. A site that opts into the visits dashboard sees your proven domain and standing beside the counts of your agents' visits to it, by level and purpose, and never an agent's id. ## 9. What we keep about you, and for how long This is the whole list, written from the registry's own tables. An operator is not a person's account, so the Privacy Policy for people does not cover it; this section does. - **Your operator record** Your name, your email address and its domain, when the address was confirmed, the version of these terms you accepted and when, your domain claim and the token that proves it, when the domain was proven and last checked, and, if we revoked you, when and why. Kept while the operator exists. A revoked operator's record is kept, because it is what refuses the address at registration and holds the domain for ninety days. - **Your tokens and codes** Operator tokens as hashes, valid for ninety days and deleted after they expire. Emailed codes as hashes, with the network prefix and the email domain the registration limits count, deleted after a day. Link codes for levels C and D as hashes, valid for seventy two hours and deleted a day after they expire. - **Your agents and their keys** Each agent's name and declarations, and when it was created, changed or revoked. Each key's public half and thumbprint, where it came from, when it was last seen in your directory, and when and why it was revoked. A key's thumbprint is kept for good, revoked keys included, because that is what stops a revoked key coming back under another agent and what lets old evidence still be checked. - **Credentials and renewals** A record of each credential issued: its id, the agent, the key, the level, the times and a hash of the token, never the token itself, kept for thirty days after the credential expires. The nonce of each renewal, kept for ten minutes. - **The links behind levels C and D** For level C, which institution linked itself and who did it. For level D, the officer's account, full name, title and assurance. The officer's row names a person, so it is in that person's export and is erased with their account. An officer who no longer answers for an operator may ask us at support@verigrant.com to remove the link, which ends level D. - **Abuse reports and the desk's decisions** Each report with the reporting site, whether the site was proven, the reporter's contact, the category, the description, the evidence lines and what each came to, its status, and each action the desk took with its note. Kept with the desk's record of its own decisions; there is no sweep that deletes them, and the standing weight of an action falls to nothing after a year even though the record stays. - **The transparency log** One leaf per credential issued, naming the credential's id, the agent, the operator, the level, the key's thumbprint and a hash of the token. The log is append only and is kept for good, because its whole purpose is that an entry cannot later be removed. We do not sell any of it, use it to train a model, or show it to an advertiser. The registration limits count registrations per network prefix and per email domain over a day and keep nothing else. There is no self service erasure for an operator today; to end an operator record, write to support@verigrant.com, and we will tell you what we can delete and what sections 5 and 8 require us to keep. ## 10. What you may not do Each of these is a breach of this agreement, and each is something the desk can act on with verified evidence under section 5. - **Do not act outside your declared purposes** An agent that declares assist and builds an index, or declares research and trains, has lied to every site that admitted it. We cannot see intent, so the declaration is the promise, and the evidence a site keeps is how it is proven. - **Do not share a key across agents, or lend one out** One key, one agent, run by you. A key handed to software you do not run, or used to sign for an agent it was not registered to, is yours to answer for until you revoke it as compromised. - **Do not impersonate a person without a pass** An agent ID says which operator's agent is visiting. It says nothing about any person. Presenting an agent as a particular person, or as acting with a person's authority, is done with a Verigrant pass that person issued, and in no other way. - **Do not scrape a site whose terms deny the purpose** A site's published terms say which purposes it allows. Reading a site for a purpose it denies, through the egress or around it, is a breach whether or not the site noticed. - **Do not exceed what you declared, or launder volume** Sending above your declared rate, or fetching at volume for a registered agent and passing the result to unregistered ones, is the thing the declared rate exists to bound. - **Do not register what is not yours** A domain you do not control, an institution you do not act for, an officer who did not agree, or an abuse contact nobody reads. Each proof exists to be true. - **Do not probe, replay or overload the registry** The registry is rate limited at every door and refuses a replayed renewal, and security research is welcome at the address in section 1. Testing on other operators' agents is not. ## 11. Fees Registering as an operator, declaring agents, registering keys, proving a domain, renewing credentials and being listed cost nothing. Level one, an agent carrying its agent ID in the clear, is free, for the operator and for the agent, and a site that admits a level one agent pays us nothing for doing so. A site may price a purpose under its own terms. That is between you and the site; we are not a party to it, we do not collect it, and the egress refuses a priced purpose rather than guessing whether you agreed. Level two, where a person's sealed details travel under a pass, is paid for by the business that receives them, as the price list says, and is never charged to an operator. ## 12. What we do not promise, and who pays if it goes wrong The registry is provided as it is. We do not promise that it will always be available, that a credential will always be renewable, or that any site will admit any agent at any level. We will say so when something is broken rather than degrade into an answer that looks fine. A level is what we observed and not a warranty about you, and a credential is a statement of your declarations and not a warranty that they are true. We do not promise that a site's evidence, a report, or the desk's decision reached the right conclusion, and a decision of the desk is ours to make on the evidence in front of it. If we cause you a loss directly, we will deal with it. What we will not pay for is indirect loss: revenue an agent did not earn, a site it was not admitted to, harm to a reputation, or the cost of something you decided to do because of a credential or a standing. Because you pay us nothing under this agreement, our total liability for everything arising out of it is limited to putting the registry right and to direct loss we actually caused. None of that limits our own fraud, death or personal injury caused by our negligence, or anything else the law where you are does not allow to be limited. What your agents do is yours. If an agent you run breaks section 10 and a site, a person or anybody else is harmed by it, that is between you and them, and you will cover us for a claim that reaches us because of what your agent did, including the reasonable cost of answering it. ## 13. Governing law and disputes Verigrant is operated by VX Encryption, Inc., based in Rapid City, South Dakota. These terms are governed by the laws of the State of South Dakota, without regard to its conflict of laws rules. Before either side files anything, we will try in good faith for thirty days to settle any dispute. If that cannot be settled, the dispute goes to the state or federal courts located in South Dakota, and both sides agree to that venue. Nothing here takes away a protection the law where you are gives you that cannot be waived, and nothing here requires you to arbitrate, and nothing here waives your right to bring or join a class action. If you have a dispute with us, write to support@verigrant.com first and we will try to deal with it directly. ## 14. When these terms change A new version of this page carries its own effective date and version string. From the day it takes effect, the registry refuses a registration that names any older version, and the console and the command line show the new one. An operator already registered is told at the address on its operator record before a change that matters takes effect, and the console names the version in force. If you do not want the new terms, retire your agents and tell us at the address in section 1, and we will end your operator record; keeping your agents registered past the effective date means you accept the new version. ## 15. The rest of it These terms are the whole agreement between us about the registry, the directory and the egress. A person's account, and anything an agent does under a pass a person issued, is governed by the Terms of Service and the Privacy Policy, and an institution's standing behind you at level C is governed by its own agreement with us. If a court decides one part of this page cannot stand, the rest of it still does. Your operator record is yours and you may not transfer it. We may transfer this agreement if the business is sold, and we would tell you at the address on your record. Not enforcing a term on one occasion does not mean we have given it up. Notices to you go to the address on your operator record; notices to us go to support@verigrant.com. --- Page: https://verigrant.com/pricing.html Title: Pricing at Verigrant: free for people, a price per application for institutions # Pricing People applying never pay, and neither do the agents acting for them. An institution pays for the applications it takes into its own systems, and finding, receiving and sorting candidates costs it nothing. These are the list prices, in US dollars and excluding tax. ### Card payments are not switched on yet Until they are, no card is charged and no money moves through Verigrant. The prices below are the list prices. Orders from agents, Fill with Verigrant, booking updates and masked contact have no price yet, and they are not billed. Neither has anything in the agent network: registering an agent at any level, an agent front, the gate, the generator, the dashboard and a directory listing are not billed, and connecting an assistant is free for the person. ## 1. People applying never pay A person applying is never charged. Holding a record, editing it, exporting it, issuing grants, revoking them, opening a check and erasing the whole account are free, and there is no tier above them that costs money. An agent acting for a person is never charged either. Everything below this section is what an institution pays. ## 2. The plans for institutions There are four plans. On each of them the included applications are counted over the life of the account, not each month, so an allowance that has been used does not come back. The four plans, what each costs and what each includes | Plan | Monthly fee | Included, over the life of the account | Each application after that | | Free | None | The first ten applications you take in | Needs a paid plan | | Per pull through | None | The first ten applications you take in | $12 each | | Platform | $200 a month | The first forty applications you take in | $5 each | | Annual contract | None; agreed and invoiced yearly | No limit | Not metered | - **Free** Everything works and nothing is charged. The free plan includes the first ten applications you take in, over the life of the account. Taking in more than ten needs a paid plan, which you can ask us to move you to, and nothing else on the service is metered. - **Per pull through** A fixed price each time you take an application into your own system, and no limit on how many. The per pull plan includes the first ten applications you take in, over the life of the account, and costs twelve dollars for each one after that, with nothing to pay in a month where you take none. - **Platform** A monthly fee and a lower price for each application you take in, with no limit on how many. The platform plan costs two hundred dollars a month. The first forty applications you take in, over the life of the account, are included, and each one after that costs five dollars. The fee is on the same invoice as the applications rather than a separate bill. - **Annual contract** Agreed with us and invoiced yearly, outside the meter, with no limit on how many applications you take in. They are still counted, for your own reporting, and priced at nothing. A contract is a figure two parties agree, so it has no list price here; write to support@verigrant.com to talk about one. ## 3. What taking in an application means You are charged once for each application you take into your own system. Taking an application in is either of two acts: advancing the candidate to interview or beyond, which means to interview, offer or hired, or reading their full record through the API. Each application is charged once, whichever of those two acts comes first. A candidate you advance and whose full record you then read is one application taken in, and reading the same record again is never charged again. Where your software reads a full record under a grant with no application behind it, that grant counts as one application in the same way. The rest is free and unlimited on every plan: posting roles, the job board, receiving applications, working your queues and reading previews. None of it counts towards an allowance, and none of it stops when an allowance is used. ## 4. A card before the first application you take in On the Free, Per pull through and Platform plans, taking an application into your own system needs a card on file, including the first one. Adding a card charges nothing. An invoice that comes to nothing is never presented, so the card is charged only for a monthly plan fee or for applications beyond what your plan includes. On the free plan it is never charged. The card is typed on a page Stripe serves and the number never reaches us. An institution on an annual contract is invoiced under its contract and is not asked for a card. ## 5. How billing works - **US dollars, tax excluded** Every price on this page is in US dollars and does not include tax. - **One invoice a month** An institution billed through the product is invoiced monthly, and its saved card is charged for that month's invoice. On the platform plan the monthly fee and the applications are on the same invoice. - **These are list prices** An institution that has agreed a different rate, or signed a written contract, pays what it agreed, and the billing screen in the application shows the figures it is actually billed at. Where a contract and this page disagree about money, the contract wins. - **Changing plan** A plan is changed by asking us, at support@verigrant.com. - **When prices change** A change to what institutions are charged applies from the next contract or the next billing period, and never to an application already taken in. ## 6. Refunds and cancellation The agreement on this is section 10 of the Terms of Service. In short: an application already taken in is not refunded. An institution may cancel at any time, and the cancellation takes effect at the end of the current billing period. The platform plan's monthly fee is not prorated. A charge made in error is refunded. A dispute about a bill comes to support@verigrant.com first. --- Page: https://verigrant.com/start-people.html Title: Let an agent act for you, safely | Verigrant # Let an agent act for you, safely Your AI agent can act for you at websites. It can search, hold a seat, book, and ask you before it pays. Verigrant gives it a short pass that shows a site a real person stands behind it, inside limits you set. The pass does not carry your name. ## 1. Before you start - **A Verigrant account for a person** It is free, and so is everything on this page. - **Your authenticator app** Turn it on in Settings, under Account and security. Some approvals ask for its code. - **An agent that works with Verigrant** Ask whoever runs your agent. The person who sets it up can follow the guide for agent developers. ## 2. Pair your agent If your assistant connects to remote MCP servers, the short way is Connect: one click from the assistant, a sign in, and an approval, with no keys to paste. The guide to Connect has it. The steps below are pairing by hand, which still works and is what an agent on its own device uses. - **Set up the agent on its own device.** Its setup prints two public keys. With the Verigrant MCP server the command is `vg-agent-mcp init`. - **Open Agents and approvals.** In Verigrant, go to Settings, then Agents and approvals. Under "Agents that act for you at websites", paste the two keys. - **Set its limits.** Choose where it may go, why it may act for you, what it may do, how long each pass lasts, how many passes it may get in a day, and for how many days. - **Choose the section of your record it holds.** Every paired agent holds the key to at least one section of your record, and can read that section. Choose the one you mind least. Verigrant still cannot read it. - **Unlock your record and pair.** Verigrant shows you an assistant code once. Give it to your agent and to nobody else. With the Verigrant MCP server, run `vg-agent-mcp pair` and paste the code when it asks. ## 3. What happens when it acts - **A pass for one site at a time** Before your agent uses a site, it asks Verigrant for a pass for that site. A pass lasts ten minutes at most. It carries an address that means you at that one site, so two sites cannot match you up through it. - **The site checks the pass itself** It does not call Verigrant to do it. Verigrant does not see the pages your agent asks for, or what comes back. - **Some sites have a door for agents** A site that uses Verigrant can give your agent its own permission to a structured interface built for agents, instead of its pages built for people. - **What Verigrant sees** Verigrant sees the site each time your agent asks for a pass. If you limit your agent to a list of sites, Verigrant can read that list. If you would rather it did not, choose any site that reads Verigrant passes. ## 4. Approving what it does When your agent wants to do several things in a row, it proposes a task. The task waits under "Waiting for your approval" in Agents and approvals. Nothing in it runs until you approve it. These are the approvals each kind of step needs by default, and the screen shows the ones in force for your agent. - **Looking and searching** No extra approval, because it runs inside a task you approved. - **Holding something, or booking without paying** One tap in Verigrant. - **Cancelling, signing in at a site, or a smaller payment** The code from your authenticator app. - **A larger payment, or acting on your account or an application at a site** A passkey. ### Passkeys are not on Verigrant yet A step that needs a passkey cannot be approved, so your agent cannot do it. The screen tells you when a step is one of these. ## 5. Payments, orders and your details - **Approving a payment** When your agent is ready to pay outside a task, it asks you on the "Approve a payment" card. You set the most it may charge. Nothing is paid without your approval. - **No money moves yet** Payments through Verigrant run in test mode. An approval you give today does not move money. - **Your traveller details** Keep names, dates of birth and traveller numbers in Settings, under Orders and activity. When your agent needs them for a purchase, you send it a copy sealed in your browser to that one business. Your agent carries the copy and cannot read it. The copy is deleted ten minutes after your agent collects it, or a day after you sent it. - **Orders and receipts** Orders and activity shows each order and the business's signed answer. "What your agents did" lists every pass and payment. These receipts are sealed to your key, so Verigrant can write them and cannot read them. - **Updates about a booking** A business you allowed can send you updates about a booking, such as a cancellation with other flights to choose from. They arrive in your Verigrant inbox, sealed to you, under the booking they are about. ### Not on the screens yet Allowing a business to send you updates about a booking, and making a masked address so a business can message you in Verigrant without learning your email, are built into the service. The screens to switch them on are not in the app yet. ## 6. Stopping it - **Stop one task** Press Stop on the task. Every later step stops at once. A site may still honour a pass it already holds for up to five minutes. - **Revoke the agent** Press Revoke on the agent in Agents and approvals. Verigrant gives it no more passes. A pass it already holds works at a site until it ends, ten minutes at most. - **Then sign in again** Until you do, the agent still holds a working key to the section of your record it was paired with. Signing in again finishes the revoke. ## 7. What is not live yet - **Payments that move money** Payments through Verigrant run in test mode. - **Passkeys** Steps that need one cannot be approved. - **A door for every site** Your agent can use a pass only at sites that read Verigrant passes. Fronts hosted by Verigrant for sites that have not built one go live on their own day. - **Health records** They are not switched on. What Verigrant can and cannot read is on the security page and in the privacy policy. --- Page: https://verigrant.com/start-business.html Title: Take orders and applications from agents | Verigrant # Take orders and applications from agents People send you sealed, structured applications through Verigrant. Their AI agents can now also drop complete orders for you to fill, people can fill your forms from their own records, and you can send updates after a booking. This page says how to start, and what is not live yet. ## 1. Set up your organization - **Create an organization account.** Sign up as an organization and confirm your email address. - **Turn on a second factor.** Every organization screen needs it. - **Create your organization.** You accept the Institution Agreement here. - **Add a card.** Card payments are not switched on yet, so no card is charged. - **Register as an institution.** Name your domain, let the browser make your keys, and publish the small file it gives you at that domain. Serve it with the header `Access-Control-Allow-Origin: *`, because each person’s browser reads it before it seals anything to you. - **Wait for approval.** Verigrant approves each institution. The checklist in your workspace shows where you are. If you sell rather than hire, admit, insure, lend or rent, choose Merchant as your kind of institution when you register. ## 2. Applications, as before People, or their agents under an assistant code, send you sealed, structured applications. You preview the fields you asked for, and pull the full application only for the people you advance. You open it with your own private key, which Verigrant has never held. You pay for each application you take in, on the plans in the price list. The institutions page has the whole of it, and the integration guide has the calls. ## 3. Orders from agents An agent acting for a person can drop a complete order into Verigrant instead of pushing it through your checkout. You never have to let a bot into your checkout pages. - **The order arrives.** It carries your offer, the total, the agent's pass, the person's payment approval, and the person's traveller details, sealed in their browser to your registered key. Verigrant checks it before it keeps it. - **You get it.** By webhook, at an https address on your registered domain, signed with Verigrant's published delivery key. Or you pull it with your API key: `GET https://verigrant.com/api/rp/orders`, then fetch and acknowledge each order. - **You open and complete it.** You open the traveller details with your own private key and complete the order in your own system. - **You send a signed result.** You post an outcome signed with your registered key: confirmed, pending, failed or needs approval. Verigrant refuses a confirmed or pending outcome above the most the person approved. The person keeps a sealed receipt of it. ### What to know today The payment approval inside an order runs in test mode. It is not money you can collect. Orders have no price yet and are not billed. Order screens are not in the organization workspace yet, so orders are handled through the interface. Verigrant keeps the sealed order for ten minutes after delivery, so you can pull it again, and deletes the order a week after it arrived. ## 4. A door for agents Agents can use a structured interface you publish, instead of your pages built for people. An agent carrying a person's Verigrant pass gets your grant and the sealed path, as below. An agent registered with Verigrant and carrying only its agent ID gets your grant at level one: search, compare and act in the clear. The generator drafts the front from your own site, the gate keeps your pages for people, the dashboard shows every agent that visits, and the directory is where agents find you. All four are in the guide for websites; the steps here are the pass. - **Save Verigrant's pass key set** Keep `https://verigrant.com/api/.well-known/verigrant-pass-keys.json` as a file and refresh it on your own schedule. You check passes against it offline, and never call Verigrant to do it. - **Publish a service file** At `/.well-known/verigrant-service.json` on your domain, listing the operations you offer to agents. - **Trade a pass for your own grant** Your grant is bound to the same agent key as the pass, and you check both on every call. - **Keep your pages strict** Your pages for people can refuse bots as firmly as they do today. The library for this is `vg-service-grant`, in Rust. It is not on a public registry yet. Write to support@verigrant.com to get it. A front hosted by Verigrant goes live on its own day, so for now you run your own. ## 5. Fill with Verigrant A person opens your form with Fill with Verigrant. Their device fills it from their own record and seals the answers to your key before anything is sent. Verigrant passes on ciphertext it cannot open. It keeps a row naming your business until shortly after the form is delivered. Verigrant registers your business and the forms your domain lists before you can offer it. Write to support@verigrant.com to start. ## 6. Updates and messages after a booking When a person allows it for a booking, you can send them updates about it, such as a cancellation with rebooking options. - **See what you may update** `GET https://verigrant.com/api/rp/deliver-back` lists the bookings people allowed you to send updates about. - **Send a sealed notice** Seal the notice to the person's key, sign it, and post it to their address, naming the booking's grant. It lands in their Verigrant inbox under that booking. Verigrant sees that you sent something and when. It cannot read it. - **Give the agent something to act on** If the person allows it, add a signed update sealed to the key their agent made for that booking. - **Message without an email address** A masked address lets you message the person in their Verigrant inbox without learning their email. It works for you alone and for that one matter. Email and phone relays are not built. People switch these on for each booking, and the screens for that are not in the app yet, so expect few of them at first. ## 7. What is not live yet - **Money moving through Verigrant** Payment approvals and card payments run in test mode. - **A price for the new services** Orders, Fill with Verigrant, booking updates and masked contact have no price and are not billed. - **Order screens in your workspace** Use the interface for now. - **Passkeys** People cannot approve a step that needs a passkey yet. - **A door hosted by Verigrant** It goes live on its own day, after the registry, the directory and Connect. Until then you run your own. - **The egress** Requiring that every agent request come through Verigrant's own network goes live on its own day. A front that requires it today refuses every agent. - **Health records and private compute** Neither is switched on. --- Page: https://verigrant.com/start-developers.html Title: Use Verigrant from your agent | Verigrant # Use Verigrant from your agent Your agent can apply for a person, act for them at websites with a pass, propose tasks they approve, drop orders and read booking updates. This page lists the pieces and the order to use them in. The integration guide covers applying. ## 1. The pieces - **The agent kit** `vg-agent-kit` in Rust, and `@verigrant/agent-kit` for Node 20 or later with no dependencies. Both make Web Bot Auth signatures, attach the `Verigrant-Pass` header, call Verigrant, and talk to a site's door for agents. The TypeScript kit also carries the agent ID: the renewal, the level one exchange, clear actions, the change feed and the front's MCP endpoint. - **The agent ID and the verigrant CLI** An agent that acts without a person, or wants a site to know who operates it, carries a Verigrant agent ID. `verigrant agent register` gets one in two minutes. The guide for agent operators is the order to do it in. - **The local MCP server** `vg-agent-mcp` runs on the person's own device over standard input and output, so any MCP client can use Verigrant. `init` makes the keys, `pair` keeps the assistant code, and `serve` serves MCP. - **The egress specification** `docs/agent-egress-pass-spec.md`, "Obtaining a pass and attaching it at egress". It gives the call, the arguments, the result, the headers and a worked example that the kit's own tests check. None of these is on a public registry yet. Write to support@verigrant.com to get them. ## 2. Pairing - **Make your keys.** Run `vg-agent-mcp init --state DIR --agent-url URL`. It prints two public keys for the person, and a Web Bot Auth key directory to publish at your agent URL. - **The person pairs you.** They paste the two keys in Verigrant, under Settings, Agents and approvals, and set your limits: sites, purposes, actions, how long a pass lasts and how many a day. - **Keep the assistant code.** Verigrant shows them an assistant code once. Run `vg-agent-mcp pair --state DIR`. It reads the code from standard input, so the code never lands in your shell history. A paired agent holds its own keys and the key to the one section of the person's record they chose. Keep them the way you keep any secret. ## 3. Getting and using a pass Ask for a pass with one MCP `tools/call` of `get_agent_pass` to `POST https://verigrant.com/api/agent/mcp`. Sign every request afresh with the request key the person's mandate names, in three headers: `X-Verigrant-Vera-Id`, `X-Verigrant-Agent-Timestamp` and `X-Verigrant-Agent-Signature`. - **Arguments** `site`, `purpose` and `agent_key_thumbprint`, and if you need them `actions`, `ttl_seconds` from 60 to 600, and `plan_id` with `plan_step`. No argument names a person, and every argument can only narrow what the person allowed. - **The result** The pass, how to present it, the person's address at that site, what Verigrant observed about the person, and when the pass ends. - **Attaching it** Send it as the `Verigrant-Pass` header inside a Web Bot Auth signature (RFC 9421), signed with the key whose thumbprint you gave, to that site and its subdomains only. - **How the site checks it** Offline, against `https://verigrant.com/api/.well-known/verigrant-pass-keys.json`. The site never calls Verigrant, and Verigrant never sees your request, the page or the response. ### Two keys, kept apart The request key signs requests to Verigrant and nothing else. The Web Bot Auth key signs requests to websites. Keeping them apart stops a site from linking the person across sites. ## 4. The tools on Verigrant's face for the person's agent - ** `get_agent_pass`** A pass for one site. - ** `propose_task_plan` and `get_plan_pay_grant`** A chain of steps for the person to approve, and the payment approval for a step that buys. - ** `record_service_outcome`** Report what a site's door answered. - ** `get_traveler_details`, `drop_order` and `order_status`** The person's traveller details sealed to the business, the order, and the business's signed outcome. - ** `register_update_key` and `booking_updates`** The updates a business sends about a booking, when the person allows it. - ** `list_inbox` and `read_inbox_item`** The person's inbox. Applying for the person works as before, with `POST https://verigrant.com/api/vera/applications`. The integration guide and llms.txt have it. ## 5. Rules your agent keeps - **Never log a pass** And never send it anywhere but its own site. - **Get a new pass before the old one ends** Short passes are how revoking reaches a site. - **A refusal is an answer** Do not retry with other arguments. Tell the person what it said. - **Ask the person for a step up** On `step_up_required`, tell the person which approval the step needs, wait until they say they gave it, then ask again. Nothing your agent sends can approve a step. - **Ask for what you need next** Request the actions the next requests need, and no more. ## 6. What is not live yet - **Money** A payment approval carries a test mode payment token. No money moves through Verigrant. - **Passkeys** Passkey approval is not on production, so a step that needs one cannot be approved. - **The hosted door and the egress** Fronts hosted by Verigrant, and the egress through Verigrant's own network, go live on their own day after the registry, the directory and Connect. Your agent can trade a pass or an agent ID for a grant at a site that runs its own door, and sends from its own network. - **Private compute and health records** Neither is switched on. - **A price** Verigrant does not charge agents. --- Page: https://verigrant.com/start-operators.html Title: Run an agent under a Verigrant agent ID | Verigrant # Run an agent under a Verigrant agent ID An agent that announces itself gets a site's agent front: live, structured data and structured actions, instead of pages built for people. This page is the order to do it in: register as an operator, declare your agent, keep its credential fresh, climb the levels when a site asks for one, and use a front. An operator registers in two minutes. The guide for agent developers covers acting for a person with a pass. ## 1. Before you start - **The verigrant CLI** `verigrant` is one binary with two families of commands: `verigrant agent`, which this page uses, and `verigrant site`, which the guide for websites uses. It is open source under the Apache License 2.0 and is not on a public registry yet. Write to support@verigrant.com to get it. - **An email address you can read** Registering and signing in are an emailed eight digit code, good once and for fifteen minutes. An operator is not a Verigrant account; it has no password. - **The operator terms** Registering accepts the Verigrant agent operator terms. They make what you declare about each agent a promise a site can hold you to. - **What you declare for each agent** A name. Its purposes, from a closed list: `assist`, acting for one person at a time; `search`, building a search index; `research`, reading for analysis; `training`, collecting for model training. The model or framework it runs on. The networks it sends from, as CIDR ranges. How many requests a day it expects to make to each site. And a contact for abuse reports, an email address or an https URL. The networks and the contact are required. ## 2. Register, and get your first agent to level A One command registers you as an operator, declares your first agent, makes its signing key, registers the key with a proof that you hold it, and fetches its first credential. It asks for the emailed code, and that is the only pause. ``` verigrant agent register --email ops@example.com --name "Example Agents" --accept-terms \ --agent-name shopper --purpose assist --framework "my-agent 1.0" \ --network 203.0.113.0/24 --rate 500 --abuse-contact abuse@example.com ``` - **Read the code and type it.** Verigrant mails it to the address you gave. Too many wrong tries end the code. You can also pass it with `--code` when you already have it. - **Read what it prints.** The operator id, `op_` and 26 characters; the agent id, `ag_` and 26 characters; and "at level A" with the credential's expiry. Nothing secret is printed. - **Know where the state is.** `~/.verigrant/agent`, or the directory `--state` or `VERIGRANT_AGENT_STATE` names. It holds your operator token, valid for ninety days, and each agent's private keys and latest credential, readable by the owner only. Keep it the way you keep any secret. - **Know where it talks to.** `https://verigrant.com/api`, unless `--api` or `VERIGRANT_API` says otherwise. Level A is a confirmed email and your agent's key on file. Verigrant hosts a level A agent's Web Bot Auth key directory for it, at `https://verigrant.com/api/agent-registry/directories/`, which is the `Signature-Agent` the agent signs with until it has a proven domain. ### Declare the networks you really send from An agent may declare `verigrant_egress` instead of its own ranges, meaning it sends through Verigrant's egress. The egress goes live on its own day, after the registry. Until then a site that checks consistency sees an agent that declared the egress and did not come through it, and warns `network_undeclared`. Declare your own ranges for now, and change the declaration when the egress is live; a change reaches the next credential. ## 3. Prove your domain for level B, and beyond Sites choose the lowest level they accept. Level B is the one most will ask for: your domain proven, and your agents' keys published there. From level B a site knows you by your proven domain, and the operator directory lists you under it. - **Claim the domain.** `verigrant agent domain claim example.com` prints the two ways to prove it. Publish one: a DNS TXT record at `_verigrant-agent.example.com` holding `verigrant-agent-verification=`, or a file at `https://example.com/.well-known/verigrant-agent-verification.txt` holding the same line. The token is yours alone, so a record somebody else published proves nothing. A claim never proven lapses after fourteen days. - **Publish your key directory.** `verigrant agent keys directory` prints the Web Bot Auth key directory of every agent on this machine. Serve it at `https://example.com/.well-known/http-message-signatures-directory`. A key counts for level B only while its thumbprint is listed there. - **Check the proof.** `verigrant agent domain verify` asks Verigrant to look now. Verigrant looks at most once a minute per operator, so a second check inside the minute is refused and nothing is lost. `verigrant agent status` shows your level, your evidence and your standing. - **Keep it published.** Verigrant checks again every day. A proof that is gone ends level B at once; a check that cannot complete keeps the proof for three days. At level B your agents sign with your own directory instead of the hosted one, and the CLI switches by itself from the credential it holds. Levels C and D are done in the operator console at `https://verigrant.com/app/operators`, where you sign in with the same emailed code. Level C is an institution registered with Verigrant standing behind you: the console gives you a business link code, and an owner or admin of an approved institution with a checked card posts it to `POST https://verigrant.com/api/orgs/{id}/agent-operators` with their institution session. Level D is a named officer who answers for you: the console gives you an officer link code, and a Verigrant person who has completed Verigrant's identity check posts it with their full name and title to `POST https://verigrant.com/api/me/agent-operators/officer`. Neither has a screen in the app yet. Both are read live, so an institution that loses its approval ends its operators' C and D at the next status list fetch. The card is checked, not charged. ## 4. More agents, and their keys - **Create another agent** `verigrant agent create --agent-name crawler --purpose search --framework "my-crawler 2.1" --network 203.0.113.0/24 --rate 2000 --abuse-contact abuse@example.com`. It makes a new key, registers it and renews a first credential. Repeat `--purpose` and `--network` for more than one. - **See the keys** `verigrant agent keys list`. With more than one agent on this machine, add `--agent ag_...` to any keys or credential command. - **Add a key** `verigrant agent keys add` makes one and registers it with its proof of possession. An agent holds at most ten live keys. The console takes a pasted key JSON too, or, from level B, a directory URL on your proven domain to import keys from. - **Rotate** `verigrant agent keys rotate` adds a new key, renews with it, then revokes the old ones. A revoked key leaves the hosted directory at once, and every credential bound to it fails at a site's next status list fetch, within the hour. - **Revoke one** `verigrant agent keys revoke `. If the key was stolen, revoke it as compromised in the console instead: evidence signed with a compromised key then never counts against you, whenever it was signed. - **A thumbprint belongs to one agent for good** Revoked keys included. Nobody can register a key they do not hold, and a key never returns under another agent. ## 5. Keep the credential fresh A Verigrant agent ID credential is a signed token, `vg-agentid+jwt`, that lives at most 24 hours and is bound to the key that renewed it. It names your agent and operator, your level, your proven domain from level B, the purposes, framework, networks and rate you declared, and its entry in a status list. A site checks it on its own server against Verigrant's published key set and never tells Verigrant which agent visited. - **Print a fresh one** `verigrant agent credential` renews when the one held is two thirds of the way through its life, and prints it. `--renew` renews now. - **Keep renewing** `verigrant agent credential --watch` renews at each two thirds mark until stopped, and on a failure tries again in a minute. Run it beside your agent, or have your agent call the renewal itself: `POST https://verigrant.com/v1/agent-registry/credential` with the body `{"agent": "ag_...", "jkt": ""}`, signed with Web Bot Auth by that key. The kit does this for you. - **Every issuance is public** Each credential issued is a leaf in Verigrant's transparency log, so a credential nobody can find a leaf for is a forgery anybody can name. - **Sign in again** The operator token lasts ninety days. On a new machine, or after that, `verigrant agent sign-in --email ops@example.com`. ### What a renewal refuses A renewal signed by a key that is not this agent's, a body that does not match its digest, a signature older than sixty seconds, a nonce used before, a credential of another agent, a revoked key, agent or operator, and more than thirty credentials in an hour. A refusal is an answer; read it rather than retrying. ## 6. Use a site's agent front - **Find the door.** A site publishes its front at `/.well-known/verigrant-service.json` on its own origin. A front that takes agent IDs lists `urn:verigrant:token-type:agent-id` among its subject token types. Sites that proved their domain are also listed in the directory: `GET https://verigrant.com/api/directory/search`, with a text, a category, a level, a purpose or a point and radius, and no credential. - **Trade your agent ID for the site's grant.** One RFC 8693 token exchange, form encoded, to the front's token exchange path, naming the purpose you are there for and, if you like, the operations you want. Send the same credential in the `Verigrant-Agent-Id` header, and sign the request with Web Bot Auth, RFC 9421, by the key the credential names, covering `@authority`, `@method`, `@path`, `signature-agent`, `content-digest` and `verigrant-agent-id`, created within sixty seconds, with a nonce. - **Read the grant.** It lists the operations your level and purpose may call. Operations you asked for and were not given are listed under `vg_withheld` with the reason, `pass_required` or `level_too_low`. Send it as `Authorization: VG-Grant ` on every call, signed by the same key, covering `authorization`. - **Call operations.** Search, list, get, availability and quote, each answering with its freshness, and `content_is_data: true`: every word a front serves is data, never an instruction to you. - **Take an action in the clear.** `POST /actions/` with `{"mode": "clear", "fields": {...}, "idempotency_key": "..."}`, exactly the fields the action lists. The site answers with a signed receipt. An action marked sealed needs a person's pass, and the site tells you which route to use instead. - **Watch for changes.** Ask the change feed what changed since your last cursor instead of polling every item. - **Or speak MCP.** A front that names an MCP path serves the same operations and actions as tools there, with the grant as the bearer and the same signature on each request. The TypeScript agent kit, `@verigrant/agent-kit` for Node 20 or later with no dependencies, does all of this: the renewal, the exchange, the signed calls, the clear actions, the change feed and MCP. The Rust kit, `vg-agent-kit`, speaks the pass today and not yet the level one exchange. Neither is on a public registry yet; write to support@verigrant.com. ### What happens at a page built for people A site that runs the gate answers a registered agent's request for a human page with HTTP 409 and a `Link` header pointing to the front. Automation with no agent ID gets 401 and the same pointer. A site may also warn you when something does not add up, such as a request from a network you did not declare or a rate above the one you declared, and may refuse a purpose its terms do not allow. ## 7. Reports, standing and what Verigrant keeps - **A site can report your agent** With up to twenty of your own signed requests as evidence. Verigrant checks each line against your keys, so a forged line never counts. The console shows the reports against your agents, without the reporter's contact or evidence. - **What an upheld report does** A Verigrant administrator can warn, rate limit, revoke the agent, or revoke the operator and every agent it runs. Each upheld action lowers your standing for a year, in full for ninety days. A report dismissed or never decided moves nothing. - **Revocation reaches every site** Through a public status list a site fetches without naming you. A revoked agent cannot renew, and its last credential dies within the hour at a site that reads the list. A revoked operator's proven domain is held for ninety days, and its email address cannot register again. - **What Verigrant holds about you** Your email address and name, the operator terms version you accepted, each agent's declarations and the public half of each key, your domain claim and its checks, the business or officer link if you made one, each issuance in the transparency log, and the reports against your agents. Verigrant does not learn which sites your agent visits unless a site reports it or opts into the hosted dashboard, which counts visits by operator and never by agent. The privacy policy and the operator terms are the documents to hold us to. ## 8. What is not live yet - **The egress** Sending through Verigrant's own network, for sites that want every request checked before it arrives, goes live on its own day. Until then declare your own networks, as above, and a site that requires the egress refuses every agent. - **The hosted door** Sites whose agent front Verigrant hosts go live on their own day. Today a front is one the site runs itself. - **Screens for levels C and D** The institution and the officer post their link codes to the interface. The screens for that are not in the app yet. - **Level D's identity check** The officer's assurance counts a completed Verigrant identity check. A phone confirmation is not recorded yet. - **The Rust kit at level one** It speaks the pass. The level one exchange, clear actions, the change feed and MCP are in the TypeScript kit today. - **Public registries** The CLI and the kits are open source and not yet published to a registry. Ask support for them. - **A price** Registering an agent is free at every level, and Verigrant does not charge agents. --- Page: https://verigrant.com/start-sites.html Title: Give your website an agent front | Verigrant # Give your website an agent front Agents already visit your site. This page is how to give them a door of their own and keep your pages for people: generate an agent front from the site you already have, publish its service file, put the gate in front of your pages, read the verdict on each visitor, and get found in the directory. A site goes from its website to a live front in fifteen minutes. The guide for businesses covers sealed orders and applications. ## 1. Three ways in - **Run the generator** `verigrant site` reads your site into a draft agent front, lets you review it, publishes the file and serves the door. Sections 2 and 3. - **Install the gate** A sidecar beside nginx, Caddy or Traefik, or a package for Express, Next.js and Cloudflare Workers, that sorts each visitor and points registered agents to your front. Sections 4 and 5. It works with or without a front of your own. - **Let Verigrant host it** The hosted door generates, serves and keeps your front, and holds sealed data until you pull it. It goes live on its own day, after the registry, the directory and Connect. This page says where that matters. All of it is open source under the Apache License 2.0 and none of it is on a public registry yet. Write to support@verigrant.com to get the `verigrant` CLI, `vg-gate`, `vg-service-grant`, `@verigrant/verify` and `@verigrant/gate`. ## 2. Run the generator ``` verigrant site init --domain example.com verigrant site verify verigrant site scan https://example.com verigrant site review verigrant site publish --out /var/www/html verigrant site serve ``` - **init makes your keys and prints your proof.** It writes a state directory, `.verigrant-site` by default or `--state`, holding the site's grant signing key and its box key, readable by the owner only and never printed. It prints the one DNS line or the one file that proves your domain: a TXT record at `_verigrant-door.example.com` holding `verigrant-door-verification=`, or the same line in `https://example.com/.well-known/verigrant-door-verification.txt`. It never overwrites a configuration that exists, so keys are never replaced by accident. - **verify checks the proof.** The record first, then the file, and records which held. A proof counts for thirty days. The scan checks it again, live, before reading a page, so a line written by hand into the configuration admits nothing. - **scan reads your site into a draft.** Your robots file, per host, and it obeys it; your sitemap, or links from the start page two levels deep; each page's schema.org markup and OpenGraph tags; Shopify and WooCommerce products, Google Merchant, RSS and Atom feeds, or one you name with `--feed`. It waits a second between requests, longer when your robots file asks, and reads at most 200 pages unless you raise it. Products, services, menu items, events, jobs, courses, rooms and articles become collections with search, list, get, availability and quote. Every form becomes an action, except search boxes and sign in forms. Card and password inputs are never accepted. Fields that look sensitive are sealed by default, and so is anything the scan cannot place. - **review is your approval.** It serves a page on `127.0.0.1:8827` with a token it prints, and nothing else can reach it. Switch operations on and off, edit fields, terms and limits, and approve. Nothing is published that you did not approve. An owner who edited `draft.json` by hand runs `verigrant site review --approve`. - **publish writes the files.** `.well-known/verigrant-service.json`, the front; `verigrant-connectors.json`; and `verigrant-snapshot.json`, the items with their date. `--out` writes them to your web root as well. - **Connect live data where it matters.** `verigrant site connect products --feed https://example.com/products.json` points a collection at a product feed. `--json` with `--map` reads a JSON API you already have, `--csv` a file on the server, and `--sql-env` with `--view` a read only Postgres view, with the database URL read from an environment variable and never written down. A collection with a connector answers live; without one it answers from the snapshot, with its date. - **Keep it current.** `verigrant site scan https://example.com --update` on a schedule keeps your reviewed draft, refreshes the snapshot and records what changed in the change feed. `--watch 3600` does the same every hour from one process. Everything the scan reads is data. Each string is cleaned and capped, nothing read from a page becomes an operation, an action kind or a path, and a page written to steer an agent is carried as a description and changes nothing else. Pages with no structured data can be labelled by a language model with your own key, with `--label`; it is off by default. ## 3. Publish the service file, and serve the door - **The file is the door's address** An agent fetches `/.well-known/verigrant-service.json` from your origin. It names your business, your collections, your operations and actions with their fields and modes, your change feed, your limits per tier and level, your terms per purpose, and your public keys. A front written for the first version of the format still reads it. - **Say what you allow** Terms per purpose: `allow`, `deny`, or a price. The generator starts you with assist, search and research allowed and training denied. A purpose your terms do not name is refused. Limits per tier and level set the calls a minute and a day, and a level with no limits is a level you do not serve, which is how you set your minimum. - **serve runs the door** On `127.0.0.1:8826`, behind your own proxy: the front, the token exchange at `/agent/v1/token`, each operation at `/agent/v1/` and the change feed at `/agent/v1/changes`. Give it Verigrant's pass key set with `--pass-keys`, saved from `https://verigrant.com/api/.well-known/verigrant-pass-keys.json`, and it trades a person's pass for your grant. `--preview` answers without a grant on loopback so you can try the front first. - **Where level one lives today** The generator's own `serve` takes passes. The level one exchange, where a registered agent trades its agent ID for your grant, clear actions and the MCP endpoint are in the open source door library, `vg-service-grant`, which a site in Rust puts behind its own listener over the files the generator published; `serve` answers those three paths with 501 and says so. The hosted door serves all of them, on its own day. - **Where clear actions arrive** At a door that takes them, by signed webhook at an https address on a public host, by email, or in the door's own inbox, set per front. A webhook or a mail that fails leaves the intake in the inbox, so nothing is lost. The agent gets a receipt signed with your grant key. ## 4. Install the gate The gate sits in front of your pages. People get the page. Verified search crawlers get the page unless you say otherwise. A registered agent gets HTTP 409 and a `Link` header pointing to your front. Automation that will not say who it is gets 401 and the same pointer. A visitor who may be a person but looks automated gets a small proof of work for its browser to do once per session. - **Fetch the files it reads.** Verigrant's agent ID key set from `https://verigrant.com/.well-known/verigrant-agentid-keys.json`, the pass key set if you take passes, and the Google and Bing crawler ranges. `deploy/gate/refresh-files.sh` does it from cron, hourly, and the gate notices a changed file within a minute. - **Write gate.json.** Your domain, your front's address, the file paths and your policy: the purposes you allow, the lowest level per purpose, what turns a warning into a refusal, whether crawlers and agents get pages, the proof of work difficulty, the rate limits by network and session, and the trap paths. Every field has a default and an unknown field is an error. `deploy/gate/gate.json` is a worked example. - **Run it beside your proxy.** `vg-gate --config gate.json` listens on `127.0.0.1:8822` and refuses any other address. nginx uses `auth_request` against `/auth/nginx` with `/render` for the refusal page; Caddy uses `forward_auth` and Traefik `forwardAuth` against `/auth`. The example configurations and a systemd unit are in `deploy/gate/`. - **Or use the package.** `@verigrant/gate` is the same gate as Express and Node middleware, Next.js middleware and route handler wrappers, and a Cloudflare Worker, built on `@verigrant/verify`. No dependencies, and it never calls Verigrant. Paths under `/.well-known/` and `/robots.txt` are never gated, so your front stays reachable. A page that pulls dozens of images and scripts should serve those outside the gate, or raise the network limit, because every gated request counts. The example configurations have not yet been run behind a real nginx, Caddy or Traefik on our side; the gate was tested against its HTTP contract. ## 5. Read the verdict One decision looks at each request and returns a verdict. The gate adds it to every request it lets through as three headers, and replaces any the visitor sent under the same names: `X-Verigrant-Class`, `X-Verigrant-Verdict`, the verdict JSON in base64url, and `X-Verigrant-Agent`. - **The classes** `person`, `search_crawler`, `agent`, `agent_for_person` when a pass rides on the same request, `unannounced_automation`, and `unknown` when there is not enough signal. - **What makes an agent an agent** A credential that verifies offline under Verigrant's key set, addressed to your site, a Web Bot Auth signature by the key the credential names, a fresh nonce, and a status list entry that reads valid. Anything wrong makes it unannounced automation with the reason, such as `agent_id_expired`, `agent_id_revoked`, `replayed` or `wrong_site`. - **The warnings** `network_undeclared`, `fingerprint_changed`, `rate_exceeded`, `purpose_not_allowed` and `upstream_bot_score_low`. Your policy's `refuse_on` turns any of them into a refusal; by default only a purpose you do not allow is refused. - **The log** Every request that carries an agent ID is written to `requests.log` in the gate's state directory, exactly as the agent signed it, each line signed by the gate's own key over a hash chained to the line before. It stays on your server, and it is what you report an agent with. ### Two settings to leave alone for now `egress_only` refuses every agent that did not come through Verigrant's egress, which goes live on its own day; set today it refuses every agent. And an agent whose status list the gate cannot fetch is refused by default, so revocation fails closed; a site that turns `status_list_required` off leaves revocation to the credential's day. ## 6. See your visitors, get found, and report - **The hosted dashboard** A registered institution presses "Opt in to the hosted dashboard" under Agent visits in its Verigrant workspace. Then `verigrant site serve --report-visits https://verigrant.com/api`, with your relying party credential in `VERIGRANT_RELYING_PARTY_CREDENTIAL`, posts one aggregate record a day per operator, level and purpose: the operations called, the actions taken and the outcomes, as counts. Verigrant refuses a record with anything else in it, so an email address, a request body or an agent id cannot be posted. Opting out stops new posts at once; the counts already posted stay with your organization. A door you run without opting in sends nothing. What Verigrant holds for an institution is in the privacy policy, and the terms of service say who agrees to what. - **The directory listing** Under Agent visits, list your site: a name, a description, up to eight categories, a location, your front's address, and the levels and purposes you accept. It becomes public when you prove the site, with a TXT record at `_verigrant-directory.example.com` holding `verigrant-directory-verification=` or the same line at `https://example.com/.well-known/verigrant-directory-verification.txt`, and press "Check the proof now". Verigrant rechecks daily; a proof that is gone delists you, and the listing returns when you publish it again. The front's address must be on your own site. Agents search it at `GET https://verigrant.com/api/directory/search`. - **Report an agent** `POST https://verigrant.com/api/agent-registry/abuse-reports` with the agent, your site, a contact, a category and up to twenty lines from your signed log. Verigrant checks each line against the agent's keys, so a forged line never counts. A report counts as from your site when it carries your relying party credential and your site is proven, by a listing or a registered domain; otherwise it is kept as claimed and unproven. An upheld report warns, rate limits or revokes the agent or its whole operator, across every site. ## 7. What is not live yet - **The hosted door** Goes live on its own day. Until then you serve your front yourself, and level one needs the door library behind your own listener, as section 3 says. - **The egress** Goes live on its own day. Do not set `egress_only` before it. - **Email delivery from the generator's door** An action set to arrive by email waits in the inbox until a mailer is wired in. The receipt says so. - **Selling priced access** You can price a purpose, and an agent is refused with the price's address. Nothing collects the price yet. - **Python** Planned. Rust and TypeScript are what ship. - **A price** The generator, the gate, the dashboard and a directory listing have no price and are not billed. Sealed orders and applications are the business guide's, with its prices. --- Page: https://verigrant.com/start-connect.html Title: Connect your assistant to Verigrant | Verigrant # Connect your assistant to Verigrant Connect is one click from your AI assistant. You sign in to Verigrant, read what the assistant is asking for in plain words, and approve. No keys to copy and no codes to paste. The assistant then acts for you at websites inside the limits you set, and it never holds your password, your keys or anything sealed in your record. This page says how, what it gets, what it never gets, and how to disconnect it. Pairing by hand, with two keys and a code, is still there and is the guide for people. ## 1. Before you start - **A Verigrant account for a person** It is free, and so is everything on this page. - **An assistant that connects to remote MCP servers** Claude, ChatGPT, OpenClaw or any assistant that adds a remote MCP server and signs in to it with OAuth. Verigrant's address for it is `https://verigrant.com/api/agent/mcp`. - **Your authenticator app, for some approvals** Turn it on in Settings, under Account and security. A step your assistant proposes may ask for its code before it runs. ## 2. Connect it - **Add Verigrant in your assistant.** Add it as a connector or a remote MCP server at the address above. The assistant opens Verigrant in your browser. - **Sign in, and unlock your record.** The page shows nothing about the request until you do, and nothing is shared until you approve. - **Read who is asking.** The page shows the assistant's name, and with it the address the browser will go to afterwards, which is the one fact Verigrant can vouch for. A line says the name is the assistant's own and Verigrant does not check it. If the address is on this device, the page warns you: any program on this device could be listening there, so approve only if you just started it yourself. - **Read what it may do.** Each permission it asks for, in words. "See what institutions have sent you: who sent what and when, never the contents." And "Act for you at websites inside the permission below: get passes, plan tasks for you to approve, and place orders you approve." - **Set its limits.** Where it may go, why it may act for you, what it may do, and for how many days. The page reads the whole permission back to you in plain words, with the approvals each kind of step will need, before the button. - **Approve.** Your browser signs the permission with your own key and sends you to the assistant with a code good for one minute. The assistant trades the code for an access token. From then on it calls Verigrant with that token, and nothing else. ## 3. What it gets - **An access token, for ten minutes at a time** Renewed while you stay connected, and never past the day your permission ends. Each renewal spends the old token; one presented twice ends the whole connection and tells you. - **A pass for one site at a time** Ten minutes at most, carrying an address that means you at that one site and never your name, within the limits you set. A site checks it itself against keys Verigrant publishes. - **Tasks you approve** When it wants to do several things, it proposes a task, and nothing runs until you approve it in Agents and approvals. Some steps then need one tap or your authenticator code. - **Orders you approve** It can drop a complete order for a business and read the business's signed answer. You set the most it may charge, and nothing is paid without your approval. - **Your inbox, outside only** If you allowed it, who sent you what and when. Never the contents. A connected assistant is held to every rule a paired agent is: the same limits, the same approvals, the same receipts, and the same place to stop it. ## 4. What it never gets The page says it before the button, and it is worth saying here in the same words: "It never gets your password, your keys or anything sealed in your record. It holds an access token that lasts ten minutes and is renewed while you stay connected, and every payment and every step you chose to approve still waits for you here." - **No key to any part of your record** An agent you pair by hand holds the key to one section of your record, the one you chose. A connected assistant holds none. It cannot open anything sealed, so a mistake on its side cannot reach your record. - **No way to approve anything** A payment, a step you chose to approve, and a form filled from your record all come back to you, on Verigrant's own page. Nothing the assistant sends can approve a step. - **No wider permission than you gave** A permission it did not ask for is refused. A purpose you did not allow is refused exactly as for a paired agent. It cannot widen its permission by renewing. - **Nobody else's account** Its token acts only for you, and is not a sign in anywhere. ## 5. What Verigrant keeps, and what it sees - **The connection** The assistant's name as it gave it, the address it sends you to, the permission you signed, when you connected it, when it was last used and when its permission ends. They are in Settings, Agents and approvals, under Connected assistants, and they leave with your account. - **Each pass it asks for** Verigrant sees the site at that moment. It does not see the pages your assistant reads there, or what comes back. If you limited it to a list of sites, Verigrant can read that list. - **Your receipts** Every pass, payment approval and order is written to a record sealed to your key. Verigrant can write it and cannot read it. The full list of what Verigrant can and cannot read is on the security page and in the privacy policy. ## 6. Disconnecting it - **From Verigrant** Settings, Agents and approvals, Connected assistants, then "Disconnect this assistant". It stops at once: its token is refused on the next request, and a code it has not yet used is dead. There is no key to retire, so there is nothing to finish at your next sign in. - **From the assistant** An assistant that revokes its token when you remove Verigrant from it, as the standard lets it, shows as disconnected on your side. One that does not still stops when you disconnect it here. - **A pass it already holds** Works at that one site until it ends, ten minutes at most. Revoking stops the next pass; it does not reach a request already made. - **Stop one task instead** Press Stop on the task in Agents and approvals. Every later step stops at once. ## 7. What is not live yet - **Sealed traveller details through a connected assistant** A connected assistant holds no key, so a copy of your traveller details sealed for it would be sealed to nobody. A purchase that needs them goes through an agent you paired by hand for now. - **Pass length and daily count on the consent page** The page uses the same defaults as pairing for how long each pass lasts and how many it may get in a day. You cannot change those two numbers there yet. - **Payments that move money** Payments through Verigrant run in test mode. An approval you give today does not move money. - **Passkeys** A step that needs one cannot be approved. - **Agent fronts on everyday websites** Your assistant can use a pass at a site that reads Verigrant passes. Fronts hosted by Verigrant go live on their own day. --- Page: https://verigrant.com/people.html Title: Your AI agent should carry your permission, not your password | Verigrant for people # Your AI agent should carry your permission. Not your password. Verigrant gives your AI agent an identity that comes from you, the way signing in with your email account gave apps one. It carries your grant, works with your data inside limits you set, and your sensitive details travel sealed to the business you chose. Free for people. Always. ## Two problems, one answer. AI agents can now shop, book and apply for you. They do it the hard way. They pretend to be you in a browser, scrape pages built for people, and type your details into forms. The website cannot tell who sent them. You cannot tell what they did. We think we have solved both halves of that. First, how an agent proves who it works for. With Verigrant, your agent carries a short pass that shows a website a real, verified person sent it, for this purpose, inside limits that person set. The pass does not carry your name. Second, how an agent talks to the websites you already use. Websites that use Verigrant give agents a second front door built for them. It answers with structured data, live: what is for sale, what it costs, what is open right now. Your agent sends back a structured request. It is a two way street of structured data instead of scraping. ## Set it up once. Then let it work. - **Connect your assistant.** One click from your AI assistant. You sign in to Verigrant and approve. No keys to copy and no codes to paste. This is Connect. - **Set its limits.** Choose where it may go, why it may act for you, what it may do, and the most it may spend. You read the limits in plain words before you approve them. - **It acts, and you approve what matters.** Your assistant searches and compares on its own. When it wants to book, buy or apply, it asks you first, with one tap or your authenticator code, depending on the step. ## You lend permission. You never hand over the keys. Today, letting an agent act for you often means giving it your password, or letting it drive a browser that is signed in as you. Then it can do anything you can do, and nobody can tell the difference. A Verigrant pass is different. It is a grant from you, for one site at a time, for a stated purpose, with a short life. A pass lasts ten minutes at most. Your agent asks for a fresh one each time. The website checks the pass itself, against keys Verigrant publishes. It does not need to call us to do it. You can stop a task, or revoke the agent, in one press. Verigrant stops giving it passes at once, and any pass it already holds runs out within minutes. ## Your agent works with your structured data, on your terms. Your record lives in Verigrant: your details, your history, your documents. Most of it is sealed in your own browser before it reaches us. The security page names the parts that are not. Your agent does not need a copy of you to act for you. When it needs something, it asks for exactly that, inside the limits you set. A request that goes past your limits is refused, and your agent is told why. When you connect your assistant with Connect, it does not hold a key to your record. Every pass, every order and every payment approval is listed under "What your agents did", so you can see what happened and when. ## Your agent carries them. It cannot read them. Some details should only ever reach the business that needs them. Your traveller details. Your address. Your application. When your agent needs one of these for a purchase, your browser seals a copy to that one business. Your agent carries the sealed copy and cannot open it. Verigrant passes it on and cannot open it either. The business opens it with its own key. The sealed copy is deleted ten minutes after your agent collects it, or a day after you sent it, whichever comes first. The business sends back a signed answer: confirmed, pending, or failed. You keep a receipt, sealed to you. Some websites accept details in the clear, as structured data, without sealing. That is still far better than an agent typing you into a form. When you want your details private, choose sealed. ## Each website sees a different you. Your pass carries an address that means you at that one website. Two websites cannot match you up through it. A pass does not carry your name. A website learns what you choose to send it, and nothing more. Verigrant sees which website your agent asks a pass for. It does not see the pages your agent reads there, or what comes back. The full list of what we can and cannot read is on the security page. It is specific enough to be wrong about, which is the point. ## Nothing important happens without you. When your agent wants to do several things in a row, it proposes a task. Nothing in the task runs until you approve it. Each kind of step has its own approval: - **Looking and searching** need no extra approval, because they run inside a task you approved. - **Holding something, or booking without paying,** takes one tap. - **Cancelling, signing in at a website, or a smaller payment** takes your authenticator code. - **A larger payment, or acting on your account or an application,** takes a passkey. You set the most your agent may charge. Nothing is paid without your approval. To stop one task, press Stop. To stop the agent for good, press Revoke. ## A few of the things your agent can do for you. ### Running shoes, from a small store. You ask for a pair in your size. Your agent reads the store's agent front, checks size and price live, and orders. If you want your address kept private, it travels sealed. ### A flight, and the cancellation in the security line. Your agent finds a fare, asks you to approve the price, and books with your traveller details sealed. If the flight is cancelled, the airline can send you rebooking options straight to your Verigrant inbox. ### A table for four at seven. Your agent reads the menu, the hours and live availability, and books. If the restaurant needs to reach you, it can message you without learning your number. ### A job application. Your agent applies with your sealed record. The employer previews the fields it asked for, and sees the full record only if it moves you forward. This one is live today. ### Watching for tickets. Your agent watches a sold out show and grabs two seats if they open, inside a price cap you set. ### Comparing prices. Your agent reads twenty stores' agent fronts and compares live price and stock, without buying anything. Some of these are live today and some are coming. The note below says which. ## We say exactly what we prove. Verigrant proves three things, with signed evidence. - **Who operates an agent.** Every agent that uses a Verigrant website is registered with us, and the website can see who runs it and how far that operator has been checked. - **That a real person sent it.** When your agent acts for you, its pass shows a verified person stands behind it, within limits that person set. - **What it did.** Requests are signed. Orders come back with signed answers. You keep receipts. What we do not claim. We cannot read an agent's mind, so we do not claim to verify its intent. We make honest behavior easy to prove and dishonest behavior expensive to hide. And we never claim we cannot see anything: the security page lists what we can see. ## Free for people. That does not change. Holding your record, connecting your assistant, getting passes, approving tasks, sealing your details and keeping your receipts are free. There is no paid tier for people. Businesses pay when they want sealed, structured data from you, or want us to run their agent front. That is how Verigrant earns. ## Where things stand today. ### Live now - **Your sealed Verigrant record.** - **Sealed job applications,** through your agent or on your own. - **Pairing an agent,** passes for one site at a time, and the limits you set. - **Tasks you approve,** with one tap or your authenticator code. - **Orders your agent drops for you,** with your traveller details sealed to the business, and signed receipts. ### Coming - **Connect, one click to connect your assistant.** Built and tested, going live next. Until then, you pair your agent with two keys and a code, as the guide shows. - **The agent network itself:** registered agents and agent fronts on everyday websites. Built and tested, going live next. - **Real card payments.** Payments run in test mode until our payment keys are switched on. An approval you give today does not move money. - **Passkey approvals.** Not on Verigrant yet, so a step that needs a passkey cannot be approved. - **Booking updates and masked contact.** Built into the service. The screens to switch them on are not in the app yet. - **Health records and private compute.** Not switched on. ## Give your agent your permission, not your password. Free for people. Always.