This post walks through how each layer works, how they combine into a single threat score, and why this architecture catches bots that simpler approaches miss. It's a WordPress plugin, but the scoring design applies to any request pipeline.

The Detection Pipeline

Every request flows through a pipeline that evaluates it before WordPress processes it:

Incoming Request
  │
  ├─ Is this IP blocked? → Yes → Block page
  │
  ├─ Is this a known good bot? → Verify via reverse DNS → Allow
  │
  ├─ Server-side analysis
  │    ├─ User-Agent patterns
  │    ├─ HTTP header consistency
  │    ├─ MITRE ATT&CK path matching
  │    └─ Rate limit check
  │
  ├─ Client-side signals (on form submission)
  │    ├─ WebDriver / headless detection
  │    ├─ Automation framework markers
  │    ├─ Canvas / WebGL fingerprint
  │    └─ Behavioral scoring
  │
  ├─ Proof-of-Work verification (on form submission)
  │    └─ SHA-256 challenge validation
  │
  └─ Score aggregation → Allow / Challenge / Block

The first two checks are fast exits. Blocked IPs get rejected immediately. Verified good bots skip detection entirely. Everything else gets scored.

Threat Scoring: 0 to 100

Every detection signal adds points to a threat score. The score determines what happens to the request:

The default blocking threshold is 75, configurable in settings. Scores at 40 and above are logged for review.

The scoring is additive. A request doesn't need to fail one dramatic test — it accumulates evidence across multiple signals. A slightly suspicious user agent (+25) combined with missing cookies (+15) and an unusual request path (+20) adds up to 60, enough to trigger a challenge. No single signal is conclusive, but the combination tells a clear story.

Base scores for common signals:

Missing standard headers:      10-30
No cookies on non-first visit:    15
Suspicious user agent:            25
Known bot user agent:             50
curl / wget / python-requests:    35
Automation tool detected:         40
Headless browser markers:         25
Rate limit exceeded:              25
Honeypot field triggered:         60
Fake bot (failed DNS verify):     80

A real Chrome browser hitting a normal page scores near zero. A Python script with a spoofed user agent, no cookies, and missing standard headers quickly crosses the blocking threshold.

Server-Side Analysis

User-Agent and header consistency

The plugin checks the User-Agent against known bot patterns (curl, wget, python-requests, Go-http-client, scrapy, and dozens more) and evaluates header consistency. Real browsers send a predictable set of headers — Accept, Accept-Language, Accept-Encoding, Connection — in a consistent order. Automated tools frequently omit headers or send them in unusual combinations.

Missing Accept-Language is a strong signal. Every real browser sends it. Most HTTP libraries don't unless explicitly configured.

MITRE ATT&CK path matching

This is one of the more distinctive pieces. Rather than maintaining an arbitrary blocklist of "bad" URLs, detection is organized by attacker tactic:

Credential Access (TA0006):
  .env, wp-config.php, .git/, *.sql         → +30 points

Collection (TA0009):
  Backup files, database dumps              → +25 points

Reconnaissance (TA0043):
  Admin probes, user enumeration            → +20 points

Discovery (TA0007):
  Debug endpoints, phpinfo, server-status   → +20 points

When an IP requests /wp-config.php.bak, then /.env, then /.git/config, each request scores individually while the rate limiter tracks velocity. The combined effect is rapid escalation to the blocking threshold.

The mapping isn't only for scoring. It surfaces in the detections table, so you can see a blocked IP was performing credential access reconnaissance rather than just "requesting bad URLs." The categorization tells you what attackers are actually looking for.

Rate limiting

Tracks requests per IP with a configurable window (default: 60 requests per 60 seconds). Exceeding it adds 25 points and can trigger automatic blocking.

The limiter uses the WordPress database for tracking, so it works behind load balancers and CDNs as long as the real client IP is forwarded in a standard header (X-Forwarded-For, X-Real-IP, or CF-Connecting-IP).

Client-Side Detection

The server-side layer catches unsophisticated bots. The client-side layer targets headless browsers, automation frameworks, and tools that spoof headers but can't perfectly replicate a real browser environment.

A scanner script loads with defer so it never blocks rendering, runs environment checks, and submits results alongside form data.

WebDriver detection — the simplest check. Selenium, Puppeteer, and Playwright all set navigator.webdriver = true by default. Stealth plugins override this, but it still catches unmodified tooling.

Headless markers — HeadlessChrome in the UA string, missing chrome.runtime and chrome.app objects (present in real Chrome, absent in headless), PhantomJS signatures on window.

Chrome consistency — a request claiming Chrome should have the chrome global with chrome.runtime, chrome.app, chrome.csi. If the UA says Chrome but these are missing or structurally wrong, the environment has been tampered with.

Behavioral scoring

For form submissions, the plugin evaluates how the user interacted with the page. This is where most sophisticated bots fail, because generating convincing human behavior at scale is genuinely hard.

Behavioral signals (40% weight):
  - Mouse velocity variance
  - Straight-line movement ratio
  - Micro-tremor score (natural hand movement)

Environmental signals (35% weight):
  - Headless browser markers
  - Automation framework detection
  - Browser API consistency

Temporal signals (15% weight):
  - Time on page before submission
  - Form completion velocity
  - Session duration

Form signals (10% weight):
  - Honeypot field triggers
  - Field completion order
  - Paste detection

Mouse velocity variance is particularly effective. Humans move with variable speed — accelerating, decelerating, overshooting, correcting. Bots that simulate movement typically use linear interpolation or simple easing functions, producing unnaturally smooth velocity profiles.

Straight-line movement ratio measures what percentage of movements travel in perfectly straight lines. Humans almost never do, because of micro-tremors and natural imprecision.

Micro-tremor score looks for the tiny involuntary oscillations present in all human hand movement. These have characteristic frequency patterns that are difficult to simulate; their absence suggests input generated by code.

Honeypot fields, rotated daily

Invisible form fields real users never see. If a field receives a value, the submission came from a bot that filled every input on the page.

What makes the implementation interesting is the obfuscation. Instead of obvious names like honeypot or trap, the plugin generates legitimate-looking field names that change daily:

// Field names rotate using a daily seed
// Examples of generated names:
//   contact_name, user_email, address_field, phone_number
// CSS class prefixes mimic common form frameworks:
//   form-, input-, wp-, cf-, gform-, ninja-

Daily rotation stops bot operators hardcoding a skip-list of honeypot names. The realistic naming defeats bots that filter for obvious trap patterns.

Proof-of-Work Challenges

The layer that makes automated attacks economically painful even when bots pass everything else.

When a form loads, the server generates a challenge: a random hex prefix and a difficulty parameter. The client must find a nonce where SHA-256(prefix + nonce) starts with N zero hex characters. There's no shortcut — it's brute force.

Server generates:
  prefix:      "a7f3c8e91b04d265"   (16 hex chars from 8 random bytes)
  difficulty:  4                     (requires 4 leading zero hex chars)
  expires:     current_time + 5 minutes
  signature:   HMAC-SHA256(challenge_data, wordpress_auth_key)

Client computes:
  nonce = 0:  SHA-256("a7f3c8e91b04d265" + "0") = "7f2a..."   (fail)
  nonce = 1:  SHA-256("a7f3c8e91b04d265" + "1") = "b391..."   (fail)
  ...
  nonce = N:  SHA-256("a7f3c8e91b04d265" + "N") = "0000a..."  (pass)

Client submits:  { challengeId, nonce, signature }

At difficulty 4, the client tries roughly 65,536 hashes on average — milliseconds on modern hardware, entirely in the background while the user fills out the form. They never see it.

Why it stops bots: a single challenge is trivial, but the economics change at scale. A bot submitting 10,000 spam comments needs 10,000 challenges — about 655 million hash operations. Achievable, but it costs real compute.

Difficulty also scales with threat signals. An IP already flagged by server-side analysis gets harder challenges. Default difficulty 4 is intentionally low for normal users; suspicious traffic might face difficulty 6, roughly 16 million hashes per challenge.

Replay prevention

Each challenge carries an HMAC signature generated with WordPress's AUTH_KEY salt. The server verifies the signature before checking the hash, which prevents:

• Challenge reuse — each challenge ID is single-use

• Challenge tampering — difficulty and prefix are signed, so they can't be modified

• Challenge forging — without AUTH_KEY, valid signatures can't be generated

• Stockpiling — a 5-minute TTL kills pre-solved challenges

Signing rather than storing means the server never writes issued challenges to the database. That keeps the table clean and removes a DoS vector where an attacker floods the challenge endpoint to fill storage.

Good Bot Verification

Not all bots are bad. Googlebot, Bingbot, and 60+ other legitimate crawlers need unimpeded access for indexing, previews, uptime monitoring, and SEO tooling.

Search engines:   Googlebot, Bingbot, YandexBot, Baiduspider,
                  DuckDuckBot, Applebot
Social:           Facebook, LinkedIn, Twitter, Pinterest
Monitoring:       Pingdom, UptimeRobot, StatusCake, Datadog
SEO tools:        Ahrefs, SEMrush, Moz, Majestic
Feed readers:     Feedly, NewsBlur
AI crawlers:      GPTBot, ClaudeBot, PerplexityBot (optional blocking)

For verifiable bots, the plugin does forward-confirmed reverse DNS:

1. Look up the requesting IP's hostname via reverse DNS

2. Check the hostname ends with a verified domain (.googlebot.com, .google.com)

3. Forward-resolve that hostname back to an IP

4. Confirm it matches the original requesting IP

A fake Googlebot scores +80 — an instant block — because spoofing a search crawler is a strong signal of intent. Results cache in WordPress transients with a 1-hour TTL to avoid repeated lookups.

This matters more than it sounds: matching Googlebot in a User-Agent string and allowing it is a bypass, not an allowlist. Anyone can send that string.

WooCommerce: carding defense

Attackers test stolen card numbers against real checkout flows. Every failed transaction generates processor fees, and a high decline rate can get your payment processing suspended.

Checkout velocity limiting — configurable max checkout attempts per IP per window (default: 5 per hour). Legitimate shoppers rarely attempt checkout more than once or twice. An IP submitting 20 attempts in an hour is testing cards.

Card testing pattern detection — multiple different card numbers from one IP, rapid sequential attempts, and headless signatures on the checkout page all trigger detection, blocking before further transactions reach the processor.

Compatible with classic checkout and WooCommerce Blocks, and declares HPOS (High-Performance Order Storage) compatibility.

Architecture decisions worth calling out

No external dependencies for core protection. The entire detection engine runs on your server. No API calls during request processing, no third-party JavaScript on the frontend. Protection works during API outages, on airgapped installs, and at any traffic volume without per-request costs. Even the admin dashboard's charting library is bundled into the plugin rather than pulled from a CDN, so the plugin makes zero external connections unless you explicitly add a Cloud API key.

Additive scoring over binary decisions. Every signal adds to a score rather than making a pass/fail call. This dramatically reduces false positives: a single suspicious signal might be coincidence, five together are a pattern. No single check that misfires can block a legitimate user on its own.

Daily rotating honeypot names. Static names get learned and skip-listed. Seeded rotation changes them daily while staying deterministic, so the server can verify which fields are honeypots without storing state.

HMAC-signed challenges instead of stored ones. The signature itself proves the challenge is legitimate and unmodified — no database writes, no storage-exhaustion vector.

Getting started

wp plugin install webdecoy --activate

Or: Plugins → Add New → search "WebDecoy" → Install → Activate.

Defaults (sensitivity medium, block threshold 75, rate limit 60/min, PoW difficulty 4) work for most sites. Requires WordPress 6.1+ and PHP 7.4+. GPL-licensed.

If you're building request scoring in any stack, the transferable idea here is the additive model: resist the urge to make any single signal decisive, and let evidence accumulate instead. It's the difference between a detector that's occasionally spectacularly wrong and one that's boringly right.

How do you handle bot scoring — hard rules or weighted signals? Curious what thresholds other people have landed on.

Originally published at webdecoy.com.

Related reading:

• Proof-of-Work CAPTCHAs with Hashcash

• Headless Browser Detection: Playwright, Puppeteer, Selenium

• Mapping Honeypot Detections to MITRE ATT&CK

A missed scraper costs bandwidth or content. A blocked customer costs a sale, a support escalation, and trust that took months to earn. Which is why a bot detection benchmark cannot stop at a single accuracy number. It has to answer a harder question: what happens to real people when this policy leaves the dashboard and starts controlling traffic?

A false positive is a business event

In bot detection, a false positive is legitimate traffic classified as automated. The technical label matters; the consequence matters more. The same wrong classification produces very different outcomes:

An aggregate false-positive rate hides these differences. A vendor can report a low global rate while causing concentrated damage on one browser, one mobile network, or one high-value route.

So the useful question is not "what is the false-positive rate?" It is: how many known-human sessions did this rule challenge or block on each protected route, and what happened next?

Accuracy is usually the wrong headline metric

Bot traffic is a class-imbalanced problem. Most requests on a customer-facing app are legitimate; the attacks worth stopping are a small slice. In that setting a large accuracy percentage can describe a weak detector.

Suppose a site receives 100,000 requests:

• 99,000 are legitimate

• 1,000 are automated attacks

• The detector catches 900 attacks

• It also flags 200 legitimate requests

The detector is 99.7% accurate. That sounds excellent. It is also blocking or challenging 200 real requests, missing 100 attacks, and producing a bot verdict that is wrong almost one time in six.

Use a small set of metrics together instead:

Precision           = true bot detections / all bot detections
Recall              = true bot detections / all actual bot attempts
False-positive rate = false bot detections / all known-human requests

In the example: precision 81.8%, recall 90%, false-positive rate ~0.2%. At one million legitimate requests per day, that last number is about 2,000 customer requests per day receiving the wrong treatment.

Google's classification metrics guide makes the tradeoff clear: changing a threshold changes all three. There is no threshold you can evaluate independently of the cost of each kind of mistake.

Which usually leads to three operating goals:

• Hard blocks favor precision. The evidence should be strong enough that a human is very unlikely to match it.

• Challenges balance precision and recall. They provide a recovery path for ambiguous traffic.

• Monitoring favors recall. A broad signal is fine when a person or later rule reviews it before enforcement.

One score should not control all three actions.

Build a benchmark that resembles production

A clean lab set with one Chrome version and a few obvious Selenium scripts proves the code runs. It does not establish that the detector is safe for customers. Build from three label groups.

Known-human traffic

Strong human labels come from successfully authenticated sessions, completed purchases that were not reversed, support-confirmed sessions, or employees following a controlled test plan. None is perfect alone — the point is traffic with independent evidence that a real person completed a meaningful action.

Keep the sample representative across:

• Desktop and mobile browsers

• Older devices and slow connections

• Corporate networks, universities, and carrier-grade NAT

• VPNs and privacy tools your customers actually use

• Assistive technology and keyboard-only navigation

• Logged-in customers, anonymous visitors, and partner users

• Every route where the policy may eventually enforce

If the known-human set contains only employees on recent MacBooks, the benchmark is measuring employee laptops, not customers.

Known automation

Run controlled clients with Playwright, Puppeteer, Selenium, curl, and any stack relevant to your app. Include slow bots, distributed low-volume clients, headless browsers, and scripts carrying realistic headers.

Trusted automation belongs in the set too. Search crawlers, uptime monitors, accessibility scanners, payment callbacks, and partner integrations are automated — that does not make them hostile.

Unknown traffic

Leave genuinely ambiguous traffic labeled unknown. Do not call every session that failed to convert a bot, and do not call every session that passed a JavaScript check human. Those shortcuts make the detector's own assumptions part of its ground truth.

Freeze the policy during each test

Record the exact configuration behind every verdict: engine version, rule and threshold version, signals that fired, score and proposed action, route group, session identifier, timestamp, allowlist decision.

If thresholds change halfway through a test without a version marker, your final precision number combines two different systems.

{
  "policy_version": "checkout-2026-09-01.1",
  "route_group": "checkout",
  "score": 72,
  "would_action": "challenge",
  "signals": ["headless_mismatch", "velocity_anomaly"],
  "identity": "unverified",
  "outcome": "purchase_completed"
}

The important field is outcome. Without it you can count detections but cannot tell whether a proposed action would have interrupted a customer.

Start in shadow mode

Shadow mode evaluates every request but does not change the response. A request that would have been challenged gets the normal page; a request that would have been blocked reaches the application. The proposed action and its evidence are logged.

This is the safest place to tune thresholds, because the detector sees real traffic while mistakes stay observable rather than customer-facing. For every route group, answer:

1. How many sessions would have been allowed, challenged, or blocked?

2. How many would-block sessions later logged in, purchased, submitted a valid form, or called an authenticated API?

3. Which rules contribute most of the false-positive candidates?

4. Are errors concentrated by browser, device, geography, ASN, customer, or integration?

5. How much attack traffic would each threshold miss?

Don't declare victory after a quiet afternoon. The sample should span weekday and weekend behavior, billing cycles, product launches, and campaigns.

The rule of three

The absence of an observed false positive is not proof the true rate is zero. A useful rough check: if a test observes zero errors in N independent known-human sessions, the upper edge of a rough 95% confidence interval is about 3/N.

Zero errors in 1,000 sessions only supports a rate below roughly 0.3%. Zero errors in 100,000 sessions supports a much tighter claim. Report counts beside rates so a reader can tell whether "100% recall" means 2 of 2 attacks or 20,000 of 20,000.

Test low-volume attacks without fooling yourself

A credential stuffer sending two attempts per IP per day never creates an obvious spike. A scraper taking one page every few minutes blends into human traffic. If the positive class holds only a handful of confirmed attacks, one mislabeled session swings precision dramatically.

• Extend the observation window. Collect enough normal traffic to see rare customer conditions, and enough attack traffic to be more than a one-day anecdote.

• Replay known attacks. Recorded sequences let you compare policy versions against identical inputs. Keep replay results separate from live ones — a recording can't reproduce every timing and network condition.

• Run controlled red-team traffic. Throttle your own automation to the rate a real attacker would use. Use realistic sessions and route order instead of hammering one endpoint.

• Measure evidence, not just volume. A low request rate doesn't erase other evidence: failed identity verification, a composite fingerprint reused across accounts, a decoy link followed, an impossible field submitted, machine-like workflow consistency. Rate should be one signal, not the whole detector.

Verify good bots before you allow them

A crawler allowlist reduces false positives only if it verifies identity. Matching Googlebot in a User-Agent creates a bypass, because any client can send the same text — Google's own documentation warns the User-Agent is commonly spoofed and recommends verifying via published IP ranges or reverse DNS with forward confirmation.

Declared identity
    -> verify source or signature
        -> verified:    apply the crawler or partner policy
        -> failed:      treat as impersonation evidence
        -> unavailable: keep unverified, avoid claiming certainty

Don't turn a failed lookup into an automatic block if the source data may be stale. Record why verification failed and choose a route-appropriate fallback — public content can often fail open, sensitive APIs may require a service token.

Shared IP addresses break simple enforcement

An IP address is a network location, not a person. One address may represent an office, university, hotel, mobile carrier, VPN exit, or large customer integration. One abusive client behind that address does not make every other client hostile.

This is exactly why an IP-only block looks accurate in a lab and fails in production: the test environment assigns one address per client, while production puts thousands of unrelated sessions behind one egress point.

Treat IP reputation and request rate as context. Correlate with session evidence, authentication state, route, TLS and browser characteristics, and behavior. When uncertainty remains, challenge the session rather than blocking the address.

Test rate limits from a shared-network simulator: send legitimate traffic from many independent sessions through one source address, then add one abusive session. The desired result is not "the attack stopped." It is "the attack stopped while the other sessions continued."

Move from shadow mode to a canary

Once shadow results meet the route's safety threshold, enforce on a small, stable cohort. Assignment should be sticky by session or account so the same visitor doesn't bounce between control and enforcement on every request.

1. Shadow everything. Collect proposed actions and business outcomes.

2. Canary challenges. Challenge a small percentage of ambiguous sessions on one route group.

3. Enforce high-confidence evidence. Block deterministic abuse, or sessions that repeatedly fail the recovery path.

4. Expand by route. Increase exposure only after guardrails stay healthy.

5. Keep a control group. A small untreated cohort keeps conversion and support impact measurable.

Start with an action that can recover. A challenge lets a misclassified human prove the detector wrong and continue. A hard block provides no such information unless the customer opens a ticket.

Define rollback triggers before the canary begins:

• Login success falls beyond the agreed tolerance

• Checkout completion drops relative to control

• Challenge abandonment rises for one browser or device class

• Support contacts mention access failures

• A major customer or partner appears in the would-block cohort

• Latency exceeds the route's budget

If a trigger fires, return the cohort to monitor mode, preserve the evidence, and investigate the contributing rule. A rollback is a successful safety mechanism, not a failed launch.

Measure conversion impact directly

Security metrics cannot tell you whether customers are being harmed. Join the enforcement decision to product outcomes using a privacy-conscious session or account key.

For a trial signup flow: landing-to-signup-start rate, signup-start to account-created rate, challenge pass and abandonment rates, time to complete the form, validation and retry errors, support requests about access.

Compare the canary with its concurrent control group. Do not compare launch week against last month's average if traffic source, promotions, device mix, or seasonality changed at the same time.

And segment the results. An overall conversion rate can stay flat while Safari users, one mobile carrier, or a single enterprise customer's corporate proxy experiences a serious regression.

Set thresholds from cost, not confidence theater

A score of 90 is not automatically safe to block. It is only meaningful if you know what generated it, how that evidence performed on representative traffic, and what a mistake costs on the current route.

Review thresholds after browser releases, mobile app updates, WAF changes, major customer onboarding, and attacker shifts. A benchmark is not a certificate that lasts forever. It is a repeatable process for finding regressions before customers do.

Production readiness checklist

• [ ] Known-human traffic covers important browsers, devices, networks, and customers

• [ ] Known automation includes trusted crawlers, partners, monitors, and hostile test clients

• [ ] Unknown traffic remains unknown rather than forced into a convenient label

• [ ] Every verdict records the policy version and contributing evidence

• [ ] Precision, recall, and false-positive rate are reported together

• [ ] Metrics are broken down by route and customer-impact level

• [ ] Shared-IP and corporate-proxy scenarios are included

• [ ] Trusted bots are verified rather than matched by User-Agent alone

• [ ] Shadow mode connects would-block decisions to product outcomes

• [ ] Canary and control cohorts are stable and comparable

• [ ] Challenges provide a recovery path for ambiguous traffic

• [ ] Hard blocks expire and can be reversed quickly

• [ ] Rollback triggers are written before enforcement starts

• [ ] Conversion, support, and latency guardrails are monitored

If several answers are no, keep the system in shadow mode. More traffic is not going to make an unmeasured policy safer.

The benchmark is the product

Bot detection accuracy is not one percentage in a sales deck. It is a body of evidence showing what the system catches, what it misses, which real users resemble automation, and what happens when a decision becomes an action.

The safest rollout is deliberately uneventful. Observe first. Label carefully. Verify trusted automation. Challenge uncertainty. Block strong evidence. Measure the customer journey at every step.

That process feels slower than turning on a global block rule. It is much faster than discovering your false-positive rate through lost checkouts and angry customers.

Has anyone here actually run a shadow-mode rollout end to end? Curious what your would-block cohort looked like the first week — ours is always more embarrassing than expected.

Originally published at webdecoy.com.

Related reading:

• Browser Fingerprinting 2026: What Still Works

• Headless Browser Detection: Playwright, Puppeteer, Selenium

An agent may need to discover a tool, prove which workload is running, authenticate an HTTP request, show that a user delegated authority, and leave enough evidence to reconstruct the action later. ARD, workload identity, Web Bot Auth, and OAuth solve different parts of that sequence. Treating any one of them as the whole answer creates an identity gap.

That distinction got sharper in 2026. Google announced the open Agentic Resource Discovery specification for finding and verifying agentic capabilities, and a separate IETF Internet-Draft on AI agent authentication proposed an architecture for agent credentials, delegated user authority, workload identity, authorization, and audit trails.

Neither replaces OAuth. Neither makes a signed bot trustworthy. Together they show what a serious agent identity architecture has to look like.

Four layers, four questions

There is a fifth layer underneath all four: observability. If an operator cannot connect the discovery result, workload credential, user delegation, authorization decision, tool call, and final side effect, the system is not meaningfully auditable.

Why API keys and user-agent strings aren't enough

Traditional web automation has two identity mechanisms: a User-Agent header that names the bot, and an API key that grants access.

The first is a claim anyone can copy. The second is usually both an identity credential and a bearer permission compressed into one long-lived secret. If that key leaks from a log, environment variable, container image, or agent transcript, whoever holds it inherits its authority.

AI agents make this worse, because one action involves several distinct principals:

• The agent operator — owns or deploys the software.

• The running agent workload — needs its own stable identity and credentials.

• The delegating user or system — whose authority the agent may be exercising.

• The resource owner — decides what that combination may do.

Collapsing those into one API key destroys the information an authorization engine needs. It also produces an audit record that says only "the key did it" — not which workload ran, who authorized it, what constraints applied, or where authority changed hands.

The July 2026 IETF draft starts from a useful premise: agents are workloads. They should receive cryptographic credentials at runtime, authenticate as themselves, carry delegated authority separately, and preserve both identities through the call chain.

Layer 1: ARD discovers capabilities before invocation

Agentic Resource Discovery addresses a problem that appears before authentication: how does an agent find the right tool, API, MCP server, A2A agent, or nested catalog without relying on a closed directory or hard-coded endpoint?

ARD uses domain-hosted catalogs and federated discovery. A publisher describes resources and attaches trust metadata; a consumer discovers a candidate, verifies the published information, then connects through the resource's native protocol.

The boundary matters. ARD is deliberately pre-invocation infrastructure. It can answer:

• Which domain claims this capability?

• Where is its endpoint and protocol description?

• What trust material did the publisher provide?

It cannot answer:

• Is this calling process the agent it claims to be?

• Did a user authorize this transaction?

• Is the requested action within policy?

Put differently: verified discovery metadata is not a runtime access token. It establishes a trusted starting point; the resource must still authenticate and authorize the caller.

ARD is still evolving — the spec repository described v0.91 as an evolving specification. Version your catalogs and don't treat today's fields as permanently fixed.

Layer 2: workload identity proves which agent is running

After discovery, the caller needs a real identity. The strongest model is not "read a secret from an environment variable." It is "attest this runtime and issue a short-lived credential to the workload that passed attestation."

The agent has a stable identifier; its credentials are temporary and rotated. Issuance can be bound to the cluster, namespace, service account, image, execution environment, or deployment policy.

SPIFFE is the mature example: a workload receives a SPIFFE ID and a short-lived SVID (X.509 or JWT) through the Workload API, then uses that identity for mTLS or application-level auth without shipping a long-lived secret beside the code.

The architectural requirements that matter:

• Give the agent a stable workload identifier.

• Provision primary credentials at runtime.

• Prefer short-lived, automatically rotated credentials.

• Keep credentials out of source code, images, prompts, and static config.

• Authenticate the agent independently from the user it represents.

This is useful even when no human is involved. A scheduled research agent or autonomous monitoring service still needs its own identity so policy can distinguish it from every other workload.

Layer 3: Web Bot Auth proves an automated HTTP caller

Workload identity fits naturally inside an organization. The open web has a different problem: a site receives an HTTP request from a crawler it does not operate. The request claims a name; the origin needs evidence the claim belongs to the operator.

Web Bot Auth profiles RFC 9421 HTTP Message Signatures so automated clients sign request components and servers verify using public keys associated with the operator.

A valid signature proves:

• The request was signed by the holder of the corresponding private key.

• Protected components were not changed after signing.

• The signature was created within its validity window.

• The identity claim ties to an operator-controlled key.

It does not prove:

• The agent is benevolent.

• The operator has a business relationship with the site.

• A user consented to the requested action.

• The request should bypass rate limits or bot controls.

• The signer is entitled to read, purchase, modify, or delete anything.

That last distinction is the most important one in this whole article: authentication is evidence for an authorization decision, not the decision itself.

A practical note on deployment: most automated traffic is still unsigned. Web Bot Auth upgrades a spoofable user-agent claim into verifiable request identity where it's present, but if you build a policy that assumes signatures, you will be building for a tiny slice of your actual traffic. Design for graceful fallback — operator-published IP ranges and forward-confirmed reverse DNS where available, and treat a bare user-agent string as unproven, not as identity.

Layer 4: OAuth carries authority, including user delegation

Once an agent is authenticated, a resource still needs to know what it may do. Two materially different cases:

The agent acts on its own authority. It obtains a narrowly scoped access token through a machine-to-machine grant, authenticating to the authorization server with its workload credential — not a static, long-lived client secret. The resulting token should be short lived, audience-restricted, minimally scoped, bound to the authenticated client where supported, and revocable without rebuilding the agent.

The agent acts for a user. Now the system must preserve two identities: the agent as the OAuth client, and the delegating principal as the subject. The user grants authority through an interactive flow; the agent separately authenticates with its workload credential.

The resource should be able to answer both:

1. Which agent exercised the authority?

2. Which user or system delegated it?

That separation limits the confused-deputy problem, and it prevents an audit record from falsely attributing an automated action directly to a human.

For multi-service workflows, OAuth 2.0 Token Exchange (RFC 8693) lets a security token service swap one token for another with a different audience or reduced authority. Every hop should narrow or preserve authority; no downstream tool should silently gain a broader token than the initiating agent received. Current OAuth security guidance is consolidated in RFC 9700 — follow it rather than reviving weaker historical patterns because the client happens to be autonomous.

An end-to-end flow

1. Discover. Query an ARD catalog; receive a candidate capability, endpoint, protocol description, trust metadata.

2. Verify discovery. Validate the publisher before connecting. Discovery results are untrusted input until verified.

3. Attest the workload. The runtime proves where and how the agent is running; the identity system issues a short-lived credential bound to its stable identifier.

4. Authenticate the connection or request. mTLS or a WIMSE proof inside a trust domain; Web Bot Auth at a public website boundary. Bind the credential to the actual request or channel.

5. Obtain authority. An OAuth token for the agent's own authority, or for explicitly delegated user authority — with the two kept distinguishable.

6. Authorize at the resource. Evaluate agent, subject, audience, scope, action, tenant, risk, and policy. A valid credential is necessary evidence, not an automatic allow.

7. Downscope each hop. Token exchange gives downstream tools only what they need.

8. Record and monitor. Logs connect agent identifier, delegating subject, token identifier, policy decision, tool call, and side effect.

9. Revoke independently. Workload, key, token, user grant, and discovered resource each revocable on their own.

Failure modes this architecture should stop

A valid identity becomes an allowlist bypass. Signing tells you who holds a key. It does not make every request from that identity safe. Keep behavioral controls, rate limits, route policy, and response-level data authorization in place for verified agents.

The user and agent collapse into one subject. If a downstream service sees only the user, it cannot tell whether the user acted directly or an agent acted for them. If it sees only the agent, it cannot enforce user-specific consent. Carry both.

A bearer token gains power as it moves downstream. Don't forward the broad original token through every tool call. Exchange or downscope per audience and action.

Discovery metadata is trusted like an access decision. Catalog content can point an agent at an attacker-controlled endpoint. Verify publisher trust metadata, constrain redirects and egress, apply normal SSRF defenses.

Static secrets are cloned with the agent. If every replica shares one API key, you cannot distinguish instances or revoke one compromised runtime.

The audit trail loses authorization context. Logging only the final API call is not enough. Preserve agent identity, delegating principal, token audience and scope, policy version, decision, and result.

Implementation checklist

• Assign every agent workload a stable identifier.

• Issue credentials at runtime after workload attestation.

• Make credentials short lived and automatically rotated.

• Never bake API keys or OAuth client secrets into agent images, code, or prompts.

• Keep the agent's identity separate from the user's delegated identity.

• Use OAuth scopes, audience restrictions, and expiry as real policy boundaries.

• Downscope authority at each tool or service hop.

• Verify HTTP signatures over the components that matter, and enforce replay bounds.

• Treat discovery results as untrusted until trust metadata is verified.

• Do not equate a valid signature with safe behavior or permission.

• Log the agent, delegating subject, authorization decision, tool call, and side effect together.

• Design independent revocation for workload credentials, signing keys, OAuth grants, and discovered resources.

• Support unsigned traffic without silently upgrading a claim into verified identity.

What's stable, what's still emerging

• HTTP Message Signatures — standardized, RFC 9421.

• OAuth Token Exchange — standardized, RFC 8693. Security BCP is RFC 9700.

• SPIFFE — deployed workload identity infrastructure with published specs and implementations.

• Web Bot Auth — IETF Internet-Draft built on RFC 9421.

• AI agent authentication architecture — an individual Internet-Draft, not an adopted standard. -03 updated July 2026, work in progress.

• ARD — open, evolving specification. Expect iteration.

That mix is normal. You do not need to wait for every draft to finalize before removing static secrets, separating agent and user identity, enforcing narrow OAuth audiences, or building complete audit trails. Those are sound security properties regardless of which emerging profile wins adoption.

The bottom line

• ARD tells an agent what exists and where to find it.

• Workload identity proves which software instance is running.

• Web Bot Auth proves who signed an automated web request.

• OAuth says what that agent may do and on whose behalf.

• Observability proves what happened afterward.

No one layer can safely stand in for the others. The 2026 standards work matters because it stops treating "AI agent" as one magical new principal and starts decomposing it into the identities, credentials, delegation, policy, and evidence that security systems already know how to manage.

If you're building agent-facing APIs right now — are you separating the agent identity from the delegating user, or is it all still one API key?

Originally published at webdecoy.com.

Related reading:

• Web Bot Auth: Google Now Signs Its Crawlers

• Signed Agents and the Coming Web Identity Schism

If you're building or maintaining a fingerprinting system, a lot of the advice from even two years ago is obsolete. This is a technical audit of what still produces usable signal, what's been neutralized, and what emerged to replace the losses.

One caveat up front: a fingerprint is not a durable cross-browser identity, and no single fingerprint should be treated as proof that a visitor is human or automated.

The Scoreboard

Each technique rated on two axes — entropy (how much identifying information it produces) and durability (how resistant it is to spoofing and browser mitigation).

The trend is clear: JavaScript-accessible signals are eroding. Network-level signals are ascendant. The most durable techniques in 2026 operate below the browser's API surface, where privacy extensions and stealth plugins can't reach them.

What's Dead

User-Agent string. Chrome killed it. Since Chrome 107 in late 2022 the string is frozen — the version number still increments, but OS version is pinned to Windows NT 10.0, platform details are generic, and it no longer differentiates minor versions or OS builds. Firefox and Safari followed. You can distinguish Chrome from Firefox from Safari, and that's about it. For bot detection it's worse than useless, because every automation framework sets whatever string it wants.

navigator.plugins / navigator.mimeTypes. Used to return arrays of installed plugins — a user with Flash 32.0.0.453, Java 8u281 and Chrome PDF Viewer had a distinct, slowly-changing signature. Chrome now returns a fixed generic array. Firefox the same. Remove these from any library that still checks them.

navigator.platform. Frozen to generic values like Win32 regardless of actual architecture. The Client Hints replacement (navigator.userAgentData.platform) is designed to be lower entropy and gates detailed values behind a permission request.

What's Degraded but Usable

Canvas fingerprinting

Draw a complex scene, read back the pixel data, hash it. GPU hardware, driver versions, font rendering and anti-aliasing produce slightly different output across devices.

Per-browser reality in 2026:

• Chrome — still consistent, device-specific output. No noise injection. Highest-fidelity target.

• Firefox — noise injection since 113 via privacy.resistFingerprinting. Off by default, on in strict privacy mode and private windows. When enabled, the same device produces a different hash on every page load.

• Safari — minimal canvas protection. Still stable.

• Brave — aggressively randomizes by default. Effectively useless against Brave users.

function getCanvasFingerprint() {
  const canvas = document.createElement('canvas');
  canvas.width = 256;
  canvas.height = 256;
  const ctx = canvas.getContext('2d');

  ctx.textBaseline = 'top';
  ctx.font = '14px Arial';
  ctx.fillStyle = '#f60';
  ctx.fillRect(125, 1, 62, 20);
  ctx.fillStyle = '#069';
  ctx.fillText('Browser fingerprint', 2, 15);
  ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
  ctx.fillText('Browser fingerprint', 4, 17);

  // Geometric shapes for GPU-dependent rendering
  ctx.beginPath();
  ctx.arc(50, 50, 50, 0, Math.PI * 2, true);
  ctx.closePath();
  ctx.fill();

  return canvas.toDataURL();
}

Verdict: still works on roughly 80% of browsers. Expect continued degradation.

Font enumeration

Weakened for three reasons: OS standardization (Windows 11, recent macOS and modern Linux distros ship increasingly similar default sets), web font dominance (most modern sites never trigger system font rendering), and browser restrictions (privacy.resistFingerprinting returns a fixed list). Still distinguishes Windows from macOS from Linux. The days of font lists as a high-entropy identifier are over.

Screen and display properties

A 1920×1080 display at 1× describes tens of millions of devices. Trivially spoofed — Playwright and Puppeteer set arbitrary viewport sizes in one line. Include in a composite, don't rely on it.

What Still Works

WebGL — the quiet workhorse

Two levels. Parameter enumeration exposes hardware and driver information:

function getWebGLFingerprint() {
  const canvas = document.createElement('canvas');
  const gl = canvas.getContext('webgl');
  if (!gl) return null;

  const debugInfo = gl.getExtension('WEBGL_debug_renderer_info');

  return {
    vendor: gl.getParameter(gl.VENDOR),
    renderer: gl.getParameter(gl.RENDERER),
    unmaskedVendor: debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_VENDOR_WEBGL)
      : null,
    unmaskedRenderer: debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL)
      : null,
    maxTextureSize: gl.getParameter(gl.MAX_TEXTURE_SIZE),
    maxViewportDims: gl.getParameter(gl.MAX_VIEWPORT_DIMS),
    extensions: gl.getSupportedExtensions(),
    shadingLanguageVersion: gl.getParameter(gl.SHADING_LANGUAGE_VERSION),
  };
}

The unmasked renderer string alone carries substantial entropy — ANGLE (NVIDIA GeForce RTX 4070 Ti Direct3D11 vs_5_0 ps_5_0) identifies a specific GPU model. Level 2 is render output: drawing a 3D scene and reading back pixels, with higher variability than canvas because 3D pipelines differ more across GPU architectures.

Why it's durable: browser vendors have been reluctant to restrict WebGL because doing so breaks legitimate applications — games, data visualizations, 3D product viewers, mapping. Injecting noise would break these visibly.

For bot detection specifically, WebGL is gold. Headless Chrome in a cloud VM reports the VM's virtual GPU — typically Google SwiftShader or llvmpipe — instantly distinguishable from any real user GPU. Even BaaS platforms that spoof this value struggle to replicate the full constellation of parameters a real GPU produces.

AudioContext

Exploits hardware-dependent differences in audio signal processing. Route an OscillatorNode through a DynamicsCompressorNode, read the output, and you get floating-point sample values that vary with the audio hardware and driver stack:

function getAudioFingerprint() {
  return new Promise((resolve) => {
    const context = new OfflineAudioContext(1, 44100, 44100);
    const oscillator = context.createOscillator();
    oscillator.type = 'triangle';
    oscillator.frequency.setValueAtTime(10000, context.currentTime);

    const compressor = context.createDynamicsCompressor();
    compressor.threshold.setValueAtTime(-50, context.currentTime);
    compressor.knee.setValueAtTime(40, context.currentTime);
    compressor.ratio.setValueAtTime(12, context.currentTime);
    compressor.attack.setValueAtTime(0, context.currentTime);
    compressor.release.setValueAtTime(0.25, context.currentTime);

    oscillator.connect(compressor);
    compressor.connect(context.destination);
    oscillator.start(0);

    context.startRendering().then((buffer) => {
      const data = buffer.getChannelData(0);
      let sum = 0;
      for (let i = 4500; i < 5000; i++) sum += Math.abs(data[i]);
      resolve(sum);
    });
  });
}

Lower entropy than WebGL, but it's an independent signal that's hard to spoof because it depends on the actual audio processing pipeline rather than a JavaScript property. Headless browsers often have no audio stack at all, or a software implementation producing output that matches no real desktop configuration.

TLS fingerprinting (JA4)

The biggest shift in fingerprinting since canvas was discovered. TLS fingerprinting doesn't operate in JavaScript at all. It analyzes the ClientHello sent during the HTTPS handshake — before page content loads, before JavaScript executes, before any browser API can be manipulated.

The ClientHello contains supported cipher suites in preference order, TLS extensions and their order, supported groups, signature algorithms, and ALPN protocols. JA4 hashes these into a fingerprint identifying the TLS stack implementation. Critically: you cannot change your JA4 fingerprint from JavaScript. It's determined by the TLS library compiled into the client.

Which means:

• A Playwright bot claiming Chrome 126 but running an older Chromium has a JA4 that doesn't match real Chrome 126.

• A Python requests session spoofing a Chrome User-Agent has a JA4 matching urllib3, not Chrome.

• A BaaS platform running headless Chrome in the cloud has a JA4 matching their specific Chromium build — often months behind stable.

The cost: it requires server-side or proxy-level access to the raw handshake. You can't do it from JavaScript. But if you control the server, or use a CDN that exposes TLS metadata (Cloudflare exposes JA3 and JA4 in firewall rules), it's the most powerful identification signal available.

HTTP/2 settings

When a client opens an HTTP/2 connection it sends a SETTINGS frame — initial window size, max concurrent streams, header table size, enabled push. Different implementations choose different defaults, and like TLS it's determined by the client implementation rather than configurable from JavaScript. Underutilized, and worth adding.

The Anti-Fingerprinting Landscape

Chrome (Privacy Sandbox). Surgical rather than blunt: reduce entropy from each API rather than blocking it. Frozen UA, reduced Client Hints, deprecated plugins. WebGL renderer info stays exposed because removing it would break too many sites. The goal is to make fingerprinting less unique, not impossible.

Firefox. The most granular controls. privacy.resistFingerprinting (off by default, on in Tor Browser) adds canvas noise, restricts font enumeration, normalizes screen dimensions, limits timer precision. Standard Firefox blocks known fingerprinting scripts by domain without modifying API output.

Safari. Pragmatic — restricts some vectors (limiting document.fonts, reducing timer precision) but focuses mainly on cookie and storage partitioning.

Brave. The most aggressive. Randomizes canvas, blocks WebGL renderer info, adds AudioContext noise, limits fonts. The goal is to make fingerprinting actively unreliable, not just lower entropy.

On the other side:

Puppeteer Extra Stealth / Playwright stealth patches patch navigator.webdriver, spoof plugin arrays, override Chrome runtime properties. Increasingly they spoof WEBGL_debug_renderer_info to report a realistic GPU instead of SwiftShader. None of it affects TLS or network-level signals.

Browser-as-a-Service (Browserbase, Hyperbrowser) run real Chromium in the cloud, producing genuine fingerprints at the JavaScript level. Their weakness is TLS: the Chromium version they run often lags stable, creating a detectable mismatch between claimed UA version and actual JA4.

Anti-detect browsers (Multilogin, GoLogin, Dolphin Anty) are the hardest to detect, because they use modified real browser engines rather than automation frameworks. Detection requires ensemble methods — no single signal catches them.

Building a System in 2026

Layer 1 — network fingerprints (server-side). Collect at the proxy or load balancer:

TLS ClientHello   → JA4 hash
HTTP/2 SETTINGS   → settings fingerprint
TCP/IP characteristics → OS fingerprint

This is the foundation because it cannot be manipulated from the client. It tells you what the client actually is, regardless of what it claims.

Layer 2 — hardware fingerprints (JavaScript). WebGL renderer + parameters, AudioContext output, canvas rendering. Harder to spoof than software properties because they depend on physical components and low-level driver behavior.

Layer 3 — behavioral fingerprints (JavaScript). Mouse movement patterns, scroll behavior, keystroke timing, touch events, interaction timing. Not traditional fingerprints, but the strongest bot/human discrimination available — a bot can spoof every static property perfectly and still fail here, because generating convincing human interaction at scale is an unsolved problem.

Cross-signal coherence is the whole game

No single technique is sufficient. The value is in the combination, and specifically in coherence. A client claiming Chrome 126 on Windows 11 should have:

• a JA4 hash matching Chrome 126's TLS stack

• a WebGL renderer matching a real Windows GPU (not SwiftShader)

• AudioContext output consistent with Windows audio drivers

• HTTP/2 settings matching Chrome's defaults

• mouse movement with human-like jitter and velocity curves

If any one of these contradicts the others, something is being spoofed. A real browser is internally consistent. A spoofed browser almost never is, because each spoofing mechanism operates independently and rarely accounts for cross-signal dependencies.

The privacy tension

This has been written from a security perspective, deliberately. Fingerprinting for bot detection and fingerprinting for cross-site tracking are the same technology applied to different ends.

The privacy concerns are real — fingerprinting has been used to track users across sites without consent, circumventing cookie controls. The browser restrictions above are responses to documented abuse.

The security case is also real. Without fingerprinting, bots are nearly undetectable. CAPTCHAs fail. Rate limiting fails. Behavioral analysis alone has a high false-positive rate. The same signals that let an ad network track you across the web are the signals that let a payment processor catch a credential-stuffing attack.

This is a genuine tension, not a false dichotomy. The current trajectory — browsers restricting JavaScript-accessible signals while network-level fingerprinting becomes the primary detection vector — is a reasonable compromise. It makes cross-site tracking harder (you can't read TLS fingerprints from JavaScript) while preserving the ability of server operators to identify suspicious clients hitting their own infrastructure.

Where this lands in three years is anyone's guess. For now: the toolkit is smaller than it was, the signals that remain are more durable than the ones that were lost, and the arms race shows no sign of slowing.

Anyone here still getting useful entropy out of canvas, or have you moved everything to the network layer?

Originally published at webdecoy.com.

Related reading:

• JA4 Fingerprinting for AI Scraper Detection

• Headless Browser Detection: Playwright, Puppeteer, Selenium

• How to Detect Browser-as-a-Service Scrapers

This is not a story about a particular CAPTCHA being broken. It's a story about a category that has lost its asymmetric advantage. The defining property of an effective CAPTCHA — that it costs more for an attacker to solve than for a legitimate user — has been priced into oblivion. Solvers cost a fraction of a cent. Vision models do the rest for free. Real users churn.

What a CAPTCHA Was Supposed to Do

A CAPTCHA, in the 2003 sense Luis von Ahn coined, is a "Completely Automated Public Turing test to tell Computers and Humans Apart." The asymmetry depends on three properties:

1. The challenge is hard for current machine learning.

2. The challenge is easy for typical humans.

3. The cost to generate the challenge is much lower than the cost to solve it.

All three were approximately true for distorted-text CAPTCHAs in 2003. None are true for any visual CAPTCHA in 2026.

The death of (1) is what people mean when they say CAPTCHAs are broken. The death of (2) is what people mean when they say CAPTCHAs are user-hostile. The death of (3) is the boring one that actually matters, because it's the one that breaks the economics for defenders.

The Solver Economy

Here's the part that doesn't get talked about enough. CAPTCHAs are not defeated primarily by AI. They are defeated by markets that price AI at scale.

2Captcha, CapSolver, AntiCaptcha and a long tail of grey-market resellers operate as commodity APIs. You send a challenge image or sitekey, you get back a token, you pay per solve. Pricing as of mid-2026, in round numbers:

Translate that into attacker math. A credential stuffing operator running 100,000 attempts a day at a 0.3% hit rate, valuing a validated account at $20, makes \(6,000/day in revenue against \)300 in solver cost.

CAPTCHA is a 5% line item in their cost of goods sold. It is not a deterrent. It is a tax an attacker pays without complaint while extracting value from your system.

The Autopsy, By Variant

reCAPTCHA v2 image grids. Solved end-to-end by GPT-4-class vision models in 2023, and by smaller, cheaper fine-tuned models since. Solve rate against modern grids is consistently above 90% — higher than the average human solve rate against the same puzzles. The audio accessibility fallback is solved by Whisper with similar reliability.

reCAPTCHA v3 invisible scoring. Three concrete problems. The score is gameable — operators run checkers in real Chrome with warm Google session cookies on seasoned residential profiles, scoring 0.7–0.9. The score routinely flags legitimate users on Linux, Firefox, hardened browsers, or VPNs, often below 0.3. And every page shipping v3 is also shipping a Google tracking beacon to every visitor, which is a live regulatory issue under GDPR and US state privacy laws.

hCaptcha. Functionally similar to v2 with a privacy-first marketing posture. Solved by the same providers at similar prices with similar success rates.

Cloudflare Turnstile. The most interesting of the modern lot, because it skips the puzzle and scores on browser environment signals. When it works, it works invisibly. When it fails, it fails opaquely. Two failure modes we see in the wild: it passes Browser-as-a-Service traffic (Browserbase, Hyperbrowser) with high frequency, because those platforms serve real Chromium on real residential IPs; and it blocks a long tail of legitimate users on hardened privacy browsers (Brave strict shields, LibreWolf, Tor) at rates that produce real conversion impact. Right shape for the future, closed implementation tied to one edge.

Arkose FunCaptcha. Long the holdout because of the 3D-rotation requirement. By 2025, depth-aware vision models trained on synthetic 3D renders started solving these reliably.

The Shape of the Replacement

Six independently useful components. Most production stacks combine three or four. None are silver bullets — the point is that combining cheap signals raises attacker cost faster than any single signal does.

1. Behavioral biometrics

Real humans interact with a page in characteristically messy ways. Continuous mouse trajectories with micro-tremors at 3–25 Hz from physiological hand movement. Hover, overshoot, correct. Inter-keystroke intervals that follow a log-normal distribution with dwell-time variance, rollover on common letter pairs, and real Shannon entropy.

Automated browsers can replay recorded human traces — that's the obvious counter. The current state of play is that replayed traces look right at first order (mouse moves, things get clicked) but break under second-order analysis: the trace doesn't match the page layout the model is currently looking at, keystroke entropy is uniform across the corpus, the timing distribution has a different tail.

Signals worth capturing, in rough order of cheapness:

• Mouse trajectory entropy and curvature

• Inter-event timing distributions (keystroke, mouse move, scroll)

• Field-fill order and time-on-form

• Pointer move events between page load and first click

• Touch vs mouse vs synthetic event detection (event.isTrusted)

• Scroll velocity profiles

• Focus and blur event sequences

2. Proof-of-work

The oldest idea in the deck, and one of the most underused. Adam Back's 1997 Hashcash proposal is the original spec: before accepting a request, require the client to find a partial SHA-256 collision against a server-issued nonce. Tunable difficulty, no interactivity, invisible to the user.

The asymmetry is straightforward. A 200 ms PoW solve on a real phone is below the threshold of perception. The same 200 ms across 10,000 parallel sessions is 33 minutes of single-threaded compute, or a real cloud bill in parallel. Worth nothing against someone targeting one account. Crippling for mass-volume operators.

async function solve(nonce, difficultyBits) {
  const target = (1n << (256n - BigInt(difficultyBits)))
  for (let counter = 0; ; counter++) {
    const buf = new TextEncoder().encode(nonce + counter)
    const digest = await crypto.subtle.digest('SHA-256', buf)
    const hashInt = BigInt('0x' + [...new Uint8Array(digest)]
      .map(b => b.toString(16).padStart(2, '0')).join(''))
    if (hashInt < target) return counter
  }
}

Difficulty calibration is the only interesting tuning question. Too low and it doesn't bite; too high and slow phones see a noticeable delay. We land around 20 to 22 bits, roughly 100–400 ms on a five-year-old Android and well under a second on anything modern.

3. Privacy Pass and Private Access Tokens

The most promising long-term direction. A trusted attester (Apple, Google, your own service) verifies the client is a real device, then issues a blind cryptographic token the client redeems at your service. You learn the request came from an attested human-controlled device. You learn nothing else. The attester learns nothing about which sites the user visits.

The catch in 2026 is coverage: well-supported on Apple platforms, partially on Cloudflare's network, effectively unsupported elsewhere. PAT is part of the stack, not the whole stack.

4. TLS and HTTP/2 fingerprinting

The layer below the browser. Every HTTP client has a TLS ClientHello with a specific cipher suite ordering, extension list, and supported groups; every HTTP/2 client has a settings frame with specific values and pseudo-header order. These vary by client library and stack version, and are very hard to spoof from a script without driving an actual browser.

A POST that arrives with User-Agent: Mozilla/5.0 ... Chrome/124 and a JA4 fingerprint that says "Go HTTP client" is automated. Full stop. No human Chrome ever produced that combination.

5. Honeypot fields and decoy endpoints

The oldest cheap trick still works for a useful slice of the threat. Two important caveats, though. Classic CSS-hidden honeypots (display: none) are increasingly invisible to vision-based agents that read the rendered page rather than the HTML — the agent never sees the field, so it never fills it. And accessibility tooling sometimes interacts with hidden fields, producing false positives for screen-reader users.

The patterns that hold up in 2026 use DOM-tree placement (a field after the submit button), naming conventions that look real but never appear in your actual schema, or Shadow DOM containment that mainstream automation libraries don't traverse.

6. Server-side risk scoring

The layer that ties everything together. Every signal above produces a feature; score requests across all of them and decide what to allow, what to challenge with a step-up, and what to silently drop.

The thing to avoid is a single hardcoded "bot or not" threshold. The thing to embrace is a graduated response that maps risk score to action.

How They Combine

A realistic 2026 stack on a high-value form:

1. Edge
   - TLS / HTTP/2 fingerprint logged
   - Datacenter ASN gets harder PoW difficulty
   - Known-bad fingerprint clusters hard-blocked

2. Page load
   - Behavioral telemetry script attached
   - Keystroke, mouse, scroll, focus events captured
   - Honeypot fields rendered into the DOM
   - PoW challenge issued at low difficulty

3. Submit
   - Form + signed telemetry token + PoW result posted
   - Honeypot fields verified empty
   - Server computes risk score across all signals

4. Decision
   - Score below A: accept silently
   - Score in band: step up (harder PoW or soft MFA)
   - Score above B: drop with response symmetry
                    (identical status, body shape, timing)

What you do not do, in any layer, is show the user a visual challenge.

An open-source implementation

FCaptcha is our open-source implementation of this stack (currently v1.37). We started it because every team that came to us asking how to replace reCAPTCHA wanted the same three things: an open-source library, a self-hostable server, and a scoring algorithm they could read and audit.

What's in the box: behavioral telemetry across mouse/keystroke/scroll/focus/environment categories; keystroke cadence biometrics (dwell variance, log-normal fit, Shannon entropy, autocorrelation, rollover detection); SHA-256 proof-of-work with server-side timing validation; vision-AI detection (zero-movement click bypass, screenshot-to-API patterns, synthetic event filtering); automation detection for Playwright, Puppeteer, Selenium, Stagehand and BaaS; servers in Go, Python and Node with identical scoring semantics; no cookies, no cross-site tracking, no PII.

1. Run the server.

docker run -d -p 3000:3000 \
  -e FCAPTCHA_SECRET=your-secret \
  ghcr.io/webdecoy/fcaptcha

That gives you POST /api/* for verification and GET /fcaptcha.js for the widget. Two deployment notes worth knowing up front: the server fails closed without FCAPTCHA_SECRET (the public dev key is in the repo, so anything signed with it can be minted by anyone), and running more than one replica requires REDIS_URL so single-use tokens are single-use across the whole deployment rather than per process.

2. Add the widget. Invisible mode auto-protects forms with no UI:

<script src="https://your-server.com/fcaptcha.js"></script>
<script>
  FCaptcha.configure({ serverUrl: 'https://your-server.com' })
  FCaptcha.invisible({ siteKey: 'your-site-key', autoScore: true })
</script>

3. Verify on the backend. A plain HTTP POST:

import requests

resp = requests.post(
    'https://your-server.com/api/token/verify',
    json={'token': token_from_form, 'secret': FCAPTCHA_SECRET},
).json()

# In FCaptcha, a LOW score means the request looks human.
if resp['valid'] and resp['score'] < 0.5:
    return accept()
elif resp['valid'] and resp['score'] < 0.8:
    return require_step_up()
else:
    return reject()

What we don't claim

This does not "solve bot detection." Nothing does. It raises the cost of mass-volume automated abuse to the point where commodity attackers move on and bespoke attackers leave signals you can act on. Targeted attackers with patient capital and real Chromium on real residential bandwidth will still get through. That's true of every defense in this category.

Behavioral telemetry can be replayed. Open datasets of recorded human interactions exist for the explicit purpose of training automation to look human. The signals that hold up are second-order ones — does the trace match the current page, does the keystroke entropy match the current user's history. Harder to replay convincingly. Not impossible.

Proof-of-work is not free for clients. A 200 ms hit is small but not zero. On a four-year-old phone with thermal throttling it can stretch to 800 ms. Tuning difficulty by device class means low-trust devices get more friction, which is its own UX cost.

No CAPTCHA replacement is GDPR-trivial. Behavioral telemetry is biometric data under EU law, and the scoring is opaque enough that "right to explanation" obligations require thought. You will still need a privacy review.

A migration path

If you're on reCAPTCHA today, the path that has worked for most teams:

1. Week 1 — Ship behavioral telemetry alongside the existing CAPTCHA. Log scores, don't gate on them. Build a dashboard of score distributions for known-good and known-bad sessions.

2. Weeks 2–3 — Calibrate thresholds against the labeled dashboard. Find the band that cleanly separates confirmed humans from confirmed bots, and the gray middle that needs step-up.

3. Week 4 — Move the CAPTCHA into step-up-only mode. Default flow is invisible; only the gray band sees a challenge.

4. Weeks 5–6 — Replace the CAPTCHA step-up with a higher-difficulty PoW step-up, or soft MFA for accounts that have it.

5. Week 7 — Remove the CAPTCHA SDK entirely. Audit the privacy footprint reduction. Tell your conversions team.

Most teams measure a conversion lift on legitimate sign-up traffic at step 3 — the moment the CAPTCHA stops gating clean sessions — and a sharper drop in confirmed bot success by step 5.

Where this goes next

Agent-driven traffic from real Chromiums. The Browser-as-a-Service ecosystem is industrializing exactly the population that defeats most behavioral defenses. Cross-session correlation, JA4-plus-device-fingerprint binding, and challenge interaction physics beyond first-order signals all matter more in this world.

Standardized client attestation. PAT is the early form. WebAuthn-anchored device attestation, TPM-backed remote attestation, and App Attest are converging toward a future where "is this a real device controlled by a real user" is a cryptographic question rather than an inferential one. Uneven and partial today. Worth tracking.

The CAPTCHA is dead. What replaces it is not one thing — it's a stack of cheap, layered signals producing a real-time score, paired with a graduated response that mostly does nothing visible to the user. That's the bar. Everything below it is theater.

Either way: please stop making people click on traffic lights.

What are you running on your sign-up flow right now? Curious how many teams have actually managed to rip reCAPTCHA out versus just layering on top of it.

Originally published at webdecoy.com.

Related reading:

• Proof-of-Work CAPTCHAs with Hashcash

• JA4 Fingerprinting for AI Scraper Detection

• Honeypot Traps: Forms, Buttons & Endpoints

• Detecting Vision-Based AI Agents

The reflex is a ten-line user-agent block in middleware.ts. After you ship it the graph looks calmer for a day. Then it climbs again.

The ten-line block is not wrong. It is just the first of three layers, and on its own it catches only the crawlers honest enough to tell you who they are. This is a working guide to all three in a normal Next.js project: an edge gate on every request, honeypot routes that catch the bots that lie, and an origin fingerprint check for the signal the edge genuinely cannot see.

We will also be honest about that last part, because most tutorials are not.

The naive block, and exactly why it fails

Almost every Next.js bot-blocking guide ends here:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

const BLOCKED = /GPTBot|ClaudeBot|PerplexityBot|Bytespider|CCBot|Google-Extended|Meta-ExternalAgent|Amazonbot/i

export function middleware(req: NextRequest) {
  const ua = req.headers.get('user-agent') || ''
  if (BLOCKED.test(ua)) {
    return new NextResponse('Forbidden', { status: 403 })
  }
  return NextResponse.next()
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

This works against a crawler that announces itself. GPTBot sends a user agent that says GPTBot, you match it, you return 403. Done.

The problem is that a user agent is a string the client chooses. Nothing forces a scraper to keep telling the truth, and the moment blocking becomes common, the well-funded scrapers stop. Perplexity was reported through 2025 to fetch pages with a generic Chrome user agent and rotating addresses after its declared bot was blocked. A scraper running headless Chrome or a plain HTTP client can set any user-agent header it likes in one line. Your regex never sees them.

So the honest framing: a user-agent block is a politeness filter. It removes the crawlers that respect your wishes, which is real and worth doing, and it does nothing to the ones that do not. The same logic applies to robots.txt, which is a request rather than a rule.

Layer one: a real edge middleware

Keep the user-agent gate, but stop treating it as the whole defense. A useful middleware does three jobs: cheaply block the honest crawlers, rate limit everyone else so a single client cannot flood you, and hand a signal to your origin so the deeper check knows where to look.

Where middleware lives, and what matcher does

middleware.ts sits at the root of your project, or inside src/. It runs on the Edge Runtime by default, before your routes and before cached output — exactly why it is the right place for a first gate. The request is stopped before it costs you a function invocation or a database hit.

The matcher is your most important performance setting. Without it, middleware runs on every asset, including static files Next.js already serves for free:

export const config = {
  matcher: [
    // run on everything except Next internals and static files
    '/((?!_next/static|_next/image|favicon.ico|robots.txt|sitemap.xml).*)',
  ],
}

Block, rate limit, or rewrite

NextResponse gives you three moves inside middleware:

return new NextResponse('Forbidden', { status: 403 })          // block
return new NextResponse('Too Many Requests', { status: 429 })  // rate limit
return NextResponse.rewrite(new URL('/tarpit', req.url))       // send to a decoy

You can hand-roll the gate from here, but it adds up fast: a regex of declared crawlers to maintain, plus a shared rate-limit store — an in-process counter (a plain Map) will not hold when edge invocations do not share memory, so you reach for Upstash Redis or Vercel KV.

That is ongoing work, and it is the work @webdecoy/nextjs exists to remove:

npm install @webdecoy/nextjs

// middleware.ts
import { withWebDecoy } from '@webdecoy/nextjs'
import { rateLimit } from '@webdecoy/node'

export default withWebDecoy({
  apiKey: process.env.WEBDECOY_API_KEY!,
  // Built-in rules engine: no separate counter store to stand up.
  rules: [rateLimit({ max: 100, window: 60 })], // 100 requests per 60s
  // Skip work on paths that never need protection.
  skipPaths: ['/_next', '/favicon.ico', '/robots.txt'],
})

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}

On every matched request this runs local analysis, applies your rules, and returns the right response on its own: a tripped rateLimit returns 429 with a Retry-After header, a deny rule returns 403, and an allowed request continues with an x-webdecoy-decision header so your routes can read the verdict downstream. onBlocked and onError let you override, and onError fails open by default, so a hiccup in detection never locks out real users.

This is a real improvement over the ten-line version. But notice what every signal so far has in common. User agent, headers, address, and request rate are all things the client controls or can rotate. To catch a bot that lies about all of them, you need a signal it does not get to set: its own TLS handshake.

The honest constraint nobody mentions

Here is the part most Next.js guides skip, and it holds whether you hand-roll the gate or use a package: you cannot compute a TLS fingerprint inside middleware.ts.

A JA3 or JA4 fingerprint is built from the raw ClientHello of the TLS handshake — the cipher suites, the extensions and their order, the supported groups, the way the client negotiates the connection. These are extremely hard to fake because they come from the client's TLS stack rather than from a header.

The catch on a platform like Vercel is that TLS terminates at the edge network before your middleware runs. By the time your code executes, the handshake is over and the ClientHello bytes are gone. The Edge Runtime has no socket access and no node:tls, so there is nothing to read. Recent Next.js versions let you move middleware to the Node.js runtime, which is useful for other reasons, but it still does not hand you the original handshake.

This is not a flaw in Next.js. It is just where the layers sit. Put the fingerprint check where the handshake is visible:

1. Your own origin, when you self-host Next.js behind your own TLS termination (next start behind nginx or Caddy), where the proxy reads the handshake and forwards it as headers.

2. A detection service that captures those handshake signals for you and returns a verdict your route handler can act on.

So the architecture becomes: gate cheaply at the edge, trap the liars with honeypots, run the fingerprint check at the origin where the signal lives.

Layer two: honeypot routes in the App Router

A honeypot exploits a simple asymmetry: a real visitor never touches it, so any hit is suspicious by definition. The classic version is a hidden form field. For a Next.js crawler problem, a honeypot route is a better fit, because crawlers follow links and probe paths humans never click.

First, plant a decoy link that humans cannot see but a link-following scraper will. Put it in your layout, and disallow the path in robots.txt so honest crawlers skip it — anything that fetches it has both ignored robots.txt and followed an invisible link, which is a strong signal:

// app/layout.tsx (excerpt)
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        {children}
        {/* Invisible to humans, irresistible to link-scraping bots. */}
        <a href="/api/trap" aria-hidden="true" tabIndex={-1}
           style={{ position: 'absolute', left: '-9999px' }}>
          Account archive
        </a>
      </body>
    </html>
  )
}

Then the trap itself — a route handler that records the hit and responds blandly so the bot does not learn it was caught:

// app/api/trap/route.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { flagClient } from '@/lib/threat'

export async function GET(req: NextRequest) {
  const ip = req.headers.get('x-forwarded-for')?.split(',')[0] ?? 'unknown'
  const ua = req.headers.get('user-agent') || ''

  // Record the hit. Anything reaching this route is presumed automated.
  await flagClient({ ip, ua, reason: 'honeypot:trap', score: 80 })

  // Respond like a boring empty resource. Do not reveal the trap.
  return new NextResponse(null, { status: 204 })
}

Now your middleware reads that stored flag and acts on it before serving real content. Rewrite flagged traffic to a tarpit instead of your actual route, which keeps the URL stable so the bot does not notice:

// inside middleware(), after the rate-limit check
import { isFlagged } from '@/lib/threat'

if (await isFlagged(ip)) {
  return NextResponse.rewrite(new URL('/tarpit', req.url))
}

The same pattern extends to fake API endpoints. A path like /api/v1/users/export that your real app never calls, but a scraper probing for data will, becomes a high-confidence trap.

Honeypots are powerful because they need no fingerprint and no machine learning. They exploit the gap between how a human and a script move through a site. But a careful scraper that only fetches linked, allowed pages at a human pace will avoid them. That is the gap layer three closes.

Layer three: origin fingerprinting

For the bot that spoofs its user agent, rotates its address, paces itself, and avoids your traps, you need the one thing it cannot rewrite: its TLS handshake. As covered above, that check has to run at the origin, in a Node runtime, not in edge middleware.

Next.js route handlers default to the Node.js runtime, which makes them the right home. The core SDK runs a two-tier check: a fast local pass on your server (suspicious headers, datacenter IP ranges, known bot user agents, missing client hints), and a deeper pass using JA3/JA4 fingerprinting to flag the case where a request claims to be Chrome but handshakes like curl.

npm install @webdecoy/node

// app/api/checkout/route.ts
export const runtime = 'nodejs' // the Edge Runtime cannot see the handshake

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { WebDecoy } from '@webdecoy/node'

const webdecoy = new WebDecoy({
  apiKey: process.env.WEBDECOY_API_KEY!,
  enableTLSFingerprinting: true,
  threatScoreThreshold: 70, // block at a threat score of 70 or higher
})

export async function POST(req: NextRequest) {
  const result = await webdecoy.protect({
    method: req.method,
    path: new URL(req.url).pathname,
    ip: req.headers.get('x-forwarded-for')?.split(',')[0] ?? '0.0.0.0',
    user_agent: req.headers.get('user-agent') ?? '',
    headers: Object.fromEntries(req.headers),
    timestamp: Date.now(),
  })

  if (!result.allowed) {
    // result.detection carries decision, confidence (0 to 100), and bot_type.
    return NextResponse.json({ error: 'Request blocked' }, { status: 403 })
  }

  return NextResponse.json({ ok: true })
}

One honest caveat about where each tier can run. The local pass works anywhere, including a route handler on Vercel, because it only reads headers and the address. The JA3/JA4 pass needs the client's actual handshake, and your function only sees that when it has socket access. Self-hosting behind nginx or Caddy, you forward the handshake details as headers and the SDK gets the full fingerprint. On Vercel's managed edge, you lean on the local signals and put the deep fingerprint check on a self-hosted origin or proxy.

Still on the Pages Router? The same package gives you a handler wrapper:

// pages/api/checkout.ts
import { withBotProtection } from '@webdecoy/nextjs'
import type { NextApiRequest, NextApiResponse } from 'next'

async function handler(req: NextApiRequest, res: NextApiResponse) {
  res.json({ ok: true }) // req.webdecoy holds the detection result
}

export default withBotProtection(handler, {
  apiKey: process.env.WEBDECOY_API_KEY!,
  blockThreshold: 70,
})

One decision from three signals

The point of three layers is that they cover each other's blind spots. Combine them into a single verdict rather than three disconnected checks:

// app/lib/decide.ts
type Signals = {
  edgeScreened: boolean   // passed the edge user-agent and rate gate
  honeypotHit: boolean    // touched a trap at any point
  threatScore: number     // 0 to 100, from result.detection.confidence
}

export function decide(s: Signals): 'allow' | 'challenge' | 'block' {
  if (s.honeypotHit) return 'block'           // touched a trap: automated by definition
  if (s.threatScore >= 70) return 'block'     // handshake or local signals say automation
  if (s.threatScore >= 40) return 'challenge' // suspicious, verify before trusting
  return 'allow'
}

A naive HTTP scraper trips the edge gate. A link-following scraper that lies about its user agent trips a honeypot. A polished headless browser that avoids the traps trips the fingerprint. To get past all three, a bot has to be honest, careful, and use a real browser TLS stack at the same time — a much smaller and more expensive population than the flood you started with.

Vercel BotID versus a self-hosted stack

If you are on Vercel you have probably seen BotID, the invisible bot-detection product powered by Kasada. It is genuinely good, and worth knowing where it fits.

BotID is a managed black box. You enable it on the routes you want protected and it makes a verdict at the edge, with no signals to inspect and no logic to tune. That is the appeal and the limitation: strong detection with almost no code, in exchange for visibility into why a request was flagged, portability off Vercel, and the ability to combine the verdict with your own honeypots and scoring. It is also a paid feature once you scale.

The self-hosted stack in this guide is the opposite trade: more code and more moving parts, in return for portability to any host, transparency about every signal, and thresholds that are yours to tune. They are not mutually exclusive — some teams run BotID on checkout and login for the managed guarantee, and run the edge gate plus honeypots plus origin fingerprinting everywhere else for coverage and insight.

Production checklist

• Scope the matcher. Never run middleware on _next/static, images, or other assets. Wasted compute, and it can break caching.

• Do not hard-block on user agent alone. Treat it as the cheap first pass, then escalate. A single spoofed header should not be enough to ban a visitor.

• Allow the good bots on purpose. Verify Googlebot and Bingbot by reverse DNS rather than trusting the user-agent string, and decide deliberately which AI crawlers you keep. Some AI search engines send referral traffic worth having.

• Watch your false positive rate. Log every block and challenge with the reason, and review the challenge bucket. If real users land there, loosen the thresholds in decide().

• Fail open, not closed. If the fingerprint service is briefly unreachable, decide whether a timeout should allow or challenge. For most sites, allowing on timeout beats locking out real customers.

• Measure the bill. The whole point was bandwidth and compute. Watch the usage graph for a week after launch so you can prove the layers are paying for themselves.

Wrapping up

The shape that works in Next.js is layered: a cheap edge gate that screens and rate limits, honeypot routes that catch the bots that lie, and an origin fingerprint check for the signal the edge cannot see. None of it requires a separate WAF or DNS surgery, and the one real constraint — that TLS fingerprinting cannot happen in edge middleware — is a reason to move that check to the origin, not a reason to skip it.

What is your site seeing from AI crawlers lately? Curious whether others are blocking outright or rate limiting and keeping the referral traffic.

Originally published at webdecoy.com.

Related reading:

• Detect AI Scrapers: Block GPTBot, ClaudeBot & More

• JA4 Fingerprinting for AI Scraper Detection

• Honeypot Traps: Forms, Buttons & Endpoints