AI agents are not a future concern. They are already changing how enterprise systems are accessed, automated, and abused.
And the security implication is clear: the more autonomous systems rely on APIs, the more important it becomes to know exactly which APIs exist, how they are being used, and whether they are being misused.
If your organization cannot answer those questions, you have a visibility problem. And in an environment where AI can accelerate both legitimate automation and malicious abuse, visibility is the first step to control.
Risk accelerating
APIs have always been a target because they expose data and business logic. What has changed is pace.
AI can now help attackers discover endpoints faster, test more abuse paths, and automate attacks that once took much more effort. Meanwhile, AI agents inside the enterprise are generating more API traffic, often with broader privileges than anyone intended.
That means security teams are facing a harder problem: not just more traffic, but more uncertainty and adversaries with improved tools.
What CISOs should be worried about
The biggest risks are not always the loudest ones.
Whether it’s an over-permissioned agent, a forgotten or shadow API, or a “legitimate” request abused to enumerate data or chain unauthorized actions, the risk is real. It’s often compounded by API tokens with broad access and long expiration times.
These are the kinds of issues that can lead to evasive data exfiltration, unauthorized payments, compliance violations, and operational surprises that go undetected far too long.
If your API security program cannot spot abnormal behavior early, the business is exposed.
Continuously discover APIs across the environment.
Classify which ones are sensitive.
Establish baselines for normal behavior.
Detect abnormal or suspicious API activity.
Support least-privilege access for AI agents.
Help revoke risky permissions quickly.
This is how security leaders turn AI agent activity from a blind spot into something measurable and governable.
The board conversation has changed
This is no longer just a technical issue for engineering or operations.
Boards care about risk, control, and business impact. They need to know how many AI agent-facing APIs are being monitored, how many anomalous calls have been detected, and how quickly the business can respond when something looks wrong.
That is the real opportunity for CISOs: to move API security into the center of the AI risk conversation.
Download the guide now
For CISOs, security leaders, and executives, this guide explains the new API security realities emerging with AI agents. We created A CISO’s Guide to API Security in the Age of AI Agentsto help you navigate the shift with clarity and confidence.
Inside, you will learn:
Why AI agents are increasing API risk rather than replacing it.
How to connect API security to business and board-level concerns.
What to look for in a practical CISO playbook for discovery, visibility, and control.
How to govern agent-driven access before it becomes business exposure.
AI agents may change how work gets done. But the organizations that understand their APIs first will be the ones best positioned to stay in control.
TL;DR: A newly disclosed denial-of-service vulnerability, CVE-2026-23870, impacts React Server Components and dependent frameworks, including Next.js App Router deployments. The flaw enables unauthenticated attackers to send specially crafted HTTP requests that trigger excessive CPU consumption during request deserialization, leading to potential service degradation or total unavailability. Imperva Threat Research Group has analyzed the vulnerability and associated attack patterns. Imperva Cloud WAF and On-Prem WAF customers are already protected against exploitation attempts targeting this issue.
The Vulnerability
Researchers recently disclosed CVE-2026-23870, a high-severity denial-of-service vulnerability affecting React Server Components and downstream frameworks such as Next.js. The issue exists in how vulnerable React Server Component implementations deserialize attacker-controlled request payloads sent to Server Function endpoints.
The vulnerability stems from improper handling of cyclic or recursively referenced data structures during request processing. Specifically, vulnerable deserialization logic within the React Flight protocol can repeatedly consume maliciously crafted models before properly marking them as processed, resulting in excessive resource consumption.
In practical terms, an attacker can send a specially crafted HTTP request to exposed Server Function endpoints in applications using React Server Components. When the payload is processed, the server enters a high-CPU execution state that can persist for extended periods before eventually throwing an error. Because the error is catchable and the attack requires no authentication, attackers can repeatedly issue malicious requests to sustain denial-of-service conditions.
The issue primarily impacts:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Affected versions include:
0.0 through 19.0.4
1.0 through 19.1.5
2.0 through 19.2.4
Patched releases are available in:
0.5
1.6
2.5
Because React Server Components are heavily used in modern application architectures, particularly high-traffic ecommerce, SaaS, and API-driven environments, exploitation can have significant operational impact. Applications leveraging Next.js App Router deployments are especially exposed due to the widespread use of Server Function endpoints.
Some of the techniques observed or associated with exploitation include:
Crafted cyclic model payloads designed to trigger recursive deserialization behavior
Repeated requests to Server Function endpoints to sustain CPU exhaustion
Abuse of React Flight protocol request parsing logic
Application-layer denial-of-service attacks targeting availability rather than data theft
Automated scanning of exposed React and Next.js deployments for vulnerable endpoints
Unlike traditional volumetric DDoS attacks, CVE-2026-23870 enables low-bandwidth, application-layer denial of service by forcing disproportionate server-side computation. This makes the attack particularly attractive because relatively small numbers of malicious requests can create significant backend resource exhaustion.
Bottom Line
CVE-2026-23870 highlights the growing security risks associated with modern server-side rendering frameworks and component-driven architectures. By abusing request deserialization logic in React Server Components, attackers can trigger disproportionate backend resource consumption using relatively low-effort HTTP requests.
Since this vulnerability requires no authentication and targets exposed Server Function endpoints directly, exploitation is straightforward in unpatched environments. Organizations using React Server Components, Next.js App Router, or related server-side rendering frameworks should immediately upgrade affected packages and review exposed application endpoints.
Imperva Cloud WAF and On-Prem WAF customers are protected against related attack activity.
There’s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back the way it found it. It restores the database filename. It deletes the tools it used. It detaches from the connections it opened. When it’s done, the server looks healthy. Logs look normal. Nothing appears to be wrong.
Except there’s a new line in /root/.ssh/authorized_keys that wasn’t there before.
We discovered this attack recently targeting a single Redis honeypot. Attacks came from 10 distinct source IPs across six countries, and over 1,200 attack attempts were recorded in a single month. Our data-driven, AI-based honeypot enabled us to detect and analyze this activity in detail.
The Attack
Redis was never designed to face the internet directly. But people expose it: a misconfigured security group, a container with the wrong port mapping, a developer who needs it reachable for a quick test. The default configuration has no password. Port 6379, open to the world.
When our Redis honeypot instance was exposed, the first visitors arrived within minutes. They connected, ran INFO, read the version string, and disconnected. That’s it. They aren’t trying to break in. They’re taking a census- cataloging what’s out there, how old it is, whether it’s protected. Thousands of these scans happen every day across the internet, quiet and mechanical.
Then a second wave showed up. These bots tried something: config set dbfilename backup.db. It’s a test. If Redis accepts the command, it means the server will let you write files to arbitrary paths on the host machine’s disk. The bot doesn’t exploit this. It just records the address and leaves. It’s building a list for someone else.
The real attack came as a single connection that tried five different methods of compromise in rapid sequence. The whole thing took a few seconds. It opened with FLUSHDB to wipe the database and clear the slate, and then worked through the following tricks:
Cron injection: redirect Redis’s save directory to /var/spool/cron/, write a key whose value is a cron entry. Now the host downloads and runs a binary from a C2 server every minute, with a randomly generated filename to dodge signature detection.
Lua sandbox escape: a Debian/Ubuntu packaging decision dynamically linked Redis’s Lua interpreter against the system library, breaking the sandbox. One EVAL command loads io.popen, leading to full RCE. CVE-2022-0543 is four years old, yet still working.
SSH key planting: same file-writing trick, pointed at /root/.ssh/authorized_keys. One line, and the operator has root access forever.
Replication hijacking: SLAVEOF tells Redis to sync from the attacker’s server, which serves a malicious shared object disguised as a database dump. MODULE LOAD turns it into a Redis extension exposing system.exec. This trick leads to full RCE through Redis’s own replication protocol.
Direct execution: use that module to download and run the binary through the shell.
Five methods, one connection, a few seconds- but attackers don’t need all five to work. They just need one.
Then the connection did something unexpected. It started cleaning up.
SLAVEOF NO ONE
system.exec "rm -rf /tmp/exp.so"
MODULE UNLOAD system
config set dbfilename dump.rdb
It detached from the rogue replication server. It deleted the malicious shared library from the disk. It unloaded the module from Redis. It restored the original database filename. Redis is often used for ephemeral data, like sessions, queues, and rate limits, so a cleared database might not even raise an alarm. It just looks like a restart.
The attack was optimized for staying hidden after breaking in. Every forensic trace is reversed. The only artifact left behind is an SSH public key, one line in a file that most administrators never read, indistinguishable from a legitimate entry. Even if you find the malware, kill the process, and delete the cron entry, the key is still there. Root access, on demand, forever. Or until someone manually audits authorized_keys, which is rare.
The Botnets
The SSH Key Operator: A sophisticated, single-operator attack that targets unprotected Redis servers. It attempts five different RCE methods. Over a single month, our single Redis honeypot recorded over 1,200 attack attempts from 10 distinct source IPs across six countries. The majority included RCE attempts: Lua sandbox exploits and replication hijacking aimed at arbitrary command execution on the host. Different C2 servers, different binary names, but the same sequence, the same Lua payload, the same SSH public key. One operator, rotating sources and randomizing filenames. The key is the only constant.
The traffic came in distinct waves. Baseline was roughly 15 to 20 attempts per day from two or three sources. Then, without warning, a wave would hit, with a single IP connecting hundreds of times in an afternoon, once every 69 seconds- in total, over 300 attempts in a few hours. We saw three to four waves per month, each lasting two to six hours, each from a different source IP. Then silence until the next wave.
MGLNDD Botnet: A separate operation that periodically connects to exposed Redis servers, sending a single command format (MGLNDD_54.147.241.42_6379) to perform a “roll call” – checking whether the Redis server is already part of their botnet. It operates from Azure VMs using AWS IP addresses, never repeating the same source twice.
The SSH key operator and the MGLNDD botnet share the same hunting ground but ignore each other completely. Two separate operations are working in the same territory. An exposed Redis port isn’t just targeted by an attacker, it’s targeted by an ecosystem.
Takeaway
The attack is silent. The window between “I’ll fix that config later” and the machine is silently compromised isn’t days or hours-it’s seconds. Everything looks fine afterward: the server is up, the application works, the dashboards are green. The only artifact is an SSH key, patient and persistent, waiting to be used.
What You Must Do:
Never expose Redis to the internet. Restrict access via security groups, firewalls, or VPCs.
Set a strong Redis password. The default has none.
Regularly audit /root/.ssh/authorized_keys for unfamiliar keys-attackers hide persistence here.
Keep Redis patched. CVE-2022-0543 still works after 4 years.
Monitor for suspicious commands: CONFIG SET, MODULE LOAD, FLUSHDB, SLAVEOF.
Use file integrity monitoring on /root/.ssh/authorized_keys to detect tampering.
Don’t trust green dashboards. Assume you’ve been breached until verified otherwise.
Imperva Data Security solutions provide comprehensive protection for your data against a wide range of threats. These offerings enable security teams to identify the location of sensitive information, monitor access patterns, and detect misuse promptly to facilitate timely response.
A five-level operating model for turning API security visibility into measurable risk reduction, faster remediation, and confident digital growth — without slowing development.
What is API security operationalization?
API security operationalization is the process of converting API discovery and visibility into continuous, measurable risk reduction across discovery, vulnerability identification, prioritization, mitigation, and scaling. It moves API security from a one-time assessment to a repeatable, outcome-driven program, with KPIs such as mean time to remediation (MTTR), high-risk API count, and exposed endpoint reduction.
Operationalization matters because APIs are the fastest-growing attack surface — and most organizations now have visibility into their APIs but cannot act on it consistently. Without operationalization, discovery becomes a catalog instead of a control.
Why most API security programs stall after discovery
Most organizations aren’t struggling to see their APIs anymore. They’re struggling to turn API security visibility into consistent, measurable outcomes. According to the OWASP API Security Top 10, the most damaging API risks — broken object-level authorization (BOLA), broken authentication, and unrestricted resource consumption — all exploit gaps that exist after discovery, not before it.
APIs are the fastest growing attack surface — Imperva research shows API-directed attacks now account for a meaningful share of the application threat landscape (see the 2025 Imperva Bad Bot Report for current bot-driven API abuse data). Yet many security programs stall after discovery: risks are identified but not prioritized. Findings are reported but not operationalized. Controls exist, but don’t scale.
Imperva API Security closes that gap.
It enables organizations to move beyond insight and into action, so API security becomes a repeatable, outcome-driven capability that reduces real risk, improves efficiency, and supports faster innovation.
Here’s how to operationalize it for impact.
Figure 1: The Imperva API Security operational maturity model — five levels from Discover to Optimize.
Level 1: API discovery and classification
Building a complete, continuously updated inventory of every API
API discovery is the continuous process of identifying every API endpoint — managed, unmanaged, shadow, and deprecated — across cloud, on-premises, and hybrid environments, then classifying each one by data sensitivity and business criticality.
You can’t secure what you don’t fully understand, and classifying APIs by data sensitivity helps reduce the scope to a more manageable set. In dynamic environments, APIs are constantly changing, new ones spin up, old ones linger, and many remain undocumented.
Operationalization starts with continuous, accurate discovery and classification:
Identify every API across cloud, on-premises, and hybrid environments — including REST, GraphQL, gRPC, and SOAP endpoints
Uncover shadow APIs, unmanaged endpoints, and deprecated/zombie APIs that bypass change-management controls
Classify APIs by data sensitivity (PII, PHI, PCI, financial), business criticality, and external exposure
Map authentication posture — which endpoints require auth, which use long-lived tokens, which are publicly accessible without auth
How Imperva delivers:
Imperva API Security provides deep, continuous visibility into your API ecosystem, helping you uncover hidden APIs and automatically build a risk-aware inventory. This gives you not just a list of APIs, but the context needed to act on them.
Outcome: Reduced API attack surface, an inventory you trust, and the foundation every later level depends on. Without trustworthy discovery, prioritization is guesswork.
Level 2: Identifying API vulnerabilities and business-logic abuse
Expose real-world risk, not just theoretical issues
Modern API attacks don’t rely on obvious exploits. They leverage legitimate access in unintended ways — abusing business logic, over-permissioned tokens, and weak authorization. The OWASP API Security Top 10 ranks broken object-level authorization (BOLA) as the #1 API risk: an authenticated user manipulates an object identifier (user ID, account ID, document ID) to access another user’s data the API never intended to expose. Unlike SQL injection, BOLA produces no malformed payloads — every request looks legitimate.
To operationalize security, you need to detect:
Broken object-level authorization (BOLA, OWASP API1:2023) and access-control gaps that grant cross-tenant data access
Excessive data exposure (OWASP API3:2023) — endpoints returning more fields than the client needs
Anomalous usage patterns and behavioral risks (account-takeover, scraping, slow-rate enumeration)
Business-logic abuse — checkout, refund, and gift-card workflows weaponized by legitimate-looking calls
Risky tokens — long-lived credentials, over-permissioned API keys, leaked secrets in client code
How Imperva delivers:
Imperva analyzes API traffic and behavior to surface context-rich risk signals, so you can see not just what’s vulnerable, but how it can be exploited in practice.
Outcome: Shift from static findings to actionable intelligence aligned with real attack paths.
Level 3: Risk-based API prioritization (cutting through alert noise)
Focus on what actually matters to the business
Not all API risks are equal and treating them that way slows teams down.
Operational maturity comes from risk-based prioritization:
Which APIs are business-critical? — handle revenue-generating workflows, customer authentication, or core data
Which expose sensitive data? — return PII, PHI, payment data, or trade secrets
Which are externally accessible? — reachable from the public internet, partner networks, or third-party integrations
What is the real-world impact if exploited? — regulatory penalty, customer trust loss, downtime cost, blast radius
How Imperva delivers:
Imperva brings together visibility, behavioral insight, and business context to help teams focus on the highest-impact risks first, cutting through noise and enabling faster, smarter decisions.
Outcome: Align security effort with business risk, not alert volume.
Level 4: API risk mitigation and measurable outcomes (KPIs that matter)
Turn insight into action, and prove it’s working
Security only delivers value when risk is actively reduced, and that reduction is measurable.
Mitigation should be paired with clear KPIs:
High-risk API count — number of APIs flagged as critical-severity, month over month (direct measure of attack-surface reduction)
Mean time to remediate (MTTR) — days from detection of an API risk to closure (proxy for security engineering velocity)
Exposed/unmanaged endpoint count — public APIs without owner, doc, or auth control (catches drift between deploys)
Protection coverage — % of high-risk APIs with active mitigation policies (shows control density across the surface)
Inline-action rate — % of detected abuse stopped at session level (vs. IP block); differentiator vs. coarse-grained tools
How Imperva delivers:
Imperva enables teams to detect and respond to malicious or risky API activity with precision, using inline actions at the client session level to stop abuse in real time, far more effective than coarse IP-based blocking. This turns API security into a measurable, outcome-driven function.
Outcome: Demonstrate real risk reduction and tangible ROI.
Level 5: Scaling API security through automation and DevOps integration
Embed API security into how your business operates
Manual processes don’t scale in modern API environments. Optimization is about making API security continuous, automated, and integrated.
This means:
Automating API discovery and risk assessment so every new endpoint is inventoried within minutes of deployment
Embedding API security into CI/CD pipelines — schema validation, OWASP-scoped tests, and policy-as-code at PR time
Integrating with the broader stack — SIEM, SOAR, ticketing, IAM, and the Imperva Web Application and API Protection (WAAP) platform
Repeatable remediation playbooks mapped to API risk class (BOLA, broken auth, excessive data exposure, business-logic abuse)
How Imperva delivers:
Imperva helps operationalize API security at scale, reducing manual effort while improving consistency and coverage. It enables security teams to keep pace with development without becoming a bottleneck.
Outcome: Scale protection without scaling complexity.
The right + left operating model: balancing protection and enablement
Sustainable API security is not just about stronger controls. It’s about balance.
Right (Protection): Visibility, detection, and enforcement to reduce risk
Left (Enablement): Automation, scalability, and efficiency to support speed
Too much focus on protection slows the business. Too much focus on speed increases exposure.
Imperva API Security brings both together.
Right + Left = Optimum—where security doesn’t compete with the business; it accelerates it.
Figure 2: Building a Sustainable Strategy – Right + Left = Optimum
Conclusion: Make API Security a Business Enabler
The difference between having API security and operationalizing it is the difference between insight and impact.
With Imperva API Security, organizations can:
Continuously discover and understand their API landscape
Identify and contextualize real-world risks
Prioritize based on business impact
Mitigate and measure outcomes
Scale security through automation and integration
The result is not just better security.
It’s faster innovation, stronger resilience, and confident digital growth.
If your API security program is stuck at visibility, it’s time to take the next step.
Operationalize it. Measure it. Scale it.
See how Imperva API Security can help you turn API security into a strategic advantage,
and start driving real business value from day one.
Frequently asked questions about API security operationalization
What’s the difference between API security and API security operationalization?
API security is the set of controls that protect APIs from abuse. API security operationalization is the practice of running those controls as a continuous, measurable program — with discovery, prioritization, KPIs, and automation rather than one-time scans.
What are the most common API vulnerabilities?
The OWASP API Security Top 10 (2023 edition) ranks broken object-level authorization (BOLA), broken authentication, broken object-property-level authorization, unrestricted resource consumption, and broken function-level authorization as the highest-impact API risks. Most modern attacks combine two or more of these.
How is API discovery different from API documentation?
API documentation describes what an API is supposed to do. API discovery finds every API that actually exists in your environment — including shadow, deprecated, and undocumented endpoints that documentation misses. Operationalized programs treat discovery as continuous, not one-time.
How do you measure API security effectiveness?
Track high-risk API count, mean time to remediate (MTTR), exposed/unmanaged endpoint count, protection coverage, and inline-action rate. KPI movement over time is the proof that the program — not just the toolset — is working.
Does Imperva API Security work with my existing WAF or WAAP?
Yes. Imperva API Security is part of the Imperva Web Application and API Protection (WAAP) platform and integrates with Imperva WAF, the Imperva CDN, and third-party SIEM/SOAR tooling. The same operational model spans web app and API protection.
CVE-2026-41940 is a critical authentication bypass vulnerability affecting cPanel & WHM, including DNSOnly, in versions after 11.40. The flaw, discovered by WatchTowr Labs, exists in the login flow and allows unauthenticated remote attackers to gain unauthorized access to the control panel. The vulnerability carries a CVSS 3.1 score of 9.8 and is classified under CWE-306: Missing Authentication for Critical Function.
cPanel & WHM is widely used to manage web hosting environments. WHM provides administrative access to hosting infrastructure, while cPanel gives individual account holders control over their hosted sites. Because this vulnerability affects the authentication layer of a management interface, successful exploitation could give attackers access to high-value administrative functions across hosting environments. The issue affects all currently supported versions of cPanel & WHM, and the flaw is tied to session loading and saving behavior.
cPanel has released patched versions and recommends immediate updates. Administrators should update a fixed version, verify the cPanel build, and restart the cPanel service. For environments that cannot immediately patch, cPanel recommends blocking inbound traffic on ports 2083, 2087, 2095, and 2096 or temporarily stopping affected services.
Imperva customers are protected out-of-the-box against CVE-2026-41940.
Observations from Our Data
Since the release of CVE-2026-41940, Imperva has observed nearly 4,000 attack requests targeting customer environments.
Our data shows:
Attacks targeting sites across 15 distinct industries and 17 countries, indicating broad scanning and opportunistic exploitation rather than activity concentrated against a single vertical or geography.
US-based sites accounted for almost 70% of observed attacks, followed by Barbados and Israel. The heavy concentration against US sites suggests attackers are prioritizing regions with large hosting and web infrastructure footprints, while the presence of smaller geographies indicates automated discovery across exposed internet-facing assets.
The most frequently targeted industries were Business, Society, and Education. This distribution reflects the broad deployment of hosting control panels across organizations that maintain public-facing websites, portals, and distributed web infrastructure.
While observed volume remains limited compared to mass exploitation campaigns, the spread across industries and countries shows active probing for exposed cPanel and WHM instances. Given the vulnerability’s unauthenticated nature and impact on administrative access, even moderate request volumes warrant urgent attention, and attack volumes will likely grow.
Mitigation and Protection
The definitive remediation for CVE-2026-41940 is to update cPanel & WHM to a patched version immediately. Organizations should also review cPanel’s detection guidance, inspect session files for indicators of compromise, and audit WHM access logs for unauthorized activity. cPanel’s advisory specifically recommends purging affected sessions, forcing password resets for root and WHM users, and checking for persistence mechanisms if indicators of compromise are found.
Imperva customers using Cloud WAF and WAF Gateway are protected against exploitation techniques associated with CVE-2026-41940. Imperva’s web application firewall inspects HTTP traffic for malicious patterns, helping block attempts to abuse authentication workflows and session-handling behavior before they reach vulnerable systems.
For customers with Cloud WAF, protection is automatically applied. Customers with WAF Gateway should refer to the manual mitigation guide sent by Imperva support teams and provided in the Imperva Community Guide.
Conclusion
CVE-2026-41940 represents a critical risk for organizations running exposed cPanel & WHM infrastructure. Its combination of unauthenticated access, low attack complexity, and potential administrative impact makes it a high-priority vulnerability for patching, monitoring, and incident review.
Imperva customers are protected against exploitation attempts associated with this vulnerability through Imperva’s web application firewall protections and HTTP traffic inspection capabilities. Organizations running cPanel & WHM should still apply vendor patches immediately, validate their deployed versions, and review available logs and session artifacts for signs of compromise.
For decades, companies have operated on a simple assumption that most internet traffic came from people. That assumption no longer holds.
The latest 2026 Bad Bot Report: Bad Bots in the Agentic Age reinforces a shift that is now impossible to ignore. Automated traffic continues to outpace human activity online, accounting for more than 53% of all web traffic in 2025, up from 51% the year before. Human activity has declined to just 47% and continues to fall.
This is not a short-term spike driven by a specific attack cycle or technology trend. It reflects a structural change in how the internet operates. Increasingly, businesses are not serving customers alone. They are serving machines.
Key Findings From the 2026 Bad Bot Report
Bots now drive 53% of web traffic. Automated activity has officially overtaken humans online, up from 51% in 2024.
27% of bot attacks target APIs. Attackers are bypassing user interfaces entirely to operate directly at machine speed.
Financial services bear the brunt. The sector accounted for 24% of all bot attacks and 46% of account takeover incidents.
AI agents are a new category of internet participant. They no longer just scan websites; they retrieve data, execute workflows, and act on behalf of users.
AI Agents and Bots Are Becoming the Default Internet User
Automation has always existed on the internet in the form of search engine crawlers, scripts, and background processes. What has changed is the scale, sophistication, and purpose of that automation.
AI is accelerating this shift. AI-driven bots have surged dramatically, but more importantly, AI agents are now emerging as a new category of internet participant. These systems don’t just scan websites; they interact with them, retrieve data, execute workflows, and increasingly act on behalf of users.
In practice, this means that what looks like a customer interaction may not be a customer at all. It may be an AI system querying pricing data, completing a transaction, or testing application behavior. For businesses, this blurs a fundamental line. The distinction between legitimate and malicious traffic is becoming harder to define, because both now operate through the same systems, use the same interfaces, and follow the same logic.
The real risk is not the presence of bots, but that much of this automation is unmanaged. In earlier phases of the internet, bot activity was episodic and often easier to identify. Today, automation is persistent. It operates continuously across digital services, often indistinguishable from legitimate use. This creates a new category of risk that many organizations are not yet equipped to handle. Uncontrolled automation can distort business metrics, inflate infrastructure costs, degrade performance, and expose sensitive workflows.
For example, bots can continuously query pricing or availability systems, creating artificial demand signals. They can interact with promotional systems at scale, exploiting business logic in ways that traditional security controls are not designed to detect. Even benign automation, when left unmanaged, can place sustained load on systems that were designed for human behavior.
The result is that companies are increasingly sharing their digital infrastructure with automated agents that they neither fully understand nor control.
APIs and Identity Systems Sit at the Center of Modern Risk
As automation evolves, so do attacker strategies. The traditional model of targeting websites at the surface level is giving way to a more direct approach.
Bots are increasingly interacting with the same APIs that power core business functions, including authentication, payments, search, and inventory systems. In 2025, 27% of bot attacks targeted API endpoints, allowing attackers to bypass user interfaces entirely and operate at machine speed. These interactions often appear legitimate, with well-formed requests and successful authentication, but the difference lies in intent and scale.
This is particularly visible in sectors where digital transactions are tightly linked to revenue. Financial services, for example, accounted for 24% of all bot attacks and 46% of account takeover incidents. The goal is not disruption for its own sake, but direct monetization.
In this environment, identity systems are no longer just a security layer. They are a primary point of exposure.
How AI Agents Are Quietly Rewriting Business Models
The shift toward machine-driven interaction is not only a security issue. It is beginning to reshape how businesses operate.
If a growing share of traffic is automated, then traditional metrics such as user engagement, conversion rates, and demand signals become harder to interpret. A spike in traffic may not indicate customer interest. A drop in performance may not be caused by user behavior.
At the same time, AI-driven systems are creating new forms of demand. Companies are beginning to consider how and whether to allow AI agents to access their services, and under what conditions. This raises questions about access control, pricing, and even monetization.
Some organizations are exploring models where AI-driven access is authenticated, measured, and potentially governed as a distinct channel. While still early, this points to a future in which businesses must actively manage not just who accesses their systems, but what.
From Bot Detection to Automation Control
For years, cybersecurity strategies have focused on detecting and blocking malicious activity. That approach is increasingly insufficient in a world where automation is both pervasive and often legitimate. The more important question is no longer whether traffic is automated, but whether it aligns with business intent.
This shift, from blocking bad bots to governing all automation based on intent, requires a new approach. Organizations must move from viewing bots as anomalies to viewing automation as a fundamental part of their operating environment. That means implementing controls that can distinguish between acceptable and harmful automation, applying governance to how systems are accessed, and designing defenses that can adapt as behavior changes.
In effect, the challenge is becoming one of control rather than detection.
A Machine-Driven Internet
The internet is entering a new phase that’s defined less by human interaction and more by machine-to-machine activity. Automation is no longer a layer on top of digital infrastructure but embedded within it, with significant implications for businesses. Trust, performance, and revenue are increasingly shaped by how well organizations manage automated interaction.
Companies that continue to operate under the assumption that users are human risk misreading their own systems. Those that adapt by understanding, governing, and controlling automation will be better positioned to compete in an internet where machines are not just participants, but the majority.
The shift is already underway. The question for businesses is not whether it will happen, but how they will respond.
The Imperva Bad Bot Report is an annual industry research report analyzing global automated bot traffic, attack trends, and the impact of malicious bots on websites, APIs, and applications. The 2026 edition focuses on the rise of AI agents and agentic automation.
How much of internet traffic is bots in 2025?
According to Imperva’s 2026 Bad Bot Report, automated bot traffic accounted for more than 53% of all web traffic in 2025, up from 51% the year before. Human traffic has fallen to 47% and continues to decline.
Why are AI agents a cybersecurity concern?
AI agents act on behalf of users, retrieving data, executing workflows, and completing transactions through the same interfaces as humans. This blurs the line between legitimate and malicious traffic, makes traditional bot detection insufficient, and exposes APIs and identity systems to automation that organizations cannot easily distinguish from real users.
Which industries are most affected by bot attacks?
Financial services experience the highest impact, accounting for 24% of all bot attacks and 46% of account takeover incidents in 2025. APIs are the dominant attack surface, with 27% of bot attacks targeting API endpoints across all industries.
When evaluating cloud security platforms, one question comes up again and again:
“How many Points of Presence do you have?”
At first glance, the logic seems sound. More locations should mean lower latency, faster response times, and better protection. The assumption is simple: if security is delivered at the edge, then more edge locations must automatically translate into stronger application security.
That assumption, however, is largely inherited from the content delivery world — and it does not hold up when applied to real‑time application and API protection.
The Common Assumption: More PoPs Means Better Security
In content delivery networks (CDNs), PoP count is a meaningful metric. Static content benefits directly from being cached as close as possible to end users. The more locations you have, the more likely content can be served locally, reducing latency and improving page load times.
Application security operates under a very different set of constraints.
Web Application and API Protection (WAAP) platforms are not simply delivering content. They must inspect every request, enforce security policies, analyze behavior, detect abuse, and mitigate attacks in real time — all while maintaining visibility across global traffic flows.
In this context, proximity alone is not the primary driver of security effectiveness.
Not All PoPs Are Created Equal
A Point of Presence is a physical location where traffic is processed — but PoPs vary widely in capability.
Some platforms emphasize deploying a very large number of small, highly distributed PoPs optimized for caching and proximity. Others prioritize fewer, high‑capacity PoPs placed at major internet exchange points and backbone hubs.
These high‑connectivity locations sit directly on global networks, allowing traffic to reach them efficiently from broad geographic regions. In practice, users are often only a few milliseconds away from a well‑connected PoP, even if it is not located in the same city or country.
For security workloads, network connectivity, inspection depth, and capacity matter far more than raw geographic density.
Anycast Routing Changes the Equation
Modern security platforms rely on Anycast routing, which automatically directs traffic to the optimal PoP based on real‑time network conditions rather than simple physical distance.
With Anycast routing:
Traffic follows the most efficient network path
Performance remains consistent even during outages
Failover happens automatically without user intervention
A well‑architected Anycast network can deliver predictable performance and resilience without requiring a PoP in every location where users reside.
Security Is Not the Same as Content Delivery
The most important distinction to understand is this:
CDNs scale by distributing copies of static content.
Security platforms scale by performing stateful inspection and coordinated decision‑making on live traffic.
Security inspection is computationally intensive and context‑dependent. Every request must be evaluated against behavioral models, threat intelligence, and policy logic. This work is fundamentally different from serving cached files.
As PoP counts increase, security platforms must make architectural trade‑offs around:
How much inspection can be performed locally
How much capacity is available per location
How security intelligence is synchronized globally
How attacks spanning regions are detected and mitigated
These trade‑offs define security outcomes far more than the number of locations alone.
What “Security in Every PoP” Really Means
Some modern platforms advertise that they run security services in every PoP, enabling them to deliver cached content and secure application traffic in the same location.
This approach offers clear advantages for latency‑sensitive use cases and environments where performance and security must be tightly coupled at the edge.
However, delivering security everywhere requires security capabilities to be highly distributed and lightweight by design. As PoP counts grow into the hundreds or thousands, platforms must balance:
Inspection depth versus per‑location footprint
Local decision‑making versus global coordination
Uniformity of protection versus operational complexity
In practice, “security in every PoP” often prioritizes speed and proximity over inspection depth, per‑location capacity, and attack absorption strength. While this model performs well under normal traffic conditions, it does not inherently guarantee stronger protection during large, sustained, or highly coordinated attacks.
Concentrated Capacity vs. Distributed Presence
Highly distributed security architectures excel at minimizing latency and handling everyday traffic efficiently.
Security‑first architectures, by contrast, are designed to concentrate capacity, intelligence, and mitigation power at strategically connected locations.
This concentration enables:
Immediate absorption of large volumetric attacks without traffic redirection
Deep, stateful inspection even under extreme load
Faster detection of coordinated attack patterns
Predictable performance during worst‑case scenarios
For application and API security, the most critical moments are not normal operations, but peak attack conditions. It is during these moments that per‑PoP capacity and global visibility matter more than sheer geographic density.
When PoP Density Does Matter
PoP count does play an important role in specific scenarios:
Global delivery of static content
Ultra‑low‑latency applications such as gaming or live streaming
Environments heavily reliant on edge caching
Many enterprises address this by separating concerns — using one platform optimized for content delivery and another purpose‑built for inline application and API security.
Architecture Over Optics
PoP count makes for an impressive slide, but it does not tell the full story.
The true measure of an application security platform lies in its network design, routing intelligence, inspection depth, per‑location capacity, and ability to perform under attack — not in how many dots appear on a map.
Some platforms optimize for being everywhere.
Others optimize for being strong where it matters most.
PoP count measures proximity.
Security performance measures resilience.
In application security, architecture — not optics — determines outcomes.
Login
