Verification and E2EE

@anonrouter/confidential (JavaScript / TypeScript) and anonrouter-confidential (Python) are twin packages that let your own app do three things without trusting AnonRouter: verify a route's evidence, encrypt inference requests end to end, and generate images and speech across the two-origin split.

The verifier is pure over its inputs, fails closed, and both languages pass the same shared known-answer test vectors, so they agree bit-for-bit.

Install

npm install ./anonrouter-confidential-0.1.0.tgz
pip install ./anonrouter_confidential-0.1.0-py3-none-any.whl

# Not published yet — see the callout above.
npm install @anonrouter/confidential

Node 22+ or Python 3.10+. You need an API key with the inference scope.

Configuration: two origins

AnonRouter serves two browser-visible origins with different jobs, and the SDK keeps them apart for you.

Both are the SDK's defaults, so most callers configure nothing but a key.

import { createClient } from "@anonrouter/confidential";

// Production origins are the defaults.
const client = createClient({ apiKey: process.env.ANONROUTER_API_KEY! });

// Or name them explicitly, for another deployment:
const explicit = createClient({
  inferenceBaseUrl: "https://api.anonrouter.ai",
  controlBaseUrl: "https://control.anonrouter.ai",
  apiKey: process.env.ANONROUTER_API_KEY!,
});

The two hops

A request travels through two parties, and verifying one tells you nothing about the other.

A verified hop 2 says nothing about who routed the request. A verified hop 1 says nothing about where inference actually ran. Only asking both establishes the whole path.

verifyRoute() — the stable contract

verifyRoute establishes both hops, cross-binds them to the route you asked for, and reports ordered states rather than a boolean. This is the call to build on.

import { createClient, atLeast } from "@anonrouter/confidential";

const client = createClient({ apiKey: process.env.ANONROUTER_API_KEY! });

const verdict = await client.verifyRoute({
  model: "venice-uncensored",
  provider: "venice",
  gateway: true,                       // omit to skip hop 1 entirely
});

verdict.overallState;                  // the weakest hop you ASKED about
verdict.gateway.requested;             // whether hop 1 was in scope at all
verdict.gateway.failedChecks;          // the exact required checks that failed
verdict.bindingMismatches;             // route asked for vs route attested
verdict.contentVisibleToAnonRouter;    // true on a tee route

if (!atLeast(verdict.overallState, "cryptographically_checked")) {
  throw new Error(`route not established: ${verdict.reason}`);
}

Cross-binding is what this adds

Each hop's verifier only ever sees its own evidence, so neither can notice that the gateway attested itself perfectly while serving a different provider, model, or privacy class than you asked for. Any disagreement lands in bindingMismatches and forces untrusted, however strong the individual hops were. Two honestly-attested parties on the wrong route is still the wrong route.

The five states

Strictly ordered. Gate with atLeast() / at_least() rather than comparing strings, so a threshold keeps meaning the same thing if a state is later inserted into the scale.

Reaching hardware_verified

Neither package bundles a DCAP engine. Shipping prebuilt binaries would mean asserting that a binary we did not build reproducibly is the reviewed one, and a hand-rolled reimplementation would be an unreviewed version of the single component whose failure mode is printing hardware_verified for a forged quote.

What ships instead is a strict adapter to the reviewed engine, plus the Intel-signed collateral it needs (the engine performs no network access, on purpose). Install anonrouter-dcap-verifier, put it on PATH or name it in ANONROUTER_DCAP_VERIFIER_BIN, and hop 1 can reach hardware_verified.

import { createAnonRouterDcapVerifier, describeDcapInstallation } from "@anonrouter/confidential/dcap";

describeDcapInstallation();   // is one installed? which one? what is its digest?

const verdict = await client.verifyRoute({
  model, provider,
  gateway: { chainVerifier: createAnonRouterDcapVerifier() },
});

The adapter fails closed on every path: a missing engine, a digest that does not match the expected one, a timeout, a crash, non-JSON output, collateral it could not acquire, or a verdict whose measured report disagrees with the quote the SDK parsed. Without an engine the ceiling is cryptographically_checked, and a policy demanding hardware verification fails closed. It never silently downgrades.

End-to-end-encrypted chat

For an E2EE provider the SDK encrypts your prompt in your process, relays only ciphertext, and decrypts the reply locally. It verifies the enclave first and binds the encryption key to that attestation, so it will not encrypt to an enclave it could not verify.

const reply = await client.chat({
  model: "venice-uncensored",
  provider: "venice",
  messages: [{ role: "user", content: "Draft a private message." }],
  maxOutputTokens: 512,
  // Re-establish hop 1 with a NEW nonce before a ticket is spent: a verdict from
  // a minute ago is a fact about a minute ago.
  requireGateway: true,
});

console.log(reply.content);
console.log(reply.usage);

requireGateway / require_gateway runs the check before the first authenticated call, so a failure means no ticket was spent and no plaintext went near the wire.

Conversations are multi-turn and text-only. Because the enclave is stateless you re-send the conversation each turn and the SDK re-encrypts it fresh, exactly like any stateless chat API. Tool calls, images, and attachments are not part of the encrypted surface and fail closed.

Providers and ceilings

Chutes is the only post-quantum route. Tinfoil is TEE-only and reaches policy_matched through its official verifier (the optional tinfoil dependency); without it, Tinfoil verification fails closed.

The near-ai verifier is registered but the live catalog publishes no callable NEAR route, so nothing selects that provider today. The callable confidential set is Tinfoil, Venice, and Chutes.

Hop 2 does not reach hardware_verified on any provider: several of these routes run GPU enclaves whose NVIDIA attestation chain is not available to verify, and chaining only the CPU quote would claim more than was checked.

The security contract

• Independent re-verification. The SDK parses the raw TDX quote and provider evidence itself and checks it against pins shipped inside the package. It never turns a provider's verified: true, a model suffix, or the gateway's verdict into a proof.
• Fresh nonce, key binding. Every verification uses a fresh nonce and confirms the enclave bound its key to that nonce, so evidence cannot be replayed.
• Credential isolation. Your API key authenticates only content-free control requests. It is never sent to the origin that carries content.
• No escape hatch. There is no environment variable that weakens a verdict. The suites set a dozen plausible spellings of one (ANONROUTER_INSECURE, ANONROUTER_SKIP_VERIFY, NODE_ENV=test, CI=true, and so on) and require the verdict for the same evidence to come out identical, not merely also-failing.

Errors

Failures raise a typed ConfidentialError with a stable code — such as attestation_untrusted, nonce_mismatch, or inference_ticket_failed — and a content-free message. Error messages never carry prompt or key material by construction. Media errors subclass the same type.

Advanced use

Both packages export the building blocks, for callers who want to verify or decrypt without the high-level client:

• Pure verifiers per provider (NearTeeVerifier, VeniceTeeVerifier, ChutesTeeVerifier, TinfoilTeeVerifier) plus verifyRawEvidence.
• TDX quote parsing: parseTdxQuote, matchMeasurementAllowlist.
• Reviewed pins: pinnedMeasurementPolicyFor, pinnedGatewayPolicyFor.
• Low-level provider crypto: providerCrypto["near-ai" | "venice" | "chutes"] (JS) or anonrouter_confidential.crypto.{near,venice,chutes} (Python), exercised by the shared known-answer vectors.

Release artifacts

v0.1.0 is the first public release: implementation, reviewed measurement pins, gateway policies, and the shared known-answer vectors ship as one auditable set under Apache-2.0, with the DCAP verifier's source under AGPL-3.0-only in native/dcap-verifier. SHA256SUMS covers both npm tarballs, the wheel, the sdist, the reproducible linux/amd64 verifier binary, and both source archives. linux/amd64 is the only target with a reproducible artifact and the only one claimed.

Two things about it are worth knowing before you depend on it:

• The registry packages are not published. npm and PyPI both 404. Install from the release artifacts.
• The shipped gateway pin predates the running content plane. v0.1.0 pins the release that was live when it was tagged, and the plane has been released since. Hop 1 therefore fails closed against production on compose_hash_pinned and release_pinned rather than passing — which is the intended behaviour for a stale pin, but it means --require hardware_verified needs a --policy you reviewed yourself until a refreshed pin ships.