How Akamai Bot Manager Detects Bots

Sensor data

The most visible part of Bot Manager is a script the site serves with its pages. Akamai's Bot Manager page says behavior anomaly detection "is configured automatically by injecting a simple script into each monitored page". That script observes the browser and the visitor's interaction and reports back, and the result travels with later requests in cookies.

Sites that run Bot Manager commonly list cookies named _abck and bm_sz in their cookie notices, described as distinguishing people from automated traffic. The names are a recognition aid only. Their contents are encoded and change with Akamai's releases, so treat any public description of the fields as a snapshot.

What the script can learn falls into three groups, and each is a standard browser capability rather than anything exotic:

• Device and environment. Screen and window geometry, available fonts, graphics and audio behavior, language, time zone, and whether automation flags such as navigator.webdriver are present.
• Interaction. Pointer movement, touch events, key timing and scrolling, and the rhythm between them. A form filled in at machine speed, or a click with no pointer path before it, reads differently from a person.
• Consistency over time. Whether the same session keeps telling the same story about the device on every page.

Akamai describes the result as a Bot Score "from 0 (human) to 100 (bot)" produced by "patented technologies with an AI framework". The site owner maps score ranges to actions, which is why two Akamai sites can treat the same client differently.

TLS and HTTP/2 fingerprints

Before a single header is read, the client has already described itself through the way it opened the connection.

The TLS Client Hello

In a 2019 research post, Bots Tampering with TLS to Avoid Detection, Akamai's threat research team explained that fingerprinting looks at "the way clients behave during the establishment of a TLS connection", using the Client Hello that every handshake sends in clear text. The cipher suites a client offers, the extensions it includes and their parameters differ between Chrome, Firefox, Safari and the TLS libraries behind Python, Go or Java.

The same post documented what Akamai named cipher stunting: tools that randomized their cipher list on each connection to avoid a stable hash. The randomization started in late 2018 and grew from tens of thousands of instances to billions within months. The lesson for anyone building a client is that randomness is not camouflage. A browser has a recognizable fingerprint; a client that has a new one every time does not look like any browser. Modern fingerprints such as JA4 also sort the fields before hashing, so reordering does not change the result. Our JA3 vs JA4 guide shows this with working code.

HTTP/2 settings and frame order

At Black Hat Europe in December 2017, Akamai researchers presented Passive Fingerprinting of HTTP/2 Clients. Their proposed fingerprint combines four things a client sends at the start of every HTTP/2 connection: the parameters in its SETTINGS frame, its initial WINDOW_UPDATE increment, its PRIORITY frames and the order of its pseudo-headers (:method, :authority, :scheme, :path). The HTTP/2 specification requires the SETTINGS frame at the start of every connection but leaves the values to each implementation, so browsers and libraries end up with distinct, stable combinations.

The talk listed detecting browser impersonators among the use cases. A request with a Chrome user agent and an HTTP/2 preamble typical of a scripting library describes two different clients at once.

You can see your own TLS fingerprint with the JA4 fingerprint checker. Compare the result from your automation browser with the result from a normal browser on the same machine.

IP reputation

Akamai sees a large share of web traffic, and its bot products draw on what its network observes about addresses: which networks they belong to and what they have been doing recently. Akamai does not publish its reputation logic in detail, so the safe assumptions are the general ones.

• Hosting and data center ranges are easy to classify. Most people do not browse from a cloud server, and public databases such as MaxMind's Anonymous IP database label hosting providers, VPNs and public proxies separately.
• Mobile carrier ranges carry many real subscribers behind carrier-grade NAT, so they are labeled as carrier networks, the same as a phone on that carrier.
• Recent behavior from an address colors the next request from it. A dedicated line has only the history of the one customer who uses it.

Reputation sets the starting point, and it is only one input to the score. A clean address with a mismatched TLS fingerprint and a scripted interaction pattern still scores as a bot. Check how your exit is classified with the ASN lookup and the IP reputation check, then move on to the client.

Behavior

Behavior is where a session that passes the first request often fails the tenth. The page script keeps reporting, and the server sees the sequence of requests.

Patterns that read as automated, regardless of the network:

• Requests at a fixed interval, or bursts no reader could produce.
• Navigation that skips the pages a person passes through, such as fetching product APIs directly without loading the product page.
• Forms completed without focus, typing or pointer events.
• One session spread across many addresses, or many sessions packed onto one address.

Akamai's product page also describes response options that change what the client experiences rather than blocking it: slowing bots during peak traffic, serving cached or alternate content, and challenging suspected bots so that attacks become more expensive. A collector can therefore receive a 200 response with stale or altered data and never see an error. If prices or stock levels look wrong in your results, verify them in a normal browser before trusting the pipeline.

What a stable client needs

This section is for permitted work only: testing your own Akamai-protected site, running QA for a client who has authorized it, or monitoring public pages whose terms allow automated access. For everything else, the answer is to ask for access.

1. A real browser engine, current and headed. The TLS and HTTP/2 fingerprints come from the engine. A scripting library cannot produce a browser's connection preamble, and impersonation libraries are a moving target that Akamai has been studying since 2017.
2. One device story. The user agent, client hints, screen, fonts, language and time zone should match one real configuration. Do not mix a mobile user agent with a desktop screen size.
3. Matching operating system signals. The TCP/IP header defaults of the machine that sends the packets should not contradict the operating system the browser claims. TCP/IP fingerprinting and p0f explains this layer and the OS fingerprint setting available on some lines.
4. A network that fits the story. A carrier address for mobile scenarios, a matching country for localized pages, and no WebRTC or DNS leak revealing a second location. Coronium's mobile proxies are dedicated devices with their own SIM, one customer per line, over HTTP or SOCKS5.
5. Session discipline. Keep one session on one IP, let the page load the way a browser loads it, and space requests per host. Rotate the IP between sessions, never inside one.
6. Verification over volume. If you run a legitimate crawler or agent, Akamai lets organizations verify a bot or AI agent so that site owners can allow it by identity. That route keeps working after the next client-side update.

For the broader picture of how these layers combine across vendors, see how websites detect proxies. For the other two large vendors, see the guides to Kasada and DataDome.

Frequently asked questions