Start here: Evaluator

How-to / navigation hub. For the engineering leader or security buyer deciding whether humanymous Gate fits your stack.

humanymous Gate is a reverse proxy that sits in front of your origin app, scores each request across seven detection layers (static client, fingerprint, client integrity, behavior, network/protocol, cross-check, and scoring), and enforces a verdict at the edge before the request reaches your app. It does not emit a binary “bot / not-bot” flag: it produces a graded risk score from 0 to 100 and maps that score to one of three verdicts — ALLOW (pass to origin), CHALLENGE (serve an accessible proof-of-work interstitial; origin never contacted), or DENY (block; origin never contacted). Hard rules can override the score for high-confidence automation signatures. The honest limitation to weigh first: Gate raises the cost of automated traffic and challenges or blocks it, but it does not solve the T4 tier — anti-detect toolchains paired with real-human click-farms. That is an explicit design boundary: it is mitigated, not eliminated, by rate limiting, by reputation, and — on the routes you opt in — by the attestation floor of the attested preset, which prices a scoring-ALLOW on operator-marked high-value routes to a per-session human Pass solve or a possession proof rather than a free pass. None of the three removes the ceiling; they raise the cost of crossing it on the surface you care about most. Everything here is a reference implementation for evaluation, not a production-hardened build; treat measured latency and false-positive figures as reference-measured, and expect a prod-delta (ACME certificates, bring-your-own keys, and operational hardening) before you ship.

A verdict as it renders in the bundled /demo — the graded risk score and the hard rules behind a DENY, not a bare bot/not-bot flag:

A humanymous /demo verdict card showing a DENY decision with its risk score and contributing hard rules

Next 3 reads

Read these in order. Each builds on the last, and together they take you from “what is this” to “running it against my own traffic.”

  1. What Gate Is (and Is Not) — The scope, the design principles (defense-in-depth, cross-check-first, low false-positive, deterministic), and the T0–T4 attacker tiers, including where the T4 ceiling sits. Start here to calibrate expectations before you look at mechanics.

  2. Will This Break My App? — The false-positive and rollout story: how privacy browsers, extensions, and old devices are handled without being scored as bots, how the safe-GET fail-open works on balanced routes, and why you deploy monitor-first (score and log, enforce nothing) before you enforce anything.

  3. Quickstart (monitor mode, 30 min) — Stand up Gate in front of a test origin, watch it score real requests in the Ledger, and enforce nothing while you build confidence. This is the fastest way to see the graded score and the ALLOW/CHALLENGE/DENY model against your own traffic.

Tip: If you are evaluating with a security team, run monitor mode against a mirror of production traffic first. You get the full risk score and verdict stream in the audit log with zero enforcement risk to live users.

Read before you benchmark: Supported topologies explains why the numbers you measure depend on where you place it. The network plane (JA3/JA4/H2) only fires when the process terminates raw TLS itself — it is inert behind a CDN/L7-LB and absent at the cmd/gate proxy — so benchmarking the Core engine and deploying the gate, or sitting behind a CDN, measures a different detector than you deploy.