Agentic AI is evolving the WAF
How to turn reachability, runtime evidence, and a judged WAF rule into a temporary block for zero-days and other critical, time-sensitive vulns
When a critical web vulnerability lands, the software patch often still needs days. Attackers do not wait that long. From January through June 2026, CrowdStrike observed that 88% of exploitation against vulnerabilities with a public proof of concept started within 48 hours of the PoC release. Verizon's 2026 DBIR puts the median time to fully remediate a CISA KEV vulnerability at 43 days.
Agentic WAF rules buy that gap as a virtual patch: a narrow, judged, tested block on the exploit path for exposed routes while the real fix ships.
This post is that pipeline. Reachability and inventory decide whether the vuln is a virtual-patch candidate. Runtime evidence and a separate judge shape a rule in your WAF dialect. CI replay and shadow mode keep promotion safe. I started from Cloud Security Podcast's conversation with Adobe on agentic WAF pipelines.
Virtual patching is the time-sensitive control
Virtual patching blocks the specific exploit traffic at the edge while the software patch goes through its normal path. Patches are the lasting fix. Rules buy hours and days.
That control matters for three cases:
A disclosed critical CVE with a public PoC and an internet-facing workload that still runs the vulnerable package.
A CISA KEV or vendor-urgent advisory where the patch window is longer than the exploit window.
Suspected zero-day activity: exploit-shaped requests on a route, no advisory yet, and you need a temporary request pattern while IR continues.
Managed rulesets still cover common attack classes. The painful gap is the new or urgent exploit path: no signature yet, a patch ticket measured in days, and attackers already mutating encodings and request fields.
A conventional WAF sees an HTTP request. It usually does not know which package sits behind the hostname, whether the asset is public, what normal traffic looks like for that route, or whether a software patch can ship in an hour or in three weeks. Narrow virtual-patch rules need that context: inventory, architecture, threat models, recent logs.
Reachability decides what gets a virtual patch
External attack surface management and cloud inventory answer a simple triage question: is this vulnerability on something attackers can hit now?
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. Frontier models start from what is reachable now, then test, rank and chain those exposures, often before your next CMDB sync. Inventory has to feed the WAF loop in near real time, or you spend the exploit window on the wrong hosts.
Large estates make the authoring seam worse. Acquisitions and independent product teams leave security engineers managing several commercial and open-source WAFs. Consolidate the authoring path across those dialects so a candidate rule can land in the right product without waiting on a single-vendor migration.
Build the agentic virtual-patching loop
Most of the loop should stay deterministic. Put the model where judgment helps: reading the advisory or incident package, drafting a narrow rule, and scoring it against a written rubric.
For a disclosed critical 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.
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. Treat the root cause as unknown until an advisory exists.
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 a WAF can inspect.
A thinner version still covers the critical path
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 for critical and actively exploited issues.
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.
MCP can replace several bespoke integrations so the agent queries inventory and observability through one tool interface. Treat that harness as a security boundary: OAuth and per-tool scopes, separate read and write identities, no token passthrough, human approval for blocking, egress restrictions (especially to cloud metadata), and complete logs of tool arguments, generated rules and promotion decisions.
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.
Prove the rule before you scale the agent
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 critical 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 for suspected zero-day patterns, and a second application.
If those three measures hold on one route, expand hostname by hostname. Each virtual patch still needs an owner, an expiry date, and a path back to the software fix.
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.
Research for this post was assisted by AI agents.
