On-call quick reference card

Quadrant: Reference — a one-screen cheat sheet. Audience: SOC on-call, during and between incidents.

Fast lookup for a shift on humanymous Gate (the reverse-proxy enforcement layer, “Gate” after first mention). Scan it; do not read it. This is the reference build, not a production-hardened one. When you need the full procedure, jump to Incident runbooks and Kill switch & bans.

Verdict legend — what each does at the edge

Verdict Edge action Origin contacted?
ALLOW pass Yes
CHALLENGE challenge_pow — accessible proof-of-work (PoW) interstitial from the control plane No
DENY block No
none (Unknown, no evidence yet) fail-closed on strict routes or unsafe methods (POST/PUT/PATCH/DELETE) → challenge; fail-open only for safe GET/HEAD on non-strict routes Depends on the fail rule

Score bands (policy 1.0.0): 0–29 ALLOW · 30–69 CHALLENGE · 70–100 DENY. Hard rules override the score. A score-based CHALLENGE upgrades to ALLOW on l7.pow.solved; PoW never clears a hard rule. Every decision is written to the audit log before it takes effect.

Top hard rules to recognize

All DENY are high-confidence (FP~0): a spike means automated traffic is arriving — reading it as an attack is safe.

Rule Fires on Action Read a spike as
HR-1 Automation artifact (Selenium / Puppeteer / Playwright) DENY Attack
HR-9 CDP leak + automation hint DENY Attack
HR-19 One fingerprint across many subnets (residential-proxy rotation) DENY Attack
HR-20 AI browser-agent (teleport click + LLM cadence) DENY Attack
HR-21 Destructive flood / HTTP/2 DoS / rate-limit ban DENY Attack
HR-30 Decision-probing sweep: many sessions from one fingerprint DENY Attack
HR-12 No interaction over the observation window CHALLENGE Heuristic — can catch some real humans. Investigate before treating as attack volume.

Full table and signal-ID drill-down: Hard rules & verdicts.

The three levers — and who commits

Lever Endpoint Committer
Unblock (lift temp ban) POST /__hmn/admin/bans/lift Single Operator
Temp ban (1h/6h/24h) POST /__hmn/admin/bans Single Operator
Permanent / CIDR ban POST /__hmn/admin/bans → POST /__hmn/admin/approvals/<id> Distinct Approver (dual-control)
Kill switch (fleet-wide) POST /__hmn/admin/killswitch → POST /__hmn/admin/approvals/<id> Distinct Approver (dual-control)
Erasure (crypto-shred) (control plane) Distinct DPO (dual-control; generic Approver cannot)

The requester never self-commits a dual-control action, in either direction (placing or lifting). Actor identity is server-derived from the bearer token; body actor fields are ignored.

Warning: The kill switch is fleet-wide. It demotes hard-rule enforcement to monitor across every node — detection still scores and logs, manual bans still enforce, but traffic hard rules would DENY now reaches origin. Pull it for a customer-hurting false-positive storm, never to calm a real attack. Roll it back (also dual-control) the moment the cause is fixed.

Ban ladder & key choice

Auto-bans climb on repeat strikes, with strike decay downward:

1h → 6h → 24h → permanent

Source=auto = ladder placed it; Source=manual = you placed it. Active set: GET /__hmn/admin/bans.

  • fp:<fingerprint> — use for residential-proxy rotation (HR-19). The IP moves; the fingerprint is the stable handle.
  • ip:<addr> / cidr:<range> — use for a fixed hostile source (many fingerprints, one IP/range). Dual-control for CIDR.
  • Avoid ip: / cidr: against shared egress — CGNAT and corporate egress put real humans behind the same address. Prefer fp:-scoped action or let rate metering absorb it.

20-second: attack vs false-positive

  1. Which verdict spiked? DENY → lean attack. CHALLENGE → could be humans.
  2. Which rule? A high-confidence DENY rule (HR-1/9/19/20/21/30) firing → attack; act with bans. HR-12 (CHALLENGE, heuristic) climbing → suspect humans first.
  3. Are real users complaining? User reports of blocks/challenges on a legit path = false-positive signal. No reports + rising DENY = attack.
  4. Shared handle? Spike keyed to one fp: across subnets = HR-19 rotation (ban the fp:). Spike behind one NAT/carrier ip: = likely shared-egress false positive (do not IP-ban).
  5. Verdict: Attack → escalate bans, keep enforcement on. False-positive storm locking out customers → route-table demote + restart, or the fleet-wide kill switch. Unsure → run the triage in Incident runbooks before touching the switch.

Endpoints you’ll actually hit

Action Endpoint
Read decision feed / filter GET /__hmn/admin/audit (?verdict=&host=&route=&rule=&minRisk=&before=)
Verify chain integrity GET /__hmn/admin/integrity
Place a ban POST /__hmn/admin/bans
Lift a ban POST /__hmn/admin/bans/lift
Request kill switch POST /__hmn/admin/killswitch
Commit a dual-control request POST /__hmn/admin/approvals/<id> (find id: GET /__hmn/admin/approvals)

Console: https://localhost:8445/__hmn/admin/console (separate admin listener; 404 on the public edge). Bearer auth on every call — a missing/invalid token returns 404, which is deny-by-default, not a bug.

Note: Bodies — POST /bans {"Key","Reason","Incident","DurationSec"}; /killswitch {"On":true}; /bans/lift uses a ?key=<ban-key> query parameter, not a body. Full shapes: CLI, config & policy reference.

KPI & alert thresholds — a framework, not numbers

The Overview view surfaces KPIs computed from the audit stream (GET /__hmn/admin/audit), and the Integrity view re-verifies the chain. The reference build hardcodes no alarm thresholds. Set your own from a monitor-mode baseline; do not copy numbers from another deployment.

Watch three signals:

  • CHALLENGE / DENY mix — the ratio of verdicts over a window. A shift toward DENY leans attack; a shift toward CHALLENGE (especially HR-12-driven) leans false-positive.
  • DENY-rate deltas — change against your own baseline matters more than any absolute rate. Alarm on the delta, not a fixed count.
  • False-positive signal from user reports — blocks/challenges reported on legitimate paths. This is the counter-signal to a rising DENY rate and the trigger to suspect a misfire.

Note: Healthy vs alarm bands are operator-set. Establish them from your own monitor-mode baseline and tune per route.

TODO(verify): specific numeric healthy/alarm ranges for CHALLENGE/DENY mix and DENY-rate delta — none exist in the reference and none may be invented; each operator must derive them from their own baseline.

The Overview surfaces five KPI tiles, each a count over the recent window: Allow, Challenge, Deny, Ban actions (auto + manual), and Records (total events sealed into this node’s chain).