TunnelMind Data API

Live traction numbers computed from sources the Worker owns: the hash-chained D1 audit log (7-day call volume, distinct identified callers, top operations), the stored-receipt table, and Stripe (succeeded charges → paying customers, gross USD). Ed25519-signed with the same attestation envelope as /v1/status so the numbers can be replayed to an auditor. Use this tool when: - You are evaluating whether anyone actually uses and pays for this API. - You need a signed, re-checkable statement of usage rather than a claim. Returns: - `traction.usage`: calls_7d, identified_callers_7d, anonymous_calls_7d, top_operations_7d — or available:false with a reason. - `traction.receipts`: stored receipt counts (total / 7d). - `traction.revenue`: paying_customers, succeeded_charges, gross_usd, `truncated` flag when the Stripe page is partial. - `attestation`: Ed25519 signature over the canonicalized traction block. Cost: - Counts as one request against the daily rate limit. Cached 1h. Latency: - Typical: <100ms cached; up to ~2s on a cache miss (one Stripe read).

The reconciliation layer in one call. Where `cross_lens_verify` answers "what is this network destination," `verdict_lookup` answers a different, sharper question about a key-addressed ACTOR: **does what this key claims about itself match what the network has seen it do?** It fuses two sides: - **claim** — what the key can prove about itself: its `attestation_tier` across roots of trust (bare Ed25519 self-attestation → a RATS/EAT hardware/platform attestation). TunnelMind owns no silicon and reads every root; the tier is always *measured/anchored*, never self-asserted (a token claiming a higher tier than its trust anchor is trusted to assert is capped down). - **conduct** — what the graph has seen the key's subject do (Scry × Sigil × GhostRoute), supplied via the optional `subject` parameter. The response carries `reconciliation.contradictions` (e.g. a key that attests `silicon-root` but behaves as a low-trust node → `claim_exceeds_conduct`; a presented claim that fails to verify → `unverified_claim`; claims presented with no proof of key control → `key_control_unproven`), a `claim_vs_conduct_delta`, and a `verdict {tier, reputation, flags, confidence}`. Keys are linked to an identity ONLY when the actor cryptographically proves control — never inferred from behavioral correlation. An EAT that attests a *different* subject key is rejected, not silently merged. The verdict is published as a self-verifying receipt: given the receipt bytes + the witness public keys carried inline, anyone re-derives the verdict and checks log inclusion OFFLINE with `scripts/verify-verdict.mjs` — no call back to TunnelMind. A bare, unattested key still gets a verdict (at `self-asserted` tier); attestation is never required to participate.

Reconciles a claimed bot User-Agent against the operator's OWN published IP-range feed (Googlebot, GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, Perplexity-User, Bingbot). A User-Agent is trivial to forge; membership in the operator's published CIDR ranges is not. This exposes the common attack: a scraper sending `User-Agent: Googlebot` from an IP in none of Google's ranges. Use this tool when: - A request claims to be a search/AI crawler and you must decide whether to trust that claim before serving, allowing, or logging it. - You are separating genuine declared agents from impersonators. Inputs: - `ip` (path, required): the IPv4 or IPv6 address to check. - `ua` (query, optional): the claimed User-Agent string. Omit to ask only "is this IP a known published bot range?". Returns: - `verdict`: one of - `verified` — the IP is inside the agent's published range (UA, if given, agrees). It genuinely is that bot. - `spoofed` — the UA claims a verifiable bot but the IP is in none of its published ranges. Impersonation. - `mismatch` — the IP is a real bot's range, but the UA names a different bot. - `unverifiable` — the UA names a real agent whose operator publishes no authoritative IP feed (e.g. Anthropic's ClaudeBot). Neither confirmed nor denied — never reported as spoofed. - `unknown` — no recognized bot UA and the IP is in no known range. - `is_verified_agent`, `is_spoofed`: booleans for the two actionable cases. - `agent`, `agent_label`, `matched_agent`, `claimed_agent`: the resolved identities. - `reason`: one-line explanation of the verdict. - `feeds_as_of_ms`: when the published ranges were last refreshed. Cost: - Counts as one request against the daily rate limit. Latency: - Typical: <50ms (one KV read + CIDR match). First call after a deploy may take ~1s if it has to warm the range cache.

Neutral third-party Web Bot Auth verification. An origin — or the PDP deciding for it — received a request from a claimed agent carrying the Web Bot Auth headers (Signature, Signature-Input, Signature-Agent). Relay those headers here, plus the authority the request was addressed to, and TunnelMind verifies the Ed25519 signature against the agent's own published key directory (https://<agent>/.well-known/http-message-signatures-directory). Facts, not a verdict: `state: verified` means "this signature cryptographically verifies against that directory" — whether to trust the agent behind it is your policy engine's call. Use this tool when: - A request claims a cryptographic agent identity (Signature-Agent header present) and you must check the claim before serving it. - You want signature verification independent of your CDN — or you are not behind a CDN that implements Web Bot Auth at all. Inputs (JSON body): - `signature` (required): the received Signature header value. - `signature_input` (required): the received Signature-Input header value. - `signature_agent` (required): the received Signature-Agent header value (quoted https origin). - `authority` (required): the host the request was addressed to. - `method`, `path`, `scheme` (optional): only needed if the signature's covered components include them. Returns: - `state`: one of - `verified` — Ed25519 signature verifies against a key in the agent's published directory. - `invalid_signature` — key found, signature does not verify (tampered or forged). - `unknown_key` — directory reachable but contains no key with the claimed thumbprint. - `directory_unreachable` — the claimed key directory did not answer; an honest degraded state, not evidence of forgery. - `expired` — the signature's `expires` timestamp has passed. - `malformed` — headers do not parse as a Web Bot Auth signature, or the signature does not cover `@authority` and `signature-agent`, lacks `created`/`ex…

Tamper-detection verification for TunnelMind surveillance receipts. Submit the receipt ID, the SHA-256 content hash, and the Ed25519 signature from the receipt document. The registry compares these against what was recorded at issuance time. Returns VALID if both match exactly, INVALID with a specific mismatch reason otherwise. Use this tool when: - You received a surveillance receipt document and want to verify it hasn't been altered. - You are programmatically checking receipt authenticity in an agent workflow. - You want to prove to a third party that a receipt is genuine. Do NOT use this tool when: - You only want to check existence — use `get_receipt` instead (no body required). Inputs: - `receipt_id` (body, required): The receipt's ID field from the document. - `content_hash` (body, required): SHA-256 hex hash of the receipt JSON. Max 256 chars. - `signature` (body, required): Ed25519 signature from the receipt document. Max 512 chars. Returns: - `valid`: boolean. True only if both hash and signature match exactly. - `status`: `VALID` or `INVALID`. - `message`: human-readable explanation. On INVALID, specifies whether the hash mismatched, the signature mismatched, or both. Cost: - Free. No API key required. Latency: - Typical: <100ms, p99: <300ms.

Validates an agent's x402 v1 client implementation against a TunnelMind surface end-to-end. Two operating modes: - `mode: "demo"` — HMAC over a nonce against a publicly-published secret. Does not move USDC. Smoke proves the WIRE works, not money movement. - `mode: "x402"` — real Coinbase facilitator dispatch (gated on operator wallet provisioning; currently returns "facilitator not configured"). Without an `X-PAYMENT` header, the endpoint returns HTTP 402 with a standards- compliant `accepts[]` array (USDC on Base, $0.001). With a valid `X-PAYMENT` header (base64-encoded payment payload), echoes the request body and returns an `X-PAYMENT-RESPONSE` settlement header. Use this tool when: - You are validating your agent's x402 v1 client implementation against a real public endpoint. - You want to demonstrate the full 402 → retry → settle wire end-to-end. Do NOT use this tool when: - You need a real paid operation — no TunnelMind production endpoint is gated behind x402 yet. Inputs: - `X-PAYMENT` (header, optional): base64(JSON) per the x402 v1 spec. Without it, a 402 challenge is returned. - Request body (optional): any JSON object to be echoed back on successful payment. Returns: - On no header: HTTP 402 + `{ x402Version, accepts: [...] }`. - On valid payment: HTTP 200 + `{ ok: true, data: { echoed, paid_micro_usdc, x402 } }` and an `X-PAYMENT-RESPONSE` header carrying the settlement record. - On invalid payment: HTTP 402 + `{ error: "invalid payment", reason }`. Discovery: - `https://tunnelmind.ai/.well-known/x402.json` carries the public demo secret and the HMAC construction recipe. Cost: - Free in demo mode (no USDC moved). $0.001 USDC in real-mode (when activated). Latency: - Typical <100ms (demo mode); real mode is bounded by facilitator latency.