F5 Shape Defense: signals, telemetry, and the JS agent

Load a login page behind F5 Shape Defense, open the network tab, and you will see a small script pulled in early, usually from a path that ends in something like ssx.mod.js. Read it and you get nothing useful. The body is not minified JavaScript in any normal sense. It is a few hundred kilobytes of bytecode fed to an interpreter that the same file builds at runtime, and that interpreter is rebuilt on the server every half hour with a fresh set of opcodes. The thing it is hiding is not exotic. It collects signals about your browser and your behaviour, packs them up, and ships them to a backend that decides whether you are a person. The interesting part is how much effort goes into making sure you cannot tell which signals, or how they are encoded, before the next version lands and the layout changes again.

That tension, between a fairly ordinary telemetry-collection job and an extraordinary amount of obfuscation wrapped around it, is the whole story of Shape Defense. This post traces it. We start with the heritage, because the obfuscation predates the bot-detection product and explains why it looks the way it does. Then the four-part architecture F5 ships today, the JavaScript agent and its virtual machine, the client signals the agent collects, the telemetry path into the AI cloud, and the collective-defense network effect that the company has always argued is the real product. Where the internals are not publicly documented, I will say so rather than invent field names.

2011 to 2020: from polymorphic defense to a billion-dollar acquisition

Shape Security was founded in 2011 by Derek Smith, Justin Call, and Sumit Agarwal. The founders came out of the Pentagon and the defense industry, where they had watched automation become the cheap way to commit fraud at scale. Agarwal is generally credited with coining the term credential stuffing, the now-standard name for replaying username and password pairs leaked from one breach against unrelated sites. The company stayed quiet for its first couple of years, then in 2012 hired Shuman Ghosemajumder, who had run click-fraud defense at Google, as its head of product and later CTO. After the F5 acquisition he became F5’s head of artificial intelligence.

The original product was not a bot detector in the modern telemetry sense. It was a polymorphic defense. The idea, captured across a family of Shape patents, was to take the HTML, CSS, and JavaScript a web server emits and rewrite it on the fly so that the names attackers depend on, form field identifiers, function names, variable names, change on every page load. US Patent 10,382,482, Polymorphic obfuscation of executable code, granted to Shape Security in 2019 with a 2015 priority date, describes exactly this: serving functionally identical code that is structurally different each time, turning the page into a moving target so that a script written to scrape a fixed field name breaks the next time it runs. The inventors named on it are Siying Yang, Jarrod Overson, Ben Vinegar, and Bei Zhang.

That heritage matters because it is the root of the obfuscation you see in the agent today. Shape’s engineers were building code-transformation pipelines years before they bolted a fingerprinting layer on top. When the product grew into full bot detection, the same instinct, make the client code unreadable and short-lived, carried over to the telemetry script. By the time F5 came calling, Shape was protecting more than half of all online banking logins in North America, its mobile SDK was deployed on over 200 million devices, and it claimed to block up to a billion fraudulent or unwanted transactions a day while letting roughly 200 million legitimate human logins through.

F5 announced the acquisition on December 19, 2019, for roughly one billion dollars, and closed it on January 24, 2020. The product became Shape Enterprise Defense, then folded into the F5 Distributed Cloud portfolio as Distributed Cloud Bot Defense. The brand on the box changed more than once. The agent underneath did not.

*Shape's nine-year arc from polymorphic code defense to the F5 product line that now carries the agent.*

The four-part architecture

F5’s own description of the system breaks it into four components, and it is worth using their names because the prose in third-party write-ups is looser. There is the Shape Defense Engine, the Client Signals, the Shape AI Cloud, and the Shape Protection Manager.

The Defense Engine is the part that sits in the request path. F5 describes it as a Layer 7 scriptable reverse proxy. It serves the JavaScript agent to browsers and the SDK to mobile apps, it terminates the requests that carry the collected signals, it applies a real-time rules engine to make a fast human-or-bot decision, and it forwards the telemetry onward. Deployment is flexible: it can run as a reverse proxy in front of the application, integrate at a CDN or existing F5 device, or sit behind the mobile SDK. The decision the engine returns at request time has to be fast, because it gates a login or a checkout, so the heavy analysis does not happen here.

The heavy analysis happens in the Shape AI Cloud. The Defense Engine streams the collected telemetry to it, and there the data is run through multiple machine-learning models looking for patterns of automation and fraud that a per-request rule could not catch. This is the asynchronous, retrospective half of the system: it is where retooling by an attacker gets noticed, where new signals and new rules get developed by data scientists working with the model output, and where the network effect across customers is realised. The Protection Manager is the console customers use to see what the system is doing and tune enforcement.

The split is the important architectural fact. A fast in-line verdict for this request, and a slow, data-rich learning loop that improves the next verdict. Most modern bot-management systems are shaped this way; the same client-collects, server-scores division appears in Akamai’s sensor_data payload and in DataDome’s scoring pipeline. What distinguishes Shape is how much it invested in the client half and in protecting it.

The reverse-proxy placement also explains why Shape historically sold to a particular kind of customer. Sitting in the Layer 7 path means terminating and re-emitting application traffic, which is intrusive, and the institutions willing to do that for fraud reasons were banks, large retailers, airlines, and government. Those are also the most-attacked applications on the internet, so the placement that makes the product hard to deploy is the same placement that gives the AI Cloud its richest data. F5’s pitch after the acquisition was that its existing BIG-IP footprint in exactly those data centres made the insertion point easier, since the proxy could ride on hardware customers already trusted in the path.

*The four named components. The Defense Engine answers each request fast; the AI Cloud learns slowly across all of them.*

The JavaScript agent and its virtual machine

Now the part the obfuscation is built to hide. The client agent is a JavaScript program whose job is to collect signals and attach them to the requests that matter, login, account creation, checkout, the endpoints scrapers want. F5’s documentation is candid that the script is heavily obfuscated and that this is deliberate: it hides which signals are collected so an attacker has to solve a complex multivariate problem blind. The mechanism is virtualization obfuscation. The real logic is compiled to bytecode, and the script ships a custom virtual machine, written in JavaScript, that interprets that bytecode.

Public reverse-engineering work fills in the shape of that VM, and the detail below comes from independent researchers rather than from F5, so treat it as observed behaviour of a specific version rather than a documented spec. The interpreter is a stack-based machine with a dispatcher loop: it walks the bytecode, reads the next opcode, decodes it, and calls the matching handler. One analysis counted roughly 230 handlers in total, of which about 90 are atomic instructions, the primitive operations like a stack push or a bitwise AND, and the remaining 140 or so are superoperators, single opcodes that fold several atomic steps into one to make traces harder to follow. The VM keeps a stack for operands and a register-style memory accessed through its own context object.

The rotation is the defining trick. A fresh version of the script is published frequently, with public analyses observing a new build roughly every 30 minutes, and on each rebuild a chunk of the handler set is reshuffled. In the version one researcher measured, more than 80 of the handlers changed identity between builds while the rest stayed put. The practical effect is that any deobfuscator pinned to a fixed opcode table goes stale within the hour. A toolkit published on GitHub takes the only durable approach to this, which is dynamic: rather than statically mapping opcodes, it hooks the live VM, injects a tracer that records every opcode actually executed, and lifts those traces back into readable JavaScript, leaning on the micro-instructions that stay consistent across versions instead of the rotating outer layer. This is the same arms race seen in Kasada’s KPSDK virtual machine, and the rotating-opcode pattern is its signature.

*The interpreter is stable in form; the opcode-to-handler mapping is not. That instability is the defense.*

The script-loading pattern researchers have documented uses two fetches of the same module path, distinguished by query string: one request acts as the launcher and a second carries a seed parameter that selects the bytecode build, for example a path ending ssx.mod.js?async followed by ssx.mod.js?seed=<id>. The exact host and path are customer- and deployment-specific, and the ssx prefix is a Shape convention rather than a guaranteed constant, so do not treat any single URL as canonical across sites.

What the client signals are

Strip away the virtualization and the collected data is conventional browser fingerprinting plus behavioural telemetry. F5’s documentation groups it into two buckets. The fingerprint bucket is the static description of the machine and browser: screen size, browser version, the set of fonts the system supports, installed plugins, and the rest of the environment surface that distinguishes one client from another. The behavioural bucket is the recording of how the session behaved: mouse movement, keystrokes, touch-screen interaction, and on mobile, device-motion data from the gyroscope.

That last group is the part automation finds hard to fake convincingly, which is why it carries weight. A headless browser can report any screen size and user-agent it likes. Producing a stream of mouse-move events with human-plausible timing, acceleration, and jitter, across a real page layout, is a different order of problem, and it is the kind of signal the AI Cloud’s models are tuned to read. The fingerprint narrows the population; the behaviour decides the case.

There is a second-order reason the behavioural signals matter more than the static ones, and it is about cost asymmetry. Spoofing a fingerprint is a one-time engineering job: figure out what a real Chrome reports for fonts and plugins, hard-code it, done. The value of that work does not decay. Forging behaviour at scale is recurring work, because credible mouse and touch traces have to be generated per session, and a model trained on millions of real sessions across the network can learn the statistical tells that a synthesizer leaves behind. So the defender wants the decision to hang on the expensive-to-fake signal, and the attacker wants to drag it back onto the cheap-to-fake one. Much of the cat-and-mouse around any agent like this is really a fight over which signals get the deciding vote. The same dynamic drives the anti-instrumentation checks other vendors ship, like Kasada’s detection of patched runtimes, which exist precisely to catch the automation frameworks used to produce fake behaviour at volume.

What is not public is the exact wire layout. F5 says the collected signals are attached to the protected requests either as HTTP headers or inside the POST body, and that the Defense Engine consumes them there. The specific header names, the field order, the serialization, and the encryption are not documented, and because the script that produces them rotates every half hour, any field map a researcher publishes is a snapshot of one build. So unlike Akamai, where the community has converged on a stable name like the _abck cookie and a recognizable sensor_data structure, Shape deliberately gives you no durable handle to grab. That is the design goal, not an accident of documentation.

*The signal categories F5 documents. Wire-level field names and encoding are not public and rotate with the script.*

The telemetry path and the AI cloud

Once the agent has its signals, the path is short to describe and the analysis is where the depth is. The signals ride along on the protected request. The Defense Engine, the reverse proxy in the path, terminates that request, runs its real-time rules to produce an immediate verdict, and forwards the telemetry to the Shape AI Cloud. F5 describes the cloud as running multiple machine-learning algorithms over the data, not a single classifier, with the model output feeding back into the hands of data scientists and domain experts who turn observed attack patterns into new signals and new rules. The system is explicitly designed as a learning loop, not a fixed ruleset.

After the acquisition F5 extended this beyond pure bot detection. The Shape AI Fraud Engine, SAFE, launched on October 6, 2020, applies the same telemetry-plus-AI approach to human fraud, the fraudster who is a real person operating a real browser and so passes a bot check. SAFE scores transactions across the user journey, from arrival through login to checkout and payment, and F5 says it can connect context across browsers and devices used by the same person, with the practical payoff of removing friction like MFA prompts for users it already trusts. That is the same signal pipeline pointed at a harder question than automation.

The privacy mechanics of the learning loop have a concrete example worth naming, because it predates the acquisition and shows the design instinct. Blackfish, announced on November 7, 2017, was Shape’s system for invalidating stolen credentials across its whole customer base. When its sensors detected a username and password being replayed in a credential-stuffing run on one protected site, it could flag that pair as compromised everywhere Shape operated, so the same credentials would not work on any customer, not even when typed in by hand. The mechanism that made this privacy-safe is the interesting bit: Blackfish does not store the credentials. It uses Bloom filters, probabilistic structures that can answer have I seen this before without holding the underlying value, so the system learns that a credential is burned without ever keeping the credential.

The network effect as the actual product

Shape’s own argument, repeated consistently by Ghosemajumder and in F5’s later materials, is that the defensible asset is not any single signal or model but the breadth of the network feeding them. Stopping a determined, well-funded attacker, the kind that retools its automation the moment a defense changes, depends on having seen that attacker’s behaviour somewhere else first. When you defend a large slice of the Fortune 500, including much of North American online banking, an attack campaign that hits one customer becomes training data that protects the rest within the same learning cycle.

This is the same logic that justifies the obfuscation. The rotating VM is not there to keep the agent secret forever, that is impossible, the GitHub toolkit proves it is tractable. It is there to keep any given de-obfuscation valuable for less time than it takes to weaponize, so the attacker is forced to re-solve the problem on a 30-minute clock while the AI Cloud, fed by every other customer, keeps learning what their automation looks like. The obfuscation buys time; the network spends it. Both halves are weaker alone. A static agent would be reverse-engineered once and bypassed cheaply; a rotating agent with no cross-customer learning behind it would just be an annoying delay. Other vendors lean on the same collective-intelligence claim, HUMAN’s collective signal network and DataDome’s detection model among them, and the question for any of them is the same: how wide is the network really, and how fast does a signal seen on one customer become enforcement on another.

Where this leaves a defender

If you run a site behind Shape Defense, the takeaway is not the field layout, because there is no stable field layout to learn. It is the architecture. A fast in-path proxy gives you an immediate verdict and a slow cloud refines it, the client telemetry leans hardest on behaviour rather than easily-spoofed static fingerprints, and the whole client is rebuilt often enough that anything you reverse today is stale within the hour. The polymorphic instinct that Shape’s founders patented in 2015 is still the load-bearing idea a decade later, just pointed at the telemetry script instead of the page markup.

The honest limit of any write-up on this system, including this one, is that the most specific public details, the 230 handlers, the 80-plus rotated per build, the ssx.mod.js seed pattern, are snapshots of particular versions captured by particular researchers, and the system is built precisely so those snapshots expire. F5 documents the shape of the thing willingly: four components, two signal categories, a learning loop. It does not document the wire format, and the agent rotates fast enough that you should distrust anyone who claims a fixed one. That gap between the documented architecture and the deliberately undocumented payload is not a hole in the coverage. It is the product working as designed.

---

Sources & further reading

• F5 / DevCentral (2024), What is Shape Security? — F5’s own technical overview naming the Defense Engine, Client Signals, AI Cloud, and Protection Manager, and describing the obfuscated JS agent.
• F5 (2019), F5 to Acquire Shape Security — December 19, 2019 announcement with the scale figures: 200M devices, ~200M legitimate logins, up to 1B blocked transactions a day.
• F5 (2020), F5 Completes Acquisition of Shape Security — confirms the January 24, 2020 close.
• Shape Security / Yang, Overson, Vinegar, Zhang (2019), US Patent 10,382,482: Polymorphic obfuscation of executable code — the code-transformation heritage, 2015 priority, that explains the agent’s obfuscation.
• svebaa (2024), Dissecting Shape Security’s Virtual Machine — independent analysis: stack-based VM, ~230 handlers, ~30-minute rotation, the seed-based script loading.
• g2asell2019 (2024), shape-security-decompiler-toolkit — README describing the custom stack-based CISC VM with rotating instruction set and the dynamic trace-and-lift approach.
• Shape Security (2017), Introducing Blackfish — the collective-defense credential system using Bloom filters, November 7, 2017.
• F5 (2020), F5 Introduces AI-Powered Solution That Blocks Fraud (SAFE) — the Shape AI Fraud Engine launch, October 6, 2020, extending the telemetry pipeline to human fraud.
• TechCrunch / Ron Miller (2019), F5 acquires Shape Security for $1B — independent coverage of the acquisition and Shape’s market position.
• Wikipedia (2025), Shuman Ghosemajumder — biography covering his 2012 arrival as CTO from Google’s click-fraud team and his post-acquisition role as F5’s head of AI.
• F5 (2024), F5 Distributed Cloud Bot Defense — the current product page for the system the Shape agent now ships under.