Next-Gen WAF: What Can Be Done
The first article closed the request path to language models: the production budget is 275 µs on CPU, an encoder costs 14.7 ms, a generative model costs seconds. This article proposes three places a local model can sit instead, all of them off the request path, all of them deciding seconds later, and all of them acting on an identity (an API key, a user, a session, a source) rather than on a request that has already been answered. Nothing here calls out to a remote service; the premise is that a WAF's traffic does not leave the box.
The three paths: (A) post-process the payloads the inline tier escalates, in context, and decide whether the identity behind them is blocked; (B) learn per-endpoint profiles from legitimate traffic, so that the inline tier has a positive model to enforce and Path A has a definition of "unexpected"; (C) read session flows, the sequence of endpoints an identity walks through, for brute force, enumeration and scraping, which are identity-level behaviours in the first place.
Each path gets the same treatment: the proposal, the evidence that supports its shape, the measurement that is still missing, and the enforcement hook. Every number comes from a dated source I opened, linked where it appears. Two sources carry most of the weight: WAPP (arXiv, Sept 2026), the only study that learned positive-security policies from live traffic and compared a statistical synthesiser against a local 27B model, and an April 2026 benchmark of LLMs against fine-tuned transformers on log-sequence anomaly detection, the closest measured analogue to session-flow analysis.
The shared shape
The request is always served by the inline tiers; the analysis lane receives copies (escalated payloads, session flows, samples of benign traffic), runs the local model on them, and its output is either an identity action or a change to what the inline tiers enforce. The latency of the analysis lane is therefore the delay between an abusive identity's first request and its block, not a delay on any request, and the cost of a wrong verdict is a wrongly blocked identity, which is why every path below ends with the false-positive rate that has to be established before enforcement is turned on.
Path A: post-process the escalated payload, in context
The proposal: the inline tier already flags a small fraction of requests it cannot decide. Instead of blocking or passing them on the payload alone, copy them to the analysis lane, where a local model sees what the inline tier structurally cannot: the decoded payload beside the endpoint's expected shape, the response the application actually returned, and what the same identity did before. The decision it returns is about the identity, seconds later.
What supports the shape. Context features carry real signal on their own: a 2023 study detected Union and Blind SQLi from NetFlow records alone, with no payload, at a 97.4% detection rate and under 0.07% false alarms (Computers & Security, 2023), though on balanced lab datasets where source IP was among the retained features, so the number is a proof of signal, not a production figure. And the outputs beyond a yes/no are where a generative model has a measured record: GenXSS clustered successful attacks and had the model write rules from the clusters, blocking 86% of previously successful payloads at F1 0.9259 (GenXSS); that was an API model, so the local version is the first thing to re-measure.
What undermines it, or is unmeasured. For the verdict itself, every head-to-head so far favours a small fine-tuned encoder over a prompted decoder: an 8B classifier matched DistilBERT on SQLi and XSS at 42× the cost (ICAIIC 2025); on log sequences a fine-tuned DeBERTa-v3 reached 95.3–98.9% F1 at 12.4 ms while a local LLaMA-3-8B ran at 156 ms and GPT-4 zero-shot scored 81.2–88.3% (arXiv 2604.12218, Apr 2026). The nearest thing to "LLM post-processes security alerts" is an August 2026 IDS-triage study: about a third of attack alerts classified correctly zero-shot, 75–83.5% with one or two examples, on 200 alerts, using API models because the authors found open models too weak (Springer, Aug 2026). Whether an injection succeeded is, in principle, visible in the response (status, size, timing), but I found no 2025–2026 source that measures breach confirmation from response data; that half of the proposal has no evidence either way. And the one field report of a security classifier going from benchmark to production is a warning: 0% false positives on the benchmark, 41% on real traffic (Prismor, Sept 2026).
The enforcement hook and its condition. The action is a block or rate-limit on the API key, user or session, reversible and logged. Because that is a heavier action than dropping one request, the number that has to exist before enforcement is switched on is the false-positive rate on the operator's own traffic, with the few-shot examples drawn from the operator's own past incidents rather than from a public benchmark. Until then Path A is an alerting layer, which it can be from day one.
Path B: learn per-endpoint profiles from legitimate traffic
The proposal: point the model at what the application's legitimate traffic looks like, endpoint by endpoint and field by field, and have it write the allow-list: which parameters exist, their types, lengths, character sets and value ranges. The inline tier then enforces a positive model, and Path A gets a definition of "unexpected" that is specific to this application rather than to attacks in general.
This is the one path with a direct, recent test. WAPP (arXiv 2609.06840, Sept 2026) built the whole loop on DVWA, OWASP Juice Shop and a 50-endpoint Flask application: records grouped by endpoint and method, bodies parsed across JSON, form, multipart, XML/SOAP, GraphQL and text, rules constraining type, requiredness, range, character evidence and parameter sets, each rule compiled into the WAF in shadow mode and replayed against a held-out benign set and a fixed attack suite before enforcement.
Three findings from that study shape the path. First, the model is not the hard part. WAPP compared its deterministic statistical synthesiser with a local Qwen3.5-27B writing the same rules, and chose the statistical engine for "grounded, closed set rules with zero model inference cost"; the LLM took 66.9 s, 98.9 s and 197.2 s per application and, on the free-text comment field, let 20% of attacks through where the statistical rules let none. On the DVWA login endpoint the LLM did better (0.00/0.00 pass-through/FPR against 0.00/0.76), so the honest reading is: the two engines fail on different fields, and the choice is per field, not global. Second, the trust filter is the hard part. With no filtering of the learning window, effectiveness was 0.5288; with all seven trust signals, 0.9000; the 2003 Kruegel–Vigna baseline sat at 0.6231. At 0.2% poisoned training traffic the learned username policy was classified Degraded, at 0.5% Broken. An attacker who can get a few hundred requests into the learning window owns the profile. Third, the free-text problem is real and concentrated: the DVWA username field blocked 28 of 43 legitimate usernames (FPR 0.6512) at the default 0.90 value-frequency floor, while constrained fields (alphanumeric search, integer page selector) ran at FPR 0.00 and blocked all ten confirmed CRS bypasses thrown at them.
A second line of evidence says the same thing from the anomaly-detection side: a one-class detector trained only on benign Drupal traffic reached 80.11% TPR at 0.79% FPR, against 29.55% at 15.57% for OWASP CRS at paranoia level 1 on the same traffic (arXiv 2609.26860, Sept 2026). Learning what is normal per application beats generic rules on both axes, and has done since 2003; what is new in 2026 is a measured pipeline for doing it safely.
The enforcement hook and its conditions. Profiles for constrained fields (identifiers, enums, numbers, bounded strings) can go to enforcement after shadow replay, and violations of them are high-confidence input to Path A. Free-text fields stay in shadow mode or get character-level operator control rather than a frequency floor. And the learning window has to be trust-filtered before anything is learned from it; that filter, not the language model, is the component a next-gen WAF has to get right. Where the local decoder earns its place in this path is at the edges: naming fields, explaining a rule to an operator, and proposing per-field engine choice from the shadow-replay results, all of them offline and all of them cheap once no API is involved.
Path C: read session flows, not payloads
The proposal: brute force, credential stuffing, account enumeration and scraping are not in any single request. Each request is well-formed and passes every payload check; the abuse is the sequence, the rate and the coverage of the walk an identity takes through the endpoints. So give a model the walk, per identity, and let it decide about the identity.
What supports the shape. The direct analogue with a measurement is log-sequence anomaly detection, and the April 2026 benchmark settles the division of labour: on HDFS, BGL, Thunderbird and Spirit a fine-tuned DeBERTa-v3 reached 95.3–98.9% F1 at 12.4 ms per sequence, Drain + Random Forest 86.4–95.1% at 0.3 ms, GPT-4 zero-shot 81.2–88.3% at 890 ms and a local LLaMA-3-8B at 156 ms (arXiv 2604.12218). The small fine-tuned model wins on both axes once labelled sequences exist, and a WAF operator has years of them. KRONE shows what the generative model is for: it derives an entity–action–status hierarchy from the raw log vocabulary, detection runs on the abstraction, and the LLM touches only 1.1–3.3% of the data, a 43.7× cost reduction at up to 96.27% F1 on BGL (arXiv 2602.07303). For HTTP the equivalent is turning raw paths (with their ids, versions and query noise) into an endpoint-and-action vocabulary per application, once, offline; the sequence model then learns on that vocabulary and the decoder is not on the scoring path. On the traffic side, the same flow features carried a 24% zero-shot F1 gain for a local Llama2-7B on carpet-bombing DDoS detection in NetFlow, and 35.1% on a real operator trace (arXiv 2503.18487), with the authors themselves listing inference latency as the open problem.
What undermines it, or is unmeasured. No source I found runs any of this on HTTP sessions labelled for brute force, enumeration or scraping; the log and NetFlow results are proxies. The cheap baseline is strong: ratio features per session, computed in ClickHouse with no model, cut false positives by 85% against static thresholds at 50,000 requests per second in a system described on this blog in 2023 (Real-Time Anomaly Detection for Web Traffic); a sequence model has to beat that on the slow, distributed version of the attack, where per-source rates stay under every threshold and the enumeration is visible only across identities. And for the agent-driven scraper the sequence may be the wrong layer: a July 2026 study found that two LLM browsing agents produced "nearly indistinguishable event traces" and that the one operating from a real browser profile with persistent cookies and history got past reCAPTCHA v3 while the other did not; the discriminator was the environment, not the behaviour (arXiv 2607.18659). A flow model needs environment signals beside it or it will be silent on exactly that attacker.
The enforcement hook and its condition. The action is identity-level by nature: rate-limit or block the key, user, session or source, seconds after the walk becomes recognisable. The experiment that has to run first: HTTP sessions from a honeypot or from SR-BH 2020, labelled by attack class, and three detectors side by side, ratio thresholds, a small fine-tuned sequence model on the endpoint vocabulary, and a local 7B–14B model few-shot, with F1 and per-session latency for each. The 12.4 ms and 95–99% F1 line from the log benchmark is the number to beat, and if the sequence model beats the ratios only on the slow attacks, that is still the result that justifies the path.
What can be switched on, and what has to be measured first
All three paths can run as alerting layers today; none of them should block an identity until the row's open measurement exists.
| Path | Can be switched on now | Must be measured first | Number to beat | Enforcement hook |
|---|---|---|---|---|
| A. Payload post-processing | Alerting on escalated payloads with context; rule drafts and analyst notes from a local decoder | False-positive rate on the operator's own traffic with few-shot examples from own incidents; whether response data confirms a breach; local-model bypass/valid-payload rates against GenXSS's API figures | 0% benchmark vs 41% live FPR (Prismor); 75–83.5% few-shot triage accuracy (IDS study, API models); 83% valid / 80% bypass (GenXSS, GPT-4o) | Block or rate-limit the key, user or session; reversible |
| B. Profiles from legitimate traffic | Shadow-mode profiles for every endpoint; enforcement on constrained fields after replay | Trust filtering of the learning window on production traffic; per-field engine choice (statistical vs LLM); free-text handling | Effectiveness 0.90 with trust filter, 0.53 without; FPR 0.00 on constrained fields, 0.65 on free text; Degraded at 0.2% poisoning (WAPP) | Positive model in the inline tier; violations feed Path A |
| C. Session flows | Ratio-based session alerts; offline endpoint-vocabulary building by the decoder | F1 and per-session latency of a fine-tuned sequence model vs ratio thresholds vs a local LLM on labelled HTTP sessions; coverage of agent-driven scrapers | 95.3–98.9% F1 at 12.4 ms (DeBERTa on log sequences) vs 156 ms (local LLaMA-3-8B); 85% FP reduction from ratios alone (2023) | Rate-limit or block the identity, seconds after the walk is recognisable |
The common thread is where the generative model sits in each row: never in the "can be switched on" column as a verdict, always as the thing that builds the vocabulary, writes the rule, drafts the note or generates the red-team payload. That is not a limitation the premise imposes; it is what the measurements say a local decoder is good for, and it is the part of a WAF that has never had a model at all.