Verigrant
Get started

Verigrant › 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.

Read the integration guide Read llms.txt

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 A Vera ID 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.

  1. Ask your user for a Vera ID. 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.
  2. 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.
  3. They approve, and the fields go straight to the institution. Your application lands in their queue. When they approve, their own browser opens the chosen fields for that one institution. Nothing readable passes through you at any point, which is why you have nothing to protect.
  4. 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.
  1. A Vera ID 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.
  2. 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.
  3. 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 there is no route anywhere that returns readable personal data to a caller.
  4. 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

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.

Integration guide Read the security page

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. 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 Vera ID cost my user?

A Vera ID 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 and send with their own model key or a metered one, and it never applies for anybody.

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.

Read the integration guide Read llms.txt

Free forever, and there is no scraping left to do.