How Akamai Bot Manager Works (2026)

Akamai is a reverse-proxy WAF — a security gateway (Web Application Firewall) that every request passes through before reaching the website behind it. It runs at the CDN edge, meaning on the nearest Akamai server to the visitor. Each request gets a trust score based on four things: IP reputation (does this address look trustworthy?), the _abck sensor data, the way the connection's encryption is set up (the TLS handshake), and behavioural telemetry (how the visitor acts). Akamai's ASN database — its map of which company owns which blocks of IP addresses — is unusually thorough, because the company has been routing internet traffic for over two decades.

Low-trust requests surface as one of:

• A silent 403 (access denied) with an invalidated _abck cookie. Akamai marks the cookie with ~-1~ or ~0~ to signal the session is burned.
• A Pardon Our Interruption block page.
• A redirect to a CAPTCHA endpoint.

1. IP address reputation

Where your IP address comes from sets a starting trust level:

• Datacenter IPs (AWS, GCP, Azure, DigitalOcean, OVH…) — addresses owned by cloud/hosting companies, pre-scored low. Even "clean" datacenter ranges tend to be flagged because Akamai's ASN data is broad.
• Residential IPs — assigned by ISPs to home connections, higher baseline trust.
• Mobile IPs — cell tower and CGNAT pools (the shared addresses phone carriers hand out), highest baseline trust.

2. The Akamai sensor and the _abck cookie

This is the layer Akamai is best known for. Every protected page loads a deliberately scrambled sensor script — usually from a path like /akam/13/... or /_bm/_data. This script quietly inventories your browser: canvas and WebGL fingerprints (tiny images and 3D scenes it draws, whose exact pixels vary by device), audio context, installed fonts, screen metrics, timezone, language, plugin list, the navigator.webdriver flag (true when automation is driving the browser), the exact shape of the window.chrome object, plus how your mouse moves and how fast you type.

The sensor then POSTs an encrypted bundle of all this back to the edge, which sets or refreshes the _abck cookie. That cookie has a fixed internal layout (~timestamp~status~hash~), and a valid one is required for later requests. A malformed or stale _abck is the single most common reason automated clients get a 403. Akamai also specifically tests for navigator.webdriver, the headless Chrome user-agent marker (the giveaway string when Chrome runs with no visible window), and inconsistencies in the permissions API.

3. HTTP and TLS fingerprinting

Akamai is widely credited with pioneering HTTP/2 fingerprinting in the WAF space — identifying clients by the low-level quirks of how they speak the protocol, not by what they claim to be.

• Most scraping libraries still default to HTTP/1.1. Real Chrome and Firefox haven't in years.
• libcurl and Go's net/http produce JA3 signatures — fingerprints of the TLS (https encryption) handshake — that don't match any real browser.
• HTTP/2 fingerprinting tracks pseudo-header order, SETTINGS frame values, and window-update sizes — connection-setup details a browser sends automatically and a script usually gets subtly wrong.

4. Behavioural and pattern analysis

Akamai correlates behaviour across sessions — once an IP/fingerprint combo builds up a low score, even a fresh _abck cookie won't rescue it. Signals include:

• Missing real-browser headers (Sec-Fetch-*, Accept-Language, sec-ch-ua).
• _abck or bm_sz cookies from the previous response sent from a different IP (a sign cookies are being shared around).
• Honeypot link hits — clicking links hidden from real users but visible to scrapers.
• Bursty timing — many requests fired faster than a human could.
• Identical sensor payloads reused across pages.

The _abck cookie is the focal point: nearly every Akamai workflow comes down to minting a valid one and keeping it valid. Three general tooling categories:

• HTTP clients with browser-impersonating TLS — curl_cffi, curl-impersonate, tls-client. These copy a real browser's handshake, but they can't run the JavaScript sensor, so they can't mint a real _abck.
• Stealth-patched browsers — Camoufox, patchright, Playwright with stealth plugins. These run the sensor inside a genuine browser, so the cookie comes out valid.
• Managed scraping APIs — services that bundle proxies, patched browsers and session persistence behind a single endpoint.

Reusing the same session value across requests keeps the _abck/bm_sz cookies and the trust score warm. Starting a fresh session every request forces the sensor to re-validate from scratch each time — which is exactly what scripted clients look like.

E-commerce, ticketing, jobs, logistics and social sites. Many of these rotate between Akamai, Cloudflare, DataDome and PerimeterX depending on conditions.

Akamai builds a continuous trust score from four inputs: IP reputation, the _abck JavaScript sensor, TLS/HTTP/2 fingerprints, and behaviour tracked across sessions. The _abck cookie is the single most telling signal — its internal ~status~ field says outright whether the session is trusted, burned, or in a challenge state. Akamai pushes sensor updates on a rolling basis, so the exact on-the-wire details change often while the four-layer structure stays the same.