Give your website an agent front

2. Run the generator

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

1. init makes your keys and prints your proof. It writes a state directory, .verigrant-site by default or --state, holding the site's grant signing key and its box key, readable by the owner only and never printed. It prints the one DNS line or the one file that proves your domain: a TXT record at _verigrant-door.example.com holding verigrant-door-verification=<token>, or the same line in https://example.com/.well-known/verigrant-door-verification.txt. It never overwrites a configuration that exists, so keys are never replaced by accident.
2. verify checks the proof. The record first, then the file, and records which held. A proof counts for thirty days. The scan checks it again, live, before reading a page, so a line written by hand into the configuration admits nothing.
3. scan reads your site into a draft. Your robots file, per host, and it obeys it; your sitemap, or links from the start page two levels deep; each page's schema.org markup and OpenGraph tags; Shopify and WooCommerce products, Google Merchant, RSS and Atom feeds, or one you name with --feed. It waits a second between requests, longer when your robots file asks, and reads at most 200 pages unless you raise it. Products, services, menu items, events, jobs, courses, rooms and articles become collections with search, list, get, availability and quote. Every form becomes an action, except search boxes and sign in forms. Card and password inputs are never accepted. Fields that look sensitive are sealed by default, and so is anything the scan cannot place.
4. review is your approval. It serves a page on 127.0.0.1:8827 with a token it prints, and nothing else can reach it. Switch operations on and off, edit fields, terms and limits, and approve. Nothing is published that you did not approve. An owner who edited draft.json by hand runs verigrant site review --approve.
5. publish writes the files. .well-known/verigrant-service.json, the front; verigrant-connectors.json; and verigrant-snapshot.json, the items with their date. --out writes them to your web root as well.
6. Connect live data where it matters. verigrant site connect products --feed https://example.com/products.json points a collection at a product feed. --json with --map reads a JSON API you already have, --csv a file on the server, and --sql-env with --view a read only Postgres view, with the database URL read from an environment variable and never written down. A collection with a connector answers live; without one it answers from the snapshot, with its date.
7. Keep it current. verigrant site scan https://example.com --update on a schedule keeps your reviewed draft, refreshes the snapshot and records what changed in the change feed. --watch 3600 does the same every hour from one process.

Everything the scan reads is data. Each string is cleaned and capped, nothing read from a page becomes an operation, an action kind or a path, and a page written to steer an agent is carried as a description and changes nothing else. Pages with no structured data can be labelled by a language model with your own key, with --label; it is off by default.

4. Install the gate

The gate sits in front of your pages. People get the page. Verified search crawlers get the page unless you say otherwise. A registered agent gets HTTP 409 and a Link header pointing to your front. Automation that will not say who it is gets 401 and the same pointer. A visitor who may be a person but looks automated gets a small proof of work for its browser to do once per session.

1. Fetch the files it reads. Verigrant's agent ID key set from https://verigrant.com/.well-known/verigrant-agentid-keys.json, the pass key set if you take passes, and the Google and Bing crawler ranges. deploy/gate/refresh-files.sh does it from cron, hourly, and the gate notices a changed file within a minute.
2. Write gate.json. Your domain, your front's address, the file paths and your policy: the purposes you allow, the lowest level per purpose, what turns a warning into a refusal, whether crawlers and agents get pages, the proof of work difficulty, the rate limits by network and session, and the trap paths. Every field has a default and an unknown field is an error. deploy/gate/gate.json is a worked example.
3. Run it beside your proxy. vg-gate --config gate.json listens on 127.0.0.1:8822 and refuses any other address. nginx uses auth_request against /auth/nginx with /render for the refusal page; Caddy uses forward_auth and Traefik forwardAuth against /auth. The example configurations and a systemd unit are in deploy/gate/.
4. Or use the package. @verigrant/gate is the same gate as Express and Node middleware, Next.js middleware and route handler wrappers, and a Cloudflare Worker, built on @verigrant/verify. No dependencies, and it never calls Verigrant.

Paths under /.well-known/ and /robots.txt are never gated, so your front stays reachable. A page that pulls dozens of images and scripts should serve those outside the gate, or raise the network limit, because every gated request counts. The example configurations have not yet been run behind a real nginx, Caddy or Traefik on our side; the gate was tested against its HTTP contract.

6. See your visitors, get found, and report

• The hosted dashboard A registered institution presses "Opt in to the hosted dashboard" under Agent visits in its Verigrant workspace. Then verigrant site serve --report-visits https://verigrant.com/api, with your relying party credential in VERIGRANT_RELYING_PARTY_CREDENTIAL, posts one aggregate record a day per operator, level and purpose: the operations called, the actions taken and the outcomes, as counts. Verigrant refuses a record with anything else in it, so an email address, a request body or an agent id cannot be posted. Opting out stops new posts at once; the counts already posted stay with your organization. A door you run without opting in sends nothing. What Verigrant holds for an institution is in the privacy policy, and the terms of service say who agrees to what.
• The directory listing Under Agent visits, list your site: a name, a description, up to eight categories, a location, your front's address, and the levels and purposes you accept. It becomes public when you prove the site, with a TXT record at _verigrant-directory.example.com holding verigrant-directory-verification=<token> or the same line at https://example.com/.well-known/verigrant-directory-verification.txt, and press "Check the proof now". Verigrant rechecks daily; a proof that is gone delists you, and the listing returns when you publish it again. The front's address must be on your own site. Agents search it at GET https://verigrant.com/api/directory/search.
• Report an agent POST https://verigrant.com/api/agent-registry/abuse-reports with the agent, your site, a contact, a category and up to twenty lines from your signed log. Verigrant checks each line against the agent's keys, so a forged line never counts. A report counts as from your site when it carries your relying party credential and your site is proven, by a listing or a registered domain; otherwise it is kept as claimed and unproven. An upheld report warns, rate limits or revokes the agent or its whole operator, across every site.