Agentic AI is evolving the WAF
Exposure context and harnessed rule loops, not another signature pack
Web application firewalls still sit in front of the request. What is changing is how rules get researched, drafted, tested and promoted when a new exploit lands.
Agentic AI helps because it can join work that used to live in separate consoles: reachability from external attack surface data, runtime evidence from logs and traces, candidate rules in the local WAF dialect, and a test harness before anything blocks production traffic. The model is not magically better at regex. The loop is faster than a human queue that waits on a vendor signature pack or a change window while scanners already hit the hostname.
A CNAPP or EASM view can tell you which vulnerable workload is exposed. A WAF can block a request to it. Between those controls sit a ticket, a security engineer, several consoles and a change window. That seam is still the WAF problem. Agentic pipelines are one way to close it.
This piece started after I listened to Cloud Security Podcast's conversation with Adobe on agentic WAF pipelines. The useful idea is simple: treat rule authoring as a harnessed agent loop that reacts to exposure and evidence, not as a specialist queue that wakes up after the PoC drops.
Static rules are not the whole WAF problem
A conventional WAF sees an HTTP request. It usually does not know:
which application and vulnerable package sit behind the hostname
whether the asset is public, business-critical or already under attack
what normal traffic looks like for that specific route
whether a software patch can ship in an hour or in three weeks
Managed rulesets still earn their keep for common attack classes. Burning an AI loop to re-tune the vendor OWASP-style package is usually diminishing returns. The painful gap is the new exploit path: no signature yet, a patch ticket measured in days, and attackers already mutating encodings and request fields.
CrowdStrike's 2026 Threat Hunting Report puts a number on that clock. From January through June 2026, 88% of the exploitation it observed against vulnerabilities with a public proof of concept happened within 48 hours of the PoC release. Verizon's 2026 DBIR puts exploitation of unpatched vulnerabilities as the leading initial access vector at 31%, with a median of 43 days to fully resolve a critical issue. Those two figures should sit next to each other on any virtual-patching slide.
False positives never left. Models make it easier for attackers to mimic legitimate traffic, which means broader rules fail louder. Narrow rules need application context: source, architecture, threat models, recent logs. Regex alone will not get you there.
External attack surface management meets the agentic WAF
External attack surface management used to mean finding unknown hostnames, certificates and shadow IT. That inventory still matters. What changed is how fast the outside-in loop moves.
Frontier models do not wait for your next CMDB sync. They start from what is reachable now, then test, rank and chain those exposures. Visibility alone is not enough when the attacker view of your perimeter updates faster than most internal asset processes.
That is also where WAF work should sit. A CVE in a library you do not expose is a patch ticket. A CVE on an internet-facing service is a virtual-patch candidate. EASM and cloud inventory answer "is this reachable?" An agentic rule pipeline answers "can we block this exploit path in minutes while the real fix ships?"
Large estates make the seam worse. Acquisitions and independent product teams leave security engineers managing several commercial and open-source WAFs. Consolidating the authoring path across those dialects is more realistic than pretending you will standardise on one vendor next quarter.
Build a virtual-patching loop, not a smarter regex
Virtual patching is the emergency control: block the specific exploit traffic while the software patch goes through its normal path. Patches are the lasting fix. Rules buy time.
Most of that loop should stay deterministic. Put the model where judgment helps.
For a disclosed vulnerability:
Ingest the advisory and available proof of concept.
Query inventory for affected packages and workloads.
Confirm public hostnames or IP addresses. Reachability matters more than SBOM hits alone.
Pull recent requests, traces and security signals for those routes.
Draft a narrow candidate rule in the required WAF dialect. Score it with a separate judge model and a written rubric. Do not ask one model to grade itself.
Replay exploit variants and known-good traffic in CI, then behind the real WAF in a private environment.
Deploy in count or shadow mode. Require a human, or a separate promote job, before blocking.
For suspected zero-day activity with no advisory, replace step 1 with an incident package: suspicious requests, decoded payloads, affected routes, response codes and traces. Infer a temporary request pattern. Do not pretend the root cause is understood.
A virtual patch blocks an observed exploit path. It does not replace the software patch, and it does not prove the vulnerability is fully understood.
An agent here is a model plus a harness: APIs, secrets, shell, memory, loops and constraints. Constraints are the point. "Create a shadow rule for this hostname" is a different permission from "enable blocking on every edge product we own."
Scope the pipeline to HTTP(S) application exploit paths. Do not point it at network-appliance parser bugs or kernel flaws a WAF cannot see.
A smaller company can run a thinner version
You do not need a multi-WAF estate. Imagine a 200-person SaaS company with one managed cloud WAF, a CNAPP or EASM view of internet-facing assets, and an observability platform.
The first useful version can be small:
A job watches GitHub Advisories, CISA KEV and vendor bulletins.
Inventory confirms the component sits on an internet-facing workload and maps it to an owner and hostname.
Observability supplies sampled requests and known-good traffic for that route.
A rule agent produces a production-dialect rule and a ModSecurity rule for local tests.
CI replays the exploit, mutations and normal application flows.
The agent opens a pull request and deploys in count mode.
A human reviews match volume and promotes to block.
The orchestrator can be a workflow service, a small service or CI. Product choice matters less than the control boundary. Its identity may read inventory and telemetry, create a candidate rule and enable shadow mode. It may not delete rules or enable blocking across every application.
One thing worth calling out: every virtual patch should carry the vulnerability or incident ID, affected hostname, evidence, test results, owner and expiry date. A technically correct rule with no owner or rollback path becomes permanent security debt.
MCP helps the prototype and widens the surface
MCP can replace several bespoke integrations. An agent can query inventory for exposed vulnerable assets and observability for the requests reaching them through one tool interface. That makes a prototype realistic for a small security team.
It also adds another internet-facing asset class. Unauthenticated MCP servers have already exposed internal records, write operations, code execution and, in some cases, cloud credentials. An MCP gateway often sits in front of powerful tools with backend credentials already attached.
The same virtual-patching loop can protect HTTP-based MCP servers and agent gateways when a request exploits a parser, route or authentication flaw. A WAF still will not catch every agentic failure mode. Prompt injection hidden in a document may be valid HTTP. Tool misuse may use an authorised session. Those need runtime inspection and least-privilege credentials, not another regex.
For the virtual-patching agent itself, I would require:
OAuth and per-tool scopes for MCP access
separate read and write identities
no token passthrough between services
human approval for blocking or destructive actions
egress restrictions, especially to cloud metadata endpoints
complete logs of tool arguments, generated rules and promotion decisions
The harness is the security boundary. A prompt saying "be careful" is not one.
Start with one route and one WAF
Pick an internet-facing application with good telemetry. Connect its inventory record to one WAF API. Build a corpus of normal requests. Run the pipeline against a historical web CVE and measure three things:
Did it block the known exploit?
Did simple exploit mutations bypass it?
Did it break any recorded customer flow?
Keep promotion manual until the answers are repeatable. Then add the telemetry-led trigger and a second application. Do not begin by giving an agent credentials to every edge control you own.
If those three measures hold on one route, you have enough evidence to argue for a second hostname. That is a better starting point than a programme to replace every WAF you already run.
References
Cloud Security Podcast, How Adobe Uses AI Agents for building a WAF Pipeline? (Ammar Alim, 4 Aug 2026).
CrowdStrike, 2026 Threat Hunting Report.
Verizon, 2026 Data Breach Investigations Report.
Wiz Research, The Security Risks Hiding Behind Exposed MCP Servers.
Model Context Protocol, Security Best Practices.
Archify - Create architecture diagrams
Research for this post was assisted by AI agents.
