Security teams can now investigate six token risks directly at the endpoint level, making it easier to prioritize findings and take action across their API estate.

APIs depend on tokens to authenticate requests and control access. But weak signing algorithms, excessive token lifetimes, exposed credentials, and inadequate expiry enforcement can undermine that protection.

Identifying these weaknesses is only the first step. Security teams also need to know which endpoints are affected, understand the associated risks, and give application owners clear guidance on remediation.

Thales’s Imperva API Security now surfaces token risk detections directly in API Inventory. Previously available in the account-level Token Risk Report, these findings are now tied to individual endpoints, bringing investigation and remediation closer together.

Why endpoint-level token risk matters

Thales’s 2026 Token & Authentication Risk Report highlights the scale of the challenge. The report found that sensitive data exposure in JWTs increased from 46.0% to 49.8% of token-risk detections year over year. It also found that the share of endpoints accepting expired tokens increased from 5.0% to 8.5%.

Nearly 40% of endpoints with token risks had two or more authentication risks, showing why teams need to understand how weaknesses can overlap.

Previously, security teams had to cross-reference the account-level report with API Inventory to locate affected endpoints. With the new enhancement, they can investigate these findings directly where they already manage API risks.

What’s new in API Inventory?

Token risks now appear as named values in the existing API Risks column, with three practical improvements.

• Filter by risk: Find endpoints associated with a specific issue, such as Expired Token Acceptance.
• Investigate at the endpoint level: Open an endpoint’s detail drawer to view the risk name, endpoint-specific description, and first and last detected dates.
• Access remediation guidance: Understand the finding and the recommended next steps without exposing the underlying tokens or credentials.

The result is a more direct workflow: identify affected endpoints, investigate the issue, and coordinate remediation without translating account-level findings into a separate endpoint list.

Six token risks. One place to investigate them.

Thales’s Imperva API Security now surfaces six token and authentication risks directly in API Inventory.

Token risk	What it means	Why it matters
JWT Weak/Missing Algorithm	A JWT uses a weak signing algorithm or lacks an appropriate algorithm.	Depending on the implementation, token integrity may be undermined, potentially allowing forgery.
JWT Excessive TTL	A token remains valid longer than necessary.	A stolen token may remain usable for an extended period.
JWT Sensitive Data Exposure	Sensitive information is present in JWT claims.	JWT payloads are encoded, not inherently encrypted, and may be readable by anyone who obtains the token.
Auth Details in Path Params	Credentials or tokens are passed in URL path parameters.	URLs may be captured in logs, proxies, and browser history.
Expired Token Acceptance	An API accepts a token after its expiry.	Access may persist beyond the intended token lifetime.
Basic Auth Token Exposure	Reusable Basic Authentication credentials are exposed in requests.	Captured credentials may be replayed until they are changed or invalidated.

Together, these detections help teams investigate weaknesses in token integrity, lifetime, data confidentiality, credential handling, and expiry enforcement.

From finding to fix

The enhancement turns token risk findings into a more actionable endpoint-level workflow.

1. Scope the issue. Filter API Inventory by a specific token risk to identify affected endpoints.
2. Prioritize. Consider endpoint exposure, data sensitivity, and other risks associated with the same endpoint.
3. Route for remediation. Share the endpoint-specific description and remediation guidance with the responsible application or engineering team.
4. Verify. Review subsequent detection activity after the fix is deployed. First and last detected dates provide useful context, but teams should validate remediation against relevant traffic and other available evidence.

By bringing these steps closer together, Imperva helps security teams move from identifying an authentication weakness to coordinating a response, while making it easier to investigate multiple risks affecting the same endpoint.

Securing the authentication layer behind agentic AI

As AI agents increasingly interact with business applications, internal services, and third-party systems, APIs remain a critical part of the security foundation. The Model Context Protocol (MCP) provides a standardized way for AI applications to connect with tools and external data sources, making secure authentication and credential handling important considerations for agentic workflows.

This is where endpoint-level token risk detection becomes particularly relevant.

Aligning with OWASP MCP01: Token Mismanagement & Secret Exposure

OWASP’s MCP Top 10 Identifies MCP01: Token Mismanagement & Secret Exposure as a key security risk for MCP-enabled systems.

Thales’s Imperva API Security’s six token risk detections align with authentication and credential-handling concerns relevant to MCP01:

• Weak or missing JWT algorithms can undermine token integrity.
• Excessive token lifetimes can extend the window in which a compromised token remains useful.
• Sensitive data in JWT claims can expose information if a token is obtained by an unauthorized party.
• Authentication details in URL paths can increase the risk of credential exposure through logs and intermediary systems.
• Acceptance of expired tokens can indicate that token expiry is not being enforced as intended.
• Exposed Basic Authentication credentials can create opportunities for credential reuse and replay.

By surfacing these risks at the endpoint level, Imperva helps security teams investigate authentication weaknesses in APIs that support agentic workflows, where those endpoints are discovered and monitored by the platform.

This is a focused contribution to MCP security, not a claim of comprehensive MCP protection. Token risk detection alone does not discover every MCP server, prevent prompt injection, enforce least-privilege permissions, or determine whether an agent’s actions are legitimate. It provides actionable insight into an important part of the security foundation on which these systems depend.

As organizations adopt MCP and more autonomous workflows, understanding and remediating authentication weaknesses across their API estate becomes increasingly important.

Make token risks easier to act on

Security teams need more than a list of potential problems. They need to connect findings with the affected endpoints, the teams responsible, and the steps required to address them.

With six token risks now surfaced directly in Thales’s Imperva API Security’s API Inventory, teams can filter findings, investigate endpoint-specific details, and access remediation guidance in one place.

The goal is simple: make token risks easier to find, easier to understand, and easier to act on – one endpoint at a time.

Learn more: Read Imperva’s 2026 Token & Authentication Risk Report to explore the authentication risks affecting APIs today.

The post Strengthening API and MCP Security Through Token Risk Detection with Thales Imperva API Security appeared first on Blog.

Cloud has transformed how organizations build, deploy, and scale applications. It has also changed what they expect from security.

Through our work with AWS, Google Cloud, and other hyperscaler partners, we’ve had the opportunity to learn from organizations operating some of the most modern and complex cloud environments. While every organization takes a different approach to cloud adoption, customers consistently highlight a common set of expectations that are shaping the future of cloud security. That work took two significant steps this year with the launch of Imperva for Google Cloud in April and Imperva for AWS in August, both designed to keep traffic inside the cloud provider’s own network while it is inspected.

To explore those expectations further, I spoke with Eyal Cohen, Manager of Product Management for Application Security, whose team works closely with our hyperscaler partners and customers.

“The biggest thing we’ve learned is that customers don’t think in terms of security products anymore. They think about how security fits into the way they build and operate in the cloud. If security creates friction, they’ll look for another way.”

Eyal Cohen, Manager of Product Management, Application Security

Working closely with hyperscale cloud providers isn’t just about expanding routes to market or supporting new deployment models. It provides valuable insights into how cloud teams operate, the challenges they face, and what they expect from the technologies they rely on every day.

Three of those expectations come up in nearly every conversation.

Lesson 1: Customers expect consistent security outcomes, regardless of where applications run

For years, security strategies often assumed that consistency came from standardization. If environments looked the same, security would be easier to manage. Modern cloud organizations have shown that assumption no longer holds.

Applications now run across different cloud providers, environments, private infrastructure, and on-premises systems. These choices are usually deliberate. Different teams, applications, and business requirements demand different architectures. Customers are not looking for identical environments. They are looking for confidence that security outcomes remain consistent across them.

Multi-cloud security is the practice of applying one set of policies, controls and visibility to applications spread across two or more cloud providers and, for most organizations, across hybrid cloud and on-premises infrastructure as well. The infrastructure is plural by design; the security outcome has to be singular.

The question is no longer whether every workload runs on the same platform. The question is whether organizations can achieve the same level of visibility, governance, protection, and risk management regardless of where workloads reside.

This expectation spans the entire organization. CISOs need a consistent view of risk across the business. Cloud architects need the flexibility to support different technology choices without creating fragmented security models. AppSec and SecOps teams need consistent policies, controls, and visibility across environments. DevOps teams need security that follows applications without introducing new processes every time infrastructure changes.

One of the clearest lessons we’ve learned from cloud customers is that architectural diversity is becoming normal. What matters is not where applications run, but whether organizations can deliver consistent security outcomes wherever they run. The infrastructure may vary. The security outcome should not.

This is the principle behind how Imperva builds for hyperscaler environments. The same Web Application Firewall, API Security and Advanced Bot Protection run from one platform across public cloud, private cloud, hybrid and on-premises environments. Imperva for AWS deploys inline with Amazon CloudFront in minutes, inspecting traffic inside AWS before it reaches origins such as an Application Load Balancer or EC2, with no architectural changes. Imperva for Google Cloud integrates directly with Google Cloud Load Balancers through Service Traffic Extension, with no DNS changes, SSL reconfigurations or routing modifications. One policy set and one console, whichever cloud the application runs in.

Lesson 2: Customers expect security to fit the way they already work

Security initiatives often struggle for a simple reason: they ask engineering and operations teams to change how they work. Modern cloud teams already use Kubernetes, Infrastructure-as-Code, CI/CD pipelines, cloud-native services, and automated workflows. If adopting a security solution means redesigning an application, disrupting a pipeline, or introducing a parallel set of manual processes, consistent adoption becomes much harder. It is the same disconnect we described in Securing Applications Anywhere: Breaking Down the Wall of Confusion.

The impact spreads across the organization: architects get more complexity, DevOps teams face disruption to established processes, and AppSec and SecOps teams gain another tool and workflow to manage. CISOs may invest in a capability that is never adopted broadly enough to deliver the intended reduction in risk.

Security cannot sit outside the cloud operating model. It must integrate with the architectures, services, and workflows customers already use. That applies to deployment as much as day-to-day operation. Infrastructure-as-Code and automation are now standard practices for many cloud teams. Security must become part of those repeatable processes rather than depend on separate, manual tasks.

The strongest security does not force teams to choose between protection and operational efficiency. It makes protection part of how they already work.

That is why Imperva treats automation as a first-class deployment path rather than an afterthought. Imperva’s Terraform provider lets teams define Cloud WAF protection as code alongside the rest of their infrastructure. Imperva for Google Cloud is API-first and integrates with Terraform and existing DevOps workflows. And Imperva Elastic WAF deploys on Kubernetes, so protection ships inside the CI/CD pipeline rather than around it.

Lesson 3: Customers expect security to be easy to adopt, operate, and scale

Effective protection remains fundamental, but customers increasingly evaluate security across the entire lifecycle: how easily it can be evaluated, purchased, deployed, operated and scaled as requirements evolve.

Every stakeholder experiences that friction differently. CISOs need confidence that security investments will be adopted broadly enough to deliver meaningful risk reduction. Cloud architects need solutions that integrate cleanly with existing environments rather than creating new technology silos. DevOps teams want deployment models that align with automation, Infrastructure-as-Code, and existing delivery pipelines. AppSec and SecOps teams need strong protection without adding significant operational overhead.

Cloud marketplaces are one example of how customer expectations are changing. They can simplify procurement and help align security investments with existing cloud commitments. However, customers increasingly expect simplicity across the entire journey, from evaluation and deployment through day-to-day operations and long-term scale.

Imperva for AWS is available on AWS Marketplace as a SaaS offering with pay-as-you-go pricing, and Imperva for Google Cloud is available through Google Cloud Marketplace, so both can be procured alongside existing cloud commitments. Each deploys in minutes without architectural changes and is managed from the same console as every other Imperva-protected application. That is what turns “easy to adopt, operate and scale” from a slogan into a deployment plan.

The same principle applies at every stage. Security that is difficult to evaluate, deploy, operate, or scale will struggle to gain traction, regardless of its technical capabilities. The solutions most likely to succeed are the ones that fit naturally into how organizations already work.

When friction prevents security from being adopted consistently, it becomes more than an operational challenge. It becomes a security challenge.

Looking ahead

The most important lesson from working with cloud customers hasn’t been about any individual product, feature, or integration. It’s been understanding how expectations are evolving.

Modern cloud organizations expect consistent security outcomes regardless of where applications run. They expect security to fit naturally into the architectures and operating models they’ve already built. And they increasingly expect experiences that make security easy to adopt, operate, and scale.

As cloud environments continue to evolve, our focus is on helping customers maintain consistent security outcomes without limiting how or where they choose to build. Security should adapt to the realities of modern cloud operations, not require organizations to adapt to security.

That means helping customers protect applications across diverse environments, integrate security into existing workflows, and reduce the friction that can slow adoption and innovation.

The lesson isn’t that every organization should follow the same cloud strategy. It’s that regardless of the platforms, architectures, or operating models they choose, security should help them achieve the outcomes they need with the flexibility they expect.

“The cloud journey is still evolving, and so is security. By working closely with leading cloud providers and listening to the organizations using them every day, we’re continually learning what it takes to deliver security that supports innovation rather than standing in its way.”

– Eyal Cohen

Find out more about Imperva for Google Cloud and Imperva for AWS. Read the launch announcements: Thales Introduces Imperva for Google Cloud and Thales Launches Imperva for AWS. Running on Azure, in a private cloud or on-premises? The same protection is available through Imperva Web Application Firewall.

Multi-Cloud Security FAQ

What is multi-cloud security?

Multi-cloud security is the practice of applying consistent protection, visibility and policy to applications and APIs that run across more than one cloud provider, and usually across hybrid and on-premises infrastructure as well. The goal is the same security outcome regardless of where a workload runs, rather than a separate toolset and policy for each environment.

What are the biggest multi-cloud security challenges?

The challenges customers raise most often are fragmented visibility (a different console and policy per cloud), inconsistent controls that leave gaps between environments, security that does not fit Infrastructure-as-Code and CI/CD workflows, and the operational overhead of evaluating, deploying and scaling a separate solution in each cloud.

How does Imperva deliver consistent security across AWS, Google Cloud and on-premises?

Imperva delivers WAF, API Security and bot protection from one platform and one console. Imperva for AWS inspects traffic inline with Amazon CloudFront, Imperva for Google Cloud integrates with Google Cloud Load Balancers through Service Traffic Extension, and the same protection is available for private cloud and on-premises applications, so one policy applies everywhere.

Can Imperva be purchased through cloud marketplaces?

Yes. Imperva for AWS is available on AWS Marketplace as a SaaS offering with pay-as-you-go pricing, and Imperva for Google Cloud is available through Google Cloud Marketplace, which helps align security purchases with existing cloud commitments.

The post Three Lessons Cloud Customers Have Taught Us About Multi-Cloud Security appeared first on Blog.

Readiness is a visibility problem, and it’s one many organizations don’t know they have.

Most security controls tell you when they’re broken. A bad firewall rule lets traffic through that shouldn’t be there. An expired certificate generates alerts. A misconfigured WAF starts blocking legitimate users and someone notices pretty quickly.

DDoS protection is different. A service can be configured, licensed, and technically available, yet not actually be protecting your traffic. Worse, it often looks exactly the same as a fully functioning service until the moment an attack arrives.

That’s the challenge with DDoS readiness: confirming, continuously, that your traffic is actually flowing through your DDoS protection rather than assuming it is.

Attacks are loud. Protection gaps are silent.

DDoS readiness: why “protected” isn’t the same as “ready”

Ask an organization whether it’s protected from DDoS attacks and the answer is often based on two things:

• We have a DDoS protection service.
• It’s been configured.

Both may be true. Neither proves your traffic is actually protected. Readiness isn’t a checkbox. It’s an operational state that needs continuous validation. At Imperva, we view DDoS readiness through three simple questions:

1. Is traffic being advertised the way you expect?
2. Are the connections carrying protected traffic healthy?
3. Is traffic actually arriving where it should?

If you can’t answer all three, you’re making assumptions about your protection posture. That gap is behind many of the reasons DDoS protection fails just when it matters most.

This is different from DDoS testing. An attack simulation shows whether mitigation holds under load on the day you run it. Readiness monitoring answers a different question: whether the path to that mitigation is still intact today, and every day between tests. You need both.

1. Is your traffic being advertised correctly?

Whether you use always-on or on-demand protection, traffic has to be routed through the protection service, usually by advertising your network prefixes to it over BGP. Problems often emerge through gradual drift rather than obvious failures.

A prefix that should be advertised is no longer being announced. A routing change made during another project alters the traffic path. An on-demand configuration hasn’t been tested since the day it was set up. Nothing appears broken, no alarms sound, but traffic may no longer be following the path you think it is. And if an attack happens tomorrow, that’s the worst possible moment to discover it.

How to check: in Imperva DDoS Protection for Networks, the Connectivity dashboard shows the advertisement status of every protected prefix. Received means it reaches Imperva on at least two connections at two different PoPs. Received with issues flags problems such as a prefix advertised to a single PoP, or an on-demand prefix missing its no-export community. Not received means Imperva isn’t getting the advertisement at all. Status changes can be sent to you by email or to your SIEM.

2. Are your connections healthy?

Protecting traffic is only half the equation. Once traffic has been inspected and scrubbed, it still needs to reach your environment. The health of tunnels and connections plays a critical role in that process. A tunnel that’s technically up but suffering from packet loss, latency, or instability isn’t delivering the same outcome as a healthy connection.

Many organizations don’t discover these issues until traffic volumes increase or operational pressure rises. In other words, exactly when they need those connections most.

How to check: with performance monitoring enabled on a GRE tunnel connection, Imperva tracks latency, jitter and packet loss between its PoP and your network. You set the thresholds. When one is crossed, Imperva logs a “connection performance degraded” event and notifies you, with automated ping and traceroute results attached to the event.

3. Is traffic actually arriving?

This is often the most overlooked readiness check; many organizations monitor overall traffic levels and see healthy numbers across the environment. The dashboard looks green, total volume looks normal, but aggregate metrics can hide local problems.

A single point of presence (PoP) may receive significantly less traffic than expected because of routing changes, connection issues, or path degradation. In a global environment, that reduction might represent only a small percentage of total traffic and easily disappear into normal variation.

The dashboard stays green, while users in that region experience a very different reality. Monitoring expected traffic levels at the PoP level helps uncover these issues before they impact users or complicate response during an attack.

How to check: Imperva PoP Traffic Monitoring does exactly this. You set a minimum level of legitimate traffic for each protected network or IP (0–100 Mbps) and a minimum share of traffic for each PoP or group of PoPs. When traffic stays below a threshold for five minutes (the default), Imperva logs a “traffic dropped below threshold” event and notifies you.

Watch for too little, not just too much

Most DDoS detection systems are designed to identify excess: more traffic, more requests, more connections and more anomalies. The assumption is simple: when something goes wrong, volume increases, but readiness issues often present in the opposite way. Traffic stops arriving where expected, advertisements change, routes shift and connections degrade. But nothing spikes, nothing triggers traditional attack alerts.

The only signal is an absence. That’s why DDoS readiness requires a different mindset. Instead of asking:

“Is too much traffic arriving?”

you also need to ask:

“Is the expected traffic still arriving everywhere it should?”

That question can reveal problems long before an attacker does.

What changes when readiness becomes visible?

When readiness becomes visible, three things change. First, readiness becomes an operational consideration rather than an emergency discovery. Teams can identify issues during routine monitoring instead of during an active incident.

Second, on-demand protection becomes easier to validate. If attack-path activation is something you’ll depend on during a crisis, you need confidence that it will work before the crisis arrives. For on-demand ranges, Imperva also raises an event if flow monitoring data stops arriving, because DDoS detection for that range is inactive until it resumes.

Third, incident response improves. When an attack begins, teams aren’t wasting precious time figuring out whether protection was actually in place. They can focus immediately on responding to the threat.

The bottom line

Protection you can’t verify is protection you’re assuming.

That assumption can survive for months or even years because most days are quiet. Every uneventful day reinforces the belief that everything is working as expected. Then an attack arrives and turns that assumption into a test.

At Thales, we believe DDoS readiness is fundamentally a visibility problem. By continuously monitoring advertisement state, connection health, and traffic flow across locations, organizations can answer the critical question before an attacker forces it: is our DDoS protection actually on, everywhere it should be?

Discover how Thales Imperva DDoS Protection helps defend your applications and networks against increasingly sophisticated DDoS attacks while keeping critical services available.

DDoS readiness FAQ

What is DDoS readiness?

DDoS readiness is the verified, ongoing state in which your traffic is actually routed through, delivered by and arriving at your DDoS protection service, as opposed to a service that is only licensed and configured. It rests on three checks: route advertisement, connection health and traffic arrival at each PoP.

How can I tell if my DDoS protection is actually working?

Check three things continuously: that your prefixes are advertised to and received by the provider, that the tunnels or connections back to your network are healthy (latency, jitter, packet loss), and that expected traffic keeps reaching each PoP. Alert on drops, not just spikes.

How is DDoS readiness different from DDoS testing?

DDoS testing simulates an attack to check whether mitigation holds at one point in time. Readiness monitoring checks, every day, that the routing and connections mitigation depends on are still intact. One complements the other.

Does on-demand DDoS protection need readiness checks?

Yes, even more than always-on. On-demand protection only matters if activation works during an attack, so verify that your advertisements are correct (with Imperva, including the no-export community) and that flow monitoring data is still arriving. If it stops, attack detection for that range is inactive.

The post Is Your DDoS Protection Actually On? appeared first on Blog.

Somewhere in your organization is a spreadsheet of certificate expiry dates, and someone who owns it. That is not a caricature. DigiCert’s 2026 research with Omdia surveyed more than 400 senior IT leaders and found that 47% still rely on manual tracking methods such as spreadsheets, and only 34% have a complete, current view of what they hold. The spreadsheet works because renewals come around once a year, and one person with a calendar can keep the whole estate in their head.

The industry has decided to take that away. The CA/Browser Forum voted in April 2025 to bring the maximum TLS certificate lifespan down in steps: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, with domain validation reuse dropping to 10 days. The first step is already live: since March 15, 2026, no publicly trusted TLS certificate can be valid for more than 200 days. By 2029 you will be proving ownership of your domains roughly every month, for every certificate, forever. The spreadsheet does not survive that. Neither does the person.

Why TLS certificate lifespans are shrinking to 47 days

Shorter lifespans shrink the window in which a stolen key or a mis-issued certificate is useful, and they push the whole ecosystem onto automation, which is where the reliability actually comes from. The destination is better. The journey is where outages live. Every manual step in your renewal process is a place where a 47-day cycle breaks something a 365-day cycle never stressed. We covered what the vote means for Imperva customers when it passed; this post is the checklist.

How to prepare for 47-day certificates: five things to do, in order

1. Inventory what you actually have. Every certificate, every domain, every site, and who renews it. Cloud WAF reports SSL coverage status for each protected site, so start with your public-facing estate. It is the part with a deadline attached and the part your customers meet first.
2. Automate domain validation now. Manual validation at a 10-day reuse window is not a process, it is a permanent job for somebody. Automatic CNAME validation makes ownership proof continuous, and it is the single change that turns the 2029 schedule from alarming to routine. The payoff starts now, not in 2029: Imperva already requires domain revalidation every 99 days for its managed certificates. We walked through the setup in Effortless certificate management with automated CNAME validation.
3. Find your non-SNI traffic before it finds you. Server Name Indication (SNI) is the TLS extension that tells the server which hostname a client is asking for. Clients that do not send it, usually older HTTP libraries, outdated monitoring tools and misconfigured internal services, cannot be served a site certificate (a site with non-SNI connections is not eligible for one), and they are rejected outright once a site moves to SNI-only mode. That is why this step comes before the next one. Non-SNI clients are also invisible unless you go looking. One custom rule with the filter hasSNI == false, set to Alert, logs every non-SNI request as a security event without blocking anything. Leave it running for a week or two, since some of this traffic is periodic, then decide. Imperva Cloud WAF Technical Guide: How to Identify Non-SNI Traffic Before Enabling SNI-Only Mode walks through it step by step.
4. Isolate the blast radius. A certificate shared across your whole estate means one renewal problem is everyone’s problem. Imperva site certificates give each site its own certificate, its own coverage status and up to 50 domains, so one team’s missed renewal does not become another team’s outage. New SNI-only sites have required site certificates since September 13, 2026, and Imperva recommends migrating existing SNI sites off shared account certificates by December 31, 2026, before automatic migration begins in Q1 2027.
5. Connect the certificate system you already run. If your certificates are governed in a Certificate Lifecycle Management (CLM) platform, the system that issues, tracks and renews certificates centrally, or in your own PKI, those renewals should reach your WAF without a person in between. The SSL Integration Center connects that workflow directly to Imperva Cloud WAF. DigiCert Trust Lifecycle Manager and Keyfactor Command are on the supported vendor list, with further CLM integrations in progress.

What Imperva is already doing: 90-day certificates and the R46 root

Imperva-managed certificates have already moved to 90-day validity (with domain validation every 99 days), ahead of the industry deadlines, with renewal and deployment automated end to end. Root trust is moving too: the GlobalSign root transition (R3 to R46) is covered by a cross certificate that Imperva includes by default until the R3 root expires in March 2029, so legacy clients keep working, and action is needed only if you pin to a specific root certificate. The direction of travel is simple. Certificate work becomes something you configure once, not something you do monthly.

The detail lives in the Cloud WAF documentation, and walks the site-certificate path step by step.

Back to that spreadsheet. If it is yours, the right time to retire it is while it still works. If you retired it years ago, the question is whether your automation reaches all the way to your applications, or stops at the CA.

Frequently asked questions about 47-day certificates

When do 47-day TLS certificates take effect?
From March 15, 2029, publicly trusted TLS certificates can be valid for no more than 47 days. The CA/Browser Forum schedule gets there in steps: 200 days from March 15, 2026 (already in force) and 100 days from March 15, 2027.

How often will I need to validate domain ownership?
The period for reusing domain validation follows the same schedule: 200 days from March 2026, 100 days from March 2027 and 10 days from March 2029. In practice that means validating for almost every renewal, which is why an automated method such as CNAME delegation matters.

Do I need to do anything for Imperva-managed certificates?
Imperva renews and deploys its managed certificates automatically, and they already have 90-day validity. What stays with you is domain validation (automatic CNAME validation removes it), moving SNI sites from shared account certificates to site certificates, and updating your trust store if you pin to a root certificate.

What happens to clients that don’t support SNI?
A client that doesn’t send SNI can’t be served a site certificate, and once a site moves to SNI-only mode those connections are rejected. A custom rule with the filter hasSNI == false, set to Alert, shows whether you have any before you switch.

The post 47-Day Certificates Are Coming: Five Things to Do Before They Arrive appeared first on Blog.

Somewhere, an attacker is recording your encrypted traffic. Not breaking it. Recording it. The bet is patient and simple: store ciphertext today, wait for quantum computers to mature, decrypt at leisure. The industry calls it harvest now, decrypt later (HNDL), and it is the rare security threat with a believable deadline attached: data with a ten-year shelf life, encrypted with algorithms on a countdown.

Most quantum-readiness advice hands you a project: audit your cryptography, plan your migration, stand up a working group. Here is what Cloud WAF customers had to do to get quantum-safe TLS on every connection between their users and the Imperva network: nothing.

What shipped: hybrid post-quantum TLS on every Cloud WAF site

Every TLS 1.3 connection from a PQC-capable client to Imperva now negotiates hybrid TLS key agreement: X25519MLKEM768, which runs classical X25519 and quantum-safe ML-KEM-768 together. ML-KEM is the key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024. It is enabled by default on all Imperva sites, with zero configuration and no measurable performance trade-off. If a client supports it, it is on. Your users’ sessions are already protected against the recording attack, and nobody on your team filed a ticket to make that happen. You can see it for yourself: open Chrome DevTools, go to the Security panel, and the connection to any Imperva-protected site lists X25519MLKEM768 as its key exchange. We explained earlier this year why post-quantum cryptography can’t wait; this post is the update now that both legs are covered.

The second leg: post-quantum TLS from Imperva to your origin

A proxy architecture has two connections per request: client to edge, and edge to origin. As of the October 4, 2026 release, Imperva also supports PQC on the Imperva-to-origin leg, so customers whose origin servers support post-quantum key agreement get quantum-safe encryption end to end: from the user’s browser, through the Imperva network, to their own infrastructure. The requirement on your side is one sentence long: an origin that can negotiate the hybrid handshake. In practice, that means OpenSSL 3.5 or later, which offers X25519MLKEM768 by default. Sites created on or after October 4, 2026 get PQC to origin automatically. Existing sites keep their current behavior until you switch it on under SSL/TLS Configuration > Origin connection security, or with the /v3/sites/origin-pqc API. If an origin can’t negotiate the hybrid handshake, the connection falls back to classical TLS without disruption.

The honest scope: what hybrid key agreement covers

Post-quantum TLS is arriving across the industry, and that is a good thing; no vendor should claim the category. What differs is the operational bill. Here the answer is: defaults. No premium SKU, no per-site enablement, no migration project for the edge leg, and, for end to end, an origin-side capability check plus one switch on sites created before October 4, 2026. For regulated sectors already fielding quantum questions from auditors and boards (finance, healthcare, defense), that turns a program into a paragraph in your next review. Behind it sits the Thales portfolio, where post-quantum work spans well beyond the WAF. One limit worth stating plainly: hybrid key agreement protects the confidentiality of each session, which is exactly what a harvest now, decrypt later attack targets. Certificate signatures are a separate, later migration (NIST’s ML-DSA, FIPS 204), because forging a signature needs a quantum computer at the moment of the handshake. Recorded traffic gives an attacker nothing to work with there.

What to do about harvest now, decrypt later

• Nothing, for the client leg. It is already on.
• Check your origin stack for hybrid key-agreement support, and switch on the second leg when it does. That means OpenSSL 3.5 or later. New sites have PQC to origin on by default; existing sites need it switched on once, in the Cloud Security Console or through the API.
• Put one line in your next security review: sessions through Cloud WAF are quantum-safe by default. Boards like sentences that end.

Detail, including how to test PQC and how to switch it on for your origin, is in the Post-Quantum Cryptography (PQC) Support documentation.

The recording attacker is patient. As of now, what they are recording from your traffic is noise with no future.

Harvest now, decrypt later: FAQ

What is a harvest now, decrypt later (HNDL) attack?

An attacker records encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the classical key exchange that protected it. Data that must stay confidential for years is at risk now, even though that quantum computer does not exist yet.

Is Imperva Cloud WAF traffic protected against harvest now, decrypt later?

Yes, for the key exchange. TLS 1.3 connections from PQC-capable clients to Imperva use hybrid X25519MLKEM768 by default on all sites. Connections from Imperva to your origin use it when the origin supports it (OpenSSL 3.5 or later) and PQC to origin is on: by default for sites created on or after October 4, 2026, and opt-in for existing sites.

What is X25519MLKEM768?

It is the hybrid TLS 1.3 key-exchange group that combines classical X25519 elliptic-curve key agreement with ML-KEM-768 (FIPS 203). An attacker has to break both to recover the session key. It follows the hybrid model adopted by Google Chrome and other major browsers, and it is what Chrome DevTools shows when a connection is post-quantum protected.

What happens if a client or origin doesn’t support post-quantum TLS?

The connection falls back to classical TLS key exchange without disruption. PQC is used only when both sides support it, and it requires TLS 1.3. See the Imperva PQC documentation for the handshake scenarios.

The post Harvest Now, Decrypt Later: The Attack You Defend Against by Doing Nothing appeared first on Blog.

This is Post 4 of a four-part series:
Post 1: Agentic AI Security: The Chatbot Era Is Over
Post 2: Generative AI Security: Why AI Needs a New Kind of Security
Post 3: The OWASP LLM Top 10 Was the Warm-Up: What Comes Next

The 2026 edition of the the OWASP Top 10 for LLM Applications, published by the OWASP GenAI Security Project on August 3, 2026, is easy to skim past. No entry was dropped and no new category was introduced, so at a glance it can read as housekeeping. It is worth a closer look than that. Eight of the ten entries changed position, and one was renamed and widened in scope, which changes what it asks of the teams working against it.

When a framework adds or drops entries, it is usually telling you the threat surface itself has changed. This edition did something more specific. The categories held, but their order was substantially revised and one of them grew, which suggests the original naming was sound while the relative priority had drifted from what teams were meeting in production. Read the movements together and a pattern shows up.

The short version: the OWASP Top 10 for LLM Applications 2026 kept all ten categories but moved eight of them. Excessive Agency climbed from LLM06 to LLM03, Unbounded Consumption from LLM10 to LLM06 and Misinformation from LLM09 to LLM07, while Improper Output Handling fell from LLM05 to LLM10. System Prompt Leakage was renamed Hidden Context Exposure and broadened to cover everything an application places in front of the model without the user seeing it.

What changed in the OWASP LLM Top 10 2026

The table below sets the 2026 order against the 2025 one, listed by 2026 rank.

2025 rank	Entry	2026 rank	Movement
LLM01	Prompt Injection	LLM01	No change
LLM02	Sensitive Information Disclosure	LLM02	No change
LLM06	Excessive Agency	LLM03	Up 3
LLM03	Supply Chain	LLM04	Down 1
LLM04	Data and Model Poisoning	LLM05	Down 1
LLM10	Unbounded Consumption	LLM06	Up 4
LLM09	Misinformation	LLM07	Up 2
LLM07	Hidden Context Exposure	LLM08	Down 1, renamed and widened from System Prompt Leakage
LLM08	Vector and Embedding Weaknesses	LLM09	Down 1
LLM05	Improper Output Handling	LLM10	Down 5

Prompt Injection and Sensitive Information Disclosure held first and second, which surprised nobody. Every other entry sits somewhere new, and the rest of this piece is about why the direction of those moves matters more than the individual rankings.

Excessive Agency and Unbounded Consumption: the climbers describe applications, not models

The two biggest climbers are the same kind of risk wearing different clothes. Excessive Agency is about what an application is permitted to do once a model is driving it: which tools it can call, which systems it can reach, how far one decision can travel before a human sees it. Unbounded Consumption is about what happens when that same application meets traffic engineered to abuse it, producing no malware and no traditional indicators, just an enormous bill. Neither is a property of the model. Both are properties of an application in production.

The biggest faller makes the same argument from the other end. Improper Output Handling dropped five places, and not because it stopped happening. It fell because it is the entry the industry already knew how to answer. Rendering untrusted output safely, refusing to execute what came back from an untrusted source, treating downstream consumers as a boundary: application security teams have been practicing that discipline for twenty years. The skill transferred. The novelty did not survive contact with people who already had the muscle.

Setting the renamed entry aside, the three entries that each slipped a place have something in common too. Supply Chain, Data and Model Poisoning, and Vector and Embedding Weaknesses are all risks you address before the application serves its first request, in procurement, in the training pipeline, in how the knowledge base was assembled and secured. They did not become less serious. They became less urgent relative to the things that only exist once the system is live.

Misinformation climbing two places fits once you ask who pays for it. A model that invents a refund policy is a quality problem in a lab and a liability problem in production, and a Canadian tribunal has already held Air Canada responsible for what its chatbot told a customer (Moffatt v. Air Canada, 2024). That entry did not move because models got worse. It moved because the consequences arrived.

Read together: the entries that climbed are the ones that only exist while the application is running. The entries that fell are handled before deployment, or handled by controls the industry already had.

From System Prompt Leakage to Hidden Context Exposure: the rename nobody is discussing

System Prompt Leakage became Hidden Context Exposure, and it is the most consequential edit in the document.

A system prompt is one specific thing: the instruction block sitting at the top of a conversation, defining the model’s role and its rules. Hidden context is everything else the application quietly places in front of the model without the user ever seeing it. Retrieved documents. Tool definitions. Prior turns held in memory. Configuration a developer assumed was private because no interface displays it.

The rename takes the entry from one field to an entire supply of runtime input, and it lands the same point the reordering makes. What the application feeds the model has become the attack surface. That is a materially bigger claim than the 2025 wording made, and any content or tooling still describing this entry as system prompt protection is now describing a fraction of it.

How to read an OWASP LLM Top 10 coverage claim, including ours

A reordering like this produces a wave of updated coverage claims, and some of them will describe protection across the whole list. Those claims are worth examining rather than accepting, and one question does most of the work: which control fires, inline, at runtime, for this specific entry?

Ask it of the entries that just fell. A poisoned model dependency arrives before a single request is served. At the moment of compromise there is no traffic to inspect, no prompt to score, no response to hold. Something does address that risk, but that something is a procurement process, a posture scan or a signed build pipeline. The same is true of a poorly governed vector store. These are real controls and they matter; they are simply not the same category of thing as a runtime control, and they usually sit with a different team and a different budget.

This is not a criticism of any product. It is the shape of the problem. Runtime protection covers runtime problems. When you meet a claim spanning all ten entries, the useful follow-up is to ask which of the ten are covered by inline enforcement, which by a scanner, which by a partner integration, and which by a policy document, and then to decide whether that composition is what you thought you were buying. A vendor who can answer that cleanly is telling you something about how they think. So is one who cannot.

Apply the same question to us. We would rather you did.

Where we stand against the 2026 order

Thales Imperva AI Application Security addresses five entries with runtime enforcement. In 2026 numbering, they are Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), Unbounded Consumption (LLM06), Hidden Context Exposure (LLM08) and Improper Output Handling (LLM10).

Two of those five moved this year, and the moves cut in opposite directions. Unbounded Consumption climbed four places, which raises the profile of a control we already ship. Improper Output Handling fell five, which lowers the profile of another one we already ship. Reporting the first without the second would be the kind of selective reading this piece is arguing against.

Two of those five are also where our next work lands, and they are connected. Hidden Context Exposure now covers tool definitions, and Excessive Agency is the question of what an application is permitted to do once a model is driving it. We are adding tool call guardrails that check whether the specific tool being called is permitted, and the tool definitions themselves are what we look at next. Today we detect and monitor tool calls. Checking them against what is allowed is the step after that, and it is better to say so plainly than to let a coverage table imply it already exists.

The other five entries need different tools, and we would rather name them than imply otherwise. Supply Chain and Data and Model Poisoning are build-time and procurement problems. Vector and Embedding Weaknesses belongs with the data security controls sitting in front of the retrieval pipeline. Misinformation is evaluation and grounding work. Excessive Agency is the one to watch: it is the entry moving fastest toward runtime, it is where the agentic controls across this whole category are heading, and at number three it is now the highest-ranked risk that most security programs have no inline answer for at all.

The list caught up with agentic AI

In a recent piece we argued that the LLM Top 10 had been the warm-up, and that the frameworks describing agentic and MCP risk had already been published while most security programs were still resourcing against the first list. The 2026 edition is that argument told from inside the framework itself.

Excessive Agency at number three is an agentic risk sitting near the top of an LLM list. Hidden Context Exposure is the retrieval and tool layer being named as attack surface. Neither entry is about a model producing text. Both are about a system taking action on the strength of what it was fed. The list has started describing applications that act, which is the same shift the newer frameworks were built for.

A practical exercise for this quarter: take the four entries that moved most, and for each one write down which control in your own environment would fire while the attack was in progress, not after it appeared in a report. The gaps in that list are what the 2026 reordering is pointing at.

Thales’s Imperva AI Application Security is purpose-built runtime protection for AI applications, agents, and the ecosystems behind them, deployable in-app, at the Imperva edge, or via API, standalone or as part of Imperva’s unified application security platform. Our white paper, Beyond the LLM Top 10, maps the agentic and MCP threat surface against the published frameworks.

Frequently asked questions about the OWASP LLM Top 10 2026

What changed in the OWASP Top 10 for LLM Applications 2026?

The 2026 edition, published by the OWASP GenAI Security Project on August 3, 2026, added and removed no categories. Eight of the ten entries changed position: Excessive Agency rose from LLM06 to LLM03, Unbounded Consumption from LLM10 to LLM06 and Misinformation from LLM09 to LLM07, while Improper Output Handling fell from LLM05 to LLM10. Prompt Injection (LLM01) and Sensitive Information Disclosure (LLM02) held their places, and System Prompt Leakage was renamed Hidden Context Exposure.

What is Hidden Context Exposure in the OWASP LLM Top 10?

Hidden Context Exposure (LLM08 in 2026) replaces System Prompt Leakage (LLM07 in 2025). It widens the entry from the system prompt alone to everything an application places in front of the model without the user seeing it: retrieved documents, tool definitions, prior turns held in memory and configuration a developer assumed was private.

Why did Excessive Agency move up to LLM03?

Excessive Agency describes what an application is permitted to do once a model is driving it: which tools it can call, which systems it can reach and how far one decision can travel before a human sees it. It climbed three places, from LLM06 to LLM03, as agentic applications that take actions moved into production.

Which OWASP LLM Top 10 risks can runtime protection address?

Runtime controls act on live traffic: prompts, responses and tool calls. Supply Chain and Data and Model Poisoning are build-time and procurement problems, Vector and Embedding Weaknesses belongs with data security controls in front of the retrieval pipeline, and Misinformation is evaluation and grounding work. When a vendor claims coverage of all ten entries, ask which are covered by inline enforcement, which by a scanner, which by a partner integration and which by a policy document.

Read more in our white paper: Beyond the LLM Top 10.

The post OWASP LLM Top 10 2026: Every Move Points the Same Direction appeared first on Blog.

Somewhere in your estate right now, a certificate is counting down to its expiry date. Today you probably know which one, because renewals still come around annually and someone owns the calendar. The industry is taking that comfort away: the CA/Browser Forum has voted to cut the maximum TLS certificate lifespan to 47 days by 2029, a decision we looked at in detail in our piece on shortened renewal periods. Renewals that happen once a year will soon happen every few weeks, and every manual touchpoint in that process becomes a potential outage. The math stops working.

The honest complication is that most enterprises do not live in a single-vendor world. You may run your own internal PKI. You may have standardized on a dedicated Certificate Lifecycle Management (CLM) platform. You may answer to compliance mandates that dictate exactly which Certificate Authority issues your certificates, and how. In those environments, visibility and control across every certificate matters as much as automating the renewals themselves. Until now, connecting those established workflows to Imperva meant manual effort, and manual effort is exactly what shrinking lifecycles no longer allow.

Today we are introducing the SSL Integration Center: an integration framework connecting Imperva Cloud WAF with leading Certificate Lifecycle Management platforms. It launches with its first supported integration, the DigiCert Trust Lifecycle Manager (TLM) Agent.

Your CLM stays in charge for certificate lifecycle management

The SSL Integration Center is not a new product or another console to learn. It is an integration framework, and the experience runs from the side you already live in: you configure the integration from within your CLM platform, and your CLM remains the place where certificates are managed. Once connected, two things happen from there. You can see all of your Imperva-managed domains and the SSL coverage status of each one, directly in your certificate workflow. And the complete certificate lifecycle cadence, issuance, renewal and deployment to Imperva, runs automatically under the policies your CLM already enforces. Imperva’s role is to integrate smoothly into the workflow you have, supplying application and SSL-coverage visibility and taking automated deployment off your hands. DigiCert is the first integration, and it sets the pattern for the CLM vendors that follow.

Thales-managed or customer-managed: your choice

Many organizations choose Thales-managed certificates because that removes the operational load of provisioning, renewal, monitoring and deployment in one move, and for them nothing changes. Others cannot adopt a fully managed approach: compliance requirements, PKI investments, established CLM platforms and governance policies often require a customer to keep control of their own certificate ecosystem. The Integration Center is built for that second group. You keep your CA, your CLM and your lifecycle processes, exactly where they run today, and Imperva plugs into them. Governance stays yours, and so does the console.

Starting with a leader: DigiCert Trust Lifecycle Manager

DigiCert TLM gives enterprises one place to discover, govern, automate and see certificates across cloud, hybrid and on-premises environments. It builds an organization-wide certificate inventory, enforces consistent cryptographic policy, and replaces surprise expirations with automated renewals. A useful way to think about the pairing: TLM is the system of record for your certificates, and the Integration Center is the delivery route into the applications Imperva protects.

With this integration, the DigiCert TLM Agent automates certificate issuance, renewal and deployment straight into Imperva. Under the hood, a post-enrollment script securely uploads the certificate chain and private key to Imperva through the Provisioning API, so a certificate governed in TLM arrives at your protected applications without anyone touching it. It runs on both Linux and Windows.

The value of that automation is documented. In a commissioned Total Economic Impact study, Forrester Consulting found organizations standardizing on DigiCert ONE, the platform behind Trust Lifecycle Manager, achieved 96% fewer outages from expired or misconfigured certificates, and a 312% return on investment over three years.

Source: The Total Economic Impact of DigiCert ONE (July 2025), a commissioned study conducted by Forrester Consulting on behalf of DigiCert. Results are based on a composite organization derived from customer interviews. Forrester does not endorse DigiCert or its offerings.

How the DigiCert TLM integration works

• Govern in DigiCert TLM. Your certificate is issued and managed centrally, under the policies your organization already enforces.
• Automate with the TLM Agent. A post-enrollment script runs on issuance or renewal and packages the certificate chain and private key.
• Deploy through the Provisioning API. The script securely uploads the certificate to your Imperva cloud account and puts it to work protecting your applications. No manual upload. No missed renewal window.

What this means for your team

• Continuous, compliant TLS protection. Issuance, renewal and deployment of custom certificates run without manual intervention, so your encryption stays current as lifecycles shrink.
• Full bring-your-own-CA automation. If you use your own Certificate Authority and custom certificates, the entire lifecycle can now run end to end.
• Fewer outages, less toil. Removing the manual steps removes the TLS outages that come from missed renewals, and frees your team from certificate babysitting.
• Your Imperva estate, visible from your CLM. Once connected, your Imperva-managed domains and the SSL coverage status of each appear inside your certificate workflow, so DigiCert’s organisation-wide discovery and Imperva’s application coverage read as one picture, without switching consoles.

A certificate automation ecosystem that grows with you

Shorter certificate lifecycles are the new baseline, and they reward the organizations that automate. The SSL Integration Center makes that automation work on your terms: the CA you trust, the CLM platform you have standardized on, the compliance posture you are held to. It sits alongside Thales’s own SSL management capabilities, including certificate visibility, site coverage monitoring, notifications and real-time SSL health monitoring. DigiCert Trust Lifecycle Manager is the first integration and it will not be the last; each CLM vendor added becomes one more certificate workflow that arrives at your applications without a human in the renewal loop.

That certificate counting down in your estate? Under TLM and the Integration Center, its renewal has already happened by the time you would have thought to check.

It is also one thread in a wider fabric. Imperva integrates across the tools enterprises already run, from SIEM and ITSM platforms to API gateways, scanners and cloud providers, through the Imperva Technology Alliance Program. If your certificate stack is the workflow we meet today, the rest of your stack has a meeting point there too.

Get started with the SSL Integration Center

If you are a Thales Imperva Cloud WAF customer using DigiCert Trust Lifecycle Manager, you can configure the integration from your TLM console today. For step-by-step setup, see the Imperva documentation on integrating custom certificates and the DigiCert + Imperva integration overview.

The post Bring Your Own CA: Introducing the Thales Imperva SSL Integration Center, Featuring DigiCert Trust Lifecycle Manager appeared first on Blog.

This is Post 3 of a four-part series:
Post 1: Agentic AI Security: The Chatbot Era Is Over
Post 2: Generative AI Security: Why AI Needs a New Kind of Security
Post 4: OWASP LLM Top 10 2026: Every Move Points the Same Direction

When the OWASP Top 10 for LLM Applications arrived, it did the industry a real service. It gave security teams a stable, vendor-neutral vocabulary for a threat surface that was moving too fast to describe. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling, unbounded consumption: five of those ten account for the bulk of what actually shows up in red-team exercises and public incidents.

Every framework earns its keep by naming what defenders are already fighting. Which is exactly why the next part matters: the next lists are not coming. They have already arrived. Most security programs simply have not caught up with them yet.

The three OWASP lists that now define AI security

Three published OWASP lists now cover the AI stack end to end. Together they are the checklist most security programs are not yet resourced against:

OWASP Top 10 for LLM Applications (2025) – the conversation layer. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption are the five that dominate real incidents.

OWASP Top 10 for Agentic Applications (2026) – the systems that act. Released 9 December 2025 by the OWASP GenAI Security Project. Ten risks, prefixed ASI, covering what happens when AI stops answering and starts doing.

OWASP MCP Top 10 (MCP01:2025-MCP10:2025) – the connective tissue. Currently in beta (Phase 3, beta release and pilot testing), covering the Model Context Protocol layer that wires assistants to real systems and data.

The OWASP agentic and MCP Top 10 lists are published. The budgets are not.

In December 2025, the OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications (2026), covering the risks that appear when AI stops answering questions and starts taking actions: agent goal hijack (ASI01), tool misuse and exploitation (ASI02), identity and privilege abuse (ASI03), memory and context poisoning (ASI06), insecure inter-agent communication (ASI07) and rogue agents (ASI10).

Alongside it, OWASP’s MCP Top 10 project is codifying the risks of the Model Context Protocol, the standard that connects AI assistants to real systems and data. It is a young list, currently in beta – Phase 3, beta release and pilot testing, with entries carrying the MCP01:2025 through MCP10:2025 designation – and it is already one of the most useful documents in AI security, because it names the attack patterns defenders are meeting right now. Three of them deserve particular attention.

Command injection and execution (MCP05). An AI agent executes system commands built from untrusted input, without proper validation. An adversary who compromises the toolchain gets their work carried forward by the agent itself, with the agent’s legitimate permissions. The prompt was never touched. The model behaved exactly as designed. The compromise came in through the tools.

Tool poisoning (MCP03). The model is handed a list of tools it may call, and it trusts their definitions and their outputs. Poison either one and you have redirected the application’s behavior without a single suspicious token appearing in the conversation.

Insufficient authentication and authorization (MCP07). MCP servers, tools, and agents interacting without properly verifying identity or enforcing access controls. Who is allowed to call this tool? Which agent may delegate to which? In most environments today the answer is: whoever asks. That is not a vulnerability in a model. It is a missing identity layer for machines.

One more entry is worth a mention because it will sound familiar to anyone tracking shadow IT: shadow MCP servers (MCP09), the unapproved deployments running outside security governance, often on default credentials. The shadow AI problem now has an OWASP number. For the practical exposures behind these entries, see MCP Server Security: The Blind Spot in Your AI Stack.

None of these are theoretical. All of them get easier as organizations wire agents into more systems. And none of them have the household-name status that prompt injection now enjoys, which means the frameworks are ahead of most security programs’ resourcing. That is a new and uncomfortable position: the industry usually waits years for its threat lists. This time the lists arrived before the budgets.

History does not repeat, but it files tickets

We have watched this movie before. Monolithic applications got the OWASP Top 10. API-based applications got the API Security Top 10, because the attacks changed shape when the architecture did. AI applications and agents are the next architecture, and this time the pattern completed itself faster than ever: the LLM Top 10 for the conversation layer, the Agentic Top 10 for the systems that act, and the MCP Top 10 for the connective tissue between them.

So the catch-up question for security teams is no longer “what threats might emerge?” It is “which published OWASP entries is my program actually resourced against?” And the question for vendors sharpens the same way. Not “do you block prompt injection?” but “walk me through the MCP Top 10 and tell me what you see, and what you can control, beyond the prompt.”

The LLM Top 10 taught the industry to take AI threats seriously. The warm-up worked. The event has already started.

Frequently asked questions about the OWASP AI Top 10 lists

What is the OWASP LLM Top 10? The OWASP Top 10 for Large Language Model Applications is a vendor-neutral list of the ten most critical security risks in LLM-based applications, maintained by the OWASP GenAI Security Project. Prompt injection, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption account for most of what shows up in red-team exercises and public incidents.

Is there an OWASP Top 10 for AI agents? Yes. The OWASP Top 10 for Agentic Applications (2026) was released on 9 December 2025. Its ten entries carry the ASI prefix and run from agent goal hijack (ASI01) to rogue agents (ASI10).

What is the OWASP MCP Top 10? A list codifying the security risks of the Model Context Protocol, the standard connecting AI assistants to real systems and data. Entries run MCP01:2025 to MCP10:2025 and include tool poisoning (MCP03), command injection and execution (MCP05), insufficient authentication and authorization (MCP07) and shadow MCP servers (MCP09). The project is in beta.

How many of the OWASP LLM Top 10 does Imperva address? Five out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling and unbounded consumption.

What should I ask an AI security vendor? Not “do you block prompt injection?” but “walk me through the MCP Top 10 and tell me what you see, and what you can control, beyond the prompt.”

Thales’s Imperva AI Application Security addresses five of the OWASP LLM Top 10 out of the box. We believe the industry’s next frameworks will be written about agents and toolchains. Thales announced the AI Security Fabric in December 2025, with an MCP security gateway and runtime access control for agentic AI interactions on the 2026 roadmap. Our white paper, Beyond the LLM Top 10, maps that terrain.

The post The OWASP LLM Top 10 Was the Warm-Up: What Comes Next appeared first on Blog.

Every year, the security industry publishes benchmark reports built more or less the same way: pick a handful of common vulnerabilities, measure how often they show up, publish the percentages, and move on. We just finished our second year running one of those reports — and the most important thing we found wasn’t a percentage. It was a pattern hiding underneath all of them.

This is Imperva API Security’s 2026 Token & Authentication Risk Report: a year-over-year look at how organizations actually handle JSON Web Tokens (JWTs), Basic Authentication, and token lifecycles, based on real detection data — not survey answers — across 1,104 customer environments and 32,725 live API endpoints. Some of what we found is good news. Some of them should genuinely worry you. And one finding, buried in a few layers beneath the headline numbers, is the reason we think most organizations are fixing the wrong things first.

What We Measured, and Why It’s Worth Trusting

This is the second year of this benchmark, which matters more than it might seem. One year of data tells you what’s happening. Two years of consistent measurement tells you what’s changing — and change is where the real signal lives.

We tracked five risk categories, unchanged from last year’s methodology: whether JWTs contain sensitive data they shouldn’t, whether they’re signed with weak algorithms, whether they’re issued with excessively long lifespans, whether Basic Authentication with raw credentials is still in use, and whether tokens keep granting access after they should have expired. Every number below is a share of real detections, not a projection.

The post Imperva API Security Token & Authentication Risk Report: Nearly 40% of APIs Face Multiple Authentication Risks appeared first on Blog.

Download the 2026 Token & Authentication Risk Report →

This post covers the headline findings. The full 2026 Token & Authentication Risk Report includes the complete year-over-year breakdown across all five categories, the reasoning behind each shift, and specific, practical recommendations for where security and engineering teams should focus first.

Get the Full Report

If there’s one thing worth taking from this report, it’s this: the next time your team finds one authentication issue on an endpoint, the right instinct isn’t relief that you caught it. It’s to ask what else is sitting there next to it — because in nearly 40% of the cases we looked at, the answer was something.

We think that’s the real story in this year’s data. The industry has gotten reasonably good at fixing the authentication problems that are legible — the ones a checklist can catch, the ones a single well-publicized recommendation can meaningfully move. It hasn’t gotten meaningfully better at the problems that require understanding how a system was actually built, which is exactly the category the two worsening risks, and the clustering pattern connecting them, fall into. A scanner can tell you a token is signed with a weak algorithm. It’s much worse at telling you that the same token is also carrying a customer’s date of birth.

“Did we pick a strong signing algorithm” is a yes-or-no question a scanner can answer in seconds. “What data did we decide to put inside this token, and did anyone revisit that decision when a new field got added eighteen months later” is not. “Are we still using Basic Auth” shows up on nearly every audit checklist in the industry. “Does every service that validates this token independently re-check its expiration or does one of them just trust the gateway” usually doesn’t, because answering it requires understanding how a system actually behaves, not just which protocol it uses.

Here’s the uncomfortable pattern sitting underneath all of the numbers above: the risks that improved this year are the ones that are easy to check. The risks that got worse are the ones that are hard to check. That’s not a coincidence — it’s a fairly accurate description of how security improvement actually happens inside most organizations.

What This Means for How We Approach Authentication

That’s the pattern that should reframe how this whole report gets read. If these risks were scattered at random, an endpoint like that would be a statistical fluke. Instead, the pattern repeats across nearly 40% of everything we measured. That’s not scattered. That’s systemic — and it means the standard response to finding one authentication issue, patching it and closing the ticket, is very likely leaving a second or third issue sitting untouched on the exact same endpoint.

At the extreme end, it’s worse than pairing. The single riskiest endpoint we found carried all five risk types at once: sensitive data in the token, a weak signing algorithm, an excessively long lifetime, Basic Authentication, and continued access after expiry. Endpoints like that usually aren’t the result of five separate, unrelated mistakes. More often, they’re a single legacy or lightly-used endpoint that never got touched when the rest of the environment moved to better practices — quietly running on old assumptions while everything around it improved.

Picture what that looks like in practice. An endpoint that embeds sensitive data inside its tokens — a risk present in essentially half of all detections — sitting on the same endpoint as an expired-token gap that lets access continue indefinitely, a risk that grew 70% this year. We can’t say how often that exact pairing occurs; our data tells us endpoints carry multiple risks, not which specific risks pair together most often. But it’s exactly the kind of compounding scenario nearly 40% of endpoints are positioned for — a token that doesn’t just leak once, but keeps leaking, because nothing in the system ever cuts it off.

We went endpoint by endpoint and asked a specific question — how often do these five risks appear together, on the same API, at the same time? The answer: 13,016 of the 32,725 endpoints we analyzed, nearly 40%, carried more than one authentication risk simultaneously. Not an edge case. Not occasional. Roughly two out of every five.

Here’s what we didn’t expect going in: authentication risk doesn’t usually show up alone.

The Finding That Changes the Story

We can’t say with certainty why either number moved the way it did — a mix of factors is plausible, including genuine changes in practice, improvements in our own detection, and shifts in which organizations were measured each year. What we can say is that the direction, for both, is the wrong one, two years running.

Expired-token access jumped from 5.0% to 8.5% — a 70% relative increase, the sharpest move of any category we track, in either direction. This one is arguably more alarming precisely because it’s the more mechanical risk to get right. Deciding what counts as “sensitive” involves judgment. Enforcing that a token stops working after its exp claim has passed does not. When it fails anyway, it’s usually because expiration was checked in one place — a central auth service — and never independently re-verified everywhere else the token gets used. Every other assumption a security team makes about tokens rests on expiration being the backstop. When that backstop doesn’t hold, everything built on top of it gets quietly weaker too.

Sensitive data inside tokens climbed to 49.8% of all detections, up from 46.0% last year — already the largest risk category in the study, now touching essentially half of everything we measured. That number deserves more alarm than it might get on first read: a JWT isn’t encrypted by default. It’s typically just base64-encoded, which is not the same thing — anyone who can see the token can read what’s inside it; no exploit required. A JWT doesn’t need to be “hacked” to leak data. It just needs to pass through an ordinary place in a modern stack: a log line capturing request headers, browser storage on a shared machine, a support ticket where a developer pastes a request for debugging. If the token carries a name, an email, an account number, every one of those mundane, everyday paths becomes a potential exposure event.

The two risk categories that got worse this year aren’t the ones with a tidy, well-known fix. They live in implementation details, and, not coincidentally, they’re the two with the most direct line to actual data exposure.

That’s a genuine win worth taking seriously. It’s also, as it turns out, the easy part.

These three have something in common: each map to a specific, well-publicized fix. Use a stronger algorithm. Migrate to OAuth2 or mTLS. Shorten your token lifetimes. None of that is a secret, and the data suggests teams that heard the advice actually acted on it.

Three of the five risks have improved. Weak signing algorithms dropped from 19.0% to 15.2% of detections — a 20% relative decline, the sharpest improvement in the study. Basic Authentication with raw credentials fell from 9.0% to 7.3%. Long-lived tokens eased slightly, from 21.0% to 19.2%.

You cannot verify a vendor’s security claims from their own datasheet, including ours. That is why independent validation matters. In our recent guide to the best WAAP solutions (Best WAAP Solutions 2026: Enterprise Buyer Guide), we argued that every serious shortlist should include independent third-party testing across both web and API threats. SecureIQ Lab’s Cloud WAAP v5.0 CyberRisk Validation, published this week, delivers exactly that: twelve leading cloud WAAP platforms, 1,608 attack scenarios, and 1,487 false-positive traps, all run under identical, adversarial conditions, with every vendor’s results published in full.

This blog is the follow up to that buyer guide and explains what the new report says and how to read any benchmark.

Balancing security efficacy and false positives

A high security-efficacy score, on its own, is easy. Tune any WAF aggressively enough and it will stop every attack, along with a meaningful share of your customers. That is the trap: security efficacy and false positives pull against each other, and false positives are never a rounding error.

Every legitimate transaction blocked is lost revenue, an abandoned cart, a support ticket, a SOC triage, another tuning cycle, and operational cost on top of the license. At scale, teams respond to false-positive pain by loosening policies or dropping rules into detect-only mode. The efficacy number you thought you were buying quietly disappears in production.

The genuinely hard engineering problem, the one that determines your real protection and your real total cost of ownership, is holding maximum efficacy and near-zero false positives at the same time.

That is the equation to grade this report on. Imperva WAF and API Security was placed in the Leader category with a perfect 100% Complete Security Score, the only perfect score of the twelve vendors, across every tested category: all OWASP web test cases, all ten OWASP API categories on all five protocols, every bot, AI-assisted bot, and Layer 7 DoS scenario, every evasion vector, and the full vulnerability assessment.

Against 1,452 legitimate-transaction test cases mixed into live traffic, Imperva achieved that balance of maximum efficacy and zero false positives. No other vendor in the field held a perfect score on both sides of the equation. This evaluation validated protection you do not have to trade away to keep your customers moving.

API security matters: Imperva scored 20% above average

Most vendors now score well on classic web attacks. The OWASP WAF group average was 89.96%, and five vendors scored 99.5% or better. APIs are a different story. Across the OWASP API Security Top 10, tested over five protocols, published scores ranged from 45.5% to 100%, around a group average of 80.3%.

Imperva scored 100% on every API category and every protocol tested, including WebSockets, where the twelve-vendor group averaged just 48%. If your evaluation shortlist is driven by web-attack demos, the API results are where you should spend more time. That was one of the main recommendations in the WAAP buyer guide, and the new numbers reinforce it.

New in 5.0: AI security and compliance

The 5.0 methodology adds AI application security: 35 attack scenarios aligned with OWASP LLM01 (Prompt Injection) and LLM05 (Improper Output Handling), scored independently of the headline results. Here is the honest reading: nine of the twelve vendors, Imperva included, scored 100% on that attack set. Runtime LLM attack-blocking is already table stakes.

Where the field separates is operating AI protection at enterprise scale. SecureIQ Lab’s GenAI & LLM Operational Efficiency rating looks at the ability to deploy, govern, and observe AI protections in production. Scores ranged from 0% to 100%, around a 73% group average. Imperva was one of five vendors rated 100%.

The second new dimension is compliance. SecureIQ Lab ran a five-layer assessment across regulatory, data-protection, audit, governance, and AI frameworks (NIST, ISO/IEC 27001 and 42001, PCI DSS, GDPR, HIPAA, and more). Imperva’s 87% was the highest score of all twelve vendors, against a 63.95% group average, including 100% on the AI security layer.

If your security purchases have to survive an audit committee, which is true for most enterprises, this is the part of the report to share with your GRC team.

In summary:

• 100% OWASP LLM score: Imperva blocked all tested LLM01 and LLM05 attack scenarios.
• Zero LLM false positives: legitimate AI interactions in the LLM test set were not blocked.
• 100% GenAI & LLM Operational Efficiency: Imperva scored 100% versus a 73% group average.
• Operational readiness matters: the rating reflects capabilities such as vulnerability coverage, sensitive data protection, full-stack LLM observability, SDK-based guardrail integration, and system-prompt-based context guardrails.

AI protection cannot stop at attack blocking. As organizations bring LLM-backed applications into production, they also need visibility, guardrails, integration, and governance that teams can operate day to day.

Imperva’s AI results show both sides of that equation: tested protection against key LLM threats and validated operational readiness to help enterprises adopt AI more securely and manageably.

WAAP Operational Efficiency in Real Life

Operational efficiency determines how practical a WAAP will be for real-world application teams.

In the SecureIQ Lab Cloud WAAP 5.0 validation, Imperva achieved a 98.8% WAAP Operational Efficiency rating, outperforming the 94.1% group average while also delivering perfect security efficacy and 100% false positive avoidance.

That combination matters because modern security teams are not only judged by whether they stop attacks, but by whether they can do so without slowing deployments, creating unnecessary tuning work, or interrupting legitimate business traffic.

The nine operational security categories tested were:

1. Ease of deployment
2. Ease of management
3. Ease of risk management
4. Logging & auditing capabilities
5. Visibility & analytics
6. Support & documentation
7. API Gateway efficiency
8. Integration capabilities
9. Geolocation based security features

Imperva scored 98.8% against a 94.1% group average, with perfect scores in every category except API Gateway Efficiency (94.4%), where JWT validation has been identified as an improvement opportunity.

The operational results show strength across the day-to-day capabilities that determine whether a WAAP can be run confidently at an enterprise scale.

Imperva was rated 100% in ease of deployment, ease of management, ease of risk management, logging and auditing, visibility and analytics, support and documentation, integration capabilities, and geolocation-based security features.

These categories translate directly into practitioner outcomes: faster setup, simpler policy reuse, stronger role and user management, clearer threat analytics, easier SIEM and SOAR integration, more flexible logging, and better tools for reducing false-positive risk.

The only operational category below 100% was API Gateway Efficiency, where Imperva scored 94.4% against a roughly 95% group average, with JWT validation identified as an area for improvement.

The takeaway for buyers: operational efficiency is not a secondary metric. A WAAP that is difficult to deploy, difficult to tune, or noisy in production becomes an operational burden even if its detection rates look strong.

Imperva’s results show that protection can be both highly effective and highly manageable — giving security, application, and platform teams independent validation that they can strengthen defenses without adding unnecessary friction to the business.

In summary: Four rules for reading any WAAP benchmark

• Read efficacy and false positives as one result, not two separate ones. A perfect block rate with a high false-positive rate does not deliver security. That combination is an outage generator with a dashboard, and its real-world efficacy will be tuned away within a quarter.
• Go to the API results before the web results. Web scores tend to cluster near the top across the industry; API scores are where architecture differences show up.
• Check which deployment model was tested. A SaaS cloud service and a self-managed virtual appliance are different operational propositions; the report calls out the model for each vendor.
• Ask every shortlisted vendor for their current published results, and for the categories where they did not lead. A vendor who cannot name one has not read their own report or needs to check their points.

The full report and methodology are public.

If you are still shaping a shortlist or building evaluation criteria, go back to the earlier Best WAAP solutions blog, Best WAAP Solutions 2026: Enterprise Buyer Guide. It is a practical playbook for what to look for in WAAP architecture, operations, and economics. SecureIQ Lab’s Cloud WAAP 5.0 results now give you independently validated numbers to plug into that playbook.

Source for all figures: SecureIQ Lab Cloud WAAP CyberRisk Validation v5.0, 2026 (AMTSO-certified). Placements and competitor scores from the published comparative report.

The post What SecureIQLab Cloud WAAP 5.0 means for your application security appeared first on Blog.

This is Post 2 of a three-part series. Start with Post 1: Agentic AI Security: The Chatbot Era Is Over, then continue to Post 3: OWASP LLM Top 10: What Comes Next – Agentic & MCP.

There is a moment every CISO is having right now, often without warning. A developer shows a working internal demo of an AI assistant trained on the company’s own documents. The product team is already planning a customer-facing version. The board has signed off on the budget. And somewhere in the middle of the meeting, a quiet question lands: what is securing this?

The honest answer, for most organizations today, is “nothing your existing stack was designed to do.”

This is not a critique of the security tools enterprises have spent years deploying. WAFs, EDRs, network firewalls, API gateways, identity platforms; these have evolved into a layered defense that genuinely works against the threats they were built for. But GenAI applications introduce a new attack surface that operates outside the boundary every one of those tools defends.

The problem is not that AI threats are more dangerous than traditional threats. The problem is that they are categorically different.

What is generative AI security?

Generative AI security is the practice of protecting LLM- and GenAI-powered applications at the AI interaction layer: the prompts going in, the model responses coming out, the conversation context in between, and the data and tools the model can reach. It is distinct from traditional application security because the attack payload is natural language, not a malformed request.

Why the old security playbook doesn’t cover generative AI?

Traditional security tools all share a common assumption: attacks come in the form of malformed inputs, malicious payloads, suspicious traffic patterns, or unauthorized access attempts. A WAF inspects HTTP headers, query strings, and request bodies for known patterns. An EDR watches for binaries behaving badly. An API gateway enforces schema and authentication.

An LLM-based application turns all of those assumptions on their head.

The payload in a prompt injection attack is grammatically correct English. The malicious code in a data leakage attack is a polite question. The denial of service pattern in an unbounded consumption attack is a perfectly legitimate looking conversation. The threats that matter to a GenAI application live at the level of the model’s logic, not at the level of the network or the HTTP request.

Even more critically, the security tools that protect the application surrounding the model have no visibility into what happens at the interface. The WAF sees the request to your AI endpoint. It does not see what the model does with that request. The API gateway authenticates the user. It does not understand whether the user is trying to convince the model to reveal its system prompt.

This is the gap that has emerged across enterprise security architectures over the last 18 months. It is not a minor blind spot. It is a category-level gap. Traditional security tools do not speak AI.

What AI-native security actually means?

When we talk about AI-native security at Imperva, we are not talking about adding AI features to a traditional security product. We are talking about a purpose-built control plane that understands prompts, model responses, conversation context, and usage patterns the way our WAF understands HTTP.

That distinction matters because AI security has to inspect the interaction itself. It has to understand what the user is asking for, how the model is likely to respond, whether sensitive data is being exposed, whether instructions are being manipulated, and whether usage patterns suggest abuse. This is inspection at the AI interaction layer rather than the network layer.

Thales’s Imperva AI Application Security is engineered specifically for the architecture of AI and agentic applications. It sits between your applications and the models they call, giving teams flexible deployment options rather than forcing a single architecture. Every input and every output is analyzed in real time, against multiple security guardrails, with adaptive risk scoring that distinguishes legitimate use from manipulation attempts.

Concretely, it addresses five of the OWASP Top 10 LLM threats:

• Prompt injection and jailbreaking attempts
• Sensitive information disclosure through model outputs
• System prompt leakage
• Improper output handling
• Unbounded consumption attacks that drive cost runaway and denial of service

And critically, it does not replace your existing WAAP. It extends it. AI Application Security plugs into the same unified Imperva platform that handles your WAF, API security, bot management, and DDoS protection. The same console, the same policy model, the same role-based access controls

The AI threat surface becomes one more dimension of the security posture your team already manages, rather than a new tool, a new vendor, and a new operational silo.

What generative AI security means for the next 12 months?

According to McKinsey’s State of AI survey (November 2025), 88% of organizations now use AI in at least one business function, up from 78% a year earlier. And in the 2026 Thales Data Threat Report, 61% of organizations named AI as their top data security risk, while the share carrying a dedicated AI security budget rose from 20% to 30%. As organizations move from simple chat experiences toward autonomous agents capable of taking actions, the need for AI-specific security controls becomes even more critical. The teams that get this right will not be the ones who deploy more security tools. They will be the ones who recognize that AI applications are a new class of asset and treat them with a control layer designed for what they actually are.

A WAF was the answer when applications moved from desktop to web. An API gateway was the answer when monoliths gave way to microservices. An AI Application Security layer is the answer for applications that no longer execute only predictable code, but interpret, generate, and increasingly act on language.

That is the new kind of security your AI deserves.

Frequently asked questions about generative AI security

What is the difference between AI security and generative AI security?

AI security is the broad category, covering everything from model theft to training-data poisoning. Generative AI security is the runtime subset: protecting live LLM and agentic applications from prompt injection, sensitive data disclosure, system prompt leakage, improper output handling and unbounded consumption.

Can a WAF stop prompt injection?

No. A WAF inspects HTTP headers, query strings and request bodies for known malicious patterns. A prompt injection payload is grammatically valid English inside a legitimate request, so it passes every WAF check. Stopping it requires inspection at the AI interaction layer, which is what an AI application security layer adds alongside the WAF.

Do I need to replace my existing security stack to secure AI?

No. AI application security extends the stack rather than replacing it. Imperva AI Application Security plugs into the same platform as the WAF, API security, bot management and DDoS protection, using the same console, policy model and role-based access controls.

Which OWASP LLM Top 10 risks does Imperva AI Application Security address?

Five of the ten out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling, and unbounded consumption.

Is generative AI security different for AI agents?

Yes. Agents take actions rather than only returning text, so a successful manipulation becomes an operational incident rather than a bad answer. See the companion post on agentic AI security below.

Read more in our white paper: Beyond the LLM Top 10.

Ready to see what AI-native security looks like in practice? Talk to your Thales representative or visit imperva.com to explore AI Application Security.

The post Why Generative AI Needs a New Kind of Security appeared first on Blog.

Short version: an MCP server is the tooling layer that lets an AI agent act on external systems. Hosted remotely, it is an API endpoint like any other — and it needs bot and WAF controls in front of it, API security on its own endpoints, and AI guardrails that inspect what the tools send back, not just what the user types in.

Not since the dot-com boom in the late 1990s has the world seen a more highly talked-about and sought-after tech revolution. Artificial Intelligence has entered every aspect of our lives – from building large scalable applications to your Monday morning Macchiato.

With this spread of wildly varying use cases, one thing became abundantly clear. Large Language Models have isolated context, which is limited to the training data and the inputs provided by a user. To expand this knowledge, we need to provide AI Agents with appropriate tooling to retrieve such information. A curl tool to view a webpage, a directory listing tool to retrieve files from a folder, or a git CLI tool to commit changes to a repo.

Humans need tools as well. We don’t sift through HTML code, read JSON responses or query API endpoints via the command line. Rather we rely on well-thought-out and structured UX components – icons, text fields, buttons, and checkboxes – all of which are wired into various functions and APIs in the backend.

AI Agents, however? They rely on different types of tools. Given that every single one of the billions of websites and applications on the Internet today works and operates differently, these tools need to cater to them. Sites have been built on everything ranging from PHP and ASP to Node and Express. The question becomes – how can I ensure my agent reliably interacts with each of these sites? You could argue that these days, most applications expose a lot of their functionality via APIs. And you would be right. While AI Agents can easily consume these APIs, it involves a few different steps –

• read the API reference documentation
• build a small handler to call this API, with appropriate context
• build a small handler to parse the response

All these steps, every single time. Every site, every application, requiring its own “code” built by the AI Agent. With limited context windows and larger thinking models, this can get out of hand quickly – both in terms of token count and time taken – for every single user prompt.

What is an MCP Server?

Enter the MCP Server. An MCP server is a standardized service that exposes a defined set of tools, resources and prompts to an AI agent over the Model Context Protocol, so the agent can act on an external system without hand-written glue code for every API. Developed by Anthropic, the Model Context Protocol was built as an open-source standard for connecting AI Applications to external systems. It was released in November 2024 and contributed to the Linux Foundation’s Agentic AI Foundation in December 2025; by that point more than 10,000 MCP servers had been published. In essence, providing the AI Agent the right tools and resources, for each of these applications, to help abstract away the complexity of each of these interactions. Think of it as a USB-C port for your AI Agent – one connector, and every application on the other side just works!
What can MCP Servers allow your agent to do? The use cases are endless and constantly expanding every day – from searching and booking flights to reviewing stock prices and executing trades (this is not financial advice!). MCP Servers give your AI Agent the tools it needs to do more than just be your information chatbot.

MCP Server Security Risks: Where the Exposure Actually Is

But all this functionality exposes a glaringly obvious security blind spot. Who is protecting your MCP Server, which now has tools exposed to action any of these tasks? Who is governing what can be asked of your AI Agent which now has access to these tools? The security implications are massive.
This is not theoretical. Imperva’s threat research team documented a critical remote code execution flaw (CVE-2025-53967) in the widely used Framelink Figma MCP server — an open-source project with more than 10,000 GitHub stars — and OWASP’s Gen AI Security Project published A Practical Guide for Secure MCP Server Development in February 2026 because the same weaknesses keep recurring. The MCP specification’s own security guidance now names token passthrough, session hijacking, the confused deputy problem and SSRF as first-class MCP risks.

Local vs. remote MCP servers: two different risk profiles

Now, not every MCP Server carries the same exposure. Plenty of them run locally – a process on your laptop, talking to your agent over stdio, never touching a network. The risk there is real, but it’s a different conversation: credentials sitting in a config file, and how much that server is allowed to reach on your behalf. The moment an MCP Server goes remote though – hosted, over HTTP, serving agents across the Internet – it stops being a local utility and becomes what it always really was underneath: an API endpoint. Exposed, authenticated, and waiting to be probed. That’s the one you can put controls in front of.
This is where Thales’s focus has been for the past several months. For decades, Thales Imperva has been at the forefront of securing sites and applications, and with the evolution of applications and their users, we’ve enabled our solutions to cover these use cases and the complex threat landscape.

Automated traffic is the baseline condition here, not the exception. Imperva’s 2026 Bad Bot Report found that bots accounted for more than 53% of all web traffic in 2025, up from 51% the year before — and that 27% of bot attacks targeted API endpoints. A remote MCP server is an API endpoint, so it inherits that traffic profile the moment it goes live. Knowing which AI bots to allow and which to block is the first control, not the last.
The Thales Imperva Cloud WAF and Advanced Bot Protection provide visibility into automated traffic heading towards the MCP Server, preventing generally malicious bot traffic and more exploitative OWASP Top 10 attack classes like command injection and SQL injection.

Thales Imperva API Security ensures your MCP Server has its own endpoints secured against everything from simple schema exploitation to complex business logic attacks. (For the wider picture of agents as API consumers, see API security for AI agents.)
Finally, our AI Application Security puts in place guardrails that sit between the AI Agent and the model behind it, securing the workflow against LLM-specific attacks like prompt injection, system prompt leakage and jailbreak attempts. And critically for MCP – it inspects what comes back from the tools, not just what goes in. Today, most people worry about user prompts. Far fewer are watching the tool response. Because an instruction buried in a log entry or an incident description can quietly make its way into your Agent’s context and get read as a command rather than data. Your MCP Server is a perfect delivery mechanism for exactly that.

Thales Imperva MCP Server for Cloud WAF

At Thales, we have also been working on our own MCP Server behind the scenes.

What does this mean for you? Imagine a world where you no longer have to log into a console to analyze where last week’s attack traffic came from. No more manually putting together a monthly executive presentation on the state of your security posture.

The Thales Imperva MCP Server for Cloud WAF is in beta today, and for now, it’s read-only by design. Your agent can query, analyze and report across your estate. Need to see which sites have your “Block requests from South Africa” ACL policy enabled? Or what security rules are enabled for your production site? Just ask your Agent! No prior knowledge strictly necessary.

It’s open source and available on GitHub – pull the container, add your API credentials, and point your agent at it.

Having trouble remembering regex for your custom rules? Or finding yourself constantly making individual site changes? Tell us! Beta feedback is what shapes where this goes.

Frequently asked questions about MCP server security

What is MCP server security?
MCP server security is the set of controls that protect a Model Context Protocol server — and the AI agent calling it — from abuse. Because a remote MCP server is an authenticated HTTP endpoint that exposes tools capable of real actions, it needs the same protections as any production API, plus AI-specific guardrails on the prompts and tool responses flowing through it.

What are the main MCP server security risks?
The recurring ones are prompt injection delivered through tool responses rather than user input, tool poisoning, over-broad OAuth scopes and token passthrough, session hijacking, SSRF during metadata discovery, the confused deputy problem in MCP proxy servers, and ordinary application flaws such as the command-injection RCE found in the Framelink Figma MCP server. Excessive tool permissions amplify all of them.

Are local MCP servers safer than remote ones?
They carry a different risk profile, not a smaller one. A local MCP server talking to the agent over stdio never touches the network, so the exposure is credentials in a config file and how far that server can reach on your behalf. A remote MCP server served over HTTP is Internet-facing, which makes it probeable — and also makes it something you can put network and API controls in front of.

Can a WAF protect an MCP server?
Yes, for the endpoint layer. Once an MCP server is remote it is an HTTP API, so a WAF and bot protection stop automated probing and injection-class attacks before they reach it, and API security covers schema abuse and business-logic attacks on its endpoints. What a WAF cannot do alone is judge intent inside the model workflow — that needs AI guardrails inspecting prompts and tool responses.

What are MCP server security best practices?
Treat the server as a production API: authenticate every inbound request and never accept tokens that were not issued for your server, use least-privilege scopes and non-deterministic session IDs bound to the user, validate and allowlist outbound URLs, start read-only before enabling write operations, log every tool call, and inspect tool responses as untrusted input. OWASP’s secure MCP development guide and the MCP specification’s security best practices are the reference baselines.

Secure your MCP server with Thales Imperva

MCP is now an open standard under the Linux Foundation, and the number of exposed servers is only going up. The controls are the ones you already know — web application and API protection in front of the endpoint, API security on its schemas and business logic, and AI application security on the prompts and tool responses moving through it. See how Thales Imperva secures applications and APIs, and try the read-only Cloud WAF MCP Server beta on GitHub.

The post MCP Server Security: The Blind Spot in Your AI Stack appeared first on Blog.

Many Australian businesses have moved their applications and data to cloud-native architectures for agility, scalability, and sovereignty. However, this move extends their attack surface beyond their typical security boundaries.

As evidenced by the Thales 2026 Data Threat Report, attackers increasingly target web applications and APIs with sophisticated methods that outpace the traditional protection built into cloud platforms. Security teams face intense pressure to deliver control and risk reduction, but this mandate creates frustration with DevOps teams, who push for speed and scale while leveraging the benefits of cloud-native tools.

The gap is best addressed by bringing the Thales enterprise-grade Imperva Web Application and API Protection (WAAP) solution directly into Australia’s Google Cloud infrastructure through a native integration. For Australian organisations running critical workloads in Google Cloud, this creates some important opportunities.

Data Sovereignty Is No Longer Just A Compliance Discussion

Organisations need confidence in where their data is stored, how it is processed, and who can access it.
For operators of critical infrastructure, the data itself is strategically significant. Data such ass traffic patterns, transaction flows, and operational telemetry from energy, financial, and health systems can reveal how essential services function, where dependencies lie, and how disruptions might be engineered. Losing visibility and control over where that data is processed and who can access it is a different order of risk. For businesses subject to SOCI Act, APRA CPS 234, or other government security mandates, controlling where data is stored and how it travels is essential for complying with Australian data sovereignty requirements.

Performance Matters When Security Becomes Part Of The Application Path

Security controls should not become a performance bottleneck. The conflict is tangible

While security teams want to ensure applications and APIs are protected with consistent security controls, visibility, compliance, and governance, DevSecOps teams want security that can be deployed quickly and integrated seamlessly into existing development workflows without creating operational overhead or slowing down application delivery.

This is one of the key reasons many organisations are showing strong interest in CI/CD-based onboarding models. Security teams prefer having the ability to deploy security controls without changing DNS records, modifying application architectures, or handing operational control of applications to another team or third-party provider.

Applications And APIs Have Become Primary Targets

A focus on websites is no longer enough for modern applications, as they depend on APIs, automation, third-party services, and machine-to-machine interactions that happen out of view of conventional monitoring. The threat actors understand this dependency and focus on the interfaces that run today’s digital services.

That is why WAAP has become such an important security category. Organisations need protection that addresses web application attacks, API abuse, automated bot activity, and Layer 7 denial-of-service attacks within a single security approach.

Imperva for Google Cloud delivers the same Imperva capabilities available through the broader cloud service, including Web Application Firewall (WAF) for cloud applications, API security, bot management, Layer 7 DDoS protection, and threat intelligence informed by global attack activity.

This is not a pared-down instance; Imperva for Google Cloud delivers the full WAAP stack locally, feature-for-feature, with the global service.

Built For Google Cloud Environments

Pressure on security teams to cut complexity is high. According to the Thales 2026 Data Threat Report, companies use 7 distinct data protection and monitoring solutions, yet visibility, staffing, and complexity remain major concerns for security teams.

As Imperva WAAP now operates within Google Cloud Australia, it makes perfect sense for solutions such as Google Cloud Load Balancing, Google Kubernetes Engine (GKE), Compute Engine, and other networking tools to work together with API security.

For cloud and platform teams, security can be deployed alongside applications rather than treated as a separate environment that requires its own operational model.

Security That Scales With Cloud Native Workloads

One of the reasons organisations move to cloud platforms is the ability to scale up or down. Security infrastructure should be able to do the same.

Regardless of whether a business is dealing with seasonal demand challenges, big public-facing platforms, high-volume APIs, or expanding digital services, the security layer must evolve with the applications and not require continuous redesign.

As more Australian organisations build cloud-native services, that expectation will become standard.
Organisations increasingly want security controls that operate where their applications operate. For businesses building on Google Cloud, keeping workloads within Australia is becoming a practical architectural decision rather than a future aspiration. By unifying Imperva’s proven application security leadership with Google Cloud’s high-performance infrastructure, organisations can eliminate the need to compromise between security and speed.

Get in contact with the local team and see how Imperva WAAP works in Google Cloud Australia.

The post Google Australia Customers Now Benefit From Imperva Cloud-Native WAAP Security appeared first on Blog.

How Thales is bringing active API protection to self-managed environments, without compromising digital sovereignty.

APIs Changed Faster Than Security Architectures

Organizations have invested heavily in discovering APIs, classifying sensitive data, and understanding API risk. That’s progress.

But visibility alone doesn’t stop attacks.

Attackers don’t wait for analysts to review dashboards. They exploit broken authorization, enumerate objects, abuse business logic, and exfiltrate data in minutes.

Knowing an attack happened is useful.

Stopping it is what matters.

How Has Sovereignty Introduced a New Challenge?

For organizations operating in finance, government, healthcare, defense, and critical infrastructure, API security has always carried another requirement.

Data cannot leave the environment.

API payloads often contain customer records, financial information, healthcare data, or classified information. Regulations and increasingly internal governance policies require that this information stays under organizational control.

That’s why many organizations choose self-managed API security.

Not because they dislike cloud. Because they cannot compromise sovereignty.

Digital sovereignty means retaining control over where sensitive data is processed, where security decisions are made, and who ultimately governs the infrastructure, protecting critical services.

That’s why Thales’s Self-Managed Imperva API Security was built, to give organizations the flexibility to deploy API security wherever their business, operational, or regulatory requirements demand, while keeping sensitive inspection and enforcement under their control.

Yet sovereignty has historically introduced an unintended compromise.

The Missing Piece: Detection Without Enforcement

Historically, this created an operational gap.

Security teams could discover APIs.

They could identify risky endpoints.

They could detect sophisticated attacks such as Broken Object Level Authorization (BOLA), one of the most critical risks identified in the OWASP API Security Top 10.

But detection alone doesn’t interrupt an attack.

When enforcement exists outside the API security workflow, response becomes another investigation, another ticket, another operational handoff. Every delay gives attackers more time to exploit vulnerable APIs and access sensitive information.

Security teams weren’t lacking visibility.

They were lacking immediate action.

For organizations operating entirely within sovereign environments, this challenge was even greater. Protecting sensitive data meant keeping security operations local—but that shouldn’t mean sacrificing the ability to actively stop attacks.

Modern security should never force organizations to choose between operational control and effective protection.

This isn’t simply feature parity. It’s an architectural parity.

Detection and enforcement can now operate together where the data already resides.

Closing the Last Mile of Sovereign API Security

Today, that trade-off disappeared.

With the latest enhancement to Thales’ Self-Managed Imperva API Security, organizations can now extend active API enforcement into self-managed deployments while maintaining complete control over where inspection, detection, and enforcement take place.

This is more than a new capability.

It represents an important step toward a sovereign-by-design security architecture—one where security adapts to the customer’s operational model instead of requiring the customer to adapt to the security platform.

Organizations no longer have to choose between maintaining sovereign control over sensitive API traffic and deploying modern API protection capable of responding to attacks in real time.

Detection and enforcement now work together, exactly where the data already resides.

One Protection Model. Any Deployment.

Modern enterprises rarely operate in a single environment.

Applications span public cloud, private cloud, Kubernetes clusters, on-premises data centers, and increasingly hybrid infrastructures.

Security shouldn’t become fragmented simply because deployments are.

Whether organizations deploy Imperva API Security through a cloud-managed service or a self-managed environment, they should expect the same security intelligence, consistent policy model, and comparable protection outcomes.

The deployment model changes.

The protection model doesn’t.

For organizations embracing digital sovereignty, that’s an important distinction. They can adopt the architecture that best aligns with their regulatory obligations and operational requirements while maintaining a consistent security posture across every environment.

Digital Sovereignty Requires Security That Adapts

The future of cybersecurity isn’t simply about moving more workloads to the cloud.

It’s about giving organizations the freedom to choose where their data lives, where security operates, and how trust is established.

That is the essence of digital sovereignty.

Modern security platforms must deliver the same level of protection regardless of deployment model, enabling organizations to protect critical assets without compromising regulatory compliance, operational resilience, or customer trust.

API security should be no exception.

With Self-Managed Imperva API Security enforcement, organizations can now:

• Detect and stop critical API threats such as BOLA within the same sovereign environment.
• Maintain complete control over sensitive API traffic and enforcement policies.
• Apply a consistent protection model across cloud, hybrid, and self-managed deployments.
• Reduce operational complexity while strengthening resilience against modern API threats.

The Future Is Sovereign by Design

Digital sovereignty is no longer simply a regulatory discussion.

It’s becoming a defining principle of modern cybersecurity architecture.

As organizations continue to modernize applications, embrace AI, and expand digital services, they need security platforms that protect innovation without requiring sensitive data to leave their control.

That’s the direction Thales has long championed: security that enables trust, resilience, and customer choice.

The latest Self-Managed Imperva API Security enhancement is another step toward that vision, bringing active API protection to organizations that require complete operational control, without compromising the security outcomes they expect.

Because the future of API security won’t be defined by where it runs.

It will be defined by where trust resides.

And increasingly, trust begins with keeping control of exactly where it belongs.

Download this guide to discover how Imperva protects production APIs without compromising data sovereignty.

The post Closing the Sovereignty Gap: Bringing Active API Protection to Self-Managed Environments appeared first on Blog.

The internet is changing fast.

For years, the main goal of search was simple: to help users find links. A user searched, reviewed results, clicked a website, and consumed the content directly from the source.

But AI is changing that model. Increasingly, users ask AI assistants for answers instead of searching for websites. They seek summaries, recommendations, comparisons, troubleshooting advice and product guidance, often receiving a complete answer without ever visiting the original source site. This creates a new reality for website owners: your content may still influence the customer journey, even when the customer never reaches your website.

This shift is why AI bot traffic matters.

AI bots scan, fetch, and process web content so AI systems can answer questions, summarize pages, recommend vendors, and understand what your business does. Some of this traffic creates value. Some of it can create risk. The challenge is knowing the difference and building the right policy.

Quick answer: Not all AI bots should be treated the same. AI traffic falls into four main types: AI search bots that help your brand appear in AI answers, AI training bots that collect content to train models, AI fetch bots that retrieve a page on behalf of a user, and agentic AI systems that take actions such as logging in, querying inventory, or completing transactions. The right policy is not “allow all” or “block all”; it is to classify each AI bot, decide which to allow on which parts of your site, and inspect every request for malicious behavior. Imperva Advanced Bot Protection classifies AI traffic, while Imperva Web Application Firewall and DDoS Protection inspect and rate-limit it, so you stay visible to trusted AI while blocking abuse.

The new tension: visibility vs. protection

As the risk from AI-driven bots increases, many organizations are now facing a difficult question:

Should we allow AI bots to scan our website, or should we block them?

Blocking all AI bots may seem like the safest option, but it can also reduce your visibility in AI-generated experiences. If your public content is not accessible to the right AI systems, your brand may appear less often when users ask AI tools for recommendations or information.

On the other hand, allowing every AI bot creates business and security risks. AI bots may collect valuable content, increase traffic costs, overload servers, or access areas of the website that were never meant to be used by automated systems.

So, the right question is not “allow or block AI bots?”

The better question is:

Which AI bots should we allow, for what purpose, on which parts of the website, and under what protection?Not all AI bots are the same

The Rise of Agentic AI

The next wave of AI traffic will not come from crawlers alone. It will come from autonomous AI agents acting on behalf of users.

Agentic AI systems can browse websites, compare products, gather information, interact with APIs, complete forms, and execute multi-step workflows with limited human intervention.

Unlike traditional search crawlers, these agents actively interact with business logic. They can create accounts, query inventory, test workflows, retrieve pricing, and trigger application functions.

This creates a new challenge for security teams. The question is no longer simply whether an AI bot is legitimate. The question is whether the action being performed should be allowed.

As AI agents become more capable, organizations need controls that evaluate identity, intent, behavior, and access permissions simultaneously.

What Most Security Teams Cannot See

Imperva Advanced Bot Protection provides one of the industry’s most comprehensive AI traffic classification capabilities, enabling organizations to identify AI search bots, AI training bots, AI fetch bots, and emerging agentic AI systems. Security teams can then apply granular policies to allow, restrict, rate-limit, or block AI traffic based on business risk and application context.

As AI traffic becomes more diverse, organizations need visibility not only into which AI tools are accessing their applications, but also what those tools are doing, which business functions they are interacting with, and whether that activity aligns with organizational policy.

Effective control starts with understanding the different types of AI traffic and applying policies accordingly.

To create a good policy, you first need to understand the different types of AI bots.

1. AI search bots

AI search bots scan public websites so AI-powered search engines and answer engines can understand what content exists online.

These bots may help your business stay visible when users ask AI tools questions like “What is the best solution for…?” or “Which vendor supports…?”

You may want to allow these bots on public marketing pages, blogs, product pages, and documentation — especially content you want customers to discover.

2. AI training bots

Training bots collect public web content that may be used to train or improve AI models.

This is where the discussion becomes more nuanced. You may want your brand to appear in AI answers, but you may not want your full content, research, product information, or intellectual property used to train external models without control or compensation.

For many organizations, training bots require a stricter policy than search bots.

3. AI fetch bots

AI fetch bots usually act in response to a user request. For example, a user asks an AI assistant to summarize a specific URL, check a product page, or compare information from your site.

Because these requests are typically initiated on behalf of a user, they often represent legitimate business value. However, they can also be abused. An attacker may try to manipulate an AI assistant into sending suspicious payloads, scanning pages, or probing your application while hiding behind a legitimate AI fetcher.

That means fetch bots should not automatically be trusted. They should be allowed only with the same security inspection applied to any other request.

AI Is Not Only Changing Search. It Is Changing Attacks

AI is enabling attackers to create bots that learn from mitigation controls, adapt their tactics, and persistently probe applications in ways that were previously impractical at scale.

According to Imperva’s 2026 Bad Bot Report, the average number of AI-driven bot attacks has increased more than tenfold (12.5x) in 2025 compared to the previous year. This growth reflects a broader trend: the same technologies helping AI assistants understand websites can also help malicious actors understand application defenses, automate reconnaissance, and accelerate attack development.

Beyond increasing the scale and sophistication of bot attacks, AI is also lowering the barrier to entry for attackers. With the right prompts, common AI assistants can be weaponized to help identify weaknesses in web applications, generate attack payloads, automate vulnerability discovery, and assist with exploiting business logic flaws. While these tools have safeguards, they can still ramp up activities that traditionally required specialized security knowledge.

AI is also enabling attackers to coordinate large-scale campaigns more efficiently, combining reconnaissance, automation, and exploitation in ways that were previously more resource-intensive and time-consuming.

As a result, organizations must consider not only how AI systems access their applications, but also how AI may be used to automate, scale, and weaponize traditional web attacks.

What we see in real traffic

Thales’s threat research data shows that legitimate AI bots currently account for around 2% of total session traffic. The Bad Bot Report shows that within that AI bot traffic, 85% comes from AI crawlers and 15% comes from AI fetch bots. While AI traffic remains a relatively small proportion of overall web traffic today, its growth rate and increasing sophistication suggest it will become a much larger consideration for application owners over the coming years.

This matters because even legitimate AI bots can introduce operational, security, and business risks.

The main risks are:

Data scraping: AI bots may continuously collect proprietary content, product data, documentation, or intellectual property.

Unintentional overload:: AI bots can be aggressive. High-speed crawling may consume bandwidth, slow the application for real users, and increase infrastructure costs.

Abuse through AI fetch bots: because fetch bots act on user prompts, attackers may try to manipulate them into sending malicious requests or scanning for weaknesses while appearing to come from a legitimate AI source.

The good news is that classic application attacks from legitimate AI bots remain relatively low. Imperva’s findings show low levels of traditional attack vectors such as SQL injection, cross-site scripting, illegal resource access, backdoor attempts, and remote file inclusion. However, there are still real examples where AI fetch bots were manipulated into sending malicious payloads, including SQL injection-style input.

This is exactly why AI bot policy should never be based only on identity. Even a legitimate AI bot must still be inspected for malicious behavior.

Visibility Must Be Paired with Control

Visibility is only the first step. As AI traffic continues to grow, organizations need the ability to distinguish between beneficial AI activity and behavior that introduces operational, security, or business risk.

AI search bots, AI training bots, AI fetch bots, and agentic AI systems all require different treatment. The challenge is not simply identifying them. It is applying the right controls to the right AI traffic at the right time.

This is where advanced bot management becomes critical.

A safe AI bot policy should not be “allow everything”

In our blog, Why AI Bot Protection and Control are Essential for Application Security,  we said, “The ability to control which parts of your application functionality are accessible to AI tools is critical to your AI Security Strategy”.

The safest approach is a layered policy.

Start by separating the website into zones:

Public content you want AI systems to understand
Examples: blogs, product pages, public documentation, company information, support articles, and thought leadership.

Content you may want to restrict
Examples: premium content, customer-only portals, pricing logic, internal search, account pages, sensitive documentation, APIs, and dynamic application flows.

Content that should never be accessed by bots
Examples: admin paths, login actions, checkout abuse paths, personal data, private files, and application endpoints that can trigger expensive actions.

Then decide which AI bot categories should be allowed in each zone.

A practical policy could look like this:

Bot type	Recommended approach
AI search bots	Allow on public content where visibility matters
AI training bots	Review carefully; block or limit where IP protection matters
AI fetch bots	Allow only with full security inspection and rate controls
Unknown AI bots	Treat as suspicious until verified
Aggressive crawlers	Rate-limit or block if they impact performance

How Thales helps you stay visible and protected

The goal is not to trust or distrust AI traffic. The goal is to understand it, classify it, and apply the appropriate controls. Thales helps organizations strike the right balance between AI visibility and application security by combining Imperva Advanced Bot Protection, Imperva Web Application Firewall, and Imperva DDoS Protection. Thales offers customers a number of different options for managing AI bot traffic without choosing between full exposure and full blocking.

Firstly, Thales’ core security protections, delivered through Imperva Web Application Firewall, inspect the request itself. Rules for SQL injection, cross-site scripting, illegal resource access, backdoors, and remote file inclusion do not depend only on who the client claims to be. If an AI bot is manipulated into sending a malicious request, Imperva WAF can still block that request out of the box.

Secondly, Imperva DDoS protection helps reduce the risk of aggressive AI crawling overwhelming the application or creating performance issues. This is important because even legitimate AI bots can generate high request volumes.

Thirdly, customers can choose their own policy. If they want to allow a specific AI bot, using Imperva Advanced Bot Protection, they can create an exception based on the bot’s Client App ID. If they want to block a specific AI bot completely, they can add it to a bad bots list in the Imperva portal.

Most importantly, even when a specific AI bot is excluded from bot protection rules, malicious requests from that bot are still inspected by Imperva’s core security rules. In other words, allowing an AI bot for visibility does not mean you are leaving your application unprotected.

Frequently Asked Questions

Should you block all AI bots?

Not usually. Blocking every AI bot can reduce your visibility in AI-generated answers and recommendations, while allowing all of them exposes you to scraping, infrastructure overload, and abuse. The safer approach is to classify AI bots and allow them selectively, by website zone, with security inspection applied to every request.

What are the main types of AI bots?

There are four: AI search bots (so AI answer engines can understand your public content), AI training bots (which collect content to train AI models), AI fetch bots (which retrieve a specific page on behalf of a user), and agentic AI systems (which take actions such as logging in, querying inventory, or completing transactions).

What is agentic AI, and why is it a security risk?

Agentic AI systems act on behalf of users, browsing sites, filling forms, querying APIs, and running multi-step workflows with limited human input. Because they interact directly with business logic, the key question shifts from “is this bot legitimate?” to “should this action be allowed?”

How much web traffic comes from bots?

According to Imperva’s 2026 Bad Bot Report, automated traffic accounted for more than 53% of all web traffic in 2025. Legitimate AI bots are a small share of that today, around 2% of session traffic in Imperva’s threat-research data, but their volume and sophistication are growing quickly.

Can AI fetch bots be trusted?

Usually, but not blindly. Fetch bots typically act on a real user’s request, so they often carry legitimate business value. However, they can be manipulated into sending malicious payloads, so they should be allowed only with the same security inspection applied to any other request.

To learn more visit https://www.imperva.com/products/ai-application-security/

The post AI Agents Are Visiting Your Website. Which Ones Should You Trust? appeared first on Blog.

Introduction

Quick answer: No single tool secures an API. API security is a layered discipline. Secure-coding analyzers and SCA scanners catch code and dependency flaws; DAST tests running APIs; API gateways and IAM enforce authentication and rate limits; a WAF blocks known attack patterns; bot management stops automated abuse; and runtime API security adds continuous discovery and catches business-logic threats like BOLA that other tools miss. This guide maps these API security tools to seven risk domains so you can see your coverage—and your gaps.

APIs power mobile apps, partner integrations, cloud microservices, SaaS platforms, and AI services; they are the business.

According to Imperva’s State of API Security report, API traffic now accounts for over 71% of all web traffic. As APIs have exploded in number and importance, so has the challenge of securing them.

When organizations look for “API security,” they quickly face a confusing mix of tools:

• Secure coding analyzers
• Dependency scanners
• CI/CD testing platforms
• Network firewalls
• Web application firewalls (WAF)
• API gateways
• Identity and access management (IAM) systems
• Bot management platforms
• Dedicated API security solutions

Each tool does protect APIs, but only in its own narrow way.

API security is not a single product. It is an architectural discipline that spans the entire API lifecycle: from design to code, deployment, runtime, and monitoring.

This blog cuts through the noise. It shows exactly which risks each security component addresses, and where the gaps remain, so you can build a complete, layered defense.

The API Risk Landscape

API risks don’t come from one place. They appear at every stage of the software lifecycle. Here are the seven core risk domains you must understand:

Why This Landscape Matters

Real breaches almost always happen when risks from multiple domains line up.

Example:

A valid token (authentication risk) + excessive data exposure (design risk) + an exposed endpoint (configuration risk) + automated enumeration (abuse risk) = a major breach.

No single tool covers every domain. That’s why a layered approach is essential.

Security Components in the API Security Stack

Enterprise API protection never comes from one product. It’s a combination of tools working in different layers. Here’s what each major component does:

Mapping Security Components to API Risk Domains

Here’s a clear, at-a-glance view of what each component covers:

Security Component	Design	Code	Supply Chain	Config	Auth	Abuse	Logic
SAST
SCA
DAST
WAF
API Gateway
IAM
Bot Manager
Runtime API Security

Legend

= Strong / primary coverage

= Partial or indirect coverage

= No meaningful coverage

What Runtime API Security delivers

• Design: Detects undocumented APIs and excessive data exposure (but doesn’t fix the original spec).
• Code: Spots exploit attempts in live traffic (but doesn’t scan source code).
• Supply Chain: No visibility into libraries or CVEs.
• Configuration: Identifies exposed or misbehaving endpoints.
• Authentication & Access: Catches misuse and authorization anomalies.
• Automation & Abuse: Detects patterns (often works alongside bot management).
• Business Logic: This is its superpower, behavioral analysis, object-level authorization monitoring, and detection of low-and-slow attacks that no other tool sees.

Quick takeaway on Runtime API Security

It shines brightest in Business Logic (its real superpower) and gives helpful visibility across most other domains, but it still works best alongside the other tools. Solutions like Imperva API Security from Thales are built specifically for this layer.

Final Thought

Building Your Layered API Security Strategy

API security isn’t about buying one magic product. It’s about understanding the full risk picture and picking the right tool for each layer.

Next Steps

1. Map your current tools against the 7 risk domains using the matrix above.
2. Spot the gaps—especially in Business Logic & Behavioral Risks, where the most damaging attacks hide.
3. Layer specialized coverage where needed. Imperva offers a strong, integrated portfolio, including industry-leading Runtime API Security, WAF, Bot Management, and API Gateway capabilities, that helps close multiple gaps with one cohesive platform.
4. Take the next step today. Review your API inventory, run a quick gap analysis, or contact your security team / Imperva/Thales’s representative for a tailored assessment.

Organizations that treat API security as an architectural discipline, not a checkbox, are the ones that move fast and stay secure.

Frequently Asked Questions

What tools are used for API security?

There is no single API security tool. A complete stack layers several: secure-coding analyzers (SAST) and software composition analysis (SCA) for code and dependency flaws, DAST for testing running APIs, API gateways and IAM for authentication and rate limiting, a WAF for known attack patterns, bot management for automated abuse, and runtime API security for discovery and business-logic threats such as BOLA.

Is a WAF enough to secure APIs?

No. A WAF blocks known attack patterns at the edge, but it cannot see business-logic abuse like Broken Object Level Authorization (BOLA) and does not discover shadow or undocumented APIs. Imperva’s research notes that traditional tools such as a WAF struggle to detect API business-logic abuse, so runtime API security is needed alongside it.

What is runtime API security?

Runtime API security continuously discovers every API—including shadow and deprecated endpoints—monitors live traffic, and uses behavioral analysis and object-level authorization checks to catch business-logic attacks, including the low-and-slow threats other tools miss.

What are the main API security risks?

API risk spans seven domains across the lifecycle: design and specification, code-level, third-party and supply chain, deployment and configuration, authentication and access, automation and abuse, and business logic and behavioral risks. Most breaches happen when risks from several domains line up at once.

The post API Security Demystified: Which Tools Actually Protect Your APIs (And Where the Gaps Are) appeared first on Blog.

Let’s Talk About Where Your APIs Actually Run

Quick answer: On-premises API security keeps API discovery, detection, and enforcement inside your own perimeter instead of a third-party cloud—the model regulated industries need. Deploying it natively on Kubernetes (sidecar sensors → a discovery controller → an inline WAF gateway) makes it practical: continuous API discovery surfaces shadow and zombie endpoints, behavioral detection catches API-specific threats like BOLA, and the WAF blocks them in real time.

Most security teams already know they need API discovery, including east-west traffic between internal services. That conversation has largely won. The harder question is: where do you actually deploy your API security solution?

For organizations in regulated industries, such as banks, healthcare systems, defense contractors, the answer isn’t straightforward. Data sovereignty requirements, compliance mandates, and network restrictions often rule out cloud-hosted security services. Your APIs run on-prem, so your API security has to run there too.

I spent years in application security before moving into product management, and one pattern kept repeating. Security teams have traditionally relied on preproduction security scanning and testing, which works well for known endpoints but inherently misses runtime security abuses, the shadow APIs, the undocumented endpoints, the services that only reveal their risk under live traffic. The coverage gap wasn’t a technology problem it was a deployment problem. The security tooling wasn’t running where the APIs were running.

That’s the problem this article is about. Not whether you need API security, you do. But how and where you deploy it, so it covers your full environment and increasingly, the answer is Kubernetes.

The API Security Gap That Nobody Wants to Admit

Once you’ve decided to deploy on-prem, the first thing that becomes clear is just how much of your API footprint was previously unaccounted for.

In my experience working with customers, teams often start out believing they have around 50 or 60 API endpoints. Once automated discovery runs against live traffic, that number frequently jumps to 300+. It’s not that anything was done wrong — those extra 240+ endpoints simply weren’t in any documentation or Swagger file. They were built for legitimate reasons, serving real traffic in production, but had never gone through a formal security review.

The real value of discovery is surfacing these blind spots not to assign blame, but to give security teams complete visibility so they can protect the full attack surface, not just the parts they already knew about.

Why Deployment Location Changes Everything

When API security runs externally or as a periodic exercise, you’re dependent on someone compiling a list of endpoints before anything gets scanned. That’s not a people’s failure it’s an architectural one. The security tooling isn’t sitting where the traffic flows, so it can only see what it’s told about.

Engineers focus on what they’re actively building. The endpoint they created eight months ago for a partner POC that never went anywhere? It’s not on their radar. The internal debugging endpoint that was supposed to be temporary? Still running. The v1 of an API that was “replaced” by v2 but never actually decommissioned? Still accepting requests.

The security team scans what they’re given. The audit report comes back clean. And everyone moves on, not realizing that the scan only covers 30% of the actual attack surface.

WAFs Are Essential but They Need the Right Intelligence

WAFs are the enforcement backbone. They sit inline, they can block traffic, and they’re battle-tested. That’s exactly what you want to stop threats in real time. The challenge isn’t the WAF itself; it’s what the WAF knows about.

A WAF is incredibly effective when it knows what to look for and where to look. But traditional WAF deployments rely on rules and signatures of SQL injection patterns, XSS payloads, and malformed requests. API-specific threats like BOLA (Broken Object-Level Authorization) don’t match those patterns. An attacker changes an object’s ID to access someone else’s data, and the request looks perfectly normal. Well-formed, authenticated, and syntactically valid. The WAF has no reason to flag it because it doesn’t have the API-level context to know that request shouldn’t be accessing that resource.

That’s where a dedicated API security layer becomes the WAF’s force multiplier. It provides the discovery, the behavioral analysis, and the API-specific threat intelligence. The WAF provides inline enforcement. Together, they form a closed loop: the API security platform detects, the WAF gateway blocks. Neither is complete without the other.

And both can only protect what they can see, which brings us back to why continuous API discovery matters so much. If an endpoint was never registered and never put behind the WAF, it’s completely exposed. Discovery closes that gap.

The Compliance Clock Is Ticking

This used to be a “nice to have” conversation. It’s not anymore. PCI DSS 4.0.1 now requires continuous API security testing and maintained API inventories. (These PCI DSS 4.0.1 requirements became mandatory on March 31, 2025.) The EU Cyber Resilience Act mandates security testing throughout the development lifecycle. ISO 27001:2022 introduced new application-security controls—including secure coding (A.8.28) and application security requirements (A.8.26)—that apply directly to APIs. If you’re in a regulated industry running on-prem APIs and you don’t have dedicated API security, your next audit is going to be uncomfortable.

Built for Kubernetes Infrastructure

Modern application environments are increasingly standardizing Kubernetes. It’s where workloads run, where infrastructure teams are investing, and where operational tooling is already mature. Our on-prem API security solution is purpose-built to deploy natively on this infrastructure.

Because it runs on Kubernetes, it inherits the operational benefits that teams already rely on pod-level self-healing for high availability, Helm-based deployments for consistent upgrades, and native integration with existing monitoring stacks like Prometheus, Grafana, or the ELK stack. There’s no separate HA architecture to build, no custom upgrade orchestration to maintain, and no new observability tooling for your SREs to learn.

For teams already running Kubernetes, adding API security to the cluster is operationally familiar. It fits into the workflows, tooling, and processes your infrastructure team already uses every day

What the Architecture Actually Looks Like

Here’s how architecture works in practice.

Continuous API Discovery

API discovery works through our lightweight sensors, deployed as Kubernetes sidecars alongside your application pods. These sensors passively mirror API traffic without adding latency or altering request flows and send the metadata to the API Security controller. The controller analyzes this traffic and continuously builds a complete inventory of every API endpoint in your environment, including REST, GraphQL, gRPC, and SOAP.

Because discovery is based on live traffic observation through the sensors rather than static documentation or manual reporting, it surfaces everything shadow APIs that were never documented, zombie endpoints that were supposed to be decommissioned, and internal services that no one remembered to put through a security review.

In my experience working with customers, teams that expected 50 or 60 endpoints routinely discover 300+. The discovery phase alone just seeing what you actually have justified the deployment for a lot of organizations. It’s the difference between securing a fraction of your attack surface and securing all of it.

Classification and Risk Scoring

Not every API carries the same risk. A health-check endpoint and a payment processing API are in different universes from a security standpoint. The platform classifies APIs based on what data they handle PII, financial data, credentials, health records and assigns risk scores. This is what keeps security teams from drowning in alerts. You focus on the endpoints that matter most.

Detection

The API security platform builds behavioral baselines for API usage and flags deviations. BOLA patterns. Schema violations. Unusual request volumes. Credential stuffing. Authentication anomalies. This is the intelligence layer it understands API-specific threats that signature-based rules alone can’t catch. But intelligence without enforcement is just expensive monitoring. That’s where the WAF gateway comes in.

Enforcement – The Detection-to-Blocking Loop

This is where our solution stands apart. The API security controller detects threats. The WAF gateway enforces inline. It’s a closed loop detection that intelligence feeds directly to the gateway, and the gateway blocks in real time. Neither layer is effective alone. The controller without the gateway can only be alert. The gateway without the controller only has signatures and static rules to work with. Together, you get detection depth and enforcement power.

We are the only solution on the market capable of this level of fine-grained blocking. And by fine-grained, we mean something very specific.

Most competing approaches block at the IP level attacker identified; entire IP blocked. In any real environment, API consumers share IPs constantly. Corporate NAT gateways, CDN exit nodes, partner integrations behind shared proxies. Block one IP and you cut off every legitimate consumer behind that address.

Our enforcement goes well beyond endpoint-level blocking. When the controller detects a threat to say, a BOLA attack doesn’t just block the endpoint or the source IP. It pushes a targeted rule to the WAF gateway that blocks the specific request pattern and the specific token involved. That means a malicious actor session gets shut down while other users hitting the same endpoint from the same IP continue uninterrupted. The blocking is surgical scoped to the exact behavior and identity, not the network address or even the endpoint as a whole.

This might sound like a subtle technical distinction, but in production it changes everything. It’s the difference between a security tool your operations team is confident turning on and one they keep in monitor-only mode because they’re afraid of the blast radius.

The Conversations This Solves

I’m framing these as actual conversations because that’s how they come up in practice.

“We don’t know how many APIs we have.”  This is the most common starting point, and continuous discovery closes the gap immediately. Every endpoint serving traffic gets catalogued and classified, whether it’s in your documentation or not.

“Our WAF handles API security.”  Your WAF is the enforcement engine, and that’s exactly the role it should play. What it needs is the right intelligence to feed it. A dedicated API security layer provides continuous discovery, behavioral analysis, and API-specific threat detection and routes that intelligence to your WAF gateway for inline blocking. Think of it as upgrading your WAF’s awareness, not replacing it.

“We can’t send traffic to a third-party cloud.”  Then don’t. On-prem deployment keeps everything in traffic analysis, detection, enforcement, and reporting inside your perimeter. This is usually a non-negotiable requirement, not a preference for organizations in regulated industries.

“We need to prove compliance and we’re running out of time.”  Continuous monitoring produces always-current audit evidence. API inventories, risk classifications, threat logs, and remediation records. It replaces the scramble of point-in-time assessments. I’ve watched teams go from dreading audits to walking in with dashboards. It changes the dynamic completely.

“Dev ships new APIs every week. Security reviews quarterly.”  That gap is where unprotected APIs live. Automated discovery closes it. New endpoints get monitored the moment they start serving traffic.

Deployment Is Not the Hard Part

I want to spend a minute on this because there’s a perception that on-prem API security deployment is a multi-week project. In my experience, for teams that already have Kubernetes running, it’s measured in hours.

The typical flow:

1. Create a namespace in your existing cluster to isolate the security workload.
2. Set up a Persistent Volume 128 GB is a common baseline. This uses whatever storage backend your cluster already supports.
3. Deploy via Helm. One command. Configuration goes in a values file. Most solutions follow this model because it’s what Kubernetes teams already know.
4. Configure traffic ingestion on how the platform gets visibility into API traffic varies by solution, but the goal is the same: continuous observation of every endpoint in your environment.
5. Integrate with your inline enforcement layer, typically your WAF or API gateway. This is what closes the detection-to-enforcement loop, so threats get blocked in real time, not just logged.

Upgrades are the same model. Helm upgrade, new chart version, done.

For a detailed step-by-step installation walkthrough, refer to our deployment guide (available to Imperva customers)

The hard part isn’t deployment. It’s usually an organizational conversation about whether to do it in the first place. Once that decision is made, the technical execution is straightforward.

Where This Is Heading

API-first architecture isn’t slowing down. If anything, the pace is accelerating in exactly the environments that have the strictest infrastructure constraints of financial services, healthcare, government, critical infrastructure. These organizations need API security that respects their boundaries, not one that asks them to relax those boundaries.

Kubernetes gives you the operational foundation. Purpose-built API security gives you visibility, detection, and enforcement. Together, they deliver a security posture that keeps up with how fast your team ships.

And it all runs inside your own perimeter. Which, for a lot of the teams I work with, is the only answer that matters.

Learn more about Thales’s Imperva unified API security platform.

API security has moved from “nice to have” to “audit requirement.” If your APIs run on-prem, your security needs to run there too. Kubernetes makes that operationally viable. The question isn’t whether to do it. It’s how soon.

Frequently Asked Questions

What is on-premises API security?

On-premises API security runs API discovery, threat detection, and enforcement inside your own data center or private cloud instead of sending traffic to a third-party SaaS. It keeps all API traffic, logs, and analysis within your network perimeter—often a hard requirement for banks, healthcare, government, and other regulated organizations with data-sovereignty and compliance constraints.

Can you run API security on Kubernetes?

Yes. A Kubernetes-native API security platform deploys as lightweight sidecar sensors next to your application pods, feeding mirrored traffic to a controller that builds a live API inventory across REST, GraphQL, gRPC, and SOAP. Because it runs on Kubernetes, it inherits pod-level high availability, Helm-based upgrades, and integration with monitoring stacks like Prometheus and Grafana—so adding it to an existing cluster typically takes hours, not weeks.

What is a shadow API?

A shadow API is an endpoint serving live traffic that is not in any documentation, Swagger file, or official inventory—often an old version, partner integration, or internal debugging endpoint that was never decommissioned. Continuous, traffic-based API discovery surfaces shadow (and “zombie”) APIs so security teams can protect the full attack surface, not just the endpoints they already know about.

The post On-Premises API Security on Kubernetes: What It Actually Looks Like in Practice appeared first on Blog.

There is a moment every security analyst knows well. It’s 2am, an alert fires, and you’re staring at a console trying to make sense of what just happened—fast. You need context, scope, and impact: What’s being targeted? Where is it coming from? Is it getting worse? What should we do next?

That moment is exactly what we built the Imperva AI Assistant to improve, starting with Cloud WAF (cWAF) investigations, where speed and clarity matter most.

Security teams are under pressure to investigate threats faster, with fewer resources

Modern application security environments generate a constant stream of signals across events, trends, attack patterns, and security posture. But turning that data into meaningful insight still takes effort. Analysts often move between dashboards, filter logs, and stitch together context across multiple tools to understand what’s happening.

At the same time, teams are expected to do more with less. A persistent skills gap and increasing alert volume mean even routine investigations can take longer than they should, slowing response times and adding pressure to already stretched teams.

The industry’s traditional response has been more dashboards, more saved reports, and more training. We think there’s a better answer: let your team ask the question in plain English and get a structured, security-relevant answer back immediately, grounded in Imperva platform data.

Introducing the AI Assistant.

What is an AI security assistant?
An AI security assistant is a natural-language tool that lets security teams investigate threats by asking questions in plain English, instead of building queries or navigating dashboards, and returns fast, ranked, security-relevant answers grounded in their own platform data. The Imperva AI Assistant brings this capability directly into the Imperva platform, starting with Cloud WAF investigations.

Protect with AI: Making security work faster, simpler, and more accessible

To address this, we’re bringing the power of AI directly into Thales’s Imperva platform.

It builds on AI ExplAIn, the one-click, plain-language explanations we introduced for Imperva Cloud WAF, extending that same clarity from individual blocked requests to full, cross-product investigations.

Our goal is simple: help security teams get answers faster, reduce manual effort, and improve day-to-day productivity.

What the AI Assistant does?

The AI Assistant is designed around three key goals:

Increase productivity
Instead of navigating dashboards or writing complex queries, users can simply ask a question and get an answer immediately.

Make AppSec more accessible
You don’t need deep expertise in Thales or Cloud WAF. The assistant uses natural language, making it easier for more team members to investigate and understand security data.

Support a wide range of use cases
Security questions don’t follow a fixed script. Our assistant can handle a variety of queries, from investigations to trend analysis, without requiring predefined workflows.

Instead of being limited to predefined dashboards or reports, teams can explore questions as they arise, using plain language to surface insights that would be impractical to design into a traditional UI. Because the assistant can draw on signals across the Imperva AppSec platform, it doesn’t just retrieve data – it connects it.

For example, an analyst might ask: “Was the IP that triggered a WAF block also behaving like automated traffic in the same session, and what changed compared to previous activity?”, and get a clear, unified answer in seconds, without having to pivot across tools or manually stitch the data together.

Security investigations, simplified with an AI security assistant
The AI Assistant is a natural-language experience built into the Imperva platform to help security teams investigate faster.
Instead of navigating dashboards or building filters, teams can simply ask:

• “What are the top attack source IPs over the last 48 hours?”
• “Which URLs are most targeted right now?”
• “What types of attacks were blocked on site XYZ.com?”
• “What changed between yesterday’s baseline and today’s spike?”
• “Are these patterns concentrated in a single source or distributed across multiple locations?”

The assistant responds with a concise, ranked answer, along with a Critical Finding that highlights the security -relevant insight, not just raw data. The assistant can also access all Imperva documentation, so teams can ask “How do I configure…? Or “Where can I find…?” to easily find the information they need.

A real-world investigation, simplified.

Imagine a security analyst investigating a sudden spike in application traffic.

Today, that process often involves switching between dashboards, filtering logs, and piecing together data from multiple sources to understand what’s happening.

With the AI Assistant, the workflow is much simpler.

The analyst can ask:

• “What’s driving the spike in traffic today?”
• “Are these requests coming from the same source or multiple locations?”
• “What has changed compared to yesterday’s baseline?”

Within seconds, the assistant provides a clear, summarized answer, highlighting key trends, identifying the most relevant signals, and surfacing a Critical Finding that explains what matters. Instead of manually connecting the dots, the analyst can quickly understand the situation, prioritize next steps, and respond faster.

Why this matters for security teams

When investigating potential threats, teams need more than confirmation that “something triggered.” They need fast, clear answers that help them understand what’s happening and what to do next.

• What’s the pattern? (Is activity concentrated, distributed, or repeating?)
• What’s the scope? (Which applications, URLs, geographies, or time windows are affected?)
• What’s the severity? (How significant is the signal, and how quickly is it evolving?)
• What’s the next best action? (Where should they focus, and what should they mitigate?)

The AI Assistant is designed to answer these questions directly, reducing investigation friction and helping teams move from data to insight, faster.

In practice, this means security teams can move from alert to understanding faster—without adding complexity or changing existing workflows.

Easy to get started

The AI Assistant is built directly into the Imperva AppSec platform, there’s nothing new to install or manage.

It’s available through the Ask AI experience and works within your existing environment, using the same data, workflows, and permissions you already rely on.

Because it’s permission-aware by design, users only see the data they’re authorized to access.

AI capabilities are always optional, customers can choose whether to enable or disable them at any time, ensuring full control over how AI is used in their environment.

Available today

The AI Assistant is currently available under controlled availability for a select group of customers. This phase allows us to refine quality, guardrails, and workflows based on real-world feedback before broader rollout.

Why it matters

AI in security has been discussed for years, often focused on detection and tuning. But the real pressure point has always been the moment of investigation, when teams need to quickly understand what’s happening and decide what to do next.

That’s where the AI Assistant is different. It focuses on turning security data into clear, actionable insight – faster. It doesn’t replace expertise, but it makes effective investigation workflows easier to access across the team.

When fewer people are bottlenecks for interpreting signals, response times improve, escalations reduce, and teams spend less time on repetitive analysis.

The impact is simple: faster decisions, fewer handoffs, and more time spent on the issues that matter most.

The bottom line

Security investigations get faster when teams can turn security data into explanations they trust. The Imperva AI Assistant is designed to shorten the path from alert to decision, starting with Cloud WAF, by helping analysts quickly pull the right data, spot what’s changed, and decide what to do next.

It starts with a question, and an answer you can defend.

Frequently asked questions about the AI security assistant

What is an AI security assistant?
An AI security assistant is a natural-language interface that lets security teams ask questions in plain English and get fast, ranked, security-relevant answers drawn from their own platform data, instead of manually building queries or pivoting across dashboards. The Imperva AI Assistant delivers this inside the Imperva platform, starting with Cloud WAF investigations.

How is the Imperva AI Assistant different from AI ExplAIn?
AI ExplAIn gives one-click, plain-language explanations of individual blocked requests in Cloud WAF. The AI Assistant goes further, answering open-ended investigation and trend questions across the Imperva AppSec platform and connecting signals, such as a WAF block and automated-traffic activity, within the same session.

What questions can the AI Assistant answer?
Teams can ask investigative and trend questions such as “What are the top attack source IPs over the last 48 hours?” or “What changed between yesterday’s baseline and today’s spike?” Because it can also read the Imperva documentation, analysts can get configuration and “how do I…” answers in the same place.

Will an AI security assistant replace SOC analysts?
No. The AI Assistant is designed to speed up investigations, not replace expertise. It removes the manual work of pulling and correlating data so analysts can focus on judgment, prioritization, and response.

Is the data the AI Assistant sees kept private and under our control?
Yes. The assistant is permission-aware, so users only see data they are authorized to access, and AI capabilities are optional; customers can enable or disable them at any time.

Want to see it in action? Request a demo or ask your Thales team about the controlled availability process.

The post Your Security Operations Team Just Got Faster: Meet Imperva’s AI Assistant. appeared first on Blog.

Web applications and APIs now sit at the center of nearly every digital business, and the threat surface has grown in step. Independent industry analysis estimates that API traffic represents more than 70% of all web traffic, that API related security incidents have climbed to roughly one third of reported data breaches, and that more than a third of recent API breaches trace back to Broken Object Level Authorization (BOLA) flaws.

At the same time, the latest AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation found that average complete-security efficacy across the leading enterprise WAAP solutions declined year over year, even as operational efficiency improved slightly. The takeaway for security leaders is straightforward: WAAP capabilities are diverging across the market, and shortlist decisions made in 2022 or 2023 may no longer reflect current efficacy or operational fit.

This guide focuses on the major WAAP vendors that most frequently appear on enterprise shortlists. It draws on independent SecureIQLab testing, recent Forrester, Gartner, KuppingerCole, and IDC research, and verified peer reviews to help security and risk leaders evaluate platforms across modern, multi-cloud, API-heavy environments without reducing the decision to a generic ranked list.

1. Scope and methodology

This comparison focuses on the major WAAP vendors most commonly evaluated by enterprise buyers: Akamai, Cloudflare, F5, Fastly, Fortinet, and Radware, alongside Imperva. It uses three categories of independently sourced evidence:

• Certified independent testing: the 2025 SecureIQLab Cloud WAAP v4.0 CyberRisk Validation, conducted under AMTSO Test ID AMTSO-LS1-TP097, which evaluated 11 enterprise WAAP solutions across more than 1,360 attacks aligned to the OWASP Top 10, OWASP API Security Top 10 2023, MITRE ATT&CK, and the Lockheed Martin Cyber Kill Chain.
• Analyst recognition: the Forrester Wave for Web Application Firewall Solutions (Q1 2025), the Gartner Market Guide for Cloud Web Application and API Protection, the KuppingerCole 2025 Leadership Compass for WAAP, the IDC MarketScape for WAAP, and Gartner Peer Insights ratings as of the date of this article.
• Verified customer reviews: Gartner Peer Insights, PeerSpot, G2, and TrustRadius user ratings, used as a sentiment signal rather than as a ranking input.

Of the seven platforms covered here, four (Akamai, Cloudflare, Fortinet, and Imperva) completed the public SecureIQLab v4.0 cycle, while three of the competitors (F5, Fastly, and Radware) are listed in the SecureIQLab comparative report as “Contact SecureIQLab” rather than appearing with published v4.0 results. For those three vendors, the profiles below rely on Forrester, Gartner, and verified customer review sources, and head-to-head efficacy comparisons should be confirmed through buyer-led testing.

Other WAAP vendors (for example hyperscaler-native services and specialized API-security vendors) may be relevant for specific buyer needs, but they fall outside the major-vendor scope used here. Buyers should treat this guide as one input among several and validate every vendor claim against their own application portfolio during a proof of value.

2. What is WAAP?

Web Application and API Protection (WAAP) is a category defined by Gartner to describe cloud-delivered services that protect web applications and APIs against runtime attacks. Core capabilities typically include a Web Application Firewall (WAF), distributed denial-of-service (DDoS) protection, advanced bot management, API security, and increasingly client-side script protection.

In practical terms, a WAAP platform sits in front of an application (or a portfolio of applications and APIs) and inspects every request, blocking exploits aligned to the OWASP Top 10 and OWASP API Security Top 10, distinguishing legitimate users from automated abuse, absorbing volumetric and Layer 7 denial-of-service traffic, and providing the visibility security teams need to investigate and tune.

For a foundational explainer, see Imperva’s What is a WAAP? Learning Center article at imperva.com/learn/application-security/web-application-and-api-protection-waap/ (set as an internal link on publish).

3. Why WAAP matters now

Three forces are reshaping WAAP buying decisions in 2026:

• API growth is outpacing API security. Independent reporting indicates that API related breaches have moved from a niche concern to roughly a third of all data breaches, while only about one in five organizations rate themselves as highly capable of detecting attacks at the API layer.
• Bots and AI-enabled automation are escalating. Public industry data shows AI-enabled bot activity rising sharply year over year, with credential stuffing, scraping, and inventory hoarding increasingly difficult to separate from legitimate users without sophisticated behavioral analytics.
• Cloud-native deployment is the new default. As more workloads move inside hyperscale clouds, development teams increasingly prefer security that runs natively within the cloud environment rather than alongside it through external routing that can add latency and operational overhead.
• Regulatory pressure is compounding. Frameworks such as PCI DSS 4.0 (client-side protection requirements), DORA, NIS2, and sector-specific rules on operational resilience are pushing application security from a best practice into a documented control requirement.

For security leaders, the business outcomes a modern WAAP must support include reduced breach risk and downtime, faster time to protection for new applications and APIs, audit and compliance readiness, and predictable cost as application portfolios scale.

4. WAAP vendor comparison at a glance

Use the table below to narrow the vendor set based on architectural focus and primary deployment use case. Then validate efficacy, API coverage, bot defense, and operational fit through your own proof of value. The order is alphabetical, not a ranking.

Vendor	Primary architectural focus	Core deployment use case	Independent 2025 recognition
Akamai	Edge-delivered WAAP on a globally distributed CDN; integrated DDoS, WAF, bot, and API security.	Large enterprises and content-heavy properties needing edge scale and integrated bot defense.	Forrester Wave WAF Q1 2025 Leader; SecureIQLab v4.0 Leader category.
Cloudflare	Cloud-native WAAP delivered on a programmable global network; tightly integrated with Cloudflare CDN, DDoS, and developer platform.	Cloud-first organizations valuing developer experience, edge programmability, and rapid deployment.	Forrester Wave WAF Q1 2025 Leader; SecureIQLab v4.0 Visionary category.
F5	Distributed Cloud WAAP combining BIG-IP Advanced WAF, Volterra, and Shape Security heritage.	Hybrid environments needing both ADC heritage and SaaS-delivered WAAP.	Forrester Wave WAF Q1 2025 Strong Performer; not published in SecureIQLab v4.0 public cycle.
Fastly	Edge-delivered WAF built on the Signal Sciences engine, integrated with Fastly’s programmable CDN.	Developer-led organizations prioritizing observability and integration into CI/CD workflows.	Forrester Wave WAF Q1 2025 Strong Performer; not published in SecureIQLab v4.0 public cycle.
Fortinet	FortiWeb WAAP available as VM, AMI, container, and SaaS, integrated with the Fortinet Security Fabric.	Fortinet-aligned shops consolidating network and application security under one fabric.	Forrester Wave WAF Q1 2025 Contender; SecureIQLab v4.0 Leader category.
Imperva (part of Thales)	Unified WAF, Advanced Bot Protection, API Security, DDoS, Client-Side Protection, and CDN, delivered as SaaS, on-premises, or natively inside AWS, Azure, and Google Cloud.	Enterprises needing unified, multi-cloud and hybrid WAAP with deep bot, API, and DDoS coverage, including cloud-native deployment.	Forrester Wave WAF Q1 2025 Leader; KuppingerCole 2025 WAAP Leader; SecureIQLab v4.0 Leader (Secure by Default).
Radware	Cloud Application Protection Service combining WAF, bot management, API protection, DDoS, and AI SOC.	Enterprises with significant DDoS exposure looking for an integrated suite plus AI-assisted SOC tooling.	Forrester Wave WAF Q1 2025 Strong Performer; not published in SecureIQLab v4.0 public cycle.

Source: SecureIQLab 2025 Cloud WAAP CyberRisk Comparative Validation Report v4.0; Forrester Wave: Web Application Firewall Solutions, Q1 2025; Gartner Market Guide for Cloud WAAP; KuppingerCole 2025 Leadership Compass for WAAP. See references.

Independent analyst standing: Forrester Wave WAF Q1 2025

The Forrester Wave groups vendors into Leaders, Strong Performers, and Contenders, a single published designation that reflects the combined strength of each vendor’s current offering, strategy, and customer feedback. Rather than restate Forrester’s underlying sub-scores, the table below shows each covered vendor’s official tier, with a short note on what Forrester emphasized. This analyst recognition complements security-efficacy testing because it weighs roadmap, innovation, integrations, and customer feedback alongside current capabilities.

Vendor	Forrester tier	What Forrester emphasized
Cloudflare	Leader	Strongest current offering of any vendor evaluated; efficiency-focused features; reference customers flagged support as an area to improve.
Akamai	Leader	Strong detection and automation; broad edge and DDoS scale; noted to lag in DevOps and scanning integrations.
Imperva	Leader	Standout Layer 7 DDoS, CISA Secure by Design Pledge signatory, and a unifying platform roadmap; room to improve in DevOps and scanning integrations and UI consistency.
F5	Strong Performer	Built-in web application scanning and a strong API security story; fewer security operations integrations and a steeper learning curve.
Fastly	Strong Performer	Developer- and business-focused vision and pre-deployment rule testing; still building out API security.
Radware	Strong Performer	AI-assisted SOC tooling and tunable detection; fewer out-of-the-box integrations and less flexible reporting.
Fortinet	Contender	Strong API security capabilities and competitive pricing; roadmap less extensive than others, no rule versioning, and rule testing limited to logging mode.

Source: Forrester Wave: Web Application Firewall Solutions, Q1 2025 (published tier designations and findings). Among the seven vendors covered here, three were named Leaders, three Strong Performers, and one a Contender.

A note on tier equivalence: within Forrester’s methodology, vendors positioned in the same tier hold equivalent standing in the evaluation. The three Leaders (Cloudflare, Akamai, and Imperva) are designated by Forrester as Leaders together; vendor-specific sub-criterion scores within the tier do not change the tier-level designation.

Verified peer feedback (G2)

Independent customer ratings on G2 are a useful third complement to certified testing and analyst evaluation, because they reflect the day-to-day operational experience of paying customers. The table below shows the current G2 standing for each covered vendor’s flagship WAF product profile. Review-base sizes vary widely across vendors, so the rating is best read alongside the volume of reviews supporting it; vendors that have not actively claimed and managed their G2 product profile may show smaller review bases and older reviews.

Vendor product (G2 profile)	G2 rating (of 5)	Review base	Notes
Imperva Web Application Firewall (WAF)	4.7	41	Highest G2 rating among the flagship WAF profiles of the seven covered vendors; primarily enterprise reviewers.
F5 BIG-IP Advanced WAF	4.6	24	Strong rating with a focused enterprise review base.
Radware Cloud WAF	4.6	141	Strong rating with the second-largest review base among the seven.
Cloudflare Application Security and Performance	4.5	595	Largest review base in the category overall; review mix skews toward small business segments.
FortiAppSec Cloud	4.4	33	Solid mid-market G2 standing; reflects Fortinet’s consolidated WAAP profile launched after the Forrester Wave Q1 2025 cutoff.
Fastly Next-Gen WAF	4.2	30	Solid mid-market rating; vendor profile noted on G2 as having limited features (managed but not upgraded).
Akamai App & API Protector	4.0	2	G2 explicitly notes that there are not enough reviews to provide buying insight; the product profile is unclaimed by the vendor.

Source: G2 verified user reviews (most recent rating snapshots at time of writing). G2 product profiles do not always cover a vendor’s full WAAP suite, and review bases vary widely; the table compares each vendor’s flagship WAF product profile. See references.

5. Key criteria to evaluate when comparing WAAP solutions

The framework below combines the SecureIQLab v4.0 evaluation model (security efficacy, operational efficiency, Secure by Design and Secure by Default ratings, false positive avoidance) with capability themes emphasized by Gartner and Forrester.

Capability	What to evaluate
Security efficacy	Independently measured coverage of OWASP Top 10 (web), OWASP API Security Top 10 2023, and advanced threats including bots and Layer 7 DDoS. Look for AMTSO-certified results.
API and microservice protection	API discovery (including shadow and undocumented endpoints), schema enforcement, BOLA and broken authentication detection, support for REST, GraphQL, SOAP, WebSockets, and gRPC.
Bot and abuse mitigation	Ability to distinguish legitimate automation from malicious bots, behavioral analytics, device and TLS fingerprinting, defenses against account takeover, scraping, and inventory hoarding.
Runtime and cloud integration	Support for major public clouds, native in-cloud deployment, Kubernetes and service-mesh ingress, edge versus centralized models, multi-cloud and hybrid coverage, CI/CD integration.
Operational efficiency and FP avoidance	Time to protection, tuning effort, automation, analytics, and false positive avoidance under real traffic. In the latest SecureIQLab v4.0 cycle, false positive avoidance ranged from near-perfect at the top of the group to noticeably weaker at the bottom.
Performance and reliability	Latency impact, scalability under load, behavior of failure modes (fail-open vs fail-closed), out-of-path versus inline architecture, published service-level commitments for availability and mitigation time.
TCO and commercial fit	Licensing model (per app, per request, per Mbps), predictability under traffic spikes, alignment with portfolio growth, marketplace availability, integration with existing security and developer toolchains.
Ecosystem and roadmap	Vendor stability, innovation pace, AI assistance, hyperscaler partnerships, SIEM and SOAR integrations, partner ecosystem, support quality reflected in verified customer reviews.

 

6. Five buyer questions to guide WAAP evaluation

Use these five questions as a lightweight evaluation framework. Each maps to one or more of the capability themes above.

1. How well does the platform stop the threats my applications actually face?

Look beyond generic OWASP coverage claims. Ask for AMTSO-certified third-party test results, and verify both web (OWASP Top 10) and API (OWASP API Security Top 10 2023) efficacy. In the latest SecureIQLab v4.0 testing, complete-security results spanned an extremely wide range, from near-complete coverage at the top to less than half of attacks blocked at the bottom, so the spread within a single shortlist can be very large.

2. How deep is the API protection, across all my protocols?

APIs are no longer just REST. SecureIQLab v4.0 testing measured coverage separately across REST, GraphQL, SOAP, WebSockets, and gRPC, and found that coverage varied widely by protocol even within a single vendor, with WebSockets generally the weakest area across the group. Confirm vendor coverage protocol by protocol, not just by headline API score.

3. How effective is bot defense against modern automation and AI-enabled abuse?

Ask vendors how they detect headless browsers, residential proxy traffic, and AI-driven scraping, and how those decisions are made without harming legitimate traffic. In the SecureIQLab bot suite, only a small number of the tested vendors blocked every attack type, so perfect bot defense is a genuine differentiator rather than a baseline.

4. How quickly can my team get to a tuned, low false-positive state?

Operational efficiency and false positive avoidance are tightly linked. In the latest cycle, the strongest vendors avoided essentially all false positives, while the weakest let through enough to translate into meaningfully more alerts per day and substantially more tuning effort for security operations teams. A few points of difference here can mean a very different daily workload.

5. How does the deployment and licensing model align with how my portfolio is growing?

Native in-cloud deployment, edge delivery, and traditional reverse-proxy models produce very different latency, resilience, and onboarding profiles, and per-request, per-Mbps, and per-application licensing produce very different cost curves as traffic scales. Walk through a 24 to 36 month projection with each shortlisted vendor, ideally informed by your own traffic baseline.

7. WAAP Vendor profiles

Each vendor profile below uses the same schema: a neutral summary, a list of capabilities verified from public documentation and independent sources, and a “Consider when” statement. Profiles are presented alphabetically. Capabilities should be re-validated against your specific environment during a proof of value.

Akamai — App & API Protector

Current market status: Publicly traded (NASDAQ: AKAM). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation.

Summary

Akamai delivers WAAP from one of the world’s largest edge networks, combining WAF, DDoS, bot management, API security, and client-side controls in its App & API Protector product. In SecureIQLab v4.0, the tested cloud-based deployment was among the strongest in the group on both complete security and operational efficiency, comfortably above the group averages, and avoided essentially all false positives. In the Forrester Wave Q1 2025, Akamai was named a Leader, strong on both current offering and strategy, with reference customers citing strong detection and automation; Forrester noted that Akamai lags in DevOps and scanning integrations and that some prospects weigh its pricing carefully.

Key capabilities

• Edge-delivered WAAP integrated with Akamai’s global CDN and DDoS scrubbing capacity.
• Behavioral bot detection that blocked every attack type in the SecureIQLab v4.0 bot suite.
• API discovery and schema-aware protection for REST and modern protocols.
• Layer 7 DDoS coverage with a perfect result in SecureIQLab v4.0 Layer 7 DoS testing.
• Integration with Akamai’s broader Zero Trust and AI security portfolio.

Consider when

Consider Akamai when your organization needs edge-delivered protection at very large scale, has significant CDN and DDoS requirements alongside WAAP, and wants a vendor with an established global footprint and analyst-recognized leadership.

Cloudflare — Cloudflare WAF (Application Security)

Current market status: Publicly traded (NYSE: NET). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, with the strongest current-offering position of any vendor evaluated. Placed in the Visionary category of the SecureIQLab 2025 Cloud WAAP v4.0 validation; rated Secure by Default.

Summary

Cloudflare delivers WAAP from a globally distributed programmable network, with strong developer experience, rapid feature velocity, and integrated DDoS, bot management, API gateway, and Page Shield (client-side protection). In SecureIQLab v4.0, Cloudflare’s complete-security result landed around the group average, but it blocked every bot and Layer 7 DoS attack type and avoided nearly all false positives; API coverage was uneven, with strength in SOAP and gRPC and notable weakness in REST and WebSockets in the tested configuration. In the Forrester Wave Q1 2025, Cloudflare was named a Leader and posted the strongest current offering of any vendor evaluated; Forrester credited an efficiency-focused feature set and noted that reference customers flagged customer support as an area to improve.

Key capabilities

• Cloud-native WAF integrated with Cloudflare’s CDN, DDoS scrubbing, and developer platform.
• Programmable security policies and edge workers for custom logic.
• Bot management that blocked every attack type in the SecureIQLab v4.0 bot suite.
• Page Shield client-side protection aligned to PCI DSS 4.0 requirements.
• Strong developer experience and rapid product release cadence.

Consider when

Consider Cloudflare when your organization values developer-led security, rapid time to deploy, and a unified edge platform across CDN, DDoS, and application protection. Plan to validate API coverage by protocol against your specific traffic mix during a proof of value.

F5 — Distributed Cloud WAAP

Current market status: Publicly traded (NASDAQ: FFIV). Named a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025. Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).

Summary

F5 brings deep WAF heritage from BIG-IP Advanced WAF and a multi-acquisition portfolio (Volterra, Shape Security), assembled into the Distributed Cloud (XC) WAAP service. F5 is often shortlisted by organizations with significant existing F5 application delivery and security investments and a need to span data center, multi-cloud, and SaaS-delivered WAAP. In the Forrester Wave Q1 2025, F5 was named a Strong Performer, solid on both current offering and strategy; Forrester credited built-in web application scanning (via its Heyhack acquisition) and a strong API security story, while noting fewer security operations integrations and a steep learning curve cited by reference customers. Because F5 did not appear in the public SecureIQLab v4.0 dataset, comparative efficacy claims should be validated through buyer-led testing.

Key capabilities

• Distributed Cloud WAAP delivered as a SaaS layer across multi-cloud and edge.
• Behavioral bot defense lineage from Shape Security.
• API security including discovery and schema validation.
• Hybrid deployment alongside BIG-IP Advanced WAF appliances and virtual editions.
• Strong fit for hybrid enterprises with existing F5 footprints.

Consider when

Consider F5 when your environment already standardizes on F5 application delivery and security infrastructure, when hybrid (data center plus SaaS) WAAP is required, and when buyer-led testing can fill the absence of comparable public SecureIQLab v4.0 data.

Fastly — Next-Gen WAF

Current market status: Publicly traded (NYSE: FSLY). Recognized as a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025 (vision described by Forrester as developer- and business-focused). Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).

Summary

Fastly’s WAF is built on the Signal Sciences engine and is closely integrated with Fastly’s programmable edge platform. The product appeals to developer-led organizations that want deep observability into request decisions, the ability to test rules before deployment, and tight CI/CD integration. The absence of Fastly from the SecureIQLab v4.0 public cycle means head-to-head efficacy comparison against the 11 tested vendors must come from internal testing.

Key capabilities

• Signal Sciences detection engine with detailed signal-based decisioning.
• WAF Simulator for testing rules prior to production deployment.
• Native integration with Fastly’s programmable CDN.
• API security features that have continued to expand in 2024 and 2025.
• Strong reported partner-style customer relationships.

Consider when

Consider Fastly when application security is closely coupled to a developer-first delivery culture, when observability and pre-deployment rule testing are priorities, and when the lack of public SecureIQLab v4.0 data can be supplemented by internal validation.

Fortinet — FortiWeb

Current market status: Publicly traded (NASDAQ: FTNT). Named a Contender in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation.

Summary

FortiWeb is Fortinet’s WAAP, available as VM, AMI, container, and SaaS, and integrated with the broader Fortinet Security Fabric. The two independent sources frame Fortinet differently. In SecureIQLab v4.0, FortiWeb posted the strongest complete-security result among the tested platform vendors, with high operational efficiency and near-perfect false positive avoidance (its bot defense blocked three of the four attack types). In the Forrester Wave Q1 2025, Fortinet placed in the Contender tier, the only covered vendor below the Strong Performer band, with developing positions on both current offering and strategy. Forrester noted a roadmap less extensive than others in the evaluation, an absence of rule versioning, rule testing limited to logging mode, and limited compliance and performance reporting, while crediting strong API security capabilities and competitive pricing.

Key capabilities

• WAAP available as virtual machine, AMI, container, and SaaS.
• Integration with Fortinet Security Fabric (FortiGate, FortiAnalyzer, FortiSIEM).
• Machine learning models for traffic profiling and threat detection.
• API security capabilities including anomaly detection, PII labeling, and gRPC support (per Forrester).
• April 2024 Google Cloud Technology Partner of the Year award in application security.
• Strongest complete-security result among the SecureIQLab v4.0 tested platform vendors.

Consider when

Consider FortiWeb when your organization is standardized on the Fortinet Security Fabric, when integrated network and application security is a priority, and when a competitively priced option within a large security platform is the goal. Buyers prioritizing rule lifecycle management (versioning, safe rule testing outside logging mode) or breadth of strategy and roadmap should weigh the Forrester findings and validate these areas during a proof of value.

Imperva (part of Thales) — Web Application and API Protection

Current market status: Now part of Thales (acquired December 2023). Recognized as a Leader in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, and the KuppingerCole 2025 Leadership Compass for WAAP. Placed in the Leader category of the SecureIQLab 2025 Cloud WAAP v4.0 validation (the fourth consecutive cycle) and awarded the Secure by Default rating.

Summary

Imperva delivers a unified WAAP combining Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, Client-Side Protection, Account Takeover Protection, and CDN under one platform, available as SaaS, on-premises, or deployed natively inside hyperscale clouds. In SecureIQLab v4.0, Imperva was among the strongest in the group on both complete security and operational efficiency, well above the group averages, and notably achieved perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance, a combination of high efficacy and full false-positive discipline that few vendors matched. In the Forrester Wave Q1 2025, Imperva was named a Leader, strong on strategy and solid on current offering. Forrester highlighted Imperva’s Layer 7 DDoS, its signing of the CISA Secure by Design Pledge, and a roadmap that integrates its application security offerings into a unified platform, while noting room to improve in out-of-the-box DevOps and scanning integrations and in some UI consistency.

Key capabilities

• Unified WAAP platform across SaaS, on-premises, and cloud-native deployment.
• Native in-cloud deployment for AWS, Microsoft Azure, and Google Cloud, with Imperva for Google Cloud (available on Google Cloud Marketplace) inspecting traffic inside the Google Cloud network via Service Extension and Private Service Connect, and onboarding without DNS, SSL, or routing changes.
• Advanced Bot Protection with behavioral analytics and fingerprinting; blocked every bot attack type in SecureIQLab v4.0 testing.
• API Security with discovery, schema-based protection, and BOLA detection; API protocol coverage well above the tested-group average.
• DDoS Protection with industry SLA commitments; perfect result in SecureIQLab v4.0 Layer 7 DoS testing.
• Client-Side Protection aligned to PCI DSS 4.0 magecart and script-protection requirements.
• Perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance in the SecureIQLab v4.0 cycle; Secure by Default rating per CISA-aligned criteria.

Consider when

Consider Imperva when your organization needs unified WAAP across multi-cloud and hybrid environments, when deep API security and bot defense are required alongside core WAF and DDoS, when low operational burden and very high false-positive avoidance are priorities, and when cloud-native deployment inside AWS, Azure, or Google Cloud is on the roadmap.

Radware — Cloud Application Protection Service

Current market status: Publicly traded (NASDAQ: RDWR). Recognized as a Strong Performer in the Forrester Wave: Web Application Firewall Solutions, Q1 2025. Not part of the public 2025 SecureIQLab v4.0 published cycle (listed as Contact SecureIQLab in the comparative report).

Summary

Radware’s Cloud Application Protection Service combines WAF, bot management, API protection, and DDoS, with continued investment in AI-driven detection and SOC automation tooling. Radware’s heritage in DDoS protection makes it a frequent shortlist option for organizations whose risk profile is heavily weighted to availability attacks. In the Forrester Wave Q1 2025, Radware was named a Strong Performer, strong on strategy and solid on current offering; Forrester credited its AI SOC Xpert tool and tunable detection models, while noting fewer out-of-the-box integrations and reference-customer feedback that reporting could be more flexible. Comparable SecureIQLab v4.0 data is not publicly available for this cycle.

Key capabilities

• Cloud Application Protection Service combining WAF, bots, API, and DDoS.
• Strong DDoS protection heritage.
• AI-assisted SOC tooling for application protection.
• Hybrid and cloud deployment options.
• Forrester recognition for detection models and pricing transparency in Q1 2025.

Consider when

Consider Radware when DDoS exposure is a primary driver, when AI-assisted SOC tooling is valued, and when the absence of public SecureIQLab v4.0 data can be addressed through internal testing.

8. Why Imperva stands out for unified, cloud-native WAAP

Imperva’s differentiation is grounded in four architectural realities that buyers can verify in their own environments and through independent testing.

• Unified WAAP rather than assembled WAAP. Imperva’s Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, Client-Side Protection, Account Takeover Protection, and CDN are delivered as one platform rather than a portfolio of acquired and integrated products. The result is consistent policy, telemetry, and analytics across the entire application protection surface.
• Validated efficacy with very low operational burden. In the latest AMTSO-certified SecureIQLab v4.0 cycle, Imperva paired among the strongest complete-security and operational-efficiency results in the group with perfect 100% results in false positive avoidance, bot defense, and Layer 7 DoS. Few vendors in the tested set combined top-tier efficacy with that level of false-positive discipline.
• Deployment flexibility, including native cloud integration. Imperva can be deployed as SaaS, on-premises, or natively inside hyperscale clouds. Imperva for Google Cloud, available on Google Cloud Marketplace, inspects traffic inside the Google Cloud network using Service Extension and Private Service Connect, and onboards without DNS, SSL, or routing changes. This native, in-cloud direction extends across AWS, Azure, and Google Cloud, and reflects a broader roadmap of running enterprise-grade WAAP inside hyperscale infrastructure rather than alongside it through external routing.
• Aligned to CISA Secure by Design. Imperva earned the SecureIQLab Secure by Default rating in the same cycle, reflecting hardened defaults and the ability to protect newly deployed applications without extensive manual tuning.

No single platform is the right answer for every environment. Buyers whose dominant requirement is a single edge platform unifying CDN, application protection, and a developer-centric workflow, or whose primary driver is the deepest possible DDoS scrubbing capacity, will want to weigh those needs explicitly. The most reliable approach is to validate any shortlist, including Imperva, against your own threat model, traffic patterns, and cloud footprint during a proof of value.

9. How to choose the right WAAP platform

Choosing a WAAP platform should start with your operating reality, not the vendor list. The matrix below maps the most common dominant security gap to the WAAP capabilities buyers should prioritize during evaluation.

If your biggest gap is…	Prioritize…
API exposure and BOLA-style abuse	API discovery (including shadow APIs), schema enforcement, behavioral analytics, BOLA detection, broad protocol coverage (REST, GraphQL, SOAP, WebSockets, gRPC).
Bot abuse and account takeover	Behavioral bot detection, device and TLS fingerprinting, real-time risk scoring, integration with fraud and identity controls.
Volumetric and Layer 7 DDoS	Always-on DDoS scrubbing capacity, time-to-mitigate SLAs, AMTSO-validated Layer 7 DoS scores.
PCI DSS 4.0 client-side scripts	Client-side protection that inventories scripts, detects unauthorized modification, and produces auditable evidence.
Operational overhead and tuning effort	High Secure by Default scores, high independent false positive avoidance scores, automated policy generation, and analyst-recognized ease of management.
Multi-cloud, hybrid, and cloud-native coverage	Consistent policy and telemetry across AWS, Azure, GCP, and on-premises; native in-cloud deployment options; CDN-agnostic delivery; marketplace availability.
Developer-led delivery culture	CI/CD integration, infrastructure-as-code support, rule-testing tooling, programmable edge.

Proof-of-value checklist

• Validate independent efficacy scores against your own application portfolio and threat model.
• Test API protection across every protocol you actually use (not just REST).
• Measure tuning effort and false positive rates under real traffic for at least two weeks.
• Confirm Layer 7 DDoS and bot defenses against representative attack patterns and adversarial automation.
• Test the deployment model you intend to run in production, including native in-cloud deployment where relevant.
• Walk through licensing across a 24 to 36 month projection that includes anticipated traffic and portfolio growth.
• Verify SIEM, SOAR, identity, and developer-tool integrations against your existing stack.
• Review verified peer feedback (Gartner Peer Insights, PeerSpot, G2, TrustRadius) for unfiltered operational reality.

10. Frequently asked questions

What are the best WAAP solutions in 2026?

There is no single best WAAP for every organization; the right platform depends on your threat profile, API footprint, and cloud architecture. Among the major vendors most often shortlisted by enterprises, Akamai, Cloudflare, and Imperva were named Leaders in the Forrester Wave: Web Application Firewall Solutions, Q1 2025, while Akamai, Fortinet, and Imperva placed in the Leader category of the AMTSO-certified SecureIQLab Cloud WAAP v4.0 validation. In that cycle, Imperva combined among the strongest security efficacy in the group with perfect 100% results in bot defense, Layer 7 DoS, and false positive avoidance. Validate any shortlist against your own traffic during a proof of value.

What is the difference between a WAF and a WAAP?

A Web Application Firewall (WAF) inspects and filters HTTP traffic to block common web exploits such as those in the OWASP Top 10. Web Application and API Protection (WAAP) is the broader, cloud-delivered category defined by Gartner that pairs a WAF with additional runtime defenses, typically DDoS protection, advanced bot management, API security, and client-side script protection. In other words, the WAF is one component inside a modern WAAP platform.

Which major WAAP vendors were named Leaders in the most recent Forrester Wave for WAF Solutions?

In the Forrester Wave: Web Application Firewall Solutions, Q1 2025, which evaluated 10 providers across 22 criteria, the vendors covered in this guide were placed as follows: Akamai, Cloudflare, and Imperva were named Leaders; F5, Fastly, and Radware were named Strong Performers; and Fortinet was named a Contender.

Which of the vendors covered here completed the most recent SecureIQLab Cloud WAAP testing?

Of the seven platforms covered here, four completed the public SecureIQLab v4.0 cycle: Akamai, Cloudflare, Fortinet, and Imperva. Akamai, Fortinet, and Imperva were placed in the Leader category. F5, Fastly, and Radware are listed as Contact SecureIQLab in the comparative report and did not appear with published v4.0 results.

Why does API protocol coverage matter so much in 2026?

API traffic now accounts for more than 70% of all web traffic, and independent industry reporting links roughly a third of recent data breaches to APIs, with about 35% of API breaches tied to Broken Object Level Authorization (BOLA). Modern WAAPs need to cover REST, GraphQL, SOAP, WebSockets, and gRPC; independent testing has shown wide variance across protocols even within a single vendor’s product.

What does native cloud deployment add over traditional WAAP delivery?

Native in-cloud deployment lets a WAAP inspect traffic inside the cloud provider’s own network rather than routing it externally, which can reduce latency and operational overhead and avoid changes to DNS, SSL, or routing. Imperva for Google Cloud, for example, uses Google Cloud Service Extension and Private Service Connect to operate inside the Google Cloud network, and Imperva offers native deployment across AWS, Azure, and Google Cloud.

What independent WAAP testing standards should I trust?

Look for testing conducted under the Anti-Malware Testing Standards Organization (AMTSO) framework. The SecureIQLab Cloud WAAP v4.0 methodology used in this guide is AMTSO-certified (AMTSO-LS1-TP097). Pair it with analyst evaluations (Forrester, Gartner, KuppingerCole, IDC) and verified peer reviews.

How should I treat vendor-supplied competitive content during evaluation?

Treat vendor-produced competitive comparisons as marketing inputs rather than evidence. Anchor evaluation on AMTSO-certified independent testing, recent analyst reports, and verified peer reviews, and confirm specific claims through your own proof of value.

11. Choose your next step

Strong WAAP decisions combine three things: independent testing data, analyst guidance, and a proof of value run on your own traffic. As next steps, security leaders typically benefit from running a quick application portfolio baseline (top 20 apps and APIs by risk), executing an internal red-team exercise against current controls, and shortlisting two to three vendors for parallel proof of value testing across the dimensions outlined above.

To explore Imperva’s WAAP capabilities, including native deployment for AWS, Azure, and Google Cloud, or to request a technical evaluation, contact the Imperva team.

12. References and appendix

All claims in this guide are supported by independent third-party sources or by vendor public documentation for descriptive facts. The full reference list is below.

Independent testing

[1] SecureIQLab, 2025 Cloud WAAP CyberRisk Comparative Validation Report v4.0, AMTSO Test ID AMTSO-LS1-TP097, https://www.secureiqlab.com.

[2] SecureIQLab, 2025 Cloud WAAP CyberRisk Validation Reports (individual vendor reports, including Akamai, Cloudflare, Fortinet, and Imperva).

[3] Anti-Malware Testing Standards Organization (AMTSO), https://www.amtso.org.

Analyst recognition

[4] Forrester, The Forrester Wave: Web Application Firewall Solutions, Q1 2025 (Sandy Carielli, et al., March 20, 2025). Tier placements and composite scorecard scores cited here are from Figures 1 and 2 of the report.

[5] Gartner, Market Guide for Cloud Web Application and API Protection, most recent edition, https://www.gartner.com.

[6] Gartner Peer Insights, Cloud Web Application and API Protection market reviews, https://www.gartner.com/reviews/market/cloud-web-application-and-api-protection.

[7] G2, Web Application Firewall (WAF) category, verified user reviews and product ratings, https://www.g2.com/categories/web-application-firewall-waf.

[8] KuppingerCole, Leadership Compass: Web Application and API Protection (WAAP), 2025.

[9] IDC, IDC MarketScape for Web Application and API Protection (WAAP).

Industry standards and frameworks

[10] OWASP Top 10 (2021), https://owasp.org/Top10/.

[11] OWASP API Security Top 10 (2023), https://owasp.org/API-Security/.

[12] MITRE ATT&CK Framework, https://attack.mitre.org.

[13] Lockheed Martin Cyber Kill Chain, https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html.

[14] CISA, Secure by Design Principles, https://www.cisa.gov/securebydesign.

[15] PCI Security Standards Council, PCI DSS v4.0, https://www.pcisecuritystandards.org.

Industry data sources

[16] SQ Magazine, API Security Breach Statistics 2026, https://sqmagazine.co.uk/api-security-breach-statistics/.

[17] TechRT, API Usage and Growth Statistics 2026, https://techrt.com/api-usage-and-growth-statistics/.

[18] Security Boulevard, 2026 API ThreatStats analysis, https://securityboulevard.com.

Vendor public documentation

[19] Akamai, App & API Protector product page, https://www.akamai.com.

[20] Cloudflare, Application Security product page, https://www.cloudflare.com.

[21] F5, Distributed Cloud WAAP product page, https://www.f5.com.

[22] Fastly, Next-Gen WAF product page, https://www.fastly.com.

[23] Fortinet, FortiWeb product page, https://www.fortinet.com.

[24] Imperva, Web Application and API Protection product page, https://www.imperva.com/products/application-security/.

[25] Imperva, Imperva for Google Cloud product page, https://www.imperva.com/products/imperva-for-google-cloud/.

[26] Imperva, Introducing Imperva for Google Cloud (company blog, 2026), https://www.imperva.com/blog/.

[27] Radware, Cloud Application Protection Service product page, https://www.radware.com.

 

 

The post Best WAAP Solutions for Enterprise Application Security: How to Choose the Right Platform in 2026 appeared first on Blog.

There is a question I have been hearing more and more from CISOs, compliance officers, and security architects over the past year. It does not start with “we had a breach” or “we failed an audit.” It starts with something that sounds almost philosophical:

“Are we quantum-safe?”

A year ago, that question came from the most forward-thinking 5% of our customer base. Today, it is coming from everyone. And that shift, from curiosity to urgency, tells you everything you need to know about where the security industry is headed.

Post-Quantum Cryptography is not a future problem anymore. It is a right now problem. And the customers asking us about it are not being paranoid. They are being smart.

What is post-quantum cryptography? Post-quantum cryptography (PQC) is a new generation of public-key algorithms designed to remain secure against attacks from both classical and large-scale quantum computers. Unlike RSA and elliptic-curve cryptography, which rely on math that a sufficiently powerful quantum computer can break, PQC algorithms are based on mathematical problems that are believed to be hard for quantum machines as well -protecting the data your organization encrypts today from being decrypted in the future.

The “Harvest Now, Decrypt Later” Threat Is Already in Motion

Let us be direct about the threat model, because it is one that does not get nearly enough attention in mainstream security conversations.

You do not need a quantum computer to exist today for your encrypted data to already be at risk.

Sophisticated nation-state adversaries are actively collecting encrypted TLS traffic right now, including your transactions, your authentication sessions, and your sensitive data in transit, with the explicit intention of decrypting it later once quantum computing reaches sufficient capability. This strategy has a name: “Harvest Now, Decrypt Later.” And it is not theoretical. It is happening.

The implication is sobering: the security decisions you make today about encryption determine the confidentiality of data that will still be sensitive in five, ten, or fifteen years. Healthcare records. Financial transactions. Government communications. Intellectual property. Any data with long-term value is already a target for harvesting.

Classical TLS, the encryption backbone of the modern internet, was not built to withstand quantum-scale attacks. The mathematical problems that make RSA and ECC hard to break today become tractable for sufficiently powerful quantum computers. When that threshold is crossed, the encryption protecting decades of harvested data becomes transparent.

This is not a hypothetical edge case. It is a strategic, long-horizon attack that demands a strategic, long-horizon defense.

Our Customers Are Already Asking. We Already Have the Answer.

Here is something I want to be transparent about, because I think it matters.

At Thales, we have been getting questions about PQC readiness from customers consistently and with increasing frequency. These are not fringe inquiries from academic researchers or early adopters chasing the next shiny thing. These are enterprise security teams, regulated industry customers in finance, healthcare, and defense, and compliance officers who are watching the regulatory horizon and doing the math.

They are thinking about it. And they deserve a vendor who is already ahead of it.

That is exactly why I am proud to share what we have built. Thales’ Imperva platform now supports hybrid TLS handshakes combining X25519 and MLKEM768, a pairing of classical elliptic curve cryptography with a quantum-safe Key Encapsulation Mechanism aligned directly with NIST PQC standards. This hybrid approach protects connections between clients and Imperva Points of Presence with both classical and quantum-safe algorithms running simultaneously, ensuring security regardless of which threat model materializes first.

And we did not just build the capability for customers. We completed the migration of all Imperva sites ourselves. We validated it in production before asking anyone else to trust it.

That is what proactive security looks like.

What Hybrid TLS Actually Looks Like in Practice

I know “hybrid TLS handshake” can sound abstract, so let me ground it in something concrete.

When a client connects to a Thales Imperva-protected application today, that TLS 1.3 session is authenticated using X25519MLKEM768, a combined algorithm that you can actually observe directly if you inspect the connection in Chrome’s security panel. You will see exactly what the screenshot above shows: “The connection to this site is encrypted and authenticated using TLS 1.3, X25519MLKEM768, and AES_128_GCM.”

That is not marketing language. That is your browser’s own security panel confirming quantum-safe encryption is active.

What this means practically:

• A classical adversary cannot break the X25519 component
• A quantum-capable adversary cannot break the MLKEM768 component
• Both would need to be broken simultaneously, which represents an effectively impossible bar with current and near-future capabilities

The hybrid model is deliberate and important. Pure PQC algorithms, while mathematically quantum-resistant, are newer and have had significantly less real-world cryptanalysis time than their classical counterparts. The hybrid approach ensures we are not trading one risk for another. We are stacking defenses. This is defense-in-depth applied to cryptography itself.

Zero Performance Trade-off. No Traffic Impact. Full Protection.

Here is the objection I hear almost every time PQC comes up in a customer conversation: “That sounds computationally expensive. What does it do to latency?”

The answer, which genuinely surprises most people: nothing measurable.

Our PQC implementation introduces no performance trade-off and no traffic impact. This matters enormously because one of the most common reasons organizations delay critical security upgrades is the perceived performance cost. Security teams propose the upgrade. Engineering teams push back on latency. The initiative stalls.

With Thales’s PQC implementation, that objection is gone.

Quantum-safe encryption that slows your applications down is not a real solution. It is a compliance checkbox that creates new operational problems while solving a cryptographic one. We were not willing to ship that. The implementation delivers genuine quantum-safe security without the operational tax, and that is the only version of this capability worth deploying at enterprise scale.

The Compliance Horizon Is Closer Than You Think

If the threat model alone is not enough to create urgency in your organization, and for some organizations it is not, that is an honest reality, then the regulatory and compliance landscape should be.

Governments and standards bodies have moved decisively and fast:

• NIST finalized its first PQC standards in 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These are no longer drafts. They are published standards.
• The S. White House issued NSM-10 directing federal agencies to inventory cryptographic systems and prioritize PQC migration timelines
• CNSA 2.0 mandates PQC adoption for national security systems with defined timelines
• Financial services regulators in the EU and UK are actively publishing PQC readiness guidance for institutions
• DORA and NIS2 in Europe are tightening cryptographic resilience requirements across critical infrastructure sectors

The direction is unambiguous. Regulated industries, including finance, defense, and healthcare, are going to face PQC compliance requirements. The organizations that begin migration now will meet those requirements ahead of schedule, with time to test, validate, and optimize. The ones that wait will be scrambling to meet deadlines under pressure.

Thales’s PQC support is directly aligned with enterprise and regulated sector expectations today. When your auditor, your regulator, or your enterprise customer asks whether your traffic is quantum-safe, the answer should already be yes.

This Is a Security Evolution, Not a Cryptographic Revolution

I want to address something directly, because the way PQC gets discussed in the media can make it sound like a complete overhaul that requires ripping out and replacing your entire security infrastructure overnight.

That framing is not helpful. And it is not accurate.

PQC is a security evolution. The underlying architecture of TLS, certificates, and encrypted communications does not change. The mathematical primitives powering key exchange and authentication do. For most organizations, particularly those working with a security partner like Imperva that has already done the migration work, the path forward is far more manageable than the “quantum apocalypse” narrative suggests.

The hybrid approach makes this especially true. You do not abandon classical cryptography overnight. You layer quantum-safe algorithms alongside proven ones, maintain backward compatibility where needed, and progressively increase quantum-safe coverage as the ecosystem matures and client-side support expands.

Supporting our customers to be PQC compliant at the start of the year was just one step in that evolution. It is a step we took proactively, before our customers needed to ask twice, because that is what it means to be a security partner rather than just a security vendor.

What You Should Do Right Now

If you are a CISO, a security architect, or a compliance officer reading this, here is where I would focus your energy:

1. Inventory your cryptographic exposure.
   Understand which systems handle data with long-term sensitivity. Those are your highest-priority migration targets. Build cryptographic agility, the ability to swap algorithms without architectural overhaul, into your design principles going forward.
2. Ask your vendors the question.
   “Are you quantum-safe?” is now a legitimate and necessary vendor evaluation criterion. Any security vendor without a PQC roadmap, let alone a GA capability in production, should be on notice.
3. Do not wait for regulatory mandates to force your hand.
   The organizations that will navigate PQC transitions smoothly are the ones building the capability now. The ones scrambling to meet a 2027 or 2028 compliance deadline will pay for the delay in both cost and risk.
4. Understand why the hybrid model is the right posture.
   Pure PQC is not the immediate goal for most enterprise environments. Hybrid classical plus quantum-safe is the right posture for 2026. Demand that from your vendors and your internal security teams.
5. Talk to Thales.
   We have done this. Our sites are migrated, our customer sites are migrated. Our PoPs support hybrid TLS with MLKEM768 today. We can help you understand what your path looks like and what questions you should be asking across your vendor portfolio.

The Bottom Line

The harvest is already happening. The standards are finalized. The regulatory expectations are forming. And the technology to protect yourself, without performance trade-offs, without ripping out your stack, is available right now.

Our customers are asking about PQC readiness because they understand the stakes. They are thinking about long-horizon risk in a way that their boards and regulators are increasingly demanding. And they deserve a security partner who is not just thinking about it alongside them but has already built, tested, and deployed the answer.

Post-Quantum Cryptography is not a problem for the security teams of 2030. It is a problem for the security teams of today, being solved by the tools available today.

Thales is quantum-ready.

The question is: are you?

Thales Imperva’s Post-Quantum Cryptography support, hybrid TLS with X25519 plus MLKEM768 for Client to Imperva connections, reached General Availability at the start of 2026. To learn more about Imperva’s PQC readiness and what it means for your organization, contact us or explore our Cloud WAF capabilities.

Post-Quantum Cryptography FAQ

What is post-quantum cryptography (PQC)?

Post-quantum cryptography is a set of public-key algorithms designed to remain secure against attacks from large-scale quantum computers. It replaces or augments classical algorithms like RSA and elliptic-curve cryptography, whose underlying math a sufficiently powerful quantum computer could break.

What is a “harvest now, decrypt later” attack?

“Harvest now, decrypt later” is a strategy in which adversaries collect and store encrypted traffic today so they can decrypt it once quantum computers become powerful enough to break classical public-key cryptography. Any data that will still be sensitive in five to fifteen years—healthcare records, financial transactions, intellectual property—is already a target.

What is ML-KEM (FIPS 203)?

ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) is the NIST-standardized post-quantum key exchange specified in FIPS 203, published August 13, 2024. Imperva pairs ML-KEM-768 with the classical X25519 key exchange to form a hybrid TLS handshake—giving every connection both classical and quantum-safe protection.

Why pair a quantum-safe algorithm with a classical one (hybrid TLS)?

Pure PQC algorithms are mathematically quantum-resistant but have had far less real-world cryptanalysis than RSA or elliptic-curve cryptography. A hybrid handshake runs both classical and PQC key exchange together: an attacker would have to break both to compromise the session. It is defense-in-depth for cryptography itself, and it’s the recommended posture for 2026.

Is Imperva quantum-safe today?

Yes. Thales Imperva’s PQC support, hybrid TLS combining X25519 and ML-KEM-768 for client-to-Imperva connections, reached general availability at the start of 2026. All Imperva sites have already been migrated. For setup details and current handshake scenarios, see the Imperva PQC support documentation.

The post The Clock Is Already Ticking: Why Post-Quantum Cryptography Can’t Wait appeared first on Blog.