Verigrant
Verigrant › The protocol
The Verigrant protocol
Verigrant is a protocol for letting AI agents use a website safely, and a set of services that run it for you if you do not want to run it yourself. The protocol is open: its formats and the code that reads and writes them are licensed Apache 2.0. A site can run the whole site side, the gate, the door, the grants and the receipts, from that code alone. Publication of the code is held for now; until it is published, write to support@verigrant.com and we will send you any of it. What a site relies on Verigrant for in version 1 is the root of trust: every agent identity and every pass is issued by Verigrant, so a site checks one issuer rather than build a federation.
Identity is not representation
Two separate questions get two separate answers. Identity is which agent is asking: every agent carries a Verigrant agent ID and signs every request with its own key, using Web Bot Auth, so a site knows the software and the operator behind it. Representation is whom the agent acts for: to act for a person or an organization, the agent also carries a pass, issued by Verigrant under a mandate the person or organization signed with their own key.
A site never learns who the person is. It sees an address that means this person at this site only. Identity without representation is an agent reading on its own account. Representation is an agent carrying someone's authority, under limits that party set and can withdraw.
The three layers
A site opens its agent door in three layers, and a grant reaches exactly one of them.
Layer 1, open: the front end of the site as structured data, for any registered agent. This is reading, nothing more.
Layer 2, identified: the agent has proved whom it represents and why it is there. This is where a site lets an agent see what it would show a signed in person.
Layer 3, transaction: the represented party approved a purchase or a booking. This is where money or a commitment is involved. Layer 3 has two shapes. Layer 3a is an agent checkout, where the agent completes a transaction at the door. Layer 3b is the handoff, which is the default: the agent prepares a complete, checked order and the business completes it with its own payment, its own fraud checks and its own customer relationship. The handoff is called the order drop, and its format is open even though Verigrant runs the relay.
Commerce on your own terms
When an agent buys from you, you decide how it is paid. By default the agent hands you a finished order and you complete the payment on your own account, so the sale, the fraud decision and the customer are yours, and Verigrant takes no cut. Agent completed card payments are not switched on yet; the handoff is what runs today.
Built, and not switched on yet. When it is switched on, a business that has a storefront and no back end will be able to let Verigrant's hosted door run the cart, the hold, the order and the signed receipt for it, priced from the business's own catalog and never by the agent. A hold means an inventory or booking hold, never held funds.
Reuse terms
A grant does not only say what an agent may read. It says what the agent may do with it afterwards: republish it, cache it, share it, or train on it, each allowed, denied, or priced, per site. So a site can answer an agent's question and still say that the answer may not be republished, or may be, for a price. A completed public answer that a site allowed to be republished is what the protocol leaves for the Entangleverse, named next.
Indexing, one choice per indexer and per purpose
A site chooses, for each indexer and each purpose, one of three things: open, meaning the indexer reads the ordinary way through robots.txt and the sitemap and needs nothing from Verigrant; grant required, meaning the indexer must hold an index grant carrying the site's terms; or refused. Verified Google and Bing crawlers are recognised and read as open by default.
The Entangleverse, the place the protocol names for completed public answers left for other agents to read, is never open: it always needs a grant, and a policy that tries to make it open is refused. Verigrant builds none of the Entangleverse itself; the protocol only names the boundary and holds the line that reaching it needs a grant.
Run it yourself, or let Verigrant be your proxy
You can run the whole site side yourself from the open code: the gate that separates agents from your human pages, the door that serves your agent front, the grants you issue, and the receipts you sign. Or you can let Verigrant stand in front: a hosted door that serves your agent front for you, an outbound relay called the egress for agents that want the highest trust, and the order drop relay for the handoff. Either way, a site keeps checking the agent itself; the relay never stands in for that check.
The sealed renderer
For a site that wants its human page readable by people but not harvested in bulk by automation, the sealed renderer serves the page and, when turned on, asks a network that opens an unusual number of visits in a short window to solve a small proof of work before it gets more. It asks nothing of a person reading normally, and an attested visit never pays it. It is off by default.
What is built, and what is in development
An honest status, with no dates. A page describes as working only what answers in production today.
Built and tested: the gate in Rust and in TypeScript, the agent ID and its signatures, the pass and the mandates, the agent front and the door, site issued grants with layers and reuse terms, per indexer indexing with index grants, and the order drop handoff.
Run by Verigrant: the registry that issues agent IDs, the pass issuer, the index grant signer, and Connect, the way a person connects an assistant.
Built, and not switched on yet: the hosted door that serves an agent front for a business, the egress outbound relay, the hosted commerce back end, and agent completed card payments. When each is switched on, it works as this page describes. Until then it does not answer in production, and no page on this site says otherwise.
The protocol and its code are licensed Apache 2.0. Publishing is held for now, so there is no download link yet.