A few days agao I watched an automated tool generate 200 variations of the SQL injection payloads Different casing. Different encoding. Different whitespace. Same goal every time: break out of the query.

A few samples of what came out:

%27%20OR%20%271%27%3D%271
' OR 0x31=0x31' --
JwlPUgkweDMxPTB4MzEnCS0t
' /*!12345OR*/ '1'='1
' UNI0DE\u004F\u0052 '1'='1
'/*!UNION*/SELECT/**/0x312c322c33/**/WHERE/**/'1'=0x31/**/||'1'='1
UNION%0bSELECT/**/0x312c322c33/**/WHERE/**/1=1/**/\u0027\u004f\u0052\u0027\u0031\u0027\u003d\u0027\u0031

URL encoding. Hex literals. Base64. Comment-splitting. Unicode escapes inside keywords. Seven completely different surface forms, all reaching for the same thing: make '1'='1' evaluate to true and bypass the query's logic.

GladiosWAF blocked all 200.

Not because it had seen these exact strings before — it almost certainly hadn't, since the tool was generating them on the fly. It caught them because none of the encoding tricks changed what the request was trying to do. The intent stayed identical across every mutation. That's the gap this whole piece is about, and it's what got me thinking seriously about what an AI-native WAF should actually do.

The Problem With Only Looking for Known Patterns

Traditional WAFs exist for a good reason: a lot of attacks follow recognizable patterns. SQL injection, XSS, directory traversal, command injection — if a request contains something that looks dangerous, block it. That model has worked for a long time, and it still catches a lot of obvious attacks.

But attackers don't always send obvious payloads. They encode strings, split them, mutate casing, add noise, hide intent inside unusual formatting. And now, with AI tools, generating dozens of variations of the same attack is trivial.

The attack keeps the same intent. The pattern doesn't.

That's the gap rule-based detection struggles with — not because the rules are wrong, but because they're built to recognize what they've already been taught, and nothing else.

AI-Native Does Not Mean Magic

I want to be careful here. AI-native doesn't mean perfect, zero false positives, or zero false negatives. It doesn't mean an AI-WAF can replace secure coding, and it definitely doesn't mean developers can stop caring about authentication, parameterized queries, access control, or input validation.

If an application has broken access control or trusts user input blindly, the fix still belongs inside the application. A WAF — AI-native or not — is not a replacement for secure design. What it should do is reduce risk at the edge: catch suspicious traffic earlier, and reduce repeated security work across projects. An intelligent defensive layer, not a magic shield.

Moving From Pattern Matching to Intent Classification

The real shift is this: instead of only looking for specific strings, an AI-native WAF should look at the request as a whole. What is being submitted? Is the input trying to escape a query, execute code, reach a local file, or hit an internal service? Does it behave like normal user input, or like an attempt to force the application into doing something unsafe?

A normal search request might look like wireless keyboard. A suspicious one might look like ' OR '1'='1' — and a traditional WAF catches that easily, because the pattern is obvious. But what about the encoded version? The version with spacing tricks? The version an AI agent keeps mutating until one variant slips through? The string changes. The goal doesn't. That's what intent classification is trying to catch.

In practice, this runs as middleware sitting in front of the route. Before a handler executes, GladiosWAF allows you to strips sensitive headers, forwards the method, URL, headers, and body to a classification API, and waits for a verdict on the request as a whole — not just a single suspicious substring. If the verdict comes back malicious, the request never reaches the handler:

router.post('/login', aiwafmiddleware, async (req, res) => {
  const { email, password } = req.body;
  const query = `SELECT * FROM users WHERE u_username = '${email}' AND u_password = '${password}'`;
  // ...
});

That /login handler builds SQL by string interpolation — a textbook injection point, and not something I'm holding up as good practice. Parameterized queries should fix this at the source, every time. But code like this still ships. A developer misses it during review, a junior dev copies an old pattern, a deadline gets in the way — it happens, and when it does, this is exactly the kind of route that gets hit first. The middleware doesn't fix the query, and it isn't trying to. What it does is sit in front of it and catch the request that's trying to break out of it, so a mistake like this one doesn't automatically become a breach the moment it's deployed.

There's also a deliberate design choice in how it fails. If the classification API times out or errors, the middleware can fail open — log the error and let the request through — or fail closed and return a 503. That's configurable rather than fixed, because "the WAF is unreachable" shouldn't silently turn into "every request gets blocked" for every team regardless of their risk tolerance.

Reducing Repeated Security Work

I built GladiosWAF because I was tired of writing the same security code over and over. Every new app needs the exact same defenses for forms, APIs, and login pages. Developers must still check input inside their apps, but copying and pasting the same security blocks across every project is a waste of time.

An AI-powered WAF acts as a ready-made shield in front of all your apps. It does not replace your code's security, but it makes protection consistent and easy. This is especially helpful for small teams without dedicated security experts who need to stay safe while focusing on building their product.

Stack Agnostic, Adopted Gradually

Modern applications span Node.js, Laravel, ASP.NET, Python, Go, and combinations of old and new systems. A WAF that only fits one environment has limited reach. The integration model should stay simple regardless of stack: before a request fully reaches application logic, the relevant data goes out for classification, and the verdict decides whether it continues, gets blocked, or gets flagged for review.

That simplicity matters most for adoption. Teams shouldn't need to rewrite their whole application to get value — they should be able to start with one route, then one API group, then expand from there. In one of GladiosWAF's reference projects, the middleware sits on /login, /taskdetail, and /edittask, while a low-risk read-only route like /listtask is left unprotected for now. That's not an oversight — it's what gradual adoption actually looks like in a real codebase: protect the routes that take user input and touch the database first, and expand coverage from there as confidence builds.

Developer Control Over What Gets Analyzed

Not every part of a request should be sent for classification. Passwords, tokens, payment data, personal records — developers need control over what gets stripped before a request is analyzed, and that responsibility belongs to the application, not the WAF vendor.

In practice, this means the middleware strips a default set of headers before anything is sent for classification — host, connection, proxy-authorization, and other transport-level headers that have no bearing on intent — and lets developers extend that list for anything else they don't want leaving the application. Detection accuracy is only half the design question. What gets analyzed, what gets removed, and what never leaves the application in the first place is the other half, and a security tool that ignores it just trades one risk for another.

Explaining Enough to Be Useful

"Blocked" isn't always helpful on its own. A bare 403 Forbidden tells a developer nothing — was this a false positive? An actual attack? Something about the route itself?

This is somewhere GladiosWAF still has room to grow. Right now the verdict it returns is a binary one — malicious or not — without a breakdown of which attack category triggered it. That's an honest tradeoff of the intent-classification approach: the model is reasoning about what a request is trying to do as a whole, not matching it against a labeled list of "this is SQL injection" or "this is XSS." It's good at catching the behavior. It doesn't (yet) explain the behavior in those terms.

Even without attack-type labels, there's still a meaningful gap between this:

Compare:

403 Forbidden

with:

Request flagged as malicious by GladiosWAF.
Route: POST /api/search

The second version at least tells a developer where to look — which route, which request — so they can pull logs and investigate, rather than guessing blind. A categorized explanation ("this looked like SQLi specifically") is a reasonable direction to build toward, but it isn't what the system does today, and I'd rather say that plainly than describe a feature that doesn't exist yet.

Useful Before an Incident, Not Just After

Most security tooling becomes important only after something has already gone wrong. A good WAF should make suspicious behavior visible earlier — what payloads are hitting the application, which endpoints are being targeted, whether an attempt is a one-off or part of a repeated pattern from the same client. That's the value of useful logging: not logging for its own sake, but logging that turns into an early warning layer instead of just a postmortem trail.

Rules Still Have a Place

The future isn't "rules are bad, AI is good" — that's too simple. Some attacks are obvious enough that a deterministic rule is the right tool. Some compliance requirements call for specific, predictable controls. The point isn't that rules should disappear; it's that rules alone aren't enough anymore. The web is too dynamic, mutated payloads are too easy to generate, and most teams can't spend all their time hand-tuning detection logic. An AI-native WAF should build on what worked rather than discard it.

What I'm Building With GladiosWAF

GladiosWAF is my attempt at this direction: an AI-WAF focused on intent, designed for developers, built to work across stacks, with developers in control of what data gets analyzed and what gets stripped first. It's honest about what it can and can't do — it is not a magic security box, and it doesn't pretend secure coding no longer matters.

The old model of endlessly writing and tuning rules isn't going away overnight, but it's showing its limits. As AI becomes part of both attack and defense, WAFs need to get more adaptive, more developer-friendly, and more focused on understanding behavior than memorizing strings. That's the direction I'm building GladiosWAF toward.