What Akamai Bot Manager checks, from the handshake to the cookie

You open a retailer or airline site, the page half-loads, and every API call behind it returns 403. Somewhere in the response headers or the cookie jar you find _abck and bm_sz. That is Akamai Bot Manager. This post sticks to what Akamai itself publishes, plus one site operator's cookie notice, and leaves out internals Akamai does not document.

A score on every request, from the first one

Akamai's product page says Bot Manager "generates a score from 0 (human) to 100 (bot), looking at all anomalies, starting with the very first request". The site owner maps score ranges to three response segments that Akamai names Cautious (watch it), Strict (challenge it) and Aggressive (mitigate it), and choose what each segment gets.

Two more details from that page matter here:

• Known bots are a separate track. Akamai keeps a directory of known bots and lets customers define their own categories, so a declared bot is classified by name rather than scored as a suspicious human.
• "Stealthy defenses that go beyond block-and-allow actions" is listed as a feature. A high score does not have to produce an error page you can see.

The handshake, read before any page exists

Akamai holds a US patent, US11799908, on "bot detection in an edge network using transport layer security (TLS) fingerprint". The method it describes hashes fields of the TLS Client Hello: record layer version, client version, and the ordered lists of extensions, cipher suites, elliptic curves and signature algorithms. That hash is then checked two ways: against a table of user agent and TLS fingerprint pairs seen in real human traffic, and against published bad signatures built from the tuple of fingerprint, header order and user agent.

A patent describes a method, not what runs in production today. It still shows what Akamai considers worth checking: whether the handshake and header order agree with the browser your User-Agent names.

HTTP/2 is the second half of that layer. Two Akamai researchers presented "Passive Fingerprinting of HTTP/2 Clients" at Black Hat Europe, built on more than 10 million HTTP/2 connections and fingerprints for over 40,000 user agents. Each HTTP/2 implementation opens a connection in its own recognisable way. Our post on TLS fingerprinting, JA3 and JA4 covers how those hashes are built.

The page script and the cookies

The second layer runs in the browser. Akamai says behaviour anomaly detection "is configured automatically by injecting a simple script into each monitored page", and lists AI models for user behaviour analysis and browser fingerprinting among its detection methods. Third-party write-ups usually call what that script posts back "sensor data". Akamai does not publish its contents, so this post does not describe them.

What you can see is the cookies. Akamai's own Identity Cloud documentation describes bm_sv as a "cookie used by Akamai Bot Manager to help differentiate between web requests generated by humans and web requests generated by bots or other automated processes". The RIPE NCC, which runs Bot Manager on its site, publishes a cookie notice listing five such cookies as strictly necessary for Akamai's Bot Management service:

Cookie	Lifetime in that notice
_abck	one year
bm_sz	four hours
ak_bmsc	two hours
bm_sv	two hours
bm_mi	two hours

Another operator's notice can list different lifetimes. The pattern is what matters: one long-lived cookie, several short ones.

What this means for a multi-account setup

A one-year cookie is a memory. Three consequences follow without guessing at Akamai's internals.

Wiping cookies every run makes you a permanent first visit. Automation that starts from an empty context arrives without the state Akamai set last time, every time. A profile that keeps its cookie jar is a returning visitor because it is one. Our guide to Playwright persistent contexts covers how to keep that state in plain Playwright.

Copying one cookie jar into several identities links them. Ten accounts presenting one long-lived Akamai cookie from ten fingerprints are linked by the cookie. Each identity needs its own jar, built by its own visits.

Blocking the script is not neutral. If the injected script never runs, nothing is reported back. Request interception rules that drop scripts can do that by accident.

When this is the wrong tool

If you fetch public data and your only problem is the handshake, plain Playwright already sends a real browser's TLS and HTTP/2, no profile tooling needed. If you run one account from your own machine, ordinary Chrome is the right setup.

If the site owner has put your network or bot category in the Aggressive segment, nothing on your side changes that. No browser, ours included, buys a better address history. AntiBrow keeps a separate local profile per identity, with its own cookie jar and its fingerprint applied in the engine, and free local profiles are unlimited. That helps with per-identity state, not with a site that has decided against your traffic.

Check it yourself

Open DevTools on the site, then Application, then Cookies. If _abck and bm_sz are there, Akamai is in front of it. Close the browser, reopen the same profile and check that _abck survived. If it did not, your setup throws away the state Akamai set on the last visit. For where this fits among other vendors, see how anti-bot systems work.

Sources, fetched 2026-10-22: Akamai Bot Manager product page, Akamai Identity Cloud cookie docs, US11799908 at Google Patents, Akamai HTTP/2 fingerprinting slides, RIPE NCC cookie notice.