Skip to content
Open to board advisory and board seats — 2H 2026, then CY 2027–2028.
See details →
Writing

WAF in the Agent Era: Good Bots vs. Abuse

Agents are now real customers hitting your edge with real economics. The old bot question — human or machine? — is the wrong one. Here's the one that matters.

By Michael YorkJune 2, 2026 4 min read 998 words All postsTable of contents

For most of the last decade, the bot question at the edge was simple and binary: is this a human or a machine, and if it's a machine, block it. That logic built an entire industry. CAPTCHAs, JavaScript challenges, device fingerprinting, behavioral scoring, all of it resting on the assumption that automated traffic is, by default, something you want to keep out.

That assumption is now wrong, and it's wrong in a way that costs money. A growing share of the traffic hitting your application is not a scraper or a credential-stuffing botnet but an agent acting on behalf of an actual customer: a shopping assistant comparison-checking your rates, a research agent pulling your product docs, an LLM-backed workflow a customer wired up to manage their own account. The user is real. The intent is legitimate. The revenue is real. And your WAF, tuned on the old binary, is treating it like an attack.

The economics changed before the controls did

We spent years thinking about bot traffic as pure cost: bandwidth burned, fraud absorbed, infrastructure scaled to serve requests that would never convert. In the agent era, a meaningful slice of automated traffic has the opposite profile. It's pre-sales. It's a customer, or a customer's delegate, doing the evaluation work that used to happen in a browser tab. Block it indiscriminately and you are declining inbound demand at the firewall.

In financial services, where I work, this gets sharper. We serve more than 1,500 financial institutions, and the people behind those institutions increasingly expect to interact with services the way they interact with everything else, through an assistant that does the legwork. When an agent shows up at the edge asking for rate information or account data on behalf of a verified user, answering with a 403 and a JavaScript challenge it can't solve is an outage you chose, dressed up as a security control.

So the binary has to go. The question is no longer human or machine. It's authorized or abusive, and those are completely different axes. Plenty of legitimate traffic is machine-driven. Plenty of abuse is impressively human-shaped. A WAF strategy built for the agent era has to stop conflating the two.

Sort by identity and intent, not by signature

If you can't sort by human versus machine anymore, you sort by something more durable: who is this, and what are they trying to do. The mechanics are all available today with public, well-understood capabilities.

Start with verifiable identity for agents. Good automated traffic increasingly wants to identify itself, through signed requests, verified bot programs the major providers publish, and cryptographic mechanisms like HTTP Message Signatures that let a client prove it is who it claims rather than just asserting a user-agent string. Treat self-identification as the front door. An agent that signs its requests and respects your published access policy is telling you it wants a relationship. Build a fast lane for it. The agents that refuse to identify, spoof a Chrome user-agent from a residential proxy pool, and rotate fingerprints every request are sorting themselves into the other bucket without your help.

Then layer AI-driven traffic analytics on top of the WAF rather than treating rules as the whole game. Static signatures catch yesterday's attack. What actually separates a legitimate agent from a scraper at scale is the shape of behavior over time: request cadence, the sequence of endpoints touched, whether the session looks like goal-directed work or like enumeration. Modern edge platforms score this continuously and give you a confidence signal instead of a hard yes or no. The model doesn't have to be magic. The value is that the decision becomes graduated. You can let a borderline-but-probably-fine agent through at a rate limit instead of blocking it outright, and reserve hard blocks for the traffic that's clearly enumerating or attacking.

And keep active threat defense as the backstop, aimed correctly. Tarpitting, dynamic rate limiting, and challenge escalation are still exactly right for abuse. The mistake is firing them on automation per se. Reserve the expensive friction for behavior that's actually hostile: bursts that look like inventory scraping, login patterns that look like stuffing, request signatures that match known abuse infrastructure. Let identity and behavior decide who gets the friction, not the mere fact that there's no mouse moving.

Build the lane before you need it

The operational trap here is treating agent traffic as an exception you handle case by case when a customer complains that their assistant got blocked. That doesn't scale, and it puts your security team in the business of manually allowlisting the future. Design the policy deliberately instead: a documented, machine-readable access policy that says what agents may do and at what rate; a verified-and-signed fast lane; a graduated middle where unknown-but-not-hostile traffic gets metered rather than killed; and hard enforcement reserved for demonstrated abuse. Four tiers, and they map cleanly onto controls you already own at the edge.

There's a governance dimension too, and it's the part security leaders should own outright. When you start admitting authenticated agent traffic into sensitive flows, you're extending your access model to non-human principals acting under delegated authority. That deserves the same rigor you'd apply to any service account: scoped permissions, auditability, the ability to revoke a misbehaving agent without taking down the customer behind it. The WAF is where this gets enforced, but the policy is a risk decision, not a firewall config.

So here's the challenge. Go pull your WAF logs and find the legitimate automated traffic you're currently blocking, the agents acting for real customers that your old binary is treating as attacks. I'd bet it's a larger and faster-growing number than anyone on your team assumes. Then ask whether your edge can tell authorized from abusive, or whether it can only tell human from machine. If it's the latter, you don't have a security gap. You have a revenue leak with a security team's name on it.

Cloud SecurityWeb Application FirewallBot ManagementFintech