anonrouter-verify

Installing either SDK package installs anonrouter-verify. It answers one question from a terminal — did this route establish the assurance I require? — and answers it with an exit code, so it can gate a deploy or a CI job rather than only inform one.

Both languages ship the same command. A cross-language parity gate runs both real executables over the same inputs and requires the JSON they print and the codes they exit with to be identical, so it does not matter which one you have.

Three subcommands

# Hop 1 only: is this data plane the reviewed build, in a TDX CVM, bound to a
# fresh nonce and this origin? Credential-free.
anonrouter-verify gateway --origin https://api.anonrouter.ai

# Both hops, cross-bound to a route. Needs an API key for hop 2.
anonrouter-verify route --origin https://api.anonrouter.ai \
  --control-origin https://control.anonrouter.ai \
  --provider venice --model venice-uncensored

# What can this machine establish at all? Contacts nothing unless --origin is given.
anonrouter-verify doctor --origin https://api.anonrouter.ai

Exit codes

That third code exists so a typo cannot be mistaken for a verification failure, and the second covers unavailable as well as untrusted: a deployment that does not expose attestation has not passed anything.

anonrouter-verify gateway --origin https://api.anonrouter.ai --dcap \
  --require hardware_verified
echo $?   # 0 met, 1 not met, 2 the command itself was wrong

Gating a deploy

--require sets the minimum state that exits 0. The default is cryptographically_checked.

#!/usr/bin/env bash
set -euo pipefail

anonrouter-verify gateway \
  --origin https://api.anonrouter.ai \
  --dcap --require hardware_verified --compact

echo "plane established; proceeding with deploy"

With set -e, a plane that stopped matching the reviewed pin stops the deploy. See the five states for what each level of --require actually proves.

Reaching hardware_verified

--dcap chains the quote's signature to Intel's roots using the reviewed engine. It is required to reach hardware_verified; without it the honest ceiling is cryptographically_checked, and the command refuses --require hardware_verified rather than quietly returning a weaker result.

anonrouter-verify doctor            # is an engine installed? which one? what digest?

doctor reports what this machine can establish — the engine, its digest, the host target, and whether a pin ships for the origin — before you depend on it in CI.

Pinning the policy yourself

Without --policy, the command holds the plane to the pin the package ships for that origin. Supply your own to pin a release you reviewed yourself, or to verify a plane the package ships no pin for.

anonrouter-verify gateway --origin https://your-cvm.example \
  --policy ./reviewed-policy.json --dcap --require hardware_verified

--allow-candidate accepts a shipped pin whose status is candidate — a reviewed but pre-release plane whose measurements are expected to move. It is off by default, so a default invocation can never quietly pass against a plane the operator has not released.

Credentials and output

• The API key for route is read only from an environment variable, never from argv, where it would be visible in the process table. Change which variable with --api-key-env.
• The command prints one JSON document on stdout (--compact for one line) and diagnostics on stderr, so a caller can branch on the exit code and still read why.
• It never prints a key, a ticket, request content, or the raw evidence body. The gateway document alone is tens of kilobytes of internal build detail; the command reports a verdict over it rather than dumping it.

anonrouter-verify gateway --origin https://api.anonrouter.ai --compact \
  | jq '{schema, state: .gateway.state, reason: .gateway.reason}'

Every document carries a schema field (anonrouter-verify/1), so a consumer can detect a format change rather than silently misparse one.

Full options

anonrouter-verify --help