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.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

What good looks like

CISOs need a practical model, not more noise.

That model should:

• 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 Agents to 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.

Download the CISO guide now

The post Why AI Agents Make API Security a CISO Priority appeared first on Blog.

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.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

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
• Broken authentication (OWASP API2:2023) — weak tokens, credential stuffing, missing MFA on sensitive flows
• Unrestricted resource consumption (OWASP API4:2023) — missing rate limits, no quota enforcement
• 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.

Want to see how Imperva API Security can be operationalized at scale? Watch the detailed expert webinar for practical guidance and real-world insights. 

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.

→ Explore the Imperva API Security platform: https://www.imperva.com/products/api-security/ 

The post API Security Operations: How to Move from Visibility to Measurable Risk Reduction appeared first on Blog.

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.

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot Report

Register Now

The Rise of Uncontrolled Automation

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.

Download the Full 2026 Bad Bot Report

Get the complete data, sector breakdowns, and defense recommendations in Imperva’s 2026 Bad Bot Report: Bad Bots in the Agentic Age.

Frequently Asked Questions

What is the Imperva Bad Bot Report?

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.

The post Bad Bot Report 2026: The Internet Is No Longer Human and It’s Changing How Business Works appeared first on Blog.

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.

The post Why PoP Count Isn’t the Real Measure of Application Security Performance appeared first on Blog.

In today’s dynamic digital environment, the pressure to innovate has never been greater. Development teams are pushing for native cloud tools to maximize performance and cost-efficiency, while security teams require best-of-breed, enterprise-grade protection to defend against an ever-evolving threat landscape. This often creates a point of friction, forcing organizations into a difficult trade-off: sacrifice performance for security, or accept weaker protections for the sake of speed.

To resolve this challenge, Thales Imperva is collaborating with Google Cloud to deliver a solution that helps bridge this gap. We are proud to introduce Imperva for Google Cloud (IGC), an integrated security solution that offers the best of both worlds: enterprise-grade application security with the cloud-native performance you expect from Google Cloud.

Imperva for Google Cloud: A Holistic, Integrated Solution

Imperva for Google Cloud is not just another security layer; it is a fully managed, best-in-class Web Application and API Protection (WAAP) solution built directly into the fabric of Google Cloud. This integration, available now on Google Cloud Marketplace,   provides robust protection without disrupting your existing infrastructure or workflows.

• Cloud-Native Performance Without Compromise: Imperva for Google Cloud uses Google Cloud’s native Service Extension and Private Service Connect to inspect traffic within the Google Cloud network. This means all traffic analysis happens without your data ever leaving Google Cloud infrastructure, preserving optimal latency, performance, and data residency.
• Quick Deployment: Forget complex re-architecture. Imperva for Google Cloud can be deployed quickly using familiar tools like Terraform, Google Cloud CLI (gCloud CLI), or the Google Cloud console UI. There are no disruptive DNS, SSL, or network routing changes required, allowing you to achieve production-ready protection almost immediately.
• Enterprise-Grade Protection Out of the Box: Imperva for Google Cloud is powered by Imperva’s industry-leading security engine, delivering comprehensive WAF, advanced API Security, and Account Bot Protection. Backed by 24/7 threat research, the Imperva solution provides near-zero false positives, with 97% of customers successfully using default policies and 95% running in blocking mode from day one. This dramatically reduces the operational overhead of constant rule tuning.

Real-World Impact: Securely Accelerating Your Business

By eliminating the trade-offs between security and performance, Imperva for Google Cloud helps organizations achieve key business outcomes:

• Accelerate Lift-and-Shift Migrations: Migrate workloads to Google Cloud confidently with security that adapts to your applications, not the other way around. Eliminate migration delays caused by complex security re-architecture.
• Unleash DevOps-Friendly Security: Empower development teams to innovate at speed. IGC closes the security gaps in built-in tools without slowing down deployment velocity or requiring developers to become security experts.
• Protect Modern Cloud-Native Applications: Secure your Kubernetes and microservices architectures with best-in-class defenses optimized for low-latency environments.
• Achieve Unified Multi-Cloud Governance: Manage security for all your Imperva-protected environments from a single, unified dashboard, providing consistent policy management and visibility across your entire multi-cloud estate.

“Bringing Thales Imperva to Google Cloud Marketplace will help customers quickly deploy, manage, and grow the company’s integrated security solution on Google Cloud’s trusted, global infrastructure,” said Dai Vu, Managing Director, Marketplace & ISV GTM Programs at Google Cloud. “Thales can now securely scale and support organizations that want to use its Imperva for Google Cloud solution to increase protection for their cloud-native applications, APIs, microservices and more.”

×

May 21 Upcoming Webinar

Findings from the 2026 Bad Bot report

Register Now

Join Us on the Journey to More Seamless Cloud Security

As we approach key industry events like our exclusive Executive Briefing Center (EBC) meeting in late March and Google Cloud Next 2026 in April, the conversation around integrated  security has never been more relevant. The launch of Imperva for Google Cloud marks a pivotal moment in our relationship with Google, providing a clear path for customers to secure their digital assets without compromise.

Ready to secure your cloud-native applications?

• Request a demo: Experience IGC in action at Imperva for Google Cloud
• Start your evaluation: Available now on Google Cloud Marketplace

The post Enterprise-Grade Application Security, Cloud-Native Speed: Introducing Imperva for Google Cloud appeared first on Blog.

AI-driven automation is no longer emerging. It is already integrated and accepted as internet traffic. From AI assistants and crawlers to enterprise automation tools, websites are now routinely accessed by non-human actors operating at scale.  Vulnerabilities or weaknesses in your application infrastructure, including risky APIs, are no longer difficult to find, as agentic AI tools, paired with automation, can observe and test endpoints and access points faster than any human.

AI-aware bot protection is a security approach that detects, classifies, and controls automated traffic generated by AI agents, LLM-powered assistants, and autonomous tools — then applies granular policies based on each bot’s identity, intent, and behavior.

Key Takeaways:

• AI-powered bots now represent a significant and growing share of internet traffic, blending seamlessly into legitimate user sessions.
• Traditional bot detection cannot reliably distinguish between beneficial AI assistants and malicious AI-driven agents.
• Unmanaged AI bots create measurable business risks: analytics distortion, inventory manipulation, API abuse, account takeover, and content scraping.
• Imperva Advanced Bot Protection provides granular visibility and control over AI-driven traffic by tool type, category, behavior, and business function.
• Effective AI bot management in 2026 requires multilayered detection with real-time, policy-based response capabilities.

The challenge for security teams is no longer understanding why automation is increasing, but gaining clear visibility and control over what that automation is doing.

The result is a growing grey zone where distinguishing among human users, legitimate AI agents, and malicious bots becomes significantly more challenging, and where traditional security controls often lack the visibility needed to reliably distinguish among them.

According to Imperva’s 2025 Bad Bot Report, bad bots accounted for 32% of all internet traffic — a 2% increase year-over-year. With AI-powered tools accelerating automation, this figure is expected to grow significantly in 2026, making bot detection and bot management a critical priority for every organization.

How Do AI Bots Blend Into Legitimate Web Traffic?

AI agents and automated tools are improving how people interact with the internet, dramatically enhancing productivity and convenience. For example:

• AI assistants like ChatGPT, Perplexity AI, and Google Gemini retrieve real-time answers from multiple websites to summarise content or compare products
• Travel platforms continuously check flight prices, seat availability, and hotel inventory
• E-commerce monitoring tools track pricing, stock levels, and competitor offers across retailers
• AI-powered shopping assistants help users find deals or complete purchases faster
• Enterprise AI tools query SaaS platforms and APIs to automate workflows like reporting, customer support, and data enrichment
• Search and indexing bots extract and index web content to power AI-driven search experiences

However, the same technological advancements that enable these positive experiences are also empowering cybercriminals. Automation at scale lowers the barrier for malicious activity, putting malicious bots at a significant advantage when automated traffic is the expected baseline. They can blend seamlessly into legitimate traffic patterns, making detection significantly more challenging.

What Are the Business Risks of Unmanaged AI Bot Traffic?

Many organizations still view bot protection as optional. However, with AI agents such as crawler bots and fetch bots, now an accepted part of internet traffic and automation accelerating at scale, bot protection has become a core security requirement. Failing to treat it as such exposes organizations to serious business risks:

How Does Imperva Deliver AI Bot Detection and Control?

The ability to control which parts of your application functionality are accessible to AI tools is critical to your AI Security Strategy.

How Does Imperva Provide Visibility Into AI Bot Traffic?

Imperva Advanced Bot Protection (ABP) offers granular visibility into AI tools, agents, and crawlers, providing a detailed, real-time view of which AI tools are accessing your websites, applications, and API endpoints.

With ABP, security teams can clearly see which AI tools are hitting their environment, which applications and URLs are being accessed, the volume and frequency of requests, and whether those requests are being allowed, blocked, or challenged

This level of visibility ensures organizations know exactly what is interacting with their digital services and helps identify unintended policy outcomes, such as blocking AI tools they want to allow, or allowing tools they should restrict.

The AI Tools dashboard provides a centralized view of AI-driven traffic, enabling faster investigation and more informed decision-making.

How Can You Control AI Bots by Tool Type, Category, and Behavior?

Beyond visibility, Imperva enables precise control over how AI tools interact with your applications.

With ABP, security teams can easily:

• Allow, block, or rate-limit specific AI tools
• Apply policies based on categories such as AI crawlers, AI agents, and AI fetch bots
• Quickly adapt policies as new AI tools emerge

This allows organizations to move from reactive blocking to intentional control of automated access.

How Does Imperva Protect Critical Business Functions from AI Bots?

Imperva ABP also provides granular control at the application and business function levels, allowing organizations to define exactly which parts of their applications AI tools are allowed to access. This ensures that:

• Approved tools can only reach intended endpoints
• Sensitive paths, APIs, or business logic remain protected
• Access policies align with business and data governance requirements

This ensures AI tools interact with applications in a controlled, predictable, and secure way.

Why Is Imperva ABP a Leading Bot Management Solution?

ABP protection against AI builds on an already strong foundation of Advanced Bot Protection, combining multilayered detection, intelligent risk scoring, and real-time controls to accurately distinguish between human, legitimate automation, and malicious bots. With deep visibility, rapid decisioning, and expert support, ABP is already a proven solution for managing sophisticated bot threats. It is now further strengthened by the ability to monitor and control AI-driven traffic precisely.

Frequently Asked Questions About AI Bot Protection

Q: What is AI-aware bot protection?

A: AI-aware bot protection is a security approach that detects, classifies, and controls automated traffic from AI agents, LLM-powered assistants, and autonomous tools. Unlike traditional bot detection that relies on static signatures, AI-aware protection uses behavioral analysis and AI tool fingerprinting to distinguish between beneficial AI assistants, legitimate automation, and malicious bots.

Q: What is the difference between traditional bot detection and AI-aware bot management?

A: Traditional bot detection identifies bots using predefined signatures and rules, treating most automated traffic as either good or bad. AI-aware bot management goes further by classifying AI tools by type, category, and behavior — enabling organizations to allow helpful AI agents while blocking or rate-limiting harmful ones with granular policies.

Q: How do AI agents bypass conventional bot defenses?

A: AI agents can mimic human browsing behavior, rotate IP addresses, solve CAPTCHA, and generate realistic session patterns. Because they operate as legitimate AI tools (such as AI assistants and search crawlers), they often pass through conventional defenses that only look for known malicious signatures.

Q: What business risks do AI bots create?

A: Unmanaged AI bots can distort marketing analytics, hoard inventory, abuse API business logic, perform credential stuffing for account takeover, scrape proprietary data and competitive intelligence, and degrade customer experience through increased site latency.

Q: Can businesses allow some AI bots while blocking others?

A: Yes. Solutions like Imperva Advanced Bot Protection enable granular control, allowing organizations to allow specific AI tools (such as approved search crawlers), rate-limit others (such as AI assistants accessing content), and block malicious AI agents — all at the individual tool, category, or endpoint level.

Q: What is agentic AI, and why does it matter for application security?

A: Agentic AI refers to autonomous AI systems that can independently browse the web, interact with APIs, and complete multi-step tasks without human oversight. These agents can probe for vulnerabilities, test endpoints, and access business functions faster than any human, making agentic AI security a critical concern for organizations.

Monitor, Control, and Prevent AI-Driven Bot Threats

Automation is now a permanent and growing part of how the internet operates. The critical challenge is no longer detecting bots alone but understanding and controlling AI-driven interactions at scale.

Organizations need to know exactly which AI tools are accessing their environments, what they are doing, and how to control that access with precision.

Imperva Advanced Bot Protection delivers the visibility, control, and adaptive protection required to operate securely in this new environment.

By enabling organizations to monitor AI agents, control their access at a granular level, and prevent malicious automation from hiding within legitimate traffic, Imperva helps businesses confidently embrace the future of AI-driven digital experiences.

Learn how Imperva Advanced Bot Protection delivers AI-aware bot management for your applications. Explore our bot protection solutions or download the latest Imperva Bad Bot Report for the most current data on AI-driven bot threats.

The post Why AI Bot Protection and Control Are Essential for Application Security appeared first on Blog.

For years, a lot of risky APIs survived simply because they were hard to find. They weren’t documented. Only a handful of engineers knew the endpoints. And if an attacker wanted to abuse them, they had to spend real time reverse‑engineering traffic and guessing how things worked.

That “security by obscurity” was never a security strategy, but it did create friction.

AI removes that friction.

Today, coding assistants and agentic tools can observe patterns in traffic, infer undocumented endpoints, generate proof‑of‑concept exploits, and test thousands of permutations faster than any human. We’ve already seen what happens when exposed APIs meet automation at scale: a hobbyist was able to gain control of thousands of robot vacuums due to exposed APIs and an over‑privileged token, something that simply wouldn’t have scaled without automation on the attacker side.

The takeaway is straightforward: if you don’t know where your APIs are, what they expose, and who can talk to them, AI will find those gaps for you, either in the hands of your developers or your attackers.

Why has API security become critical in the age of AI agents?

API security is the foundation of protecting applications against automated, AI-driven threats. In the past, attackers relied on manual reverse-engineering to discover undocumented API endpoints. Today, AI agents and coding assistants can autonomously map traffic patterns, infer hidden endpoints, and test thousands of exploit permutations in seconds. Furthermore, AI agents can bypass traditional web application firewalls (WAFs) by executing perfectly formatted, syntactically correct requests that abuse business logic—such as chaining legitimate calls to perform a Broken Object Level Authorization (BOLA) attack.

Because AI agents use APIs as their primary control plane, securing these interfaces is no longer just about preventing data breaches; it is about establishing the necessary guardrails to ensure AI tools operate safely and within their intended scope.

How AI Agents Change the Threat Model

AI doesn’t just make attackers faster. It changes what “attack” looks like, because agents can behave like normal users while still doing abnormal things.

1) Business Logic is the New Frontline

Traditional API protections – gateways, WAFs, basic input validation, are good at stopping obviously bad traffic: missing tokens, malformed payloads, suspicious content types.

But agents don’t have to look suspicious. They can follow every syntactic rule and still abuse your business logic.

Imagine an agent that:

• Uses a valid user token and calmly walks the edges of a pricing API until it discovers discount combinations you never intended to allow.
• Chains perfectly legitimate calls to pivot from one customer data to another customer’s data. This effectively executes a Broken Object Level Authorization (BOLA) attack – a critical vulnerability highlighted in the OWASP API Security Top 10 – without brute‑forcing raw IDs.

Nothing in those requests’ screams “attack.” The danger is in the sequence, the intent, and the scale, the exact things many baseline controls don’t reason about.

2) Agent-Specific Protocols Expand the Attack Surface

Agents aren’t only calling the same APIs as your mobile app calls. They’re increasingly using agent‑first toolchains and protocols that wrap platforms behind “tool” interfaces, making discovery and invocation easier than ever.

Look at what’s happening across major SaaS ecosystems: new CLIs and frameworks are designed so an agent can discover capabilities, understand schemas, and call dozens of APIs through a single control surface. Under the hood it’s still JSON over HTTP but packaged in protocols and workflows many security tools don’t meaningfully parse or recognize.

If your security stack doesn’t understand what it’s looking at, it can’t apply real policy. It just sees “some JSON” and hopes for the best.

The Thales Vision: API Security as the AI Agents’ Control Plane

At Thales, we see API Security evolving into the control plane for AI agents: the place where you get a coherent view of what agents are doing, which APIs they’re touching, and how to govern that behavior, consistently and at scale.

1) Start with ruthless visibility

You can’t protect what you can’t see, and AI moves too fast for spreadsheets and tribal knowledge.

We’re focused on:

• Finding every API: Discovering shadow, zombie, and newly created APIs across clouds and data centers, then mapping the data they expose and the business functions they support.
• Making agent traffic visible: Identifying traffic that comes from agents and agent toolchains, tying it back to the human or system they’re acting for, and surfacing suspicious patterns early.

The goal: when your CISO asks, “Which agents can touch customer PII today?” you can answer with confidence instead of guesswork.

2) Speak the same language as AI agents

We’re extending the API Security engine, so it doesn’t just see “JSON over HTTP ” but understands the agent protocols layered on top, things like MCP (Model Context Protocol) style streams and backend API calls from an agent-oriented CLI.

Once we can parse and normalize that traffic, we can:

• Apply the same validation and anomaly detection we already use for REST and GraphQL.
• Correlate what an agent is doing across back‑end services, rather than treating every request as an isolated event.

In practice, that means the security brain becomes protocol‑aware. Whether an action comes from a mobile app, a browser, or an AI agent using a modern toolchain, the same set of eyes is watching.

3) Put real guardrails around tokens and delegation

Agents run on delegation. They act on behalf of users and services using tokens, keys, and temporary credentials. When those credentials are over‑privileged or long‑lived, you get “quiet catastrophe” scenarios, like a single token shared among thousands of agents.

We’re building on our existing token visibility to:

• Score token risk: Evaluate scope, lifetime, usage patterns, and anomalies like sudden geography changes or volume spikes.
• Create policies specifically for agent delegation: For example, “This support agent’s token can only read billing data for the current customer, up to N requests per hour, and never export full datasets.”
• Catch replay and abuse: Detect when tokens are cloned, reused from odd locations, or used by unexpected agent identities.

If an AI agent starts stretching beyond the intent of its access, querying too broadly, too often, or in the wrong context, the platform should be able to flag, throttle, or cut it off in real time.

4) Defend the messy middle: business logic and BOLA

Agents follow natural‑language prompts, not carefully designed UI flows. That makes them unusually good at stumbling into the “negative space” of your application: edge paths nobody documented, but your back end still accepts.

Our approach anchors security in behavior and intent:

• Model sequences of calls as workflows and look for patterns that don’t match real user behavior, for example, moving from one customer account to another without a corresponding permission to change.
• Treat BOLA as more than “did you increment an ID,” and start reasoning about what resource the agent is effectively asking for when it requests “all internal reports” or “all projects in the system.”

The endgame is business‑level guardrails you can express clearly, and enforce across all agents, regardless of how clever the prompts are.

Meeting you where you already are

None of this works if it requires an exotic, parallel deployment just for AI. That’s why we’re embedding agent controls into the places customers already rely on Imperva today:

• Imperva Cloud WAF for internet-facing API
• Imperva WAF Gateway for on-prem and hybrid environment
• Imperva eWAF for cloud-native and microservices workloads

In each case, it’s the same security engine doing heavy lifting, discovering APIs, understanding protocols, analyzing behavior, and enforcing policy inline on every agent’s call.

Where we’re heading

AI agents are already inside organizations, helping engineers, answering customers, and automating operations. The real question is whether they’re operating inside guardrails you actually understand.

Our view is simple:

• You don’t secure AI by bolting something onto the model.
• You secure AI by controlling the APIs and data the model can reach.

By turning API Security into the shared control plane for AI agents, across discovery, protocol understanding, token governance, and business‑logic protection, we want to help teams say “yes” to AI without crossing their fingers behind their back.

If you can see every agent, every call, and every token, you can turn AI from a wild card into an engineered advantage. That’s the future we’re building toward.

The post API Security for AI Agents: Why Protection Has Never Been More Important. appeared first on Blog.

Application development has changed dramatically. Enterprises now release software faster, operate more digital services, and deploy applications across a mix of public cloud, private cloud, APIs, containers, and on-premises infrastructure.

As application delivery has accelerated and architectures have become more distributed, a disconnect has emerged between the teams building applications and those responsible for protecting them.

This tension is often described as the Wall of Confusion between DevOps and IT Security.

But the challenge does not stop there.

Over time, organizations have also introduced multiple security tools to protect different parts of the application stack. Each tool is managed separately, often by different teams, through different platforms, policies, and workflows.

The result is an additional layer of complexity. Security teams must navigate multiple vendors and fragmented controls, while DevOps teams experience delays as security becomes harder to integrate into fast-moving development cycles.

Understanding how to break down both the organizational and operational layers of this confusion is essential for organizations that want to maintain innovation while ensuring consistent, scalable security.

Applications Now Run Across Hybrid Environments

Today, around forty percent of enterprise applications run in the public cloud, and that number is expected to rise significantly to 62% over the next two years.

Source: Vanson Bourne Survey, “DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery”

Yet the shift to cloud does not mean applications live in one place. Most organizations now operate across hybrid and multi-cloud environments where applications run across public cloud platforms, private cloud infrastructure, on-premises systems, Kubernetes clusters, and an expanding network of APIs.

Cloud-agnostic strategies are also becoming more common as organizations seek flexibility and avoid dependence on a single provider. At the same time, many enterprises continue to operate legacy systems alongside modern cloud-native services.

The result is a highly distributed application landscape. Applications now run across multiple environments simultaneously, and security must be able to protect them wherever they operate.

Source: Vanson Bourne Survey, “DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery”

DevOps and Security Want the Same Outcome

Despite the perception of conflict, DevOps and IT Security teams are largely aligned on the goals of modern application security. Both groups ultimately want the same outcome: applications that are secure, reliable, and able to scale with business demand.

Research conducted with Vanson Bourne reinforces this alignment. 96% of DevOps and 95% of IT Security professionals agree that modern environments require security that is flexible across any architecture.

This global study of 1,500 professionals across the US, Europe, and APAC highlights an important point. Modern application security is not just a technology problem. It is a workflow and collaboration challenge.

Security and DevOps want the same outcome, but they experience different frustrations. These gaps can create delays, bottlenecks, false positives, and friction that undermine the cloud-native innovation organizations are working to achieve.

The Wall of Confusion: Conflicting Priorities, Fragmented Security and Tool Sprawl

The Wall of Confusion is not just about DevOps and Security working in silos. It is also about how security is delivered. Over time, organizations have added more and more security tools. One for web applications, another for APIs, another for cloud, another for containers. Each tool solves a specific problem, but together they create complexity instead of clarity.

Security teams are left navigating multiple vendors, switching between management platforms, and maintaining different policies across environments. This makes it difficult to keep controls aligned and increases operational overhead.

At the same time, gaps begin to appear. As applications move across environments, it is not always clear if they are fully protected. Policies become inconsistent because what is set in one environment does not automatically apply to another.

In fact, based on a 2026 survey of Imperva Application Security customers, 77% of security professionals say operational complexity is their biggest challenge.

For DevOps teams, this complexity shows up as delay. Security becomes a bottleneck not because it is unnecessary, but because it is too difficult to operationalize.

That is the wall and it is what needs to come down.

Why Traditional Security Models Fall Short

When applications operate across multiple environments, security approaches designed for fixed infrastructure quickly become difficult to manage.

Many organizations rely on a mixture of embedded protections, centralized security services, and environment-specific tools to protect different parts of their application landscape. While each solution may address a particular need, together they can create fragmented security architectures. This fragmentation leads to inconsistent policies, duplicated alerts, limited visibility, and increased manual effort.

Security teams must manage multiple tools and workflows, while development teams experience delays when security is applied inconsistently or too late in the process. Both teams are constrained by the same underlying issue: security models that were not designed for modern, distributed application environments.

Security Must Move with the Application

Modern applications are no longer tied to a single infrastructure model. They are composed of microservices and APIs, deployed through automated pipelines, and distributed across multiple environments.

Security therefore cannot remain a centralized checkpoint that appears late in the development process. Instead, protection needs to move with the application and operate consistently wherever that application runs.

This means security controls must function across public cloud environments, private infrastructure, hybrid deployments, Kubernetes clusters, APIs, and the traditional systems that many organizations still rely on.

DevOps and IT Security teams increasingly recognize this shift. They are not asking for less security. They are asking for security that works the way modern applications work.

Securing Applications Anywhere with Thales

As application architectures continue to evolve, organizations are no longer dealing with a single security challenge, but with the need to protect applications consistently across every environment they operate in.

The issue is not just distribution. It is how to secure that distribution without adding more tools, more complexity, or more operational overhead.

Security strategies built around isolated environments or disconnected tools are no longer sufficient. What is needed is a unified approach that delivers consistent protection, visibility, and control across the entire application landscape.

Now, the question becomes how to deliver that in practice.

Many vendors talk about flexibility but still require organizations to choose a single deployment model or manage multiple disconnected solutions. Imperva takes a fundamentally different approach. It meets organizations where they are, supporting multiple deployment models while maintaining a single, unified security experience.

This includes protection for internet-facing applications and APIs through Imperva Cloud, native integration for public cloud environments (Imperva for Google Cloud), container-based deployment for Kubernetes and microservices, and gateway deployment for on-premises, hybrid, and air-gapped environments.

The key is that all of these deployment options are powered by the same Imperva Security Engine.

This means one management console, consistent policies across every environment, and unified visibility across the entire application portfolio, regardless of where applications are deployed. Security teams do not need to manage multiple tools or vendors, and DevOps teams do not need to change how they build and deploy applications.

That is what securing applications anywhere really means.

Download the whitepaper: DevOps vs Security: Breaking Down the Wall of Confusion in Modern Application Delivery

The post Securing Applications Anywhere: Breaking Down the Wall of Confusion appeared first on Blog.