How Akamai Bot Manager Works
Akamai Bot Manager is the bot-detection layer of Akamai's CDN and security platform, used by large enterprises across retail, banking, and media. Here's a neutral look at the telemetry it collects and how it decides at the edge.
Quick Answer
Akamai Bot Manager runs client-side JavaScript that collects telemetry — mouse movement, keystroke timing, touch, and device/browser properties — and packages it as a sensor payload that Akamai's edge validates. A separate product, Account Protector, targets account abuse and takeover.
- →The client script is widely referenced as the bmak sensor producing sensor_data
- →Akamai techdocs expose JA4 client TLS fingerprint settings APIs
- →Blocks usually return an error (often HTTP 403) rather than a visible puzzle
This guide explains how Akamai Bot Manager detects automation. It is not a bypass walkthrough. Some implementation details below are community-understood rather than official Akamai documentation; we flag which is which, because accuracy is the point.
The client-side sensor (bmak / sensor_data)
Akamai Bot Manager loads client-side JavaScript — commonly referenced in the security community as the bmak sensor — that collects telemetry about how the client behaves: mouse movement, keystroke timing, touch events, and a range of device and browser properties.
This telemetry is packaged into a payload widely documented as sensor_data and sent back to be validated at Akamai's edge. A request that lacks coherent, browser-consistent sensor data — or never produces any — looks unlike a real interactive session.
The _abck and ak_bmsc cookies
Two cookies are widely documented in the security community (this is community-understood, not Akamai-official terminology):
- →
_abck— the bot-management cookie, validated against the sensor payload - →
ak_bmsc— a Bot Manager session cookie
The relationship between the cookie state and the sensor data is what the edge checks: the cookie is only considered valid once the client has produced telemetry consistent with a real browser session.
JA4 TLS fingerprints and Account Protector
Akamai's official techdocs expose API endpoints to get and modify JA4 client TLS fingerprint settings for App Security — so JA4 support is documented. JA4 summarizes how a client negotiates its TLS handshake, which often differs between a real browser and an automation library.
Alongside Bot Manager, Account Protector is Akamai's product aimed at account abuse and account-takeover (ATO) — focusing on login and account-level risk rather than general bot traffic.
What the block looks like
Unlike CAPTCHA-style products, an Akamai block typically returns an error or denial — often an HTTP 403 with an Akamai reference code — rather than presenting a visible puzzle to solve. The decision happens at the edge before the request reaches the origin.
Why mobile / CGNAT IPs are treated differently
Edge enforcement has to reckon with the fact that mobile carrier IPs sit behind Carrier-Grade NAT (CGNAT): thousands of real subscribers share a single public address. A block applied to that address hits a crowd of legitimate humans, not one isolated bot.
Cloudflare documented this constraint in its October 29, 2025 blog, "detecting CGN to reduce collateral damage." Cloudflare reported CGNAT IPs were being rate-limited about 3× more often than non-CGNAT IPs despite showing lower bot activity, and built CGN detection specifically to avoid punishing the many humans sharing those addresses.
This is a documented defender design constraint, not a bypass. It explains why mobile carrier IPs tend to receive higher default trust at the network layer — the cost of over-blocking them is high. See CGNAT and mobile proxies.
Sources
Related Guides
Test on real mobile carrier IPs
Genuine 4G/5G IPs in the USA, UK, and Netherlands for legitimate, compliant data work. Test it for $5.