As I dig deeper into our annual research, there are several inescapable conclusions I arrive at, largely driven by the impact of AI on, well, everything.
One of those inescapable conclusions is that it’s time for WAAP to shift from “Web App and API Protection” to “Web, API, and AI Protection.”
I said what I said.
There are many reasons to make this statement, first and foremost of which is “web” and “app” are redundant. While estimates can vary depending on the methodology and time period, several industry sources suggest that roughly 80% of Internet traffic is delivered via HTTP protocols (including both HTTP and HTTPS). For example, the Cisco Visual Networking Index (VNI) reports and similar analyses from content delivery networks like Akamai have consistently indicated that web traffic—predominantly transmitted over HTTP/HTTPS—comprises the vast majority of global Internet traffic.
Any traffic delivered over “HTTP/S” is generally considered an “app” from the perspective of delivery and security services. Whether the content generated is from a modern or traditional application, static or dynamic, is largely irrelevant to the plethora of services used to deliver and secure it. Even the percentage of infrastructure services, such as DNS, delivered via HTTP/S is growing. Industry estimates from Cloudflare generally suggest that roughly 10–20% of DNS traffic is delivered via HTTPS (DoH) today.
So, let’s drop the “web app” and just say “web.”
The API in WAAP remains important. API traffic has been growing, there’s no need to cite all the sources that say APIs are dominant today. But in case you need me to, it was way back in 2021 when the RapidAPI State of APIs Report indicated that billions of API calls were made each month across a diverse range of services. When averaged over a month (which has roughly 2.6 million seconds), those numbers implied an average on the order of 400,000 API calls per second globally.
And that was four years ago, before generative AI burst onto the scene.
Which brings us to the real point of this post, which is to incorporate AI into WAAP.
Now, I know I just said let’s not be redundant so the reality that AI consumption is almost universally accomplished via APIs makes it seem like it’s unnecessary, but the variation in how delivery and security services must deal with non-deterministic, largely text-based content is important enough to warrant being called out. At least for now.
Because you see, the top delivery and security services planned for use in protecting AI inferencing are, wait for it, largely the same as those included in WAAP.
Now, let’s not ignore that in the past year a new security service, AI gateway, has entered the room. AI gateways add AI-specific protections around prompts and responses needed to address some of the AI-specific vulnerabilities that exist, such as prompt injection, jailbreaking, and even hallucinations.
Now, the thing is that AI gateways alone are not enough to protect models, because APIs have unique threats, too. And components of WAAP like bot management and DDoS protection hail from the plain old web (that’s the HTTP/S) we talked about earlier.
But let’s look at the data. Because we asked folks about the deployment of delivery and security services (because of course we did).
We found that the percentage of respondents that deploy all four of the traditional WAAP technologies is 94%.
And the percentage of respondents that deploy all four of the traditional WAAP and an AI gateway is, wait for it, you know it…yes, 94%.
In other words, organizations already deploy these technologies together because they know that to protect AI models and inferencing servers requires protecting the entire stack, from layer 4 to layer 7. And that means all five services are necessary:
So, my inescapable conclusion is that WAAP needs to evolve from focusing on just apps and APIs to include AI.