Frontier AI attacks applications in two ways: faster exploits, and AI-driven actors that simply log in. Defending against both takes every layer working together, with security and delivery built as one.
Kayvan Farzaneh, Solutions Architect, F5
PK Iyer, Sir Dir, Solutions Engineering, F5
In August 2026, one of the world’s largest retailers tried to block an AI shopping agent from its store, and couldn’t. A US appeals court struck down its order blocking the agent, finding that because the agent acts on a real customer’s instructions, it is the customer accessing the store, not the AI company (Amazon v. Perplexity, 9th Cir., August 2026, as reported by Engadget).
The most sophisticated e-commerce operation on earth cannot simply wall these agents out: not legally, and, by the retailer’s own account, not technically either. The agent kept getting in, disguised as an ordinary browser. That is now the design goal of the most capable AI agents: to look exactly like a real customer. They arrive through residential proxies on the same networks your customers use, and mimic human behaviour closely enough to slip past the controls meant to catch them.
So if you can’t block them, and often can’t tell them apart from a human, one question is left: do you know which AI agents are on your applications right now, acting for your customers, with credentials your systems trust, doing things you never designed for?
Frontier AI has changed the application threat model in two ways at once. It has made the old attacks faster: models can now discover vulnerabilities and weaponize them within hours, collapsing the patch window from weeks to minutes. And it has created a new kind of attacker entirely, one that doesn’t present as an attacker at all. Autonomous, AI-driven actors and agents don’t break in, they log in, with valid credentials and perfectly legitimate requests, to abuse what your application is designed to do.
Defending against the first requires security that extends beyond attack signatures. Defending against the second requires security that can see actors and behaviours, not just requests. This article explains how F5 addresses both through the F5 Distributed Cloud platform, and why frontier AI threats demand full-stack protection rather than a single-point solution.
The real fear isn’t complexity, it’s silent failure
CISOs and security practitioners don’t fear the attack that triggers hundreds of alerts. They fear the one that triggers none: the silent blind spot they aren’t prepared for, posing an unquantifiable risk to the business. Modern AI-driven attacks are built to look exactly like that. The syntax is valid. The token passes. Nothing is technically malicious, but the outcome is.
Attackers no longer break applications; they misuse them, exploiting the gap between what an API can do and what it should do. The actors doing it are increasingly autonomous agents that browse, query and transact the way a person would, and they hide behind the same residential ISPs your real customers use, so network-level identity tells you very little about who is on the other end. Each traditional security layer answers one question well and stays blind to the rest. No single control was designed for this combination, which is why the answer has to be full-stack protection.
Layer one: the Web App Firewall, now AI-powered
The web application firewall is still the foundation. It answers one question: is this request structurally dangerous? SQL injection, malformed requests, known exploit patterns. A modern WAF uses thousands of signatures to detect these threats efficiently and at scale.
But frontier AI has broken the assumption that model was built on: that when a vulnerability is disclosed, defenders have time to read the advisory, test a patch, and schedule a maintenance window. Post-Mythos, now that frontier models have shown they can find and weaponize vulnerabilities on their own, that window has collapsed from weeks to hours. When CVE-2026-42208, a critical SQL injection in the widely used LiteLLM AI proxy, was indexed in the public advisory database, the first confirmed exploitation attempt was documented within 36 hours. No manual signature-writing process wins that race.
So the real question is no longer whether you have a signature for a given attack. It’s what your WAF does in the window before one exists. F5 Distributed Cloud answers with two capabilities that work together.
The first is speed of protection, and it works in both directions. Because Distributed Cloud is a SaaS platform, F5 pushes new and updated signatures into every customer’s data path almost immediately, with no appliances to upgrade and no maintenance window to wait for. And customers don’t have to wait for F5 either: the platform lets security teams push their own virtual patch, shielding a vulnerable application within minutes while they schedule the real fix on their own terms. There is a catch every practitioner knows, and we’ll come back to it: a brand-new rule can misfire, and the safe practice of staging it in monitoring mode is precisely the window an AI-accelerated attacker is racing to exploit.
The second capability matters even more: the WAF engine itself got smarter.
The historic weakness of signatures was accuracy. Low-confidence signatures create false positives, so many organizations left most rules in monitoring mode. F5 addressed this by training AI models on real-world traffic, using HTTP attack fragments to combine groups of weak signals into confident decisions. The result is broader coverage and blocking-mode confidence, without drowning teams in false-positive noise.
This delivers something signatures alone cannot: catching attacks before a dedicated signature exists. CVE-2026-42208 is a documented example. F5 tested Distributed Cloud WAF against the live LiteLLM exploit in two configurations. With a signature-only default profile, the WAF missed the attack; the SQL payload smuggled inside an Authorization: Bearer header evaded static matching. With the AI-powered engine enabled, a neural-network classifier recognized the injected SQL fragments as malicious and blocked it. Pre-exploit protection, delivered before customers could patch. (F5’s broader response to the collapsing patch window is covered in its frontier AI defense overview, and the full CVE-2026-42208 write-up is on the F5 blog.)
The capture below shows the same principle on a different vulnerability: a real exploitation attempt against Spring Cloud Gateway, as seen by the AI-powered WAF.
The AI-powered WAF combines multiple low-accuracy signature matches into a single high-confidence risk decision.
Look at the right side first. The request tripped several signatures at once: a command-execution attempt, two expression-language injection patterns, and probing of a predictable resource path. Every single one is marked low accuracy. In a traditional WAF, that label is exactly why rules stay in monitoring mode; any one of them, alone, fires on too much legitimate traffic to block on.
Now the left side. The AI engine doesn’t evaluate them alone. Taken together, multiple weak indicators in the same request forming a coherent attack chain produce a risk score of 99, with high confidence of impact to confidentiality, integrity and availability. Four signals that a signature-based WAF couldn’t safely act on individually become one decision it can block with confidence.
That’s the shift in one picture: from “does this request match a pattern?” to “what do all these signals mean together?” It is the principle that lets a WAF flag attacks before a dedicated signature exists for them, because coherent attack context doesn’t depend on a published identifier.
Closing the window: from scan to virtual patch
That leaves the practitioner’s catch from earlier. If the AI engine is the safety net for attacks nobody has a signature for yet, the virtual patch is the deliberate response to a vulnerability you know you have. The question is how fast, and how safely, you can get one in front of the application.
This is where being a full L7 proxy in the data path matters. A virtual patch is only as good as the point where it is enforced, and F5 Distributed Cloud sits between every client and the application: terminating the connection, parsing the full request and response, and holding the request until a decision is made. Enforcing security at the payload level is the capability F5 has been known for through two decades of BIG-IP, and that same capability is now on the SaaS platform too, in front of applications wherever they run. There is no appliance to upgrade, no agent to install in the application, and no release train to wait for. A patch defined in the console is live on every load balancer that references it, in minutes.
It also means a virtual patch isn’t limited to a WAF signature. Because the WAF, API security, bot defense, rate limiting and Malicious User Mitigation all sit in the same data path, the mitigation can be the right control for the flaw. A service policy can enforce function-level authorization, closing a BFLA gap by restricting who can call an administrative endpoint or method, or match a payload pattern to block an exploit outright. API schema enforcement validates request and response payloads, authentication validation rejects requests whose tokens don’t hold up, and rate limiting and Data Guard cover brute force and data leakage. Each control is narrow, targeted at one flaw on one path, which is why it can go to blocking mode far sooner than a broad signature could. The week of monitoring-mode staging shrinks to the time it takes to confirm the exploit is blocked and legitimate traffic still flows.
The PHP2Shell incident in October 2026 is a live example. Details of two critical PHP remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, leaked publicly about a day before the official fix was released: bugs rated 9.2, affecting PHP from version 5 onward, which covers a large share of the web. The exploit arrives through upload requests that drive PHP’s session upload-progress feature, and the public guidance was to disable that feature and block the triggering requests. That is exactly what a service policy does. Working from the leaked attack details, some XC customers chose to apply service policies matching the triggering request pattern, closing the vector for their applications hours before the CVE records were even published. F5 released dedicated signatures within hours of the official release, once their accuracy was confirmed. And F5’s own testing reports that the AI-powered engine needed neither: it scored the exploit payload as critical risk from patterns learned in earlier attacks, the same principle described above.
The remaining question is where the list of flaws comes from. Increasingly, the answer is: from AI, on the defender’s side. F5 Distributed Cloud Web App Scanning combines external attack-surface discovery with dynamic application security testing, and its GenAI-enhanced crawling makes that testing more effective. The model reads each page, understands what inputs the application expects, and supplies them to reach the next page or state. The scanner gets to the workflows behind forms and multi-step journeys that traditional crawlers stall on, so more of the application actually gets tested. For organizations that can’t run their own models to scan their applications, this is how they get the same AI-driven discovery attackers now have. And because the scanner and the enforcement point live on the same platform, a finding arrives in terms the platform already understands: which endpoint, which parameter, which payload. Translating it into a virtual patch is a short step.
An F5 engineer has published an open-source virtual patching copilot, FrontierAI-Virtual-Patch on GitHub, that closes this loop end to end. It is a community project rather than an official F5 product, but it shows how short the step is. LLM agents discover and adversarially verify a vulnerability, pick the right Distributed Cloud control for it, generate the configuration and, after a human approves, deploy it to the live load balancer, validate that the exploit is blocked while legitimate traffic still flows, and roll back automatically if not. It is model-independent, and it treats every virtual patch as a band-aid rather than a cure: each finding also gets a code-fix pull request, and a ledger tracks the patch from found to mitigated to remediated to retired, so a temporary shield never quietly becomes permanent.
That is the defender’s answer to a patch window that has collapsed to hours: the same class of AI the attacker is using, pointed at your own applications, with a platform underneath it that can enforce what it finds, in minutes. But even a great WAF only sees syntax. The other half of the threat doesn’t use dangerous syntax at all. It uses valid syntax to produce invalid or unauthorized outcomes.
Layer two: API security, discovering and defending business logic
Modern applications expose their business logic through APIs, used by humans, other applications and AI agents alike. Every agent request is an API call to your application.
That makes API discovery the starting point. You can’t protect endpoints you don’t know exist, and shadow, zombie or orphan APIs are a persistent risk. But discovery now has a bigger role: it is the foundation for governing AI-driven traffic, because you can’t judge whether an actor should be doing something until you know what your APIs actually do.
Most serious API incidents don’t happen on unknown endpoints. They happen on APIs that are known, documented and authenticated, and still being exploited. A valid user with a valid token accessing resources they aren’t authorized to. Every request looks clean in isolation; the relationship between the user and the data is what’s broken.
Static rules can’t catch that, because nobody writes a rule for logic they didn’t know could be abused. F5’s approach is different: the platform builds machine learning models from the API traffic itself, learning, per endpoint and per entity, what the business logic actually is. Which identities normally access which objects, and in what context. The relationships that developers encoded implicitly across hundreds of endpoints, but no one ever wrote down as a policy, the system learns by watching, until it holds a working model of how the application is supposed to behave.
That changes what detection means. This isn’t just spotting statistical anomalies such as unusual volumes or odd frequencies. Once the model has learned that an object is normally accessed by a specific user identity, a similar request for that same object from a different user identity stands out immediately. No repeated abuse required.
Here is a detected incident demonstrating exactly that:
A BOLA detection: the learned access pattern for a private object broke when a different authenticated identity requested it.
Read the detection description: an attacker manipulating the dynamic segment of a resource path, /vehicle/{vehicleId}/location, to reach another user’s data. Classified automatically as a BOLA attack (Broken Object Level Authorization, the top entry in the OWASP API Security Top 10).
There was no enumeration campaign to flag here. No burst of traffic, no failed logins, nothing a WAF signature could match. By any volumetric or rate-based measure, almost nothing happened at all. What caught it is the pattern. The platform had learned, from traffic, that this object was private, accessed by one user and only that user. When requests arrived for the same object under a different authenticated identity (attributed from the JWT, as the second panel shows), the learned access pattern broke, and that break is the detection. Not a database of who owns what; a model of how objects are normally accessed, sensitive enough that a handful of out-of-pattern requests is all it takes.
That’s the difference between rules and learned logic, and it matters enormously for agentic threats. An AI-driven attacker doesn’t need to be noisy. A few precise, valid requests can exfiltrate exactly what they came for. Defense that needs a flood to notice will miss it; defense that has learned normal access patterns is far more likely to catch it.
Layer three: bot defense, knowing who’s actually acting
The WAF sees syntax. API security sees logic. Neither answers the most fundamental question of the agentic era: who, or what, is behind this session?
That is the actor layer, and it is where the agents from the opening land. AI agents now browse and interact with applications the way humans do: operating real browsers, completing real workflows, at a pace and precision no human matches. At the same time, residential proxies make network-level identity meaningless, and device fingerprints alone collide at scale.
Detecting that a request is arriving through a residential proxy rather than a genuine customer connection is exactly what Bot Defense does, reading behavioural signals the proxy can’t disguise. And it isn’t only obvious attackers who evade this way. We’ve observed the same evasive instinct in agentic browsing, including some well-known consumer-facing AI agents, reaching for residential proxies when they meet a geo-block, a rate limit or a bot defense. When an agent is built to evade, behavioural analysis at the actor layer is what still gives it away.
F5 Bot Defense answers the actor question in two complementary ways. The first is deep telemetry: behavioural and interaction signals that automation, even sophisticated AI-driven automation, can’t fully replicate. This is what distinguishes humans from bots from AI agents, including agentic browsing sessions that drive real browsers through real workflows the way a person would.
The second is verifiable identity, using emerging standards F5 supports: Web Bot Auth and Know Your Agent (KYA). With Web Bot Auth, an agent cryptographically signs its requests, and F5 validates that signature to confirm the claim. When an agent presents itself as a shopping assistant built by a particular provider, that identity is proven, not merely asserted. KYA goes further: beyond who the agent is, it attests to the context behind it, what kind of agent it is, which platform it runs on, and which human or enterprise authorized it to act. Telemetry answers what is acting; these frameworks answer who it is, and on whose behalf.
That changes the default. Instead of risking a legitimate agent getting caught in the anti-bot net, a business can maintain an allow-list of the agents it wants, and when an agent’s Web Bot Auth signature validates against that list, Bot Defense lets it through rather than treating it as a bot to stop. This is the answer to the retailer in the opening: not a wall, but a guest list. For the shopping assistants driving real customer purchases, it is the difference between enabling revenue and accidentally blocking it, and it is also what protects the real customer behind the agent from being caught in the crossfire.
Because not all automation is malicious, the goal isn’t to block every agent. It is visibility: knowing what’s acting on your platform, so policy can be set with facts instead of guesses. As these identity standards mature, that same visibility becomes the foundation for finer-grained control. Here is what it looks like in the platform, a Bot Defense view of live traffic:
Bot defense identifies and classifies AI agent traffic: by volume, by intent category, and by named (or unmatched) identity.
Start top-left: of all bot transactions on this application, AI-driven transactions are counted as their own class. A third of the automated traffic here isn’t a classic crawler or script, it’s AI. Top-right shows why that distinction matters: the same traffic broken down by intent, into web crawlers, AI assistants and AI data scrapers. Three very different actors deserving three very different policies.
The bottom row is identification. Known agents are named, GPTBot and Meta-ExternalAgent, alongside something more interesting: an agent presenting bot-authentication signals but matching no known identity, surfaced explicitly as unknown. That is the actor layer doing its job: not just “automation detected,” but which automation, what kind, and, critically, which actors can’t be identified at all. An unknown agent that then misbehaves can be classified as malicious automation and policy applied accordingly.
And it is accelerating: across F5 Bot Defense customers, verifiable agent traffic, the Web Bot Auth signed requests described above, has grown roughly tenfold since May:
Verifiable AI-agent traffic (requests signed via Web Bot Auth) grew roughly 10x from May to the end of September 2026 across F5 Bot Defense customers. The majority are shopping assistants; the next-largest group interacts with the cart and checkout.
Most of these agents are shopping assistants performing product search on behalf of consumers, followed by agents that act on the shopping cart itself, right through to checkout. This is agentic commerce arriving in real production traffic. The platforms that can see and classify these agents today are the ones that will be able to govern them tomorrow.
And note what isn’t happening in these dashboards: blanket blocking. You may want search crawlers. You may also want AI assistants acting on behalf of your customers. The value of the actor layer is that these choices become deliberate policy decisions, made with evidence, not invisible automation you never knew was there.
Stitching it together: correlation across layers
Agentic threats are hard to detect for a simple reason: in isolation, each layer sees a clean request. The agent quietly abusing your platform doesn’t fail any single check. What exposes it is correlation: building a behavioural risk picture for every entity, over time, across all three layers.
In F5 Distributed Cloud, this correlation engine is Malicious User Mitigation. It continuously scores every entity against signals from across the stack: WAF events, failed authentication attempts, unusual object access, machine-precise timing, residential proxy usage and other behavioural indicators. Alone, each signal may be too weak to act on. Together, they become a risk profile the platform can trust, turning scattered hints into a confident decision and escalating mitigation automatically as risk builds.
It goes beyond correlating discrete security events. The engine also applies behavioural anomaly detection per entity, learning what normal activity looks like for each actor and flagging deviations even when no individual rule has fired. That is how an entity can accumulate risk from behaviour alone: not because it tripped anything, but because it stopped looking like itself.
Malicious User Mitigation: signals from different layers fuse into one entity’s risk score, and the score builds as behaviour accumulates.
The top event shows correlation across layers: a handful of requests, three WAF security events, and threat intelligence marking the source as a high-risk IP. Three different systems’ observations, evaluated to produce a single risk score for one entity. No individual element would justify blocking; together they are already a 65.
The timeline below shows the other dimension: correlation over time. Watch the score climb, from failed login attempts, to a behavioural anomaly in API access layered on top, to more failures: 48.6, then 54.4, then 60.2, and finally 100. Each event in isolation is the kind of thing that happens to legitimate users every day. A user mistypes a password; an integration calls an unusual endpoint. What legitimate users don’t do is all of it, in sequence, in seconds. The engine reads the sequence, not the snapshots, and by the time the pattern completes, the entity is already scored for automatic mitigation.
This is the answer to the actor that’s clean at every checkpoint: no single layer had to catch it, because the platform was never relying on a single layer. It also gives you a second answer to the monitoring-mode dilemma, acting on WAF signals before you’re confident enough to block on them alone; Preston Ashworth shows how to use Malicious User Mitigation exactly that way here.
This layered defense has been tested against a real frontier-AI attacker. ARTEX is an open-source agentic penetration testing framework: LLM-driven agents that run reconnaissance, find vulnerabilities and execute exploit chains on their own. It is no longer a research tool. Zscaler documented a campaign in late September 2026 in which a threat actor used it against South Korean financial institutions and stole the personal data of roughly 67,000 people. It is a working example of the attacker this article describes. When we ran ARTEX against web applications in our lab, the AI-powered WAF alone blocked approximately 95% of its attacks. Adding Malicious User Mitigation took protection to 100% in our tests: the few requests that slipped past individual checks built up an entity-level risk score, the attacking agent itself was detected, and everything it sent afterwards was mitigated. One layer stops most of the attack; the correlation layer stops the attacker.
Each layer sees a fragment. Correlation assembles the full picture, and surfaces the actor that cruises through each individual checkpoint but is obviously malicious once you see the whole.
Why security and delivery must be one platform
There is a ceiling on what blocking alone can achieve, and AI-driven attackers lower it further. To a learning attacker, every blocked request is training data. A clean block tells the model exactly which probe failed, so it adjusts, returns with new infrastructure and new fingerprints, and you’ve lost visibility. The cycle repeats, faster each time.
A more effective way to mitigate an AI-driven attacker is to deceive it instead of blocking it. Serve responses that look like success but contain nothing real, and the feedback the model learns from is poisoned: it wastes its attack budget, trains on wrong signals, and stays visible while fraud teams investigate. This is only possible when security decisions can change how the application responds, not just whether a request gets through. A bolt-on watching traffic from the side can drop a request; only the platform that delivers the application can answer it with something else. That is why delivery and security must be the same platform, in the data path, everywhere your applications run. The same position enables the gentler controls too: slowing an abusive workflow without touching legitimate traffic, or adapting policy per actor in real time.
Full-stack protection, delivered as one
This is F5’s answer to frontier AI threats, both facets of them:
- An AI-powered WAF for structural attacks: syntax, known exploits, protocol anomalies.
- Virtual patching for the collapsed patch window: GenAI-enhanced scanning to find the flaw, and any control on the platform to shield it in minutes while the real fix ships.
- API security for logic abuse: discovery, learned business logic, and the attacks that look valid but produce the wrong outcome.
- Bot Defense for the actor layer: human, bot or AI agent, and whether they belong there.
- Correlation across all of it, because each layer sees a fragment but together they reveal the full picture.
- Built into application delivery, so security doesn’t just observe or block; it changes how applications respond.
Separately, each layer is necessary. Together, on one platform, everywhere your apps run, that is full-stack protection. And it isn’t just F5 saying so. SecureIQLab, an independent security testing laboratory, evaluated F5’s WAAP across roughly 40 test cases encompassing approximately 2,000 attack and benign payloads, with enterprise traffic running in the background to recreate a typical customer environment:
| SecureIQLab test category | Result |
|---|---|
| Total security score | 97.09% |
| OWASP WAF Top 10 — key risks | 100% |
| OWASP API Top 10 — key risks | 100% |
| Bot attack mitigation | 100% |
| Layer 7 DoS protection | 100% |
Every layer described in this article, validated in the same independent test. (Details in F5’s summary of the results.)
That is the F5 Application Delivery and Security Platform (ADSP): delivery and security built as one. Not a vision, but what F5 delivers today.
The platform principle doesn’t stop at the application’s front door, either. Applications are themselves becoming agentic, exposing MCP servers and AI services of their own, and because Distributed Cloud already sits in the data path, extending these same controls inward is the natural next step. That is a story of its own, and we’ll cover it in a follow-up article.
References
Amazon v. Perplexity ruling. Engadget, “Perplexity has successfully overturned Amazon’s injunction on its AI shopping bot”: Perplexity Has Successfully Overturned Amazon's Injunction On Its AI Shopping Bot
F5 frontier AI defense overview, “Defend against frontier AI threats at runtime”: Defend against frontier AI threats at runtime | F5
CVE-2026-42208 write-up. F5 blog, “F5 Distributed Cloud WAF provided native protection to customers for CVE-2026-42208”: F5 Distributed Cloud WAF provided native protection to customers for CVE-2026-42208 | F5
PHP2Shell and the AI-powered WAF. F5 blog, “AI found it. AI is stopping it.”: AI found it. AI is stopping it. | F5
Virtual patching copilot (community project by an F5 engineer). FrontierAI-Virtual-Patch on GitHub, design document: FrontierAI-Virtual-Patch/DESIGN.md at main · f5devcentral/FrontierAI-Virtual-Patch · GitHub
Making WAF monitoring mode powerful. Preston Ashworth, DevCentral: Making WAF Monitoring Mode Powerful - DevCentral
SecureIQLab independent test results. F5 blog, “Independent tests reveal F5 provides protection against AI app attacks”: Independent tests reveal F5 provides strong protection against traditional, emerging, and targeted AI app attacks | F5