Verigrant
Register an agent

Verigrant › Open source

Open where it spreads the network. Closed where it holds trust.

Everything a website needs to tell who is knocking, and everything an agent needs to announce itself, is open source under the Apache License 2.0. Twelve Rust crates, three TypeScript packages, one public repository. A site checks every credential on its own server, against keys it already holds, and never calls us to decide.

See what is open How the agent network works

Apache License 2.0. Copyright 2026 VX Encryption, Inc., doing business as Verigrant.

A trust layer nobody can read is not a trust layer.

Verigrant sits between AI agents and the websites people use. An agent proves who operates it and who sent it; a website answers with live, structured data instead of being scraped. Both halves of that only work if the checking is in the open.

So the checking is in the open. The library that decides who a visitor is, the gate that acts on the decision, the door a site serves to agents, the generator that builds that door out of an existing website, and the kit an agent operator embeds are all published under the Apache License 2.0. You can read them, run them, fork them, and hold us to what they do.

Verification never calls home. A site checks agent IDs, passes and signatures against public keys it fetched once. We do not learn which agent visited which site unless the site chooses to report it. That is not a promise about our logs. It is a property of code you can read.

What stays closed is the part that would be worth attacking: issuing the credentials, and holding people's sealed data. The boundary section names every piece on each side.

What is open, piece by piece.

One public repository holds all of it, as a workspace with only the open members in it. Each crate and each package carries its own LICENSE, its own NOTICE and a README of its own.

The verifier

One decision function. It looks at a request and returns a verdict: a person, a search crawler, a registered agent, an agent acting for a person, unannounced automation, or not enough signal, with the consistency checks, the warnings and the evidence behind it.

vg-verify in Rust. @verigrant/verify in TypeScript, on Web Crypto, for Node 20 or later and for Cloudflare Workers, with no dependencies.

The gate

What acts on the verdict in front of your pages. People and search crawlers pass, registered agents are pointed to your agent front with a machine readable answer, unannounced automation is told to register, and a visitor that does not add up is asked for a one time proof of work.

vg-gate as a sidecar for nginx auth_request, Caddy forward_auth and Traefik forwardAuth, with the proxy snippets in deploy/gate. @verigrant/gate as middleware for Express, Node, Next.js and Workers.

The door

The site side of an agent front: the service file, the token exchange that turns an agent ID or a pass into a service grant, the check that a call is covered by the grant, actions and purchase outcomes with idempotency, intake, the change feed and the front's MCP endpoint.

vg-service-grant.

The agent ID and the pass

The two credential formats, with the code that issues and checks them. The agent ID says who operates an agent and what it is there to do. The pass says a verified person sent it, to this one site, for this purpose, inside limits they set. Both are checked offline against the published key set.

vg-agent-id for the credential and the ag_ and op_ id formats. vg-pass for the pass, the Web Bot Auth signer and verifier, the site check and the receipt.

The agent kit

What an agent operator embeds: the agent's Web Bot Auth key, the agent ID held and renewed, the agent front's exchange, operations, actions and change feed, passes and payment approvals over Verigrant's MCP, task plans with step up, and the egress fetch. The agent talks to the site itself.

vg-agent-kit in Rust. @verigrant/agent-kit in TypeScript, from agent-kit-ts, with no dependencies. vg-agent-mcp is the same kit as a local MCP server over standard input and output, so any MCP client can use it. vg-pass-agent is a reference command line over the kit.

The generator and the command line

One binary with two families of commands. verigrant site proves your domain, scans your website into an agent front, opens a local page to review it, publishes it and serves it. verigrant agent registers an operator, declares agents, manages keys and fetches credentials.

verigrant-cli, the verigrant command.

The formats underneath

The crates everything above stands on: the cryptography, the order drop an agent posts sealed for a business to pull, and the intake manifest. No HTTP client, no storage, and no way to open what was sealed for somebody else.

vg-crypto, the client side cryptographic core, and the only place the zero knowledge constructions are written down. vg-order and vg-intake for the two formats.

The test site

An example airline the kits' own tests run against, which admits an accountable agent on Verigrant's published keys alone and never contacts us. It is in the repository so that cargo test on a fresh clone passes the way it passes here.

vg-pass-site, in the repository and not on crates.io.

Twelve crates go to crates.io: vg-crypto, vg-pass, vg-agent-id, vg-verify, vg-intake, vg-service-grant, vg-order, vg-agent-kit, vg-gate, verigrant-cli, vg-agent-mcp and vg-pass-agent, in that order, because a dependency has to be on the registry before the crate that needs it. Three packages go to npm under the @verigrant scope: @verigrant/verify and @verigrant/gate at 0.1.0, and @verigrant/agent-kit at 0.2.0. The crates share one workspace version, 0.1.0.

Clone it, build it, test it.

The repository is an export with a fresh history. It holds exactly the crates and packages above, and nothing else of ours.

Getting the source and the packages 
git clone https://github.com/VERIGRANT_GITHUB_ORG/verigrant
cd verigrant && cargo build --workspace && cargo test --workspace

cargo install verigrant-cli
npm install @verigrant/verify
npm install @verigrant/gate
npm install @verigrant/agent-kit

Node 20 or later for the packages. Nothing in the packages pulls a dependency of its own, by design: a verifier a website runs on every request should not widen that website's supply chain.

What crates.io carries is packaged out of the same public tree the repository shows, so the two cannot drift, and each crate names a commit of the public repository.

The source is at github.com/VERIGRANT_GITHUB_ORG/verigrant under the Apache License 2.0. The repository, the crate and the packages publish on the day the organisation is named. Until then, write to support@verigrant.com for any of them.

How the agent network works.

Six steps, and the open source above is five of them. Verigrant issues the credential. Everything that reads one is code you can run yourself.

  1. Register, and get an agent ID. One command registers you as an operator, declares your agent, makes its signing key, registers the key and fetches its first credential. It pauses once, for the code we email you. The agent ID is a signed token that lives at most 24 hours and is bound to your agent's key; the kit renews it for you.
  2. Declare what the agent is and does. Its name. The purposes it acts for, from a closed list: assist, acting for one person at a time; search, building an index; research, reading for analysis without training; training, collecting for model training. The model or framework it runs on. The networks it sends from. How many requests a day it expects to make to each site. A contact for abuse reports. Those declarations are a promise you make in the terms you accept, and sites can hold you to them.
  3. Announce yourself, and get the front door built for agents. A site that uses Verigrant publishes its agent front at a standard address on its own domain. Your agent signs every request with its own key under Web Bot Auth, RFC 9421, carries its agent ID in a header, and trades that ID for a grant in one standard OAuth token exchange, RFC 8693, naming the purpose it is there for. The grant lists what your level and purpose may call.
  4. Read and act in structured data. Search, list, get, availability and quote, all live. Buy, book, reserve, apply, request a quote or ask a question, with exactly the fields the action names. Ask what changed since your last cursor instead of polling every item. Every agent front is also an MCP server, where each operation and action is a tool and the grant is the authorization.
  5. The site checks you with the open verifier, and the gate acts on it. The verdict comes out of vg-verify or @verigrant/verify, on the site's own server, against keys it already holds. The gate applies it in front of the human pages. Skip the announcement and you get the human website like anyone else, and the gate decides what happens next.
  6. Acting for a person: Connect. A person connects your agent in one click. Verigrant is an OAuth 2.1 authorization server for remote MCP clients, so the person signs in, reads your limits in plain words and approves, and your agent reaches Verigrant's MCP server with a short lived token. No keys to paste. Your agent can then carry a pass for that person: ten minutes at most, one site at a time, with an address that means that person at that one site and nowhere else. Sensitive details travel sealed to the business, so your agent carries them and cannot read them.

Two guides walk the whole of it with the commands attached: the guide for agent operators and the guide for websites.

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

Four levels of accountability. Sites pick their floor.

An agent ID carries a level, and a level is how much somebody has put on the line for that agent. Climb one when a site you want asks for it. Every level is free.

  1. Level A, keys and an email. A confirmed email address and your agent's signing keys. Verigrant hosts your key directory for you.
  2. Level B, a domain. Prove a domain with one DNS line or one file, and publish your key directory there. Rechecked daily.
  3. Level C, a business and a card. Your business checked against the public company register, with a card on file. The card is checked, never charged.
  4. Level D, an accountable person. A named officer of that business passes Verigrant's identity check. There is a person whose name is on it.

A site reads the level out of the verdict and decides for itself. Level A is worth little at a site that matters, which is the point of having four.

The boundary, stated plainly.

Open source is a claim people should be able to check, so here is the line. Everything that reads a credential is open. Everything that issues one, or holds a person's data, is ours and is not.

Open, under Apache 2.0

  • The verifier, in Rust and in TypeScript.
  • The gate, as a sidecar and as middleware.
  • The door that serves an agent front, with its MCP endpoint.
  • The agent ID and the pass formats, with the code that checks them.
  • The agent kit, in Rust and in TypeScript, and as a local MCP server.
  • The generator and the verigrant command line.
  • The cryptographic core, the order drop format and the intake manifest.
  • The written specifications, publishing with the source.

Run by Verigrant, and not open source

  • Issuance. Minting agent IDs and passes, and the registry behind them.
  • The data plane. People's sealed records, and everything that holds them.
  • The order drop service an agent posts a sealed purchase into.
  • Fill with Verigrant.
  • Private compute.
  • The egress, the published set of addresses an agent can send through.
  • The hosted door, for a business that would rather we ran its front.
  • The service itself: the API, and the web application people sign in to.

The closed crates say publish = false, carry no licence and no LICENSE file, and cargo refuses to publish them: core-api, web, gateway, vg-egress, vg-hosted-door, vg-compute, vg-compute-client, vg-compute-wire and vg-highway. Nothing published depends on any of them, which is what makes the open half usable on its own.

Two things the open half does not include yet. The design documents under docs/ are not published, so a crate's doc comment can name one a reader cannot see; which of them go out, and after what review, is still open. And three further test tools, vg-rp, vg-intake-demo and smoke, are Apache 2.0 in our own tree, so that a reader of the open code reads them under the same licence, but they go to neither the repository nor crates.io.

Apache License 2.0, and nothing on top of it.

The licence is the Apache License, Version 2.0, unmodified, with no extra field of use condition, no contributor licence agreement and no second commercial licence. Copyright 2026 VX Encryption, Inc., doing business as Verigrant, a South Dakota corporation. It carries Apache 2.0's patent grant, which is most of why that licence was chosen for a protocol other people have to be able to implement.

The licence does not grant rights in the Verigrant name or logo. That is section 6 of Apache 2.0 rather than anything we added. Build on the code, ship your own product, and call it yours.

Each crate says license = "Apache-2.0" itself and carries a LICENSE and a NOTICE beside its source; the workspace deliberately names no licence, so nothing of ours becomes Apache 2.0 by inheriting it. One snapshot of somebody else's work is vendored: the Mozilla public suffix list, in vg-pass/data, under the Mozilla Public License 2.0.

Found something wrong in it? Security reports go to support@verigrant.com, and the security page says what we do with one.

Where things stand today.

Live now

  • All of the code above is written, built and tested, under the licence it will ship under.
  • The kit and the local MCP server for pass based access, available on request from support.
  • Passes, task plans, sealed details and the order drop, through Verigrant's MCP tools.

Coming

  • The public repository, the crates and the packages. Everything is packed and the publish runs clean offline. It goes out on the day the GitHub organisation is named, which is why the addresses on this page are still a placeholder.
  • The agent network itself: agent IDs and levels A to D, the gate, the door with level one, the generator and the directory. Built and tested, going live next.
  • Connect, one click OAuth for a person's assistant. Built and tested, going live next.
  • The written specifications, publishing with the source. Until then the guides carry each format's fields and paths.
  • Python packages. Planned.

The developer front door has the rest of the detail: the formats, the red team's attacks and the answers, and the directory API.

Read it before you trust it.

That is the whole reason it is open.

Verigrant for developers Add an agent front to a site

Web Bot Auth. OAuth token exchange. schema.org. MCP. Nothing proprietary on the wire.