On June 12, 2026, the US government ordered Anthropic to cut off public access to its two strongest models, Claude Fable 5 and Claude Mythos 5. TechCrunch broke the order, and Time confirmed the company complied worldwide within a day. Fable 5 had shipped three days earlier as the “safe to use” and generally available model. Mythos 5 was the more capable sibling, never opened to everyone. Anthropic’s own account is that someone found a jailbreak around Fable’s safety layer, the part built to block answers in cybersecurity and biology, and the government decided the risk of leaving it running was too high. Not everyone agrees with this decision: Scientific American argued the restriction could end up hurting defenders more than attackers, but the fact is that, up to today, nothing has changed.
Before proceeding, let me thank NetNut, the platinum partner of the month. Their set of solutions cover all your needs for scraping.
You can read that episode two ways. Either the guardrails were the only thing standing between a public model and a stream of attack-ready output, or the shutdown was a tidier story than the truth. We are not going to settle that here. For our corner of the world, the lesson is simpler. A capable model, stripped of guardrails or jailbroken around them, automates the expensive part of an attacker’s job. Deobfuscation, code analysis, and figuring out how an unfamiliar system behaves under pressure. Those tasks have always gated the scraper-versus-vendor arms race because they cost human reverse-engineering hours, and that gate is now moving.
The cat-and-mouse game we cover every week runs on a hidden economy. A vendor ships an obfuscated sensor. Someone on the scraping side spends days or weeks reading minified JavaScript, renaming variables, and rebuilding the logic until the parameters make sense. The cost of that labor is what keeps most protections standing. If a model can do a real share of it on its own, the math behind the whole arms race changes.
Manus AI, and why not Claude
Manus is not a chat assistant. It is an agent that pairs a language model with a sandboxed virtual machine, and inside that machine, it runs code, fetches pages, beautifies scripts, and iterates on its own output. Meta acquired it at the end of December 2025 for around two billion dollars, though by June 2026, Chinese regulators were already forcing parts of that deal to unwind. What that architecture buys is verification. Manus not only describes what a script might do. It runs the script and checks.
That difference shows up the moment you set guardrails next to it. Ask Claude or ChatGPT to deobfuscate a live anti-bot sensor and explain which signals feed its scoring, and you tend to hit a wall. Those products keep tight cybersecurity guardrails, and the Fable shutdown is the clearest sign yet of how hard that line is enforced. We handed the same class of task to Manus, and it got to work. We have looked at agentic browsers and AI scraping assistants before, but those were aids for a human operator who still did the thinking. Here, the model does the reverse engineering.
We have written about Akamai more than any other anti-bot system. For the bypass-oriented background, THE LAB #30, THE LAB #85, and THE LAB #100 cover the recovery-when-nothing-works case, proxy chaining, and the browser-login-plus-HTTP hybrid. We will not repeat any of that.
What we wanted this time was not a bypass. It was a map. Akamai Bot Manager protects net-a-porter.com, and it defends in stacked layers that each fail differently:
A TLS fingerprint check at the edge, evaluated before a single line of the client JavaScript runs.
A sec-cpt cryptographic challenge, whose state lives in the bm_sc cookie.
A behavioral sensor that serializes a binary telemetry payload and posts it to a collect endpoint, validating the _abck cookie.
A client-side anti-hook layer that checks the browser environment for tampering and reports integrity separately.
The model we asked Manus to build covers the client sensor and the challenge flow, plus whatever it could observe about the TLS gate from the outside. A working end-to-end bypass was out of scope. We are not shipping code with this article, and we did not ask Manus to produce a runnable solver, even though our tests suggest we are really close to a working solution. What we’ll share here is a summary of the analysis Manus did; in the code repository, you will find the full details.
The task was deliberately cold. We did not give Manus our own Akamai notes, our wiki, or any of the prior Lab articles. We pointed it at net-a-porter.com and asked it to study how Akamai's protection works, deobfuscate the client script, and explain which parameters feed into the sensor. Nothing more.
We chose this target for three reasons. It runs a real, current Akamai deployment on a high-value luxury store. The sensor was observable live, so the agent could fetch and instrument the actual script rather than reason about a stale sample. And we already understand Akamai well enough internally to judge whether the output was accurate or confident nonsense.
The reason the task went to Manus rather than a chat assistant is the guardrail gap from the previous section. Deobfuscating a production anti-bot sensor and enumerating the signals it scores is exactly the kind of request the heavily guarded models decline. Manus took it, ran the analysis in its VM, and came back with the two documents below.
What came back
The output was more detailed than we expected from a single task run. We are sharing it in two parts and deliberately not sharing it all.
The two documents below are Manus AI’s output. We reproduce them as reportage, to show what an agent derived on its own. We have not independently re-run every claim, re-derived every value, or confirmed that each detail still holds against the live site. Treat the specifics as the agent’s findings, not as TWSC-verified ground truth. The sensor version Manus reports, 746702557, was compiled on 2025-05-09, so some details may already have rotated. Where the agent surfaced operational specifics that amount to a turnkey recipe (exact module filenames, the full endpoint table, the CSS selector ids, the challenge request names), we have redacted them.
This is a schema of how Akamai Bot Protection according to Manus AI
Part one, reproduced in full, the anti-hooking and TLS summary
This first document is the safe exhibit. It explains how Akamai detects a tampered browser and how the TLS gate at the edge decides who even gets a challenge. We reproduce it verbatim.
Akamai Bot Manager: Anti-Hooking and TLS Fingerprinting Summary
Target:www.net-a-porter.com Sensor Version: 746702557 Author: Manus AI
This document isolates and summarizes two of the most critical defensive layers in Akamai Bot Manager (BM): its client-side anti-hooking mechanisms and its edge-level TLS fingerprinting. These two systems work in tandem to defeat headless browsers, automated scraping frameworks, and reverse-engineering attempts.
1. Anti-Hooking Mechanisms
Akamai’s client-side script goes to extraordinary lengths to ensure the browser environment is pristine. The anti-hooking logic is primarily housed in the dynamically loaded h module.
1.1 Native Function Verification. Scraping frameworks often override native browser APIs (such as navigator.webdriver or HTMLCanvasElement.toBlob) to spoof a legitimate environment. Akamai detects these overrides using several techniques. It uses Function.prototype.toString inspection to check whether native functions still return the expected [native code] string, and it detects whether the toString method itself has been hooked or proxied. It uses Object.getOwnPropertyDescriptor to inspect the getters and setters of critical APIs, and a property that should be read-only but carries a custom getter is flagged as tampered. It also checks for JavaScript Proxy objects wrapping standard DOM APIs, a common technique in tools like Puppeteer Stealth.
1.2 The “Clean iframe” technique. To bypass hooks placed on the main window object by automation tools, the scheduler class dynamically injects a hidden iframe into the DOM:
Once injected, Akamai extracts pristine, unmodified API references directly from iframe.contentWindow. This lets the script call the original native functions even if the main window object has been heavily spoofed.
1.3 The anti-hook verification payload (/ah). The anti-hook module computes a cryptographic hash representing the integrity of the environment. This check runs as a “Type 3” callback in the scheduler, so it executes before the main telemetry payload is serialized. The result is sent to the /ah endpoint. If the environment is clean, the URL parameter ah=0 is transmitted. If verification is pending or failed, it transmits ah=1.
2. TLS Fingerprinting and Edge Escalation
While the anti-hook mechanisms operate in the browser, Akamai’s most formidable defense occurs at the edge server level via TLS fingerprinting.
2.1 The TLS barrier. Before the client-side JavaScript even executes, the Akamai edge server evaluates the incoming connection’s TLS fingerprint (JA3/JA4 hashes, cipher suites, ALPN extensions). Empirical testing on net-a-porter.com revealed a strict dichotomy. Consumer TLS, for example Safari emulated via curl_cffi, gets a 200 OK response carrying the sec-cpt cryptographic challenge. This is a soft block that lets legitimate browsers prove their authenticity. Headless or automation TLS, for example standard Node.js or Puppeteer Chromium, gets an immediate 403 Access Denied that bypasses the challenge flow entirely.
2.2 The escalation trap. The most critical finding about Akamai’s architecture is how TLS fingerprinting intersects with the client-side behavioral telemetry behind the _abck cookie. A request with a valid TLS fingerprint receives the sec-cpt challenge, and solving it updates the bm_sc cookie by appending ~0~0~0. At the same time, the browser must send a rich, roughly 2.2KB binary payload to the /collect endpoint to validate the _abck cookie. If an automated tool solves the sec-cpt challenge but fails to provide a valid behavioral payload, or sends it over a connection with a mismatched TLS fingerprint, the edge server detects the anomaly.
The result is that even if a real Chromium browser driven by Puppeteer Stealth generates a mathematically perfect 2,199-byte behavioral payload and solves the challenge, Akamai still refuses to validate the _abck cookie, because it detects the Puppeteer TLS fingerprint at the edge. The server then escalates and returns a permanent 403 Access Denied for that session.
2.3 Summary. Akamai requires perfect synchronization of a trusted network-level TLS fingerprint and pristine browser-level behavioral data. Spoofing the browser environment, which trips the anti-hook defenses, or using a non-standard TLS stack, guarantees session termination.
Part two, reproduced with redactions, the deep technical analysis
The second document goes much further. It walks the bootstrapping sequence, the module system, the fingerprinting surface, and the telemetry transport. This is the part that starts to read like a blueprint, so we keep the architecture and the reasoning and we strip the operational specifics. Redaction markers below are ours, not Manus’s.
