Akamai Bot Manager Cookies Explained: _abck, ak_bmsc, bm_sz, bm_sv

Akamai Bot Manager cookies are how Akamai keeps track of what it has already decided about your client. bm_sz arrives first, usually on the first HTML response, and lives about four hours. ak_bmsc and bm_sv are short session cookies of about two hours. _abck is the persistent one, typically set for a year: it records whether your browser's client-side checks have been accepted. Their values are encrypted and undocumented. What you can read from them is which cookies you hold, when they change, and whether they stay with one client on one IP.

Akamai Bot Manager cookies at a glance

Akamai does not publish a field-by-field specification for these cookies. The most reliable public information is cookie disclosures: Akamai's own product docs and cookie pages, and the cookie policies of sites that run Bot Manager. The table below combines them. Where sources disagree, the table says so.

Sources: the RIPE NCC cookie list gives all five, classed as strictly necessary, with 1 year for _abck, 4 hours for bm_sz and 2 hours for ak_bmsc, bm_sv and bm_mi. cookie.is lists the same lifetimes for _abck, bm_sz, ak_bmsc and bm_sv. Akamai's Identity Cloud cookie table gives the bm_sv description and HttpOnly/Secure/SameSite flags for ak_bmsc and bm_sv. Akamai's own cookie preferences page files _abck, ak_bmsc and bm_sv under strictly necessary and bm_sz under performance.

Two practical warnings. First, every one of these attributes is set per deployment, so the lifetimes above are typical, not guaranteed. Read the actual Set-Cookie headers on the site you work with. Second, newer deployments set additional cookies whose names you may see in DevTools. We found no reliable public description of them, so they are left out here.

_abck: the cookie that carries the verdict

_abck is the persistent cookie that reflects whether your browser has passed Akamai's client-side checks. It is first issued in an unvalidated state, then rewritten by the server each time the Bot Manager script reports in. It typically has a one-year expiry, but the "validated" state inside it lasts much less time than the cookie does.

Its value is a long encrypted string with tilde-separated sections. The only parts anyone discusses are short markers like ~-1~ and ~0~. Treat what follows as community observation. Akamai has never documented these markers, and one detailed write-up, Scrapfly's, explicitly advises against inferring fixed fields from the value at all. The reading that independent sources agree on is roughly this:

• ~-1~ in the early position: the client has not yet satisfied the client-side check. This is the state a fresh _abck arrives in, and the state it stays in if no acceptable telemetry ever arrives.
• ~0~ in that position: the check is satisfied for now. The common description is a client-side "stop signal" that tells the page script it can stop sending telemetry.
• A validated cookie can be reset. Protected endpoints can issue a new _abck that puts you back into an unvalidated state, for example before a login or checkout.

The Crawlex write-up gives the same reading and stresses that it comes "entirely from people watching the cookie change". The important consequence is what ~0~ does not mean. It is not an access pass. Akamai still scores every request on IP reputation, protocol fingerprints and request patterns, and a ~0~ cookie presented from a different client or network can fail. Akamai's own Bot Manager quick start lists a detection called Cookie Integrity Failed, which "ensures that no bot operator has tampered with or is trying to replicate a Bot Manager cookie". So a copied _abck is exactly what the system is built to catch.

Because the page script reads this marker, _abck is generally not HttpOnly; you can usually see it in document.cookie. We have not found an Akamai statement on this, so confirm it on the site you are testing.

bm_sz: the session seed

bm_sz is usually set on the very first HTML response from a protected host, before any Bot Manager JavaScript has run, and it lasts about four hours. Technical write-ups such as Crawlex's bm_sz analysis describe it as the per-session input the client-side script works from. That is why a bm_sz from another session or origin breaks everything that follows. If a client never receives bm_sz, the protected page probably did not go through Bot Manager at all, which is useful to know when debugging.

ak_bmsc: the short-lived session cookie

ak_bmsc is a roughly two-hour session cookie. Disclosures describe it as distinguishing humans from bots, and Akamai's Identity Cloud docs also describe it as "used to optimize performance". Write-ups disagree on its HttpOnly flag. Akamai's own Identity Cloud table says HttpOnly: false, while several scraping blogs say it is HttpOnly, which suggests the setting differs between deployments. If it disappears mid-session, the usual cause is that two hours have passed or that your client dropped cookies.

bm_sv and bm_mi

bm_sv is the one cookie Akamai describes directly ("used by Akamai Bot Manager to help differentiate between web requests generated by humans and web requests generated by bots or other automated processes"). It lasts about two hours. Akamai's quick start also lists a Session Validation detection that "counts the number of HTML page and AJAX requests that come from a client". The naming suggests a link to bm_sv, but nothing public confirms it, so do not rely on that. bm_mi appears in some deployments' disclosures with a two-hour lifetime and no further detail.

How the sensor flow works, conceptually

Bot Manager works in layers. The edge evaluates every request on its own, and a JavaScript layer in the browser adds client-side evidence that is recorded in _abck. Akamai's quick start names the main detections:

• Impersonators of known bots: fake Googlebot and similar.
• User-agent based detection and request anomaly detection: inconsistencies within a request.
• Web scraper reputation: "a bad reputation score to IP addresses that have recently engaged in scraping activity".
• Cookie integrity, session validation and browser validation: "confirms that requests come from a real web browser".
• Behavior anomaly detection: Premier only, on transactional endpoints such as login and checkout.

Akamai's current detection methods page describes the same split: transparent detection catches "out-of-order headers and browser version mismatches", while active detection "employ[s] an interaction to confirm the request is coming from a web browser".

The cookie lifecycle follows from that design:

1. The first response from a protected host sets bm_sz and an unvalidated _abck, and the page loads Akamai's script.
2. The script collects client signals in the browser (environment, timing and, on some pages, interaction) and posts them to a first-party endpoint on the same site.
3. Akamai scores the submission together with the request-level signals and returns a Set-Cookie that updates _abck.
4. Later requests carry the cookies. The edge checks that they are intact, belong to this session and fit the rest of what it sees.

Out of scope: this article does not describe the sensor payload, how to generate it or how to construct cookie values. Forging Akamai telemetry is exactly what Cookie Integrity and related detections exist to catch, and it is not something we help with. For the wider signal picture, including TLS and HTTP/2 fingerprints, see our Akamai Bot Manager deep-dive.

Why HTTP-only clients get stuck with an invalid _abck

An HTTP library like requests, httpx or Go's net/http does not execute JavaScript, so the Bot Manager script never runs and nothing ever updates _abck. The client keeps sending the unvalidated cookie it received on the first response. On pages where Akamai requires browser validation, that is the expected result.

Fixing TLS does not change this. An impersonation library can make the handshake and HTTP/2 frames look like Chrome, but it cannot produce the client-side evidence the script would have produced. What usually happens in practice: pages that only use the transparent layer keep working, while pages that need active validation (logins, carts, search APIs on some sites) start returning 403s or challenge pages.

Before choosing your tools, ask which pages you actually need. A lot of public data is available without the active layer, and a site's official API or data feed is often a better answer than automating a browser.

What a real browser on a clean, consistent connection does differently

A real browser runs the script, keeps its cookies, sends one consistent TLS and HTTP/2 fingerprint, and stays on one network for the whole session. That combination is what moves _abck to its validated state and keeps it there. Each part matters:

• Keep the cookie jar for the whole session. If you drop cookies between requests, every request looks like a first visit: new bm_sz, unvalidated _abck, and the script has to run again. In Playwright, one browser context is one cookie jar. Do not open a new context per page.
• Keep one exit IP per session. Cookies issued to a session on one IP and replayed from another look like the replication that Cookie Integrity is designed to catch. If you rotate IPs mid-session, the cookies stop matching the network they were issued on. Use a sticky session for anything with state (browsing a category, a cart, a logged-in flow) and rotate only between sessions. Our sticky vs rotating sessions guide covers how to size them.
• Start from a clean IP. Web Scraper Reputation is scored per IP. A datacenter range with a scraping history starts out under suspicion before any cookie is set. Residential and mobile IPs carry different reputation baselines; our IP reputation deep dive explains how those scores are built.
• Request at a human-plausible rate. Session Validation literally counts HTML and AJAX requests per client. A valid _abck will not save a session making hundreds of page requests a minute.

A minimal Playwright setup that respects these rules looks like this. One persistent context, one sticky residential exit, and saved state so the next run continues the same session instead of starting over:

from pathlib import Path
from playwright.sync_api import sync_playwright

STATE = Path("state.json")
PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "USERNAME-sid-abc123-ttl-10m",   # sticky: same exit IP for this session
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY)
    context = browser.new_context(
        storage_state=str(STATE) if STATE.exists() else None
    )
    page = context.new_page()
    page.goto("https://www.example.com/", wait_until="load")
    # ... a small number of navigations, at a human pace ...
    names = sorted(c["name"] for c in context.cookies())
    print(names)                                # see which Akamai cookies you hold
    context.storage_state(path=str(STATE))      # keep the jar for the next run
    browser.close()

Tie the saved state to its session ID. If you resume state.json through a different exit IP, you recreate the IP-change problem you were trying to avoid.

Troubleshooting: symptom, likely cause, what to check

Check one variable at a time. Most "Akamai is blocking me" reports turn out to be one of the first three rows. An unhelpful but honest answer also belongs in this table: sometimes the site has decided not to serve automated traffic on that path, and the right response is to stop, or ask for access.

For site owners: reading these cookies in your own logs

If you run Bot Manager, log the cookie names and the _abck state marker, not the values, and use Akamai's own bot results for decisions. The values are encrypted and the format can change without notice. Patterns you can get from a normal access log:

• Requests to deep URLs with no bm_sz or _abck at all. These are cookieless clients: either first hits or tools that discard cookies. A high share on product or search URLs, with no matching landing-page hits, suggests scripted access.
• The same _abck value seen from many IPs or ASNs. This is cookie sharing or replay. Akamai's Cookie Integrity detection is built for it. Your logs let you see how big the problem is and which paths are affected.
• Sessions that stay unvalidated for many requests. This usually means clients that never execute your pages' JavaScript. Check this before tightening rules, because privacy extensions and broken script delivery cause it too.
• Origin-side bot results. Akamai can forward its verdict to your origin as request headers. Auth0's integration guide documents the akamai-bot and akamai-user-risk headers and points to Akamai's "Forward Bot Results to Origin" configuration. A supported field like this beats parsing cookie internals.

On privacy: these cookies are identifiers tied to a device. Disclosures such as RIPE NCC's class them as strictly necessary, which in the EU generally means they don't need consent. Logs that keep raw values together with IPs are still personal data, so hash or drop the values once you have the marker and the name set.

What these cookies do not tell you

A cookie can show that client-side validation has not happened yet. It cannot show that a request will be allowed. Request-level detections (IP reputation, protocol fingerprints, header anomalies, rate) run independently of _abck, and site owners set per-path policies you cannot see from outside. When debugging, use the cookies as one signal and the response codes, challenge pages and timing as the others.