The WAF Is Learning: How ML and Behavioral Analysis Are Reshaping Application Protection

For years, a web application firewall was mostly a large list of known-bad patterns. It was useful, but brittle. A new attack vector slipped through until someone wrote a signature, and legitimate traffic that happened to look like an old attack got blocked. The usual fix was more rules, more tuning, and more full-time WAF administration.

A different model is now in production at several major vendors. Instead of asking “does this request match a known attack?”, these systems ask “does this request look like it belongs here?” The answer comes from models that learn what normal traffic looks like for a specific application and flag deviations from that baseline.

That sounds like a small wording change. It is not. It changes what the WAF is learning, what it is deciding, and how much you can trust the result without testing it against your own traffic.

What “adaptive” actually means

The word is used loosely across the industry. In products that genuinely implement it, the core mechanism usually has three parts.

Per-application baselining

The system observes traffic to a specific application over a learning period and builds a statistical profile: request patterns, field values, session behavior, TLS fingerprints, geographic distribution, and other signals. The baseline is not a global ruleset with a different name. It is supposed to reflect how that application normally behaves.

Risk scoring instead of binary decisions

Rather than a simple block-or-allow decision, each request gets a risk score based on how far it deviates from the learned baseline. That gives security teams context and lets them set thresholds that match their risk appetite. It also means the WAF can flag something suspicious without immediately breaking a legitimate workflow.

Continuous retraining

The baseline is not static. The models update as traffic changes, so the system can adapt to new features, seasonal patterns, and legitimate behavior changes without someone manually rewriting a rule every week.

This is different from a traditional WAF’s “learning mode,” which often just suppresses alerts during a setup window. Adaptive systems keep retraining in production. That is the important distinction.

The main implementations in 2026

The market is crowded, and every vendor now says “AI.” The useful comparison is not the label. It is where the model sits in the decision path.

F5 Distributed Cloud WAF

The F5 Distributed Cloud WAF combines a signature-based engine with a neural network that builds a behavioral profile and assigns each request a risk score. In internal F5 testing, the company reported 98% threat detection while reducing false positives to 1%. A NetworkWorld interview with an F5 representative in June 2026 also reported that the false-positive rate dropped from roughly 18% to roughly 1% for customers who activated the AI-powered WAF, and that those customers reached blocking mode faster than teams relying on hand-configured signature rules.

In September 2026, F5 added anomaly detection that continuously analyzes each application’s traffic over a 48-hour window to establish baselines, plus agentic threat intelligence for autonomous virtual patching. Both were rolling out to Distributed Cloud customers, with broader availability planned.

The most interesting detail is the hybrid design. In F5’s write-up of CVE-2026-42208, the neural network acts as a secondary classifier: when a signature fires, the model evaluates whether the flagged content is genuinely malicious or benign and adjusts the request’s risk level. Signatures trigger the investigation; ML resolves the ambiguity.

Check Point WAF

The Check Point WAF, formerly CloudGuard WAF, uses a dual-layer ML architecture: a supervised model trained on known attack patterns and an unsupervised model that looks for contextual anomalies without prior knowledge of the attack. The product is positioned as requiring no signatures and no manual tuning.

Check Point’s headline numbers — 99.5% detection and a 0.56% false-positive rate — come from its own WAF Comparison Project 2026. That project tested 14 WAF solutions against more than 1 million legitimate requests and 74,000 malicious payloads. It is a vendor-run benchmark: Check Point designed the methodology, ran the test, and published the results. Treat the numbers as directional, not definitive.

The company also received a Frost & Sullivan 2026 Technology Innovation Leadership recognition for its prevention-first WAF and API security. That is independent analyst validation, but it is not a benchmark. The no-signature, ML-first design is still distinct enough from the rest of the market to be worth understanding on its own merits.

Akamai App & API Protector

The Akamai App & API Protector takes a two-engine approach.

The Adaptive Security Engine continuously analyzes WAF rule triggers against real traffic, identifies false-positive patterns, and emits tuning recommendations. Akamai describes a multi-phase pipeline: shadow-mode testing on live traffic, ML pattern extraction, human review, and deployment. At launch, the engine was reported to increase detections by 2× and reduce false positives by 5×; later ML updates reportedly reduced false positives by an additional 4×. The system draws on a 9 PB intelligence database and 400 human threat hunters.

The Behavioral DDoS Engine, launched in October 2024, uses ML to set traffic baselines from TLS fingerprints, geographic data, and network identifiers. It continuously monitors traffic and adjusts sensitivity to improve accuracy while reducing false positives.

Akamai is more conservative than F5 or Check Point in one important way: the ML engine recommends tuning changes, and a human reviews and applies them. It is adaptive, but not fully autonomous. That is a deliberate trade-off between automation and oversight.

Cloudflare

The Cloudflare WAF is a different case. Its most recent development is Adaptive Intelligence, launched on August 31, 2026: a continuously retraining ML model that replaces the fixed-version detection models previously used for bot scoring. Enterprise customers enable it through an “Auto Update Machine Learning” toggle in the Bot Management dashboard.

Cloudflare describes three planned components: the continuously retraining model, which is now live; automatically generated disposable rules, which are upcoming; and learning from the entire network’s traffic, also upcoming. The model uses Cloudflare’s global network to distinguish human from automated traffic.

Cloudflare also has a separate Anomaly Detection engine that records a per-domain baseline and flags outlier requests. In July 2026, it announced an ML WAF detection capability that complements managed rulesets by identifying bypasses and malicious payloads without human involvement.

The trade-off is scale versus specificity. Cloudflare’s model is trained on global network data rather than per-customer baselines. That gives it a huge sample, but it is less tailored to one application’s behavior than a per-app model.

Sovereign Fortress High Assurance WAAP

The Sovereign Fortress High Assurance WAAP, developed through the SELinux Firewall project, takes a different architectural route. It separates inspection, risk evaluation, and enforcement instead of treating the WAF as one monolithic engine.

The locally operated ML Inspection Engine evaluates application input, while configurable rule-based controls — including Coraza with the OWASP Core Rule Set — provide complementary inspection. Behavioral observations, browser-attestation signals, TLS fingerprints, and reputation data add context. A local risk decision service evaluates those signals under configured policy and publishes scoped, time-limited decisions for gateway enforcement. Actions include allowing requests, blocking operations, applying traffic limits, and requiring a browser challenge. The platform also has a CAPTCHA service with single-use passes, route-specific authentication, policy-based authorization, and request limits.

The distinctive part is confinement of the protection platform itself. Runtime processes run in confined SELinux domains, with no unconfined runtime processes. Type Enforcement restricts resource access, Linux namespaces separate selected resource views, and restricted capabilities limit privileged operations. The runtime network environment is separated from the host’s network stack using a dedicated network namespace, macvlan interfaces, VRF-based routing, and service-bound nftables policies.

Core inspection, risk evaluation, and enforcement operate locally. Events are available for investigation and forwarding to external monitoring or SIEM systems, and separate AI gateway capabilities support controlled access to model services, provider routing, and usage limits. The High Assurance approach ties these architectural constraints to versioned configuration, validation, and tests of enforcement, failure behavior, and compromise boundaries. Detection accuracy, false-positive rates, and throughput still have to be established for the specific software version, configuration, and deployment being assessed.

If you want the Linux background for that confinement model, the SELinux overview on this blog is a good starting point.

What the benchmarks do and do not tell you

Vendor-run benchmarks are not independent. Check Point’s WAF Comparison Project was designed, executed, and published by Check Point. F5’s 98%/1% numbers come from internal F5 testing. Akamai’s 2×/5× claims come from its own product brief. That is not automatically bad — vendors need to validate features before launch — but it means the numbers are directional rather than definitive.

For independent validation, look at SecureIQLab, an AMTSO-certified lab that published a 2026 WAAP CyberRisk Validation report testing 12 cloud WAAP solutions. Its findings showed WAF vulnerability assessment scores averaging 99.7% across vendors, but newer attack surfaces scored much lower: WebSocket API protection averaged 48.3%, and API privilege escalation averaged 58.3%. The gap between detecting known attacks and detecting novel ones is still significant across the industry.

There is another problem with comparing “AI WAFs” as a category: the ML is doing different work at different vendors. At F5 and Check Point, the model is the primary detection engine and makes the block-or-allow decision. At Akamai, ML is a secondary layer that tunes and validates signature-based decisions. At Cloudflare, ML is primarily for bot scoring, with a separate and newer ML layer for WAF detection. When a vendor says “AI-powered WAF,” the question is not whether AI is present. The question is what the AI is actually deciding.

Per-application baselines also need time. F5’s anomaly detection needs 48 hours of traffic before it can establish a baseline. Akamai’s engines need time to observe patterns. The “out-of-the-box, zero tuning” claim is therefore partly true: signatures or global models can provide immediate coverage, but the adaptive layer needs traffic and time before it becomes fully useful.

What this means for Linux and self-hosted setups

The shift from signatures to ML and behavioral detection is real, but it is not a clean replacement. The most effective deployments in 2026 are hybrid: signatures provide immediate coverage for known attacks, and ML provides the adaptive layer that catches some of what signatures miss while reducing the false-positive burden.

For Linux shops, that has a few practical consequences.

Do not rip out ModSecurity or the OWASP Core Rule Set because ML is fashionable. Keep them as one layer, especially for immediate virtual patching. If you want an open-source example of the ML-WAF model, the open-appsec post is a useful counterpoint.
Baselines need traffic. A low-traffic homelab or a staging app will not train a per-application model well. Do not judge a 48-hour baseline on a service that sees twenty requests a day.
Risk scores are only useful if they reach your logs. Ship them to your SIEM, correlate them with authentication events, and alert on changes in the score distribution — not just on blocks. If you already run Wazuh, that is a reasonable place to start.
Test against your own traffic. A vendor benchmark does not include your API, your authentication flow, or your bot traffic. Run the WAF in detection or shadow mode first, compare false positives, and then decide what to block.
Keep the application-layer controls. ML does not fix missing object-level authorization, unvalidated JSON, or an API that trusts a client-supplied tenant ID. Those still need schema validation, authorization checks, and rate limits.

A managed WAAP can take a lot of operational weight off a small team, but it is still a relationship. Ask where the traffic goes, how the model is trained, what data is retained, and how you get your logs and rules out if you leave.

Questions to ask before you buy

The feature grid will not answer the important questions. Ask these instead.

What is the ML actually deciding: blocking, scoring, tuning recommendations, or just alerting?
Is the model trained per application, per tenant, or on global network data?
How long does the baseline take, and what happens after a major application change?
Who reviews false positives, and how quickly can a rule or threshold be changed?
Can you export risk scores, rule IDs, request IDs, and identity context to your SIEM?
Has an independent lab tested the specific ML detection claim, or only the older signature engine?
What happens if the service fails: fail open, fail closed, or bypass?
How is training data handled, where is it stored, and what is the retention policy?
Can you move your rules and logs to another provider without starting over?

The short version

The WAF is learning, but it has not become autonomous in any way you should bet the farm on. Signatures still provide immediate coverage for known attacks. ML adds an adaptive layer that can catch some novel behavior and reduce the false-positive treadmill. Behavioral analytics adds context that neither signatures nor a single request can provide.

The vendors furthest along on the “ML as primary detector” path, F5 and Check Point, are still rolling out their latest capabilities and have not published independent third-party validation of their ML-specific detection claims. The more conservative vendors, Akamai and Cloudflare, have scale and a longer track record, but their ML complements rather than replaces their rule-based engines.

For anyone evaluating WAAP platforms, the key question is no longer “does it use AI?” Every vendor says yes. The question is: what is the ML actually deciding, how is it trained, and has anyone independent verified the results? If you run Linux, keep the open-source rule engine as a layer, put the adaptive features through your own traffic, and make sure the logs end up somewhere you can actually investigate.

Sources

F5 press releases, June and September 2026; F5 write-up of CVE-2026-42208.
NetworkWorld, June 2026; Help Net Security, September 2026.
Check Point WAF Comparison Project 2026 report; Frost & Sullivan, April 2026.
Akamai, “From WAF to WAAP” white paper, March 2025; Akamai product brief.
Cloudflare blog, July and August 2026; Cloudflare developer documentation.
SecureIQLab, 2026 WAAP CyberRisk Validation v5.0.
Sovereign Fortress High Assurance WAAP architecture documentation.