What AI Monetization Means for Web Application Firewalls
A web application firewall inspects incoming requests to an application and filters out the ones that look dangerous. It checks requests against rules that describe known attack patterns, examining headers, IP addresses, request bodies, and user-agent strings to catch things like SQL injection, cross-site scripting, and credential stuffing. For nearly three decades this has been a security function with a clear mandate: keep malicious traffic out and let legitimate traffic through.
Generative AI complicates that mandate because it introduces a large and growing class of traffic that is neither clearly malicious nor clearly human. An AI crawler harvesting content for training is not attacking the application in any traditional sense. A retrieval system fetching a page to ground an answer is behaving, at the protocol level, much like a browser. An autonomous agent completing a task may look almost identical to a logged-in user. None of these fit the threat-or-not model the firewall was built around, and yet each one raises a question the content owner urgently wants answered: should this system have access, and on what commercial terms.
The structural tension is that firewalls make a security decision when the AI era increasingly demands an economic one. Blocking a genuine attack protects the application at no cost, because the attacker was never going to generate value. Blocking an AI system is different, because that system might be willing to pay for the access it is taking. The firewall's inherited logic treats all unwanted automation as a threat to be excluded, when a large part of it is really demand to be priced. Resolving that mismatch is what turns the firewall from a pure security control into a potential point of monetization.
Why the threat model does not fit AI traffic
The firewall's core method is pattern recognition against known signatures. It works because malicious behaviour tends to leave detectable traces, and because the underlying assumption held for a long time: traffic was mostly human, and the automated exceptions were mostly hostile. That assumption has decayed. As one industry assessment put it bluntly, the model of thinking about web traffic in terms of human behaviour is increasingly useless when a significant portion of traffic comes from bots, APIs, and AI agents that do not behave like humans at all.
Agentic traffic is the hardest case. If-then security rules assume sequential, predictable request patterns, but an autonomous agent plans its own path and invokes tools in orders no rule anticipated. It does not move through an application the way a human does, and it is not trying to. That makes it consistently invisible to logic designed around human sessions, so the firewall either lets it pass unexamined or flags it as anomalous for reasons that have nothing to do with whether it should be paying for access.
Identity makes the problem worse. A firewall's judgement depends heavily on what a request declares about itself, and AI traffic is increasingly opaque at that layer. Many agentic systems drive a real browser session and present ordinary browser user-agents, which is why understanding what AI scraping actually involves matters more than reading a user-agent string. A control that cannot reliably tell an agent from a person cannot make a sound security decision about it, and it certainly cannot make a sound pricing decision about it. The firewall is being asked to adjudicate traffic it can no longer confidently identify.
The cost of getting the decision wrong runs in both directions
Because the firewall sits at the perimeter and enforces in real time, an error at this layer is expensive whichever way it falls. Block too aggressively and the application turns away legitimate traffic, including the AI systems that drive citations and referrals. Allow too permissively and the application absorbs unrestricted extraction, serving up content and burning compute for systems that return nothing.
The financial stakes are not hypothetical. AI bots aggressively harvesting an application's content generate overwhelming traffic and incur data transfer charges, degrading performance for human users while consuming resources the content owner pays for. There is also a competitive dimension that a security lens tends to miss: unauthorised training use can turn an application's own content into a competing service, diluting its market value without any compensation flowing back. The firewall that treats this only as a load or abuse problem is measuring the wrong cost.
The volume trajectory means this decision only grows in weight. Akamai has projected that AI API calls will grow 1,000-fold by 2027, which means the share of traffic that falls outside the human threat model is set to dominate rather than remain an edge case. A control plane that handles this traffic with a binary allow-or-block switch will misprice an ever-larger portion of the demand reaching the application, because the switch has no setting for "permitted, metered, and billed."
From signatures to purpose, and from purpose to price
The more useful frame is the one the standards bodies are converging on: classify traffic by purpose, not just by threat. The IAB Tech Lab's guidance on bot and crawler management argues that blanket blocking is no longer viable and that content owners need graduated controls to distinguish a value-driving ally from a resource-draining extractor. That distinction is a business judgement layered on top of the security one, and it is precisely the judgement a firewall's binary model cannot express.
Once purpose is the organising principle, the firewall's role expands. The same position that lets it inspect and filter a request lets it apply a purpose-specific policy: allow a search crawler that drives referrals, require a license for a training crawler that permanently absorbs content, meter an agent according to the workload it imposes. This is the difference between a security control and an access control that carries commercial terms. It is why the emerging protocols pair enforcement with contracts. The IAB's Content Monetization Protocol, for instance, is designed so AI systems have commercial agreements in place before crawling occurs, which only works if there is an enforcement layer that can check for that agreement at the moment of the request.
Firewall vendors are already extending in this direction, though most are still framing it as security. AWS added AI bot management and an AI Activity Dashboard to its firewall, and Cloudflare's Firewall for AI addresses model-facing threats like prompt injection and model denial of service. These are real capabilities, but they mostly protect AI applications rather than help content owners charge AI systems. The gap between defending against AI traffic and monetizing it is still open, and it is the more valuable gap to close.
Where security enforcement and monetization have to meet
The firewall's limitation is the same one every enforcement layer in the AI stack runs into. It is very good at deciding whether a request proceeds. It does nothing, on its own, to turn a permitted request into revenue. A firewall can confirm that an AI system asked for a specific resource and can allow that request under a purpose-based rule. It cannot, by itself, read the licensing terms attached to that resource, record what was consumed, and move payment from the AI company to the content owner.
Those missing pieces are what separate blocking from pay-per-use infrastructure. For a permitted AI request to become a paid one, three things have to be true at the moment of enforcement. The terms of access have to be expressed in a form the requesting system can read, which is the work of machine-readable licensing. The access has to be metered so the content owner knows exactly what was consumed. And settlement has to happen automatically, because no one is negotiating a contract in the milliseconds a firewall takes to evaluate a request. Enforcement supplies the gate. Monetization requires everything that turns passing through the gate into a transaction.
The stakeholder incentives make clear why this convergence is necessary rather than optional. Content owners want compensation for machine access, not just the ability to refuse it. AI companies want dependable, low-friction access to the content their systems rely on, and they increasingly need that access to be licensed rather than legally exposed. Security teams want to protect the application without becoming the arbiter of every commercial relationship it might have. These interests align only when the enforcement point is connected to a settlement mechanism, so that the same request the firewall permits can be priced and paid for without a human in the loop. Supertab Connect provides that connection, letting content owners publish machine-readable licensing terms, enforce them at the point of access, and settle usage automatically, which turns the firewall's permit-or-deny decision into the front end of agentic commerce rather than the end of the interaction.
Security Was Always the Gate. The Question Now Is What the Gate Charges
The firewall's position has quietly become more valuable than its original job description. It was built to keep bad requests out, and it will go on doing that, because the AI era has not reduced the volume of genuine attacks. What has changed is that a large and rising share of the traffic reaching the gate is neither friend nor foe in the old sense. It is demand, arriving in a form the firewall was never designed to price.
Vendors that treat AI traffic purely as a security category will keep building better detection and better blocking, and they will remain a cost centre in their customers' eyes: necessary, defensive, disconnected from revenue. The vendors that recognise the gate as an economic instrument will build toward something their customers value more, which is the ability to say yes to AI access on terms that pay. The technical capacity to identify and filter machine traffic is becoming standard equipment. The capacity to attach a price to what passes through is not, and the firewalls that develop it will hold a position in the AI economy that a pure security tool can never reach, because they will be standing at the exact point where access is granted and value could change hands.
