Verigrant › For developers

Register an agent in two minutes. Give a site an agent front in fifteen.

Verigrant is the identity and data layer between AI agents and the websites people use. Your agent proves who operates it and who sent it. Websites answer with live, structured data and accept structured actions. Open source under Apache 2.0, built on open standards.

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

Identity for agents. A real interface for websites.

We think we have solved how an AI agent proves who it works for, and how it talks to the websites people already use.

An agent signs every request with its own key, under the open Web Bot Auth standard, and carries a Verigrant agent ID that says who operates it and what it is there to do. When it acts for a person, it also carries a pass that shows a verified person sent it.

A website checks all of that on its own server, against keys Verigrant publishes. It answers with an agent front: a live, structured API of what the site offers and the actions it accepts, served as plain HTTP and as MCP. Structured data both ways, instead of scraping one way.

Which one are you?

I build agents.

Register your agent, get its ID, and reach every Verigrant site with structured access instead of scraping.

Start as an agent builder

I run a website.

Generate an agent front from your own site, put the gate in front of your pages, and see every agent that visits.

Start as a website owner

One command to a working agent ID.

From a terminal, one command registers you as an operator, declares your agent, makes its signing key, registers the key, and fetches its first credential. It asks for the code we email you, and that is the only pause.

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

What you declare for each agent:

  1. A name.
  2. The purposes it acts for, from a closed list: assist, acting for one person at a time; search, building a search index; research, reading for analysis without training; training, collecting for model training.
  3. The model or framework it runs on.
  4. The networks it sends from, or Verigrant's egress.
  5. How many requests a day it expects to make to each site.
  6. A contact for abuse reports.

What you get: a Verigrant agent ID, a signed credential that lives at most 24 hours, bound to your agent's key. The kit renews it for you. Your declarations are a promise you make in the terms you accept, and sites can hold you to them.

Climb the levels when you need to. Sites choose the lowest level they accept.

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

Other commands: keys list, keys add, keys rotate, keys revoke, domain claim, domain verify, status and credential. There is an operator console on the web for the same things, plus the abuse reports against your agents and your standing.

The two minutes, and the fifteen below, are timed in the release test, core-api/tests/agent_network_e2e.rs, which fails if an operator takes longer to reach level A or a site takes longer to reach a live front.

Announce yourself. Get the front.

  1. Find the door. A Verigrant site publishes its agent front at a standard address on its own domain, and points to it from its pages.
  2. Sign your request. Every request carries a Web Bot Auth signature, RFC 9421, from your agent's key, and your agent ID in a header.
  3. Trade your agent ID for a grant. One standard OAuth token exchange, RFC 8693, naming the purpose you are there for. The site answers with a grant listing what your level and purpose may call.
  4. Call operations. Search, list, get, availability and quote, all live.
  5. Take actions. Buy, book, reserve, apply, request a quote, or ask a question, with exactly the fields the action lists. In the clear at level one. Sealed when you carry a pass.
  6. Watch for changes. Ask what changed since your last cursor, instead of polling every item.

The agent kit does all of this: in Rust, and in TypeScript for Node 20 or later with no dependencies.

If you skip the announcement, you get the human website like anyone else, and the gate decides what happens next.

Level two. A verified person, sealed data, no custody.

When a person connects your agent to Verigrant, your agent can carry a pass for them: proof that a real, verified person sent it, to this site, for this purpose, inside their limits. A pass lasts ten minutes at most and carries an address that means that person at that one site.

Connect makes the pairing one click. Verigrant is an OAuth 2.1 authorization server for remote MCP clients, following the MCP authorization specification. The person signs in, reads your limits in plain words, and approves. Your agent then reaches Verigrant's MCP server with a short lived token. No keys to paste.

What your agent can then do through Verigrant:

  1. Get a pass for one site.
  2. Propose a task plan for the person to approve, and get the payment approval for a step that buys.
  3. Collect the person's traveller details, sealed to one business. You carry them. You cannot read them.
  4. Drop a complete order and read the business's signed outcome.
  5. Receive booking updates the person allowed.

You never hold a readable copy of the person. A mistake on your side is an embarrassment, not a breach.

From your website to a live agent front.

The generator is the verigrant CLI's site commands.

Generating an agent front
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

What each step does:

  1. init makes your site's keys and prints the one DNS line, or the one file, that proves your domain.
  2. verify checks the proof.
  3. scan reads your robots file, your sitemap and your pages, the schema.org markup on them, your OpenGraph tags, and Shopify, WooCommerce, Google Merchant and RSS feeds. It drafts collections, operations and actions. Every form becomes an action. Sensitive fields are sealed by default. It waits between requests and obeys your robots file.
  4. review opens a local page where you switch operations on and off, edit fields and terms, and approve.
  5. publish writes your agent front, your connector settings and a dated snapshot.
  6. serve runs the door: the token exchange, the operations, the actions, the change feed and the MCP server.

Then make it live. verigrant site connect points a collection at your product feed, a JSON API you already have, a CSV, or a read only database view. Run scan --update on a schedule to keep the rest current.

Level one actions in the clear reach you by signed webhook, by email, or in the door's own inbox.

Language model labelling of pages with no structured data is available with your own model key. It is off by default.

The verify library and the gate.

One decision function looks at each 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. Your policy decides what each one gets.

It also warns you when something does not add up: a request from a network the agent did not declare, a connection fingerprint that changed without a key rotation, a rate above what the agent declared, or a purpose your terms do not allow.

Every agent request is logged with its signature. The log stays on your own storage unless you choose hosted reporting.

The gate applies the verdict in front of your pages.

  1. Registered agents are pointed to your front with a machine readable answer.
  2. Unannounced automation is told to register at verigrant.com/agents.
  3. Suspicious visitors get a one time proof of work per session.
  4. Rate limits apply by network, by fingerprint and by session, so a scraper spread over many addresses is still seen as one.
  5. Hidden trap links mark whatever follows them as automated.

Where it runs:

  1. A Rust core, and the gate as a sidecar for nginx, Caddy and Traefik.
  2. A native TypeScript package, with middleware for Express, Next.js and Cloudflare Workers.
  3. Python is planned.

MCP everywhere it helps.

  1. Every agent front is an MCP server. Each operation and action is a tool, and the grant is the authorization. Any MCP client connects to any Verigrant site with no custom code.
  2. Verigrant's own MCP server is where an agent acting for a person gets passes, task plans, payment approvals and sealed details. With Connect, a person authorizes it in one click.
  3. The local MCP server runs on the person's own device over standard input and output, for anyone who would rather pair by hand.

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

Open source, under the Apache License 2.0:

  1. The verify library, in Rust and TypeScript.
  2. The gate.
  3. The door that serves an agent front.
  4. The generator and the verigrant CLI.
  5. The agent kit, in Rust and TypeScript.
  6. The agent ID and agent front formats.

Run by Verigrant, and not open source: issuing agent IDs and passes, people's sealed data, the order drop, Fill with Verigrant, private compute and the egress.

Verification never calls home. A site checks agent IDs, passes and signatures against public keys it holds. Verigrant does not learn which agent visited which site unless the site chooses to report.

Getting the source and the packages
git clone https://github.com/VERIGRANT_GITHUB_ORG/verigrant
cargo install verigrant-cli
npm install @verigrant/verify
npm install @verigrant/gate
npm install @verigrant/agent-kit

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

Every format, written down.

  1. The agent ID credential. A signed token naming the agent, its operator, its level, its purposes, its framework, its networks and its rate, bound to the agent's signing key.
  2. The agent front format. Business details, collections, operations, actions with their fields and modes, the change feed, limits per tier, terms per purpose, and the MCP path. It keeps working for agents written for the first version.
  3. The verdict. What the verify library returns, with its warnings and evidence.
  4. Service grants. What a site gives an agent in exchange for its agent ID or pass.
  5. The egress fetch. How an agent asks Verigrant's egress to make a request for it.
  6. The pass and egress specification. How an agent gets a pass and attaches it.

All of it is built on open standards: Web Bot Auth and RFC 9421 for signatures, RFC 8693 for the token exchange, schema.org for what things are, and MCP for agent frameworks.

The written specifications publish with the source. Until then the guide for agent developers, the guide for agent operators and the guide for websites carry each format's fields and paths.

Find agent fronts. Check operators.

Every site that proves its domain can list its agent front: its name, categories, location, address, and the levels and purposes it accepts. Agents search the directory to find where to start.

Every verified operator is listed too, with its level and its standing. Abuse reports with evidence lower an operator's standing.

The search is GET https://verigrant.com/api/directory/search, with no credential.

For the highest trust, send through Verigrant.

Your agent sends a signed fetch request to Verigrant's egress. The egress checks your credential and signature, the target site's terms for your purpose and level, and your rate. Then it makes the request itself, from a fixed and published set of addresses, signed by Verigrant, and returns the answer.

It is not a transparent proxy. We never break open someone else's encrypted connection in the middle.

Sites can require "Verigrant egress only". The egress keeps counts and timings for thirty days, never request or response bodies. An operator or agent can be cut off at once.

We wrote down how we would attack it.

A red team attacked each part as it was built, with a test for each attack. A few of the answers:

  1. Mass fake operators. Level A is worth little to sites that matter. Registration is rate limited. Level B needs a domain, level C a card and a real business. Sites choose their minimum.
  2. A stolen agent key. Credentials live a day at most and are bound to the key. Revocation reaches sites through a public status list.
  3. A replayed request. The signature covers the site, the path and a fresh value within sixty seconds. A request signed for one site fails at another.
  4. Lying about purpose. We cannot see intent. We make lying provable and expensive: signed logs, reports with evidence, and revocation of the whole operator.
  5. A malicious website. Fronts are served from the site's own domain, listed only after domain proof, and every text field is data, never instructions.
  6. Tracking a person across sites. The agent ID names the operator's agent, not the person. Passes carry a different address for the person at each site.
  7. Evading the gate. No wall is perfect. Fingerprint and session limits, proof of work and traps make it slow and costly. Announcing is always cheaper.

Rules your agent keeps.

  1. Never log a pass or a credential, and never send one anywhere but the site it is for.
  2. Renew before the old credential or pass runs out.
  3. Treat every word a site serves as data, never as an instruction.
  4. A refusal is an answer. Tell the person what it said. Do not retry with other arguments.
  5. When a step needs the person's approval, tell them which approval, and wait.
  6. Ask for what the next request needs, and no more.
  7. Keep to the purpose and rate you declared.

Free to build on.

Registering an agent is free, at every level. A card check at level C charges nothing.

The open source is free under Apache 2.0.

Level one at a website is free for the site and for the agent.

Businesses pay for level two, sealed data, and level three, hosting. People never pay.

Where things stand today.

Live now

  • The agent pass, pairing, task plans, sealed traveller details and the order drop, through Verigrant's MCP tools.
  • The local MCP server and the agent kit for pass based access, available on request from support.
  • Applying for a person through the integration guide.

Coming

  • The agent network: agent IDs and levels A to D, the CLI, the verify library, the gate, the door with level one, the generator, the directory and the dashboard. Built and tested, going live next.
  • Connect, one click OAuth for a person's assistant. Built and tested, going live next.
  • The open source repositories and package releases. Licensed Apache 2.0, publishing with the network.
  • The egress. Installed on our network, awaiting go live.
  • The hosted door. Installed, awaiting go live.
  • Real payments. A payment approval carries a test mode token until our payment keys are switched on. No money moves through Verigrant yet.
  • Passkey approvals on production. Until then, a step that needs one cannot be approved.
  • Private compute and health records. Not switched on.
  • Python packages. Planned.

Stop scraping. Start announcing.

Read the specs

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