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 rests 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 isn't a scraper or a credential-stuffing botnet. It's 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
Here's the reframe I keep coming back to. 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. If you block it indiscriminately, you're not hardening your security posture. You're 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, the wrong answer is a 403 and a JavaScript challenge it can't solve. That's not security. That's an outage you chose.
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.
The real mechanic: identity and intent, not just signatures
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. That sounds abstract, so let me name the actual mechanics, all of which are available with public, well-understood capabilities today.
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/no. The point isn't that the model is magic. It's 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 you reserve hard blocks for the traffic that's clearly enumerating or attacking.
And keep active threat defense as the backstop — but aim it 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. Instead, design the policy deliberately: 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. That's four tiers, and it maps 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.
