Akamai Bot Manager
CDN and WAF
Also known as: Akamai, AkamaiGHost, Kona Site Defender
Denies with a 403 Access Denied page carrying a reference number, and is unusual in offering operators a deliberately ambiguous 200 response and a tarpit that never answers at all.
Akamai Bot Manager runs on the same edge as Akamai's CDN, so its responses arrive with ordinary CDN headers and the bot decision is layered on top. The classifier is fed by a sensor script that posts a fingerprint payload and by the _abck cookie that carries the resulting verdict, so a request that never ran the script arrives already unverified.
What sets Akamai apart is the breadth of response actions available to its customers. Alongside a conventional deny, operators can choose actions that do not look like blocks: serving alternate content on a 200, slowing a connection to the point of uselessness, or simply not responding. That makes status-code-only detection unusually unreliable in front of an Akamai site, because a successful-looking response can carry a denial page in its body.
Akamai's Bot Manager documentation sits behind a customer login, so the response details below are drawn from observable wire behaviour rather than from published specifications, and the specific action a site uses is a per-customer configuration choice.
How to identify it
- akamai-grn on the response is the Akamai global request number and is the most reliable positive marker. It appears on ordinary allowed traffic too.
- server: AkamaiGHost, server: AkamaiNetStorage, or a customer-renamed edge server value.
- The _abck and ak_bmsc cookies are Bot Manager deployment markers.
- A block page reading Access Denied with a Reference # value, or the softer Pardon Our Interruption wording.
- x-akamai-transformed on responses that passed through Akamai's optimisation pipeline.
Headers
- akamai-grn: Global request number. This is the reference an Akamai customer needs in order to look up a specific request in their logs, so capture it whenever you report a false positive.
- server: Often AkamaiGHost or AkamaiNetStorage, though customers routinely rename it, so absence proves nothing.
Cookies
- _abck: The Bot Manager verdict cookie. Set on first contact and updated when the sensor posts its payload. Its presence indicates Bot Manager is deployed, not that the client passed.
- ak_bmsc: Bot manager session cookie, set at the edge and used to carry session state between requests.
- bm_sz: Session-scoped companion cookie seen alongside ak_bmsc on Bot Manager deployments.
Status codes
403 Access Denied
Blocked. Observed behaviour.
The classifier or a WAF rule denied the request. This is the standard Bot Manager deny action.
What triggers it
- A TLS or HTTP/2 fingerprint that does not match the browser the User-Agent claims.
- A missing or stale _abck verdict, which is what happens when the sensor script never ran.
- Address reputation, or a request rate above a configured rate control.
How to confirm it
- A body containing Access Denied and a Reference # value.
- akamai-grn on the response.
- Sometimes a mime-version header, which is unusual enough on a normal page response to be a hint.
What to do about it
- Record the reference number and the akamai-grn value. These are the only identifiers a site operator can use to find your specific request, and a false positive report without them is very hard to act on.
- Check whether you are reaching the site in a way that could never run its client-side script. If so, the verdict cookie will never be valid and the denial is structural rather than incidental.
- Approach the site operator for API access or an allow rule. Akamai cannot lift a customer's decision on your behalf.
HTTP/2 403 server: AkamaiGHost mime-version: 1.0 akamai-grn: 0.1a2b3c4d.1780000000.1e2f3a4b content-type: text/html <HTML><HEAD><TITLE>Access Denied</TITLE></HEAD><BODY> <H1>Access Denied</H1> You don't have permission to access "http://example.com/" on this server. <P>Reference #18.1a2b3c4d.1780000000.1e2f3a4b</P>
429 Rate control triggered
Rate limited. Observed behaviour.
A rate control policy fired. Worth noting that this can appear on a low request count, because Akamai rate controls can be scoped to a shared address or network rather than to your session.
What triggers it
- Exceeding a configured request rate for a path, an address, or a network.
- Sharing an address with other traffic that is consuming the same budget.
How to confirm it
- akamai-grn on the response, and sometimes retry-after.
What to do about it
- Back off and reduce concurrency. Unlike the 403, this one clears on its own.
- If a single request draws a 429, the counter is almost certainly not counting only you. That points at the address rather than at your pacing.
200 Deny page served on a success status
Deceptive. Observed behaviour.
The status line says success and the body is a denial or an alternate page. Serving deceptive content is an available Bot Manager response action.
What triggers it
- An operator choosing an action designed not to tell automated clients that they were detected.
- Alternate content actions that return a stripped or substituted page.
How to confirm it
- A 200 whose body contains Access Denied, Pardon Our Interruption, or a page that is structurally unlike the real one.
- A response far smaller than the genuine page, or one missing the elements the page always has.
What to do about it
- Validate the body, not the status code. Any pipeline that treats 200 as success will silently ingest denial pages and treat them as data, which is worse than a clean failure because it corrupts results without raising an error.
- Assert on a required element of the real page and fail loudly when it is missing.
503 Custom deny response
Blocked. Operator configurable.
A customer-configured deny response. Akamai lets operators pick the status and body for a denial, so this is a policy choice rather than a service problem.
What triggers it
- An operator who prefers denials to look like capacity problems.
- A deny action pointed at a custom error page.
How to confirm it
- akamai-grn present, and a body that does not read like a genuine outage page.
What to do about it
- Distinguish it from a real outage by checking whether ordinary browser traffic reaches the site at the same moment. If the site is up for a browser and 503 for you, it is a policy response.
If you run a site behind it
- Reference numbers are the support surface. Make sure your deny pages keep them, because they are what turns a customer complaint into a log lookup.
- Deceptive actions have a real cost: they also hide false positives from you. A blocked customer who receives a 200 will not report an error, they will just believe your site is broken.
- Rate controls scoped to shared address space will catch corporate networks and carrier-grade NAT along with the traffic you meant to limit.
If your traffic is being caught by it
- Never treat 200 as success in front of an Akamai site without validating the body.
- A tarpit action produces a hung connection rather than a status code. If requests to one path routinely time out while other paths answer normally, treat the timeout as a verdict rather than as a network fault.
- Capture akamai-grn on every failure. It is the single most useful thing you can hand a site operator.