I've been thinking about this for a while, and I want to write it down honestly — not as a security whitepaper, but as someone who's actually sat with this problem.

Here's the thing about rule-based WAFs. They do work and I don't deny it.

You set up a rule that looks for

UNION SELECT or <script> or ../../../

and it blocks the obvious stuff. That's real value. I've seen it catch real attacks. But somewhere along the way, I started noticing that the attacks we were actually worried about weren't the obvious ones.

And that's where the bypasses started becoming visible.

The attack string isn't always obvious anymore

For a long time, the thinking was simple: malicious request comes in, it contains a suspicious pattern, WAF catches it.

The problem is that attackers figured out this thinking a long time ago too.

The same SQL injection intent can be written a dozen different ways. URL-encoded. Unicode-encoded. Split across parameters. Buried inside a JSON body. Casing changed, comments added, nested, disguised as normal text.

None of that changes what the attack intends. But it absolutely changes whether a pattern-matching rule recognizes it.
That's the part that started me thinking.

A WAF rule asks: does this request look like something I've seen before? But the right question is: what is this request actually trying to do?

Those aren't the same question. And for a long time, I got that wrong.

Obfuscation isn't new, but it's gotten easier

I want you to know something: AI didn't invent SQL injection. It didn't invent XSS, or path traversal, or command injection. These attacks are old.

What has changed is how easy it is to generate variations of them.

Before, someone might manually crafted a handful of mutated payloads and test them. Now, generating fifty variations of the same attack idea takes almost no effort. You can take a known payload, ask for it to be rewritten in different styles, encoded differently, embedded in different structures, and you'll get back a list of things that all do roughly the same thing but look completely different on the surface.

That's not inherently terrifying. A lot of those generated payloads won't be sophisticated. But sophistication isn't the point. Volume and variation are.

Static rules are built around the idea that attacks have a recognizable shape. When variation becomes cheap, that assumption starts to break down.

I Built a Small AI Agent to Test My Own Assumptions

At some point, thinking about this in theory wasn't enough anymore. I wanted to actually test and see it.

So I built a small internal agent using a DeepSeek model and pointed it at my own AI WAF. Controlled environment, my own system, not aimed at anyone else's infrastructure. The goal wasn't to build something sophisticated or scary. It was just to answer one question: how quickly can the same malicious intent take on a different shape?

The agent's job was simple. Take known attack categories. Generate variations. See what comes out.

I was surprised at how it turned out.

Not because every payload was clever — many of them weren't. But here's the thing that stuck with me: every single mutation the agent produced was still flagged as malicious when analyzed. The intent survived every transformation.

' OR '1'='1
'%0B/*!50000OR*//**/%0A%0D%55%4E%49%4F%4E%0C/*!12345SELECT*/%0D%0A/*!CONCAT*/(CHAR(0x27)||'1'||CHAR(...
'%0B/**/OR/**/%55%4E%49%4F%4E/**/%53%45%4C%45%43%54/**/'1'%3D'1'--%0A

The payload moved from a query string into a JSON body. It changed encoding. It changed casing. It got wrapped inside normal-looking text. The surface kept shifting, but underneath, it was still doing the same thing — and something designed to look for intent, rather than pattern, still caught it.

That's when the weakness of static matching stopped being theoretical for me.

A rule-based system is trying to recognize a specific shape. But the shape kept changing. The meaning didn't.

And if a small agent running on my own machine could generate that kind of variation in minutes, I couldn't avoid this one question: how much of this is already happening in real traffic, from people who have been doing this a lot longer than I have?

That experiment didn't make me think AI replaces security engineering. If anything, it pushed me in the opposite direction. Good security still needs proper validation, authorization checks, rate limiting, logging, and human review. None of it is going away.

But it made one thing clear for me: if variation is this easy to generate, defenders can't keep depending on systems that need to recognize the exact shape of an attack before they can stop it.

Intent has to be part of the picture.

The tuning spiral

Here's something I didn't fully appreciate until I spent time inside real WAF configs: the tuning problem is real, and it is compounding.

You miss an attack, so you add a rule. That rule turns out to be too broad and starts blocking legitimate requests — a markdown editor, a developer portal, a support form where someone is describing a SQL error. So you add an exception. Then another attack gets through with a slightly different encoding, so you add another rule. And so on.

At some point, you're not really managing security anymore. You're managing a rule system.

And that rule system is full of implicit assumptions about what your application does, what your users look like, and what "suspicious" means in context. Those assumptions drift. Applications change. New endpoints get added. The team that wrote the original exceptions has moved on.

I've seen WAF configs I couldn't fully understand, let alone maintaining it. Rules that exist because of something that happened years ago. Exceptions that are there for the "just in case."

This isn't a criticism of the people who built them. It's a structural problem with the approach.

The attacks that don't look like attacks

The thing that really pushed me to rethink this was realizing how many meaningful attacks have nothing suspicious in them at all.

Given the example here:

GET /api/invoices/1021

Without

UNION SELECT or <script>

No suspicious symbols. A completely clean-looking API request .

But if the logged-in user isn't supposed to access invoice 1021, this is a broken object-level authorization bug — BOLA, or IDOR if you prefer that term — and it's been on the OWASP API Security Top 10 for years because it's so common and so easy to miss.

A traditional WAF can't catch this. Not because it's broken, but because the problem isn't in the syntax of the request. The problem is in its meaning, given who's making it and what they're allowed to do.

The same applies to a lot of business logic abuse. Skipping workflow steps. Manipulating fields that shouldn't be editable. Sending unexpected nested structures to confuse parsing. Repeating parameters. These don't look like attacks. They look like API calls.

And to be honest — an AI WAF has the same blind spot here. Analyzing request syntax and patterns alone won't catch BOLA or IDOR either, because the request is clean. There's nothing to flag. Catching it requires knowing who the user is, what they're authorized to access, and whether this specific request violates that. That's application-level context a WAF sitting in front of traffic doesn't naturally have.

Where intent-based detection does help is at the behavioral layer — flagging a user iterating through sequential IDs, or accessing resources at a rate inconsistent with normal usage. That's anomaly detection, not authorization enforcement. It can surface suspicious patterns. It can't definitively say "this is unauthorized" without being wired into your application's auth context.

BOLA and IDOR are an authorization problem. The fix lives at the application layer, not the WAF layer. AI or otherwise.

Rules alone don't have the context to know the difference. And sometimes, neither does the WAF.

What I think actually needs to change

I'm not arguing that rule-based WAFs should be abandoned. I don't think that. They're still useful, they're widely understood, and they catch real attacks.

But we've been asking them to do something they were never really designed to do — catch attacks built to evade detection.

The shift I keep coming back to is this: instead of asking whether a request matches a known bad pattern, we need systems that can reason about what a request is trying to accomplish.

That sounds abstract, so let me be cleared about what it means in practice.

An ML-based layer can look at signals that rules don't typically combine: the structure of the payload, the encoding pattern, the relationship between fields, the shape of the request relative to what this endpoint normally receives, the character distribution in a value that should be a name or an ID.

None of those signals alone is conclusive. But together, they can surface something that looks off even when no single rule would catch it.

That's the layer I think is missing from a lot of security stacks.

Why I started working on GladiosWAF

I want to be honest about what prompted GladiosWAF: it comes back to this frustration.

I kept seeing the same pattern: developers doing everything right — validating input, checking auth, setting up rate limiting, reviewing OWASP — and still having blind spots in traffic inspection because the WAF was built around a static picture of what attacks look like.

The web we're building on isn't static anymore. The applications are more API-driven. The clients are more diverse. The payloads are more complex. And the tools available to generate attack traffic has never been easier.

The idea behind GladiosWAF is simple: what if the WAF could focus less on matching exact strings and more on classifying intent? What if it could flag suspicious traffic even when the payload is encoded, obfuscated, or just slightly different from anything it's seen before?

Not as a replacement for good application security. Not instead of authorization checks or input validation. But as a smarter layer in front of the application, one that doesn't need a signature to recognize that something is wrong.

The honest summary

Rule-based WAFs are not dead. They're part of a layered defense, and that layer matters.

But modern attack traffic is designed to look different every time. AI makes that variation cheaper. Obfuscation makes it easier. And the result is a growing gap between what static rules catch and what actually gets through.

The string isn't always the problem.

The intent is.

And I think it's time we built tools that can actually look for it.

Your WAF should understand intent, not just match patterns. GladiosWAF helps detect modern web attacks across APIs, GraphQL, headers, cookies, queries, and request bodies — including evasive traffic that traditional rule-based systems may miss. Explore GladiosWAF at https://www.gladioswaf.ai