Verigrant
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.
Free forever. No fee to apply for somebody and no fee to redeem a grant you were given.
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.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.
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.
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.comAn 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.