This page introduces the background section and links to the detailed pages on threat models, adversaries, automation economics, vendor claims, and AI-agent traffic.
Automated traffic is now an ordinary operating condition for websites, not a fringe case. Vendor telemetry puts bots at roughly half of web traffic, with a substantial share classified as bad-bot activity (Thales/Imperva 2026). These figures should be read carefully: they come from infrastructure-provider visibility, with opaque sampling and classification, not from a neutral census of the whole internet. But they are enough to justify the project’s starting point: public web services are no longer serving only human users.
Not all automation is harmful. Search-engine crawlers, monitoring services, accessibility tools, feed fetchers, archiving services, link-preview tools, and analytics systems can support useful web functions. Commercial bot-management documentation also separates verified or allowed bots from unwanted automation (Cloudflare, Bot Management docs). The risk comes from automation that uses human-facing systems at machine scale: credential stuffing, fake-account creation, scraping, inventory hoarding, denial of inventory, carding, ad fraud, reconnaissance, and abuse of APIs or business logic (OWASP; OWASP, Automated Threat Handbook v1.3; Thales/Imperva 2026).
Recent sources describe a landscape moving from simple scripts toward browser-native automation, residential proxies, CAPTCHA solving, cloud browsers, and AI agents (Thales/Imperva 2026; HUMAN, State of Agentic Traffic; Wang et al. 2026, FP-Agent). That shifts the practical question. It is no longer enough to ask whether a request is made by a bot. The harder questions are what the automation is doing, what account or session context it uses, how costly it is to run, and whether the service should allow it.
This background section is a landing page. The detailed argument is split across the pages linked below.
How to read the evidence
A caution applies throughout: the evidence base is much stronger for capability and market existence than for real-world prevalence or defensive effectiveness. OWASP gives a useful threat taxonomy. Vendor reports give visibility into what providers say they observe. Academic and independent studies give narrower but cleaner tests. The project keeps those evidence types separate rather than treating them as equivalent.
The register classifies every source on an operational proximity axis: capability → claimed → observed → measured. The corpus concentrates at capability and claimed; observed is mostly vendor-measured telemetry; and measured is a small number of bounded studies. This is the main thing to hold in mind when reading the section.
Two editorial commitments follow from that.
Vendors are evidence, not subjects. Marketing pages, white papers, and threat reports tell us what the field says it does. They are cited as evidence about the landscape, not as endorsements or measurements of product effectiveness.
Methods before actors. A technique described in the abstract is in scope. A campaign attributed to a named group is not. Where a source’s value is buried inside actor attribution, the project extracts the technique and discards the attribution.
This section also has deliberate boundaries. It does not cover named threat-actor attribution, criminal revenue flows, or a comprehensive catalogue of incidents. High-profile public cases are used only where they clarify a wider pattern of automated abuse, such as scarcity exploitation, credential attacks, scraping, or inventory hoarding.
What this section covers
- Threat model — defines automated abuse as activity at scale against systems built for human users, using OWASP Automated Threats to Web Applications as the main vocabulary for naming abuse types.
- Booking-style example — grounds the abstract threat model in ticketing, appointments, reservations, and other scarce-inventory services.
- Adversary model — describes attackers by motivation and capability, not by named groups.
- Economics of automation — looks at the cost structure of automation: tooling, proxies, CAPTCHA solvers, cloud browsers, and managed scraping infrastructure.
- Commercial defender landscape — reads vendor material as evidence about the field’s vocabulary and claimed controls, not as vendor evaluation.
- AI-agent shift — explains why browser-native automation and AI agents weaken the old boundary between human user and bot.
Sources used on this page
- Cloudflare, Bot Management docs — Cloudflare (2026). Bot Management documentation.
- HUMAN, State of Agentic Traffic — HUMAN Security / Kaiserman (2026). State of Agentic Traffic – May 2026.
- OWASP — OWASP Foundation (n.d.). Automated Threats to Web Applications (project page).
- OWASP, Automated Threat Handbook v1.3 — OWASP / Watson, C., & Zaw, T. (2026). Automated Threat Handbook: Web Applications v1.3.
- Thales/Imperva 2026 — Thales / Imperva (2026). 2026 Thales Bad Bot Report: Bad Bots in the Agentic Age.
- Wang et al. 2026, FP-Agent — Wang, Shafiq & Vekaria (2026). FP-Agent: Fingerprinting AI Browsing Agents.