Akamai Bot Manager scoring: from sensor collection to the bot-score header

A request arrives at an Akamai edge server. Before it reaches your origin, Bot Manager has already decided how much it trusts the client, expressed that decision as a number between 0 and 100, sorted that number into one of a handful of response buckets, and either let the request through, slowed it down, served it something else, or killed it outright. All of that happens in the time it takes to terminate a TLS handshake and read a cookie. The question this post answers is the part in the middle: how a pile of network signals and JavaScript telemetry becomes a single score, and what a customer actually configures on top of it.

The score itself is the easy part to describe and the hard part to reproduce. Akamai publishes the scale (0 is human, 100 is bot) and the names of the segments it groups scores into. It does not publish the weights, the feature list, or the exact field layout of the telemetry it scores. So this is a reference built from two kinds of source: Akamai’s own technical documentation and product material for the configuration and signalling side, and security-researcher write-ups for the collection mechanics that Akamai keeps deliberately opaque. Where a detail is inferred rather than documented, the text says so.

The rest of this piece walks the pipeline in order. First the signals that feed the score, split into what the edge sees for free and what the injected JavaScript collects. Then the scoring step itself, where those signals become a number, and the response segments that carve the number into actionable ranges. Then the configuration surface: categories, actions, and the progression from monitor to mitigation. Finally the headers and objects Bot Manager exposes downstream, including the one most people reach for and the one they should reach for instead.

What the edge sees before any JavaScript runs

Akamai groups its detection into a small number of methods, and the first one needs nothing from the client beyond the request itself. The documentation calls this transparent detection. It runs on the raw HTTP request and looks for the mismatches that separate an automated client from a real browser: incorrect header signatures, out-of-order headers, browser version strings that do not line up with the rest of the request, and the fingerprints of common bot-building frameworks. Akamai describes evaluating “dozens of request anomalies” and feeding the result into a calibrated risk score. None of this asks the client to do anything. It is pure observation.

Underneath the HTTP layer, the same first-request analysis includes the network fingerprint. Akamai inspects the TLS ClientHello at the edge, where the cipher ordering, GREASE values, ALPN list, and signature algorithms form a JA3 or JA4 hash that either matches a known browser profile or does not. The HTTP/2 layer adds its own fingerprint: the SETTINGS frame values, the header-frame pseudo-header ordering, and the window sizes a client negotiates are remarkably stable per stack and remarkably hard to forge from a generic HTTP library. A Go client and Chrome can request the identical URL and produce completely different HTTP/2 fingerprints. If you want the full picture of how that network layer works, the mechanics are the same ones described in TLS fingerprinting: from ClientHello bytes to JA4 and the HTTP/2 piece on DataDome’s network fingerprinting; Akamai and DataDome diverge in how they score these, not in what they measure.

The point of the first-request layer is that it produces a score before the page has loaded. Akamai is explicit that Bot Manager “looks at all anomalies, starting with the very first request.” A client that fails the TLS check, sends headers in the wrong order, and presents a user-agent that does not match its JA4 hash is already scoring high before a single line of sensor JavaScript executes. The later layers refine that number; they do not start it from zero.

*Four detection methods feed one score. The first two run on the raw request; the second two need JavaScript and, for the behavioral layer, an actual interaction.*

The sensor payload: what the injected JavaScript collects

The transparent layer can flag obvious automation, but it cannot tell a headless Chrome driving a real browser engine apart from a human using the same engine. For that, Bot Manager injects a client-side script that collects telemetry and ships it back for server-side scoring. Akamai’s documentation refers to this generically as active detection (“an interaction to confirm the request is coming from a web browser typically used only by a person”) and behavioral detection (Premier-tier analysis of “movement patterns and other interaction details unique to humans”). The script that does the collecting is widely known by its bmak global and the sensor_data field it produces.

The exact field layout of sensor_data is not public. What follows is inferred from researcher analysis of observed traffic rather than from Akamai documentation. The payload is an encoded, obfuscated string assembled from a long list of components and posted back to a path that the script chooses. Researchers who have reverse-engineered the 2.0 generation describe the payload as a large array of elements (one widely-cited write-up counts 58) that is concatenated and encrypted before transmission. The components fall into a few families.

There is environment data: the browser’s user-agent as the JavaScript sees it, screen and window metrics, timezone, language, the list of plugins and MIME types, and the results of feature-detection probes against APIs like Canvas, WebGL, and AudioContext. A Canvas hash is one of the more durable signals here because it depends on the GPU and driver stack and cannot be trivially randomized without also looking abnormal. There is timing data: how long the script took to execute, how the page’s performance counters look, and whether the timing of various operations matches a real browser running real work. And there is interaction data: pointer movement traces, click coordinates and timing, key-press intervals, touch events on mobile, and device-motion readings where the sensor is available.

That last family is the part the behavioral layer cares about most. Akamai’s Premier tier focuses behavioral analysis on “specific transactional endpoints like login or checkout pages,” which is exactly where a credential-stuffing or checkout bot has to act and exactly where a human produces messy, high-entropy mouse and keyboard traces that a script struggles to fake convincingly. The reason the server insists on real telemetry is that it verifies the payload on its own infrastructure. You do not get a trusted cookie by submitting a plausible-looking blob; you get it by submitting telemetry consistent with a real browser that actually rendered and interacted with the page. The deeper structure of this payload, including the bmak object and the fields it reads, is covered in the companion piece on Akamai’s sensor_data payload.

The collected telemetry rides in two forms. Older deployments POST the encoded sensor_data as a form field. Newer ones can carry it inline in an akamai-bm-telemetry request header, base64-style encoded, which Akamai’s reporting exposes as a distinct “inline telemetry” client type alongside standard browser telemetry and native mobile SDK telemetry. The transport changed; the role did not. Either way the score on the server is only as trustworthy as the telemetry that produced it, and the cookie is the receipt.

The cookie as the score’s carrier

The _abck cookie is where the per-session verdict lives. The first time a browser hits a protected site it receives an _abck value that is, in effect, untrusted: the sensor script has not yet run and posted its telemetry. After the script runs and the server validates the resulting sensor_data, the server reissues _abck in a validated state, and subsequent requests carry it. A second cookie, bm_sz, scopes the session and ties into a separate pixel-style challenge layer that many clients miss entirely. The detail of both cookies sits in the companion posts on the _abck cookie and its validation handshake and the bm_sz cookie and pixel challenge; for scoring purposes the thing to hold onto is that the cookie is not the score, it is a token whose server-side state reflects the score.

The chaining is what makes the cookie hard to reuse. Akamai correlates the cookie against the rest of the request fingerprint, so an _abck value validated by one browser fingerprint does not transfer to a request that presents a different TLS hash, a different HTTP/2 fingerprint, or telemetry that contradicts the earlier session. Researchers consistently describe a single mismatch invalidating the cookie and the requests that follow it. The cookie also does not reset the client’s history: once an IP and fingerprint combination has accumulated a high score, a fresh cookie does not launder it clean, because the score draws on signals that persist beyond any one cookie’s lifetime.

*The handshake. The first cookie is a placeholder; only after the server validates the posted telemetry does the reissued cookie carry a trusted verdict.*

From signals to a number

Here is where the documentation thins out and the honest answer is “Akamai does not publish this.” The bot score is the output of a model, not a hand-written rule table, and the weights are the product. What Akamai does state is the shape of the thing. The score runs 0 to 100, where 0 is a human and 100 is a bot, and it is generated by looking at all the anomalies across the detection methods, beginning with the first request and refining as more signals arrive. The company describes the scoring as self-tuning: the system learns the normal traffic pattern of each protected site and adjusts its detections to that baseline, so the same raw behavior can score differently on two different properties.

This adaptive piece is the lineage of the 2016 Cyberfend acquisition. Akamai bought Cyberfend in December 2016, a startup whose product combined machine-learning detection with what its founders described as human cognitive science, aimed squarely at credential abuse. The behavioral scoring in today’s Bot Manager Premier descends from that work. Akamai’s later product material talks about patented machine-learning models that “see traffic at the edge, assign a Bot Score for each request, and learn over time,” trained on the company’s own traffic rather than open datasets. The longer arc of how the product got here is the subject of the history of Akamai Bot Manager.

One observable behavior is worth flagging because it sits between scoring and response. Researchers note that when submitted telemetry is plausible but not convincing, the system may admit the request while deliberately slowing it, with processing delays that stretch from sub-second up to several seconds depending on confidence. That is the score expressing itself as latency rather than as a hard block, and it overlaps with the tarpit and slow actions a customer can configure. The model produces a number; the number can manifest as a delay before it ever manifests as a denial.

Two structural facts about the scoring are documented and worth stating plainly. First, the granularity that reaches customers is coarser than the raw 0-to-100. Akamai’s analytics expose bot score in buckets of 10, not as individual values, and the EdgeWorkers API exposes only the segment a request fell into, not its numeric score. The fine-grained number is an internal quantity. Second, the score and the category are separate axes. A request can be scored as very likely a bot and also be categorized as a known, allowed bot (a search engine crawler, say), and the category can override what the score would otherwise trigger. Scoring answers “is this automated”; categorization answers “and do we care.”

Response segments: turning the score into ranges

Customers do not write rules against individual score values. They configure response segments, which are named bands across the 0-to-100 range, and attach an action to each band. Akamai’s documentation names the segments and the intent behind each.

The lowest band is the cautious response, covering requests “least likely to be bots, which you should monitor.” The middle band is the strict response, covering “a mix of bot and human traffic, which you may want to test with a challenge action,” the genuinely ambiguous traffic where a challenge does double duty as a second detection pass. The top band is the aggressive response, the “highest bot scores,” which a customer “may mitigate with a strong action like Deny.” Alongside these sits a safeguard response, described as a set of requests Bot Manager holds aside for special handling, and the baseline human classification for requests that triggered no detection at all and scored zero.

These segment names are not just documentation prose; they are the literal API surface. The EdgeWorkers botScore object exposes a responseSegment with boolean predicates that mirror the segments one to one: isHuman() for the zero-score, no-detection case, then isCautiousResponse(), isStrictResponse(), isSafeguardResponse(), and isAggressiveResponse(), plus an isUnexpectedResponse() guard for segments the running code does not recognize. An EdgeWorker reading request.botScore.responseSegment.isAggressiveResponse() is asking which band the score landed in, never the raw number. The segment boundaries themselves (where cautious ends and strict begins) are customer-tunable rather than fixed constants, which is why Akamai documents the segment names but not threshold values: the thresholds are yours to set against your own risk tolerance.

*The segment names are documented; the exact cut points are not, because the customer sets them. The widths drawn here are illustrative.*

The configuration surface: categories, actions, and the climb to mitigation

Scoring is half the system. The other half is what a customer attaches to the output, and that splits along the two axes from earlier: the score-segment path and the category path.

On the category side, every Akamai-defined bot belongs to a category, and a customer assigns an action per category. Search-engine crawlers, monitoring services, and archivers are bots too; many of them are bots you want. Akamai’s own guidance is to allow or monitor the categories that matter to your business and deny the rest. Beyond the built-in library, customers create custom categories for partner or vendor bots they recognize, and they can recategorize an Akamai-defined bot into a category of their own. The action attached to a category can win over the score: a known good crawler that happens to look automated still gets the allow its category assigns.

On the score side, the action is keyed to the response segment. The action vocabulary is the same whichever path triggers it. Monitor logs the request and does nothing else, the starting position for every detection. Allow passes it through. Deny blocks it. Tarpit and the slower delay variants hold the connection open and starve the client of throughput, which is often more useful than an outright block because it wastes the attacker’s resources without immediately signalling that they were detected. Challenge actions present a CAPTCHA or a cryptographic challenge, and a conditional action lets one detection’s outcome depend on context. Serve-alternate and custom-deny actions let a customer return chosen content or a tailored error rather than a generic block page.

In Akamai’s configuration-as-code form, these map to discrete resources. The Terraform provider exposes akamai_botman_bot_detection_action, akamai_botman_challenge_action, akamai_botman_conditional_action, akamai_botman_custom_deny_action, and akamai_botman_serve_alternate_action for the action types, alongside akamai_botman_custom_bot_category and akamai_botman_custom_bot_category_action for category management and akamai_botman_transactional_endpoint_protection for the login-and-checkout behavioral layer. Most of these take their settings as JSON rather than as a spray of individual arguments, which keeps the action definitions external and versionable.

The operational advice Akamai gives is consistent and worth repeating because it is the part teams get wrong: start everything in monitor. Run the detections against real traffic, watch where your legitimate clients land in the score distribution, and only then promote individual segments and categories from monitor to challenge, tarpit, or deny once you trust that the detection is firing the way you expect. The challenge action earns special mention here because it does double duty. A challenge in the ambiguous middle band is a second detection layer, not just a gate: clients that solve it prove themselves and proceed, clients that cannot are filtered, and the customer avoids the false-positive cost of denying the gray-area traffic outright. Strong detection with a weak response strategy looks like a wall of failed blocks; strong detection with a graduated response is the point of having a score at all.

What Bot Manager forwards to your origin

The score and category do not stay locked inside Akamai. Bot Manager can forward its verdict to the origin as request headers, which is how an application backend reacts to bot traffic without re-implementing detection.

The header most teams discover first is akamai-bot. Bot Manager adds it to forwarded requests to carry its bot determination downstream, and it is conditional: the header is only present when Akamai’s upstream rules concluded the requestor is a bot. If the request is judged human, the header is simply absent, so origin code has to treat absence as the human case rather than expecting an explicit “not a bot” value. A related header, akamai-user-risk, carries a user-risk score and is likewise sent only when Akamai actually computed one, for instance on a login request that account-protection features evaluated. Integrations like Auth0’s Akamai connector consume exactly these two headers as supplemental signals, surfacing them as akamai.akamaiBot and akamai.akamaiUserRisk fields inside the login pipeline.

A caveat on naming, because it trips people up. The angle of this post mentions an akamai-bot-category style of response signalling, and that is a reasonable mental model for what gets forwarded, but the documented header that carries the bot verdict to origin is akamai-bot, not a header literally named akamai-bot-category. The forwarded headers are conditional and their exact set depends on configuration and product tier, so the safe statement is that Bot Manager exposes its bot determination and user-risk score to origin through dedicated akamai-* headers, with akamai-bot being the one consistently documented. Where you need the category or the response segment rather than a binary bot flag, the cleaner path is not an origin header at all but EdgeWorkers, where the botScore.responseSegment object hands you the segment programmatically at the edge before the request is ever forwarded.

*Two ways to read the verdict. Forwarded headers reach your origin but carry a coarse, conditional signal; the EdgeWorkers object gives you the response segment at the edge.*

What this pipeline actually constrains

Strip away the product names and Bot Manager scoring is a funnel that narrows trust at every stage. The edge scores you on bytes you cannot avoid sending. The injected script scores you on telemetry that has to come from a real rendering engine doing real work. The cookie binds that verdict to a specific fingerprint and refuses to travel. And the customer-side configuration decides, per score band and per category, whether the verdict turns into a log line, a delay, a puzzle, or a closed door. Each layer is individually beatable in a lab; the funnel is hard because the layers cross-check each other, and a number that drifts in one of them pulls the whole session’s score with it.

The honest boundary of any reference like this is the model in the middle. Akamai publishes the scale, the segment names, the action vocabulary, and the forwarded headers, and all of that is reproducible from the documentation. It does not publish the feature weights, the exact sensor_data layout, or the precise rule that turns a Canvas hash and a mouse trace into a 73 rather than a 41. Those are the parts this post sourced from researcher observation and labelled as inferred, and they are exactly the parts Akamai will keep changing, because a published scoring function is a solved scoring function. The configuration surface is stable enough to build against; the score underneath it is a moving target by design.

One concrete thing to carry away: the coarseness is deliberate and it cuts both ways. Customers get scores bucketed to tens and segments rather than raw values, which is enough to act on and not enough to reverse-engineer the boundary. Anyone studying the system from outside gets the same coarse view through the cookie and the headers, plus whatever latency the tarpit decides to spend on them. The score is precise inside Akamai and intentionally blurry everywhere it is exposed, and that blur is itself part of the defense.

---

Sources & further reading

• Akamai (2024), Detection methods — the five detection methods (Akamai-validated, custom-categorized, transparent, active, behavioral) and what each evaluates.
• Akamai (2024), Handle adversarial bots — the cautious/strict/aggressive response segments, the 0-100 scale, and the monitor-to-mitigation progression.
• Akamai (2024), BotScore object — the EdgeWorkers responseSegment API with isHuman, isCautiousResponse, isStrictResponse, isSafeguardResponse, isAggressiveResponse.
• Akamai (2024), Define bot responses (Terraform) — the akamai_botman_* action and category resources used to configure responses as code.
• Akamai (2024), Security analytics dimensions — confirms bot score is reported in buckets of 10 and lists the bot category, score, and response-segment dimensions.
• Akamai (2016), Akamai Acquires Cyberfend — the December 2016 acquisition that brought the machine-learning behavioral detection into Bot Manager.
• Akamai (2024), Building an Effective Bot Management Strategy — Akamai’s own guidance on using the score, the green/gray/red traffic model, and challenge-as-second-detection.
• Auth0 (2024), Configure Akamai to Send Supplemental Signals — documents the akamai-bot and akamai-user-risk forwarded headers and their conditional presence.
• xiaowei (2024), Decoding Akamai 2.0: sensor_data and akamai-bm-telemetry — researcher analysis of the encoded sensor payload, the element array, Canvas fingerprint and motion components.
• Scrapfly (2026), Bypass Akamai Bot Manager — researcher write-up of the layered TLS/HTTP2/cookie scoring stack and the fingerprint-coherence requirement.
• The Register (2016), Akamai buys bot-sniffing startup Cyberfend — independent reporting on the acquisition and Cyberfend’s detection focus.