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 forthcoming 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.

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.

Through CVE-2026-17106, an attacker-controlled container could turn a routine file copy into two powerful outcomes:

Host file overwrite: creating or replacing any file writable by the user running docker cp, including shell configuration, executables, SSH configuration, source code, and persistence mechanisms.

Code execution: Executing attacker-controlled code as the logged-in user on macOS or, when docker cp runs with elevated privileges on Linux, achieving root code execution immediately after the command completes by overwriting the runc binary.

The exploit chains two weaknesses in Docker’s archive pipeline: a filesystem race that lets a running container produce an inconsistent tar archive, and an extraction flaw that allows the Docker CLI to follow a planted symlink outside the intended destination.

Together, these weaknesses turn the user’s own Docker CLI into a write primitive. The attacker controls the container and its files, the CLI supplies access to the host filesystem.

The docker cp command is routinely used to retrieve build artifacts, test results, logs, and forensic evidence from containers. This makes the vulnerability particularly relevant to CI systems, developer workstations, privileged automation, and incident-response workflows. In the last case, simply collecting evidence from a compromised container could activate the payload waiting inside it.

The impact also reaches AI-agent workflows. Docker Sandboxes uses sbx cp to move files between an isolated agent environment and the host. Docker Sandboxes 0.38.0, released August 6, identifies and fixes a “destination-escape flaw in sbx cp copy-out” under CVE-2026-17106. This means retrieving an artifact produced inside an untrusted or compromised coding-agent sandbox could expose the host to the same class of destination escape.

From a Simple Copy to a Host Write

The command that started this research could hardly look more ordinary:

docker cp container:/path/to/file.txt ./file.txt

The source is inside the container. The destination is chosen by the user. The expected security boundary seems obvious: Docker should write to ./file.txt and nowhere else.

But docker cp is not a direct filesystem-to-filesystem copy.

When copying from a container, the Docker daemon walks the container’s live filesystem and turns the selected path into a tar archive. The Docker CLI receives that archive and extracts it on the client machine.

This architecture creates a powerful connection between two security domains. The container controls the archive contents, while the local CLI performs the resulting filesystem operations with the permissions of the person or process that invoked docker cp.

For this design to remain safe, Docker needs to preserve two properties:

1. The daemon must produce a coherent archive from the container’s filesystem.
2. The CLI must confine every extracted object to the destination selected by the user.

We found a way to break both properties in the same copy operation.

Impact

The vulnerability provides an arbitrary file create or overwrite primitive within the permissions of the Docker CLI process.

The malicious container does not automatically inherit root privileges from dockerd, and exploitation requires a user or automated system to invoke docker cp against the attacker-controlled path.

But the final write occurs on the machine running the CLI, with the authority of that user-not with the permissions of the process inside the container.

We validated the exploit on Linux with Docker Engine 29.6.1 and on macOS with Docker Desktop 4.81.0 (232925).

Developer Compromise on macOS

Docker Desktop runs the daemon inside a Linux virtual machine, but a container-to-local docker cp operation is extracted by the CLI running on macOS.

This means the archive crosses the VM boundary before the vulnerable operation occurs. The symlink is followed by a process on the Mac, and its target is interpreted in the Mac’s filesystem namespace.

A malicious container could therefore target files such as shell startup scripts, user-level executables, SSH configuration, source trees, cloud configuration, or persistence mechanisms under ~/Library/LaunchAgents. Overwriting a shell startup file could execute the attacker’s code the next time the user opens a terminal.

The container does not need to escape the Docker Desktop VM directly. It convinces the local CLI to perform the write on its behalf.

Root Code Execution on Linux

On Linux, the daemon and CLI commonly run on the same host. The write still carries the CLI user’s permissions.

For an ordinary user, the attacker can reach files writable by that account. If an administrator, CI worker, or maintenance process invokes sudo docker cp, the operation can reach root-owned system paths.

In our proof of concept, we replaced /usr/bin/runc with a shell script. A later Docker lifecycle operation executed the replaced binary and created a marker file as root.

The exploit did not obtain root from the Docker daemon. The copy already had enough authority to replace runc, and the later execution converted that file write into root code execution.

The Archive That Described Two Filesystems

The first part of the chain was in the archive producer.

Both the Moby and Docker CLI source trees we reviewed used github.com/moby/go-archive v0.2.0. For a container-to-local copy, Moby’s containerArchivePath creates a tarballer and runs it inside the container filesystem:

Source: Moby containerArchivePath, Docker Engine 29.6.1, lines 76–82.

Docker locks the container object while the archive is read, but that lock protects Docker’s internal state. It does not freeze processes running inside the container.

Those processes can continue renaming files, replacing directories, and creating symlinks while the daemon walks the source tree.

The tarballer performs that walk with filepath.WalkDir:

Source: moby/go-archive v0.2.0 archive walk, lines 691–802.

WalkDir reads a directory entry and records its type. If the entry is a directory, the walker plans to descend into it.

The callback then passes the pathname to addTarFile, which looks it up again with Lstat to create the tar header:

Source: moby/go-archive v0.2.0 addTarFile, lines 295–317.

The same pathname now answers two different questions at two different times:

Traversal decision: is this entry a directory that WalkDir should enter?

Archive metadata: is this entry a file, directory, or symlink that should be written to the tar stream?

If the path changes between those observations, the two answers no longer need to agree.

Turning the Race into a Reliable Primitive

In our proof of concept, /watched/file.txt is intentionally deceptive. An LD_PRELOAD interposer makes it appear to be a regular file to processes inside the container by redirecting exact accesses to a hidden backing file, /watched/.file.txt.regular. The Docker daemon, however, sees the underlying file.txt path as a directory and can walk the attacker-controlled tree beneath it.

The walker initially sees the following directory:

After WalkDir records escape as a directory, the attacker moves it aside and replaces it with a staged symlink:

The switch requires only two rename operations, winning a filesystem race blindly would be unreliable, so we gave the container a clock.

Our proof of concept places a large file immediately before the pivot directory and monitors it with filesystem notifications. When the daemon opens that file, the attacker knows the walk has reached the right location. The large file widens the timing window, and the notification signals when to perform the two renames.

What begins as a race becomes a repeatable sequence.

After the switch, addTarFile sees a symlink and emits a symlink header for file.txt/escape. Control then returns to WalkDir, whose earlier directory entry still says that escape is a directory. The walker descends through the same pathname and adds a child beneath the symlink’s archive name.

The resulting tar stream contains two entries:

Each entry is understandable on its own. Together, they describe two different moments in the source filesystem: escape is represented as a symlink, while its child is represented as though escape were still a directory.

At this point, the container has produced an inconsistent archive. That alone should not be enough to write outside the destination. The client still controls extraction and can reject the dangerous sequence.

It did not.

The Extractor Checked One Path and Created Another

For a copy from a container, the Docker CLI eventually reaches archive.CopyTo:

Source: moby/go-archive v0.2.0 CopyTo, lines 418–437.

Neither option confines traversal through an intermediate symlink. The vulnerable symlink handling attempted to perform its own containment check:

Source: moby/go-archive v0.2.0 symlink extraction, lines 480–492.

The validation and the filesystem operation use different values.

The containment check validates targetPath, a path constructed with filepath.Join. The subsequent os.Symlink call receives the original hdr.Linkname from the archive.

For an extraction path of /safe/output/file.txt/escape and a link target of /usr/bin, the validation evaluates:

That constructed path appears to remain under /safe/output, so the check approves it. Docker then gives the original absolute target to the kernel:

The check approves one path. The filesystem creates another.

The same condition has an additional weakness: string prefixes do not represent path containment. A path such as /safe/output-elsewhere also begins with /safe/output. Our chain already had what it needed from the checked-value-versus-used-value mismatch.

The extractor then processes the child entry, file.txt/escape/runc.

Docker cleans the archive name, joins it to the destination, and checks for a lexical ../ escape, but the child entry contains no ../. As text, it remains beneath the destination.

The previous tar entry has changed what the pathname means on disk. Before creating the child, the vulnerable extractor does not re-establish confinement against the resolved target:

Source: moby/go-archive v0.2.0 addTarFile, lines 295–317.

When the file is created, the kernel follows escape -> /usr/bin. The attacker’s bytes land at /usr/bin/runc on the Docker client rather than under /safe/output.

The full chain is:

1. WalkDir records escape as a directory.
2. The container replaces it with an absolute symlink.
3. addTarFile emits the symlink into the tar stream.
4. WalkDir descends using its earlier directory type and emits a child entry.
5. The CLI validates a constructed target but creates the original absolute symlink.
6. The CLI extracts the child through that symlink and writes outside the destination.

One stale directory entry and one ineffective containment check were enough to turn docker cp into a host write.

From Host Write to Host Compromise

At this point, the copy operation is no longer confined to the destination chosen by the user. The attacker-controlled container has gained a write primitive on the Docker client, with the permissions of the process running docker cp.

What happens next depends on those permissions. A copy launched by a developer could target user-writable startup files, shell configuration, source code, or persistence mechanisms. If the command runs as root, as is common in automation and some Linux environments, the same primitive could reach system executables and privileged configuration, turning the file write into root code execution.

The vulnerability simply prepares the malicious filesystem and waits. The trigger may be a developer retrieving a build artifact, a CI job collecting test results, or an incident responder copying evidence from a container they already suspect is compromised.

In each case, the operation intended to take data safely out of the container becomes the step that carries the attack back onto the host.

Mitigations

Users should upgrade to Docker Engine and CLI 29.7.2 or later, and Docker Desktop 4.86.0 or later.

Where upgrading is not immediately possible:

• Avoid copying from running, untrusted, or compromised containers onto a sensitive client.
• Stop the container before copying. Docker supports copying from a stopped container, preventing a live process from performing the race used in this chain.
• Avoid sudo docker cp and root-run copy automation.
• Run the Docker CLI with the least privilege required for the workflow.
• Retrieve data from suspicious containers using a disposable account, VM, or similarly isolated environment.

Stopping the container blocks the producer race demonstrated here. It does not replace safe extraction: any archive originating from an untrusted source should still be treated as hostile input.

Conclusion

Container boundaries are not defined only by namespaces, virtual machines, or the Docker daemon. They also depend on the client-side tools that move data across those boundaries.

docker cp connects a live, attacker-controlled filesystem to an extractor running with the user’s authority. That design requires both sides of the pipeline to preserve a strict contract: the archive must be coherent, and every extracted object must remain inside the destination.

CVE-2026-17106 broke that contract. The daemon observed one pathname as two different objects, producing a symlink followed by its apparent child. The CLI then validated one path, created another, and allowed the child entry to cross onto the client filesystem.

The most important lesson is simple: archive extraction is a security boundary. Path normalization and string-prefix checks cannot enforce that boundary once symlinks and concurrent filesystem changes are involved. Filesystem operations must be rooted so that the kernel, not a string comparison, guarantees where the write can land.

We responsibly disclosed the vulnerability to Docker and delayed publication several times to align disclosure with a usable patch. We would like to thank Docker’s security and engineering teams for investigating the report, coordinating the CVE, and working through the regressions introduced by the initial fix.

Responsible Disclosure Timeline

April 11, 2026 – We reported the vulnerability to Docker with technical details and reproduction information.

April 14, 2026 – Docker acknowledged receipt and began reviewing the report.

April 15, 2026 – Docker confirmed the behavior as a valid finding and explained its assessment of the client-side privilege boundary.

July 10, 2026 – The initial 90-day disclosure period elapsed without a public patch. We requested a concrete remediation, advisory, and publication schedule.

July 14, 2026 – Docker described two remediation tracks: extraction-library hardening as the primary security fix and source-walk hardening as follow-up work. We agreed to delay publication while the fixes were prepared.

July 24, 2026 – Docker provided CVE-2026-17106 / GHSA-hfg8-hc9c-6c3h and targeted an August 3 coordinated release.

July 27, 2026 – Docker confirmed that the source-walk TOCTOU would not receive a separate CVE and would instead be addressed as defense-in-depth hardening.

July 30, 2026 – moby/go-archive v0.3.0 and Docker Engine/CLI 29.7.0 shipped the extraction fix.

July 31, 2026 – Docker reported significant functional regressions caused by the initial hardening and requested a final extension to August 10. Follow-up go-archive and Engine releases addressed the regressions.

August 1, 2026 – We agreed to extend coordinated disclosure to August 10.

August 6, 2026 – Docker Sandboxes 0.38.0 shipped a fix for a destination-escape flaw in sbx cp copy-out under CVE-2026-17106. Docker also confirmed that the Docker Desktop update remained scheduled for August 10.

August 10, 2026 – Docker released Docker Desktop 4.86.0, bundling Docker Engine 29.7.2 and delivering the corresponding Docker Desktop fix.

The post CopyEscape: Taking Over Docker Hosts with docker cp appeared first on Blog.

On August 6, 2026, WordPress released version 7.0.3 with security fixes that include a pre-authentication reflected cross-site scripting vulnerability on the login screen with the potential to lead to PHP code execution. The issue is tracked as CVE-2026-64638 and is rated High severity with a CVSS score of 8.9.  

About XSS2Shell 

The vulnerability starts on the WordPress login page. When a login attempt uses an invalid username, WordPress includes that value in an error message returned to the browser. The security researchers found that the value is processed by multiple HTML sanitization components that do not interpret certain malformed markup in exactly the same way.  

That parser disagreement can allow attacker-controlled HTML elements to survive the first sanitization step and later become active elements in the browser. On its own, this is not yet JavaScript execution, but the researchers showed how the injected elements can interact with JavaScript that WordPress already loads on the login page.  

The result is reflected XSS in the security context of the affected WordPress site, without the attacker first needing a WordPress account.  

From Reflected XSS to Server Compromise 

The significance of XSS2Shell comes from the way several otherwise legitimate browser and WordPress features can be chained together. The researchers demonstrated that the XSS primitive can be used to trigger same-origin requests and interact with WordPress REST functionality. Against a logged-in administrator, the chain can then reach privileged WordPress capabilities and ultimately lead to PHP code execution on the server.  

At a high level, the chain is: unauthenticated malicious input -> reflected XSS on the WordPress login page -> JavaScript execution in the WordPress origin -> abuse of a logged-in administrator session -> privileged WordPress actions -> PHP code execution. 

An important distinction is that CVE-2026-64638 should not be described as a zero-interaction unauthenticated RCE. The official WordPress advisory states that escalation to RCE requires successful social engineering and explicit interaction by the target victim. In practice, the full chain targets a user who is already authenticated with sufficient WordPress privileges.  

Why This Vulnerability Matters 

It is in WordPress Core. The vulnerable behavior is part of WordPress itself rather than a third-party plugin or theme. No attacker account is required for the initial XSS. The vulnerability is reachable pre-authentication from the login screen. It demonstrates the risk of exploit chaining. What begins as a parsing inconsistency becomes significantly more serious when combined with browser behavior, WordPress JavaScript, REST functionality, and administrator capabilities. The potential impact is high. If the complete chain succeeds, an attacker can reach server-side PHP code execution, affecting confidentiality, integrity, and availability.  

Affected WordPress Versions and Patch 

WordPress states that the issue affects all versions of WordPress. Version 7.0.3 contains the fix, and WordPress has backported the security change through branches eligible for security fixes, currently down to the 4.7 branch. The corresponding patched releases include 6.9.6, 6.8.7, 6.7.6 and equivalent maintenance releases for older supported branches.  

WordPress recommends that sites update immediately. Sites that support automatic background updates will begin receiving the security release automatically, but administrators should verify that the update completed successfully. 

How Imperva Protects Customers 

Imperva’s AI-powered security engine is designed to help protect customers against the next generation of AI-assisted attacks.  

Rather than relying solely on known payloads or static signatures, Imperva uses strict protocol validation, behavioral analysis, anomaly detection, and continuous threat intelligence to detect and mitigate zero-day attacks and previously unseen malicious traffic patterns. This layered approach enables Imperva to respond rapidly when attackers or AI-driven research tools uncover novel techniques or new emerging threats, helping ensure customers remain protected even as zero-day discovery and exploitation become increasingly automated and fast-moving. 

Imperva has since observed widespread activity targeting more than 11,000 distinct websites across 67 countries. Hundred thousands of requests were already recorded indicating broad, highly automated targeting rather than isolated attempts against a small number of organizations. More than 95% of the tools associated with this activity were written in Go, while over 75% of targeted websites were in the United States. Gaming was the most frequently targeted industry, accounting for 32% of observed sites, followed by education at 26% and financial services at 24%. 

Recommended Actions 

Update WordPress immediately. Sites on the 7.0 branch should update to WordPress 7.0.3 or later. Organizations on older maintained branches should install the corresponding patched maintenance release.  

Verify automatic security updates. Do not assume the patch was applied successfully; confirm the running WordPress version on production systems. 

Keep Imperva protections current. Cloud WAF customers receive managed security-rule updates. On-Prem WAF customers should maintain current product and security-content updates in accordance with Imperva guidance. 

Review privileged accounts and credentials. Investigate unexpected administrator changes, application credentials, plugin installations, or other privileged actions on systems that remained vulnerable after disclosure. 

Reduce administrator exposure to untrusted content. The full RCE chain requires interaction by a target victim, so administrators should avoid opening untrusted links while authenticated to sensitive WordPress environments. 

AI-Assisted Vulnerability Discovery 

XSS2Shell is also notable because of how the complete chain was developed. The security researchers state that they’ve used open-source AI models and a multi-agent research workflow, starting from earlier Same Origin Method Execution (SOME) research, and that the system took nearly four days to build the full chain.  

The finding illustrates how AI-assisted security research can connect subtle behaviors across multiple layers of a complex application. For defenders, it reinforces the value of layered controls that can stop an exploit chain at more than one stage instead of relying only on a vulnerability-specific patch. 

Bottom Line 

CVE-2026-64638, or XSS2Shell, shows how a subtle parsing inconsistency in a widely deployed platform can become far more serious when chained with legitimate browser and application functionality. WordPress has released fixes, and administrators should patch immediately.  

Imperva Cloud WAF and On-Prem WAF customers are protected against exploitation attempts associated with CVE-2026-64638. Existing XSS and application-security protections block the malicious input used to initiate the attack chain, and Imperva has further fortified mitigation after reviewing the newly disclosed techniques. 

The post Imperva Customers Protected Against XSS2Shell (CVE-2026-64638) in WordPress Core appeared first on Blog.

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.

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?

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.

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.

The conversation that the user sees may therefore represent only a small part of what the agent is actually doing. Many of its actions take place quietly in the background, without being clearly presented to the user or the security team. 

This creates a significant visibility challenge for security teams. Organizations may not know which AI-powered applications are active on developer machines, what those applications are doing, or whether their behavior aligns with company policies.  

An agent does not need to be malicious to create risk. While trying to complete a task, it may interpret instructions too broadly and access information the user did not intend to expose or perform actions that extend beyond the original request. 

The Endpoint Visibility Gap 

Traditional endpoint security controls may capture individual parts of an agent’s activity without revealing their significance. An IDE or terminal process accessing a sensitive file, such as an .env file, may appear to be routine development activity. But if the process is controlled by an AI agent that has already communicated with an LLM provider, the same event has a very different security meaning. The developer may not have chosen to open the file at all. The agent may have accessed it autonomously while trying to complete a task.  

Without connecting these events to the agent responsible for them, security teams may interpret autonomous agent behavior as ordinary user activity. This challenge is amplified by the fact that AI capabilities are not limited to a fixed set of recognizable applications. Traditional security controls can often map, classify, or restrict known software, but almost any Python script, IDE extension, command-line tool, or internal application can gain agentic capabilities by connecting to an LLM and acting on its responses. This makes application-based detection difficult. Blocking the underlying application or interpreter is usually not practical because the same software is also used for legitimate work.  

As a result, application-based allowlists and blocklists cannot provide sufficient visibility or control on their own.  

The real challenge is therefore not just detecting a process, file access event, command execution, or network connection. It’s determining whether that activity was initiated by the developer or autonomously by an AI agent. 

From AI Discovery to Behavioral Understanding 

Identifying an AI-enabled process is only the first step. Security teams must also understand how its behavior develops throughout the session. 

After receiving instructions or model output, an agent may create child processes, execute shell commands, inspect local files, access sensitive directories, or initiate additional network connections. The sequence of these actions can reveal how the agent interpreted its task and whether its behavior moved beyond what the user expected. 

This behavioral context becomes especially important during an investigation. A single command, file access event, or outbound connection may appear legitimate when viewed alone. When these events are connected chronologically, however, they may reveal a very different story: the agent encountered new input, changed its behavior, accessed a sensitive resource, and then attempted to communicate with an external destination. 

The goal is not only to identify that an AI agent was active, but to reconstruct its activity and understand the relationship between the agent, its subprocesses, the resources it accessed, and the destinations it contacted.

Introducing ShadowAI-Watch 

This is why we created ShadowAI-Watch, an open-source runtime discovery and behavioral monitoring tool for AI-powered applications and agents. 

ShadowAI-Watch runs independently on the user’s machine and does not require changes to the monitored application. It provides a host-level view of AI agent activity by correlating processes with outbound LLM connections and tracing the actions that follow. 

The tool is designed to identify custom AI agents, coding agents, browser agents, LLM-powered applications, and locally hosted models, including applications that may not have an obvious AI-related process name. 

ShadowAI-Watch supports multiple privilege levels, ranging from a low-privileged user to full administrative access. With limited privileges, it inspects process information available through /proc to discover agentic applications. With elevated privileges, it enables its full eBPF-based monitoring mechanism, providing deeper and more precise visibility into process and system activity. 

ShadowAI-Watch Workflow 

ShadowAI-Watch runs locally on the user’s machine and continuously monitors outbound network activity across running processes. When a process connects to a known large language model provider, the tool identifies it as AI-related and traces the process tree to determine which application initiated the connection. 

It then continues observing the session and correlates subsequent commands, child processes, file access, and network activity with the identified application.  

Together, these events create a chronological record of the agent’s runtime activity and the sequence that led to each action. 

These events are written to a JSON Lines audit file and displayed live in the terminal using color-coded output. The audit data can also be sent to a remote dashboard for visualization and risk analysis. This gives security teams both immediate visibility while the agent is operating and a structured audit trail that can be examined after the session. 

The released repository includes the components responsible for generating logs and structured audit records. Organizations can use this data to build their own dashboards, monitoring workflows, or integrations based on their specific requirements. 

ShadowAI-Watch workflow 

Watching a Browser Agent Get Hijacked 

The demo begins with a simple request: summarize a website by opening a URL and following the links it contains. 

To the user, this looks like an ordinary browsing task. The BrowserUse agent opens the site, moves between pages, and gathers the information it needs. In the background, ShadowAI-Watch discovers the agent, identifies it as BrowserUse, and begins tracing its activity in real time. 

At first, everything proceeds as expected. 

Then the agent reaches a page containing an instruction that did not come from the user. It was placed there by an attacker and attempts to convince the agent to open an external URL and transmit session data to an attacker-controlled endpoint. 

The agent follows the instruction. 

From the developer’s perspective, the agent still appears to be navigating the website as requested. The malicious request is hidden within the normal browsing flow and could easily go unnoticed. 

ShadowAI-Watch sees a different story. 

It sees the agent reach the page containing the indirect prompt injection. It then observes the agent’s behavior change and detects its attempt to connect to a destination unrelated to the original task. Instead of treating the request as isolated browser traffic, ShadowAI-Watch links it to the active BrowserUse session and to the attacker-controlled content that preceded it. 

What appeared to be routine browsing is revealed as an agent hijacking sequence: a legitimate task, exposure to a malicious instruction, a change in behavior, and an attempted transmission of sensitive data. 

The video below shows that sequence unfolding in real time, from the discovery of the BrowserUse agent to the detection of the malicious outbound connection. 

See ShadowAI-Watch at DEF CON 34 

Our team will present ShadowAI-Watch in the AppSec Village Arsenal at DEF CON 34 during the session, “The Agent Asked. We Allowed. Now What?” 

ShadowAI-Watch is available as an open-source project for Linux, with macOS support coming soon. Access the repository and learn how to get started here: https://github.com/ThalesGroup/shadowai-watch 

The post ShadowAI-Watch: Bringing AI Agent Activity Out of the Shadows appeared first on Blog.

Understanding HTTP Desync Attacks 

Modern web applications rarely receive requests directly from users. Traffic commonly passes through several components, such as a CDN, load balancer, reverse proxy, or WAF, before reaching the application server. 

An HTTP desync vulnerability occurs when two of these components disagree about where one request ends and the next begins. A front-end system may treat a sequence of data as one complete request, while the back-end interprets part of the same data as the beginning of another request. This parsing difference can allow an attacker to smuggle traffic past front-end security controls. 

Depending on the affected architecture, successful exploitation can lead to security-control bypasses, cache poisoning, access to restricted functionality, or response queue poisoning. In a response queue poisoning attack, a response intended for one user may be delivered to another, potentially exposing sensitive information. 

HTTP/1.1 is particularly exposed to this class of problem because request boundaries can be represented in multiple ways, and products do not always handle malformed or unusual combinations consistently. 

What’s HTTP Terminator? 

The HTTP Terminator is an autonomous research system designed to generate, evaluate, and refine potential protocol attacks. Using small fragments of protocol specifications as inspiration, it generated about 30,000 unique desync vectors in testing and evaluated them against websites where testing was authorized through vulnerability disclosure or bug bounty programs. 

The research ultimately demonstrated many novel desync triggers, one new desync pattern, and one new weaponization technique. It also introduced Shared-Parser Confusion, a broader attack concept that may extend beyond request smuggling. 

New and Unexpected Desync Triggers 

Traditional request-smuggling testing often focuses on conflicts involving the Content-Length and Transfer-Encoding headers. The new research shows that parsing differences can also be triggered by less obvious HTTP features, including unusual request methods, unexpected method-and-body combinations, uncommon transfer encodings, duplicate headers, and content types normally associated with responses.  

One notable example involved the multipart/byteranges content type. According to the research, this behavior affected more than 200 websites in the authorized target set and appeared across multiple server implementations. The lesson for defenders is clear: protection cannot rely only on a short list of well-known request-smuggling payloads.  

Dual Matching Content-Length Headers 

Security controls commonly look for requests containing conflicting Content-Length values. The research showed that some systems can also behave unexpectedly when a request contains two matching Content-Length headers. Although the values appear consistent, components in the request chain may still process the duplicate headers differently and disagree about whether the request has a body or where it ends. 

This pattern was exploitable in real deployments, including an environment where response queue poisoning exposed a long-lived API key. The underlying issue was later linked to a server misconfiguration. 

The Dangling-Byte Technique 

Response queue poisoning has often been unreliable because the front end may notice an unexpected extra response and close the connection before the attack succeeds. The dangling-byte technique improves reliability by sending an incomplete smuggled request that is missing one byte. The next legitimate request supplies that byte, completing the attacker’s request only after the victim’s traffic arrives. 

In the tested scenarios, this removed a significant timing race and made response theft substantially more reliable on affected architectures. 

Shared-Parser Confusion 

The research also introduced Shared-Parser Confusion. Some implementations reuse parsing logic for both HTTP requests and HTTP responses. As a result, functionality intended for processing responses may accidentally be activated by attacker-controlled data inside a request. 

This expands the potential attack surface beyond ordinary request-processing behavior. Response-specific headers, content types, and parser rules may also influence how a malicious request is interpreted.  

How Imperva Protects Customers 

Imperva’s AI powered security engine is designed to help protect customers against the next generation of AI-assisted attacks, including systems like HTTP Terminator that can generate and test large volumes of novel protocol variations. Rather than relying only on known payloads or static signatures, Imperva combines strict protocol validation, behavioral analysis, anomaly detection, and continuous threat intelligence to identify malicious or ambiguous traffic patterns at scale. This approach allows Imperva to respond quickly when attackers or AI-driven research tools uncover new ways to abuse protocol edge cases, helping ensure that customers remain protected even as attack discovery becomes more automated and faster-moving.

Imperva’s protection against HTTP desync attacks does not depend on one vulnerability-specific signature. Cloud WAF and On-Prem WAF use dedicated security rules and protocol-validation controls designed to identify malformed, conflicting, and ambiguous HTTP requests before they reach protected applications. 

These protections cover behavior commonly associated with desync and request-smuggling attacks, including: 

• Invalid or ambiguous HTTP message framing 
• Redundant, duplicated, or conflicting request headers 
• Malformed protocol elements and abnormal request structure 
• Suspicious combinations of methods, headers, and message bodies 
• Attempts to embed an additional HTTP request within an existing request 
• Known request-smuggling and response queue poisoning patterns 

Imperva’s analysis determined that existing protections were already blocking the primary practical attack patterns described in the HTTP Terminator research. Following a detailed review of the newly published vectors, Imperva also fortified its mitigation to provide additional coverage for the newly documented parsing variations. 

Imperva telemetry shows that these protections are actively blocking real-world exploitation attempts, especially using desync techniques. Observed POST bodies include payloads characteristic of the HTTP Smuggler Burp Suite extension, with embedded or malformed request lines, randomized paths, and synthetic headers intended to reveal parsing discrepancies between front-end and back-end systems. Examples of blocked payloads include: 

TRACE /?x=yz HTTP/1.1 
TRACE / HTTP/1.1 X-YzBqv: = 
GET / HTTP/2.2 X-YzBqv: 
TRACE /wrtzllsk1005516x1x6 HTTP/1.1 
GET /tRmNtR1g00ir3d HTTP/1.1 

These requests are not normal application traffic. They are crafted probes designed to test whether components in an HTTP request chain disagree about request boundaries or interpret an embedded request differently. Imperva blocked these attempts before they reached protected applications, demonstrating that the threat is already being explored in the wild and that existing desync protections are providing practical coverage. 

Cloud WAF customers receive managed protection updates as part of the service. On-Prem WAF customers should enable dedicated available controls such as Response Forking – HTTP Desync policy (if not enabled) to mitigate these attacks. 

Recommended Best Practices 

Imperva provides protection against the practical attack techniques described in the research, but organizations should also reduce the underlying risk within their application delivery architecture. 

1. Keep infrastructure components updated. Apply vendor patches to web servers, reverse proxies, application delivery controllers, API gateways, CDNs, and load balancers. 
2. Reject ambiguous HTTP requests. Do not forward requests containing duplicate framing headers, invalid transfer encodings, or malformed protocol syntax to backend systems. 
3. Restrict unnecessary HTTP methods. Allow only the methods required by the application, and define which methods may legitimately contain a request body. 
4. Prefer HTTP/2 or newer protocols upstream. Imperva Cloud WAF allows clients-to-WAF HTTP/2 support and also WAF-to-origin server HTTP/2 support. 

 On Prem WAF also supports HTTP/2 traffic inspection. 

Conclusion 

The HTTP Terminator research demonstrates both the continuing security challenges of HTTP/1.1 and the growing ability of AI-assisted systems to discover unexpected protocol behavior at scale. 

It also highlights why defense against HTTP desync attacks must be based on strict protocol validation and broad behavioral coverage, not only signatures for previously published payloads. 

Imperva Cloud WAF and WAF Gateway customers are protected against the practical desync techniques described in the research. Existing dedicated security rules were already blocking the associated malicious request patterns, and Imperva has further fortified these protections in response to the newly published findings. 

Imperva Threat Research will continue monitoring this area and emerging HTTP parsing techniques to protect customers as the threat landscape evolves. 

The post Imperva Customers Protected Against Novel HTTP Desync Attacks appeared first on Blog.

That diagram was accurate for about eighteen months. It is not accurate anymore.

Look inside a modern AI application and the chatbot is the least interesting thing in it. There are agents living inside the application, making decisions and calling functions without a human typing anything. There are MCP servers sitting outside the application, connecting models to real systems and live data. There are tools (scripts, APIs, plugins) that the model can invoke, retrieved documents flowing into context windows, and orchestration layers deciding which agent hands work to which. The application is no longer app-plus-LLM. It is an ecosystem.

What is agentic AI security?

Agentic AI security is the practice of securing AI applications that take actions, not just applications that answer questions. It covers the whole AI execution path: the agents making decisions, the tools and APIs they invoke, the MCP servers connecting them to live systems, the documents retrieved into context, and the orchestration layer routing work between agents. Prompt inspection alone covers only the first hop.

That matters for one uncomfortable reason: security architectures inherit their assumptions from the diagrams they were designed against. If your AI protection assumes a single conversation crossing a single boundary, it is defending an architecture nobody runs anymore.

What changed in the AI attack surface

Three things, in quick succession.

First, agents started taking actions. A chatbot that gives a wrong answer is embarrassing. An agent that acts on a manipulated instruction is an operational incident. It can query a database, call an API, or trigger a workflow before any human notices. The blast radius of a successful prompt injection grew from “bad reply” to “bad transaction.”

Second, the Model Context Protocol and similar tool-integration patterns arrived. MCP is useful: a standard bridge between AI assistants and real systems. It is also, by definition, an expansion of the attack surface. Every tool a model can reach is something an attacker can try to reach through the model. We unpack those exposures in detail in MCP Server Security: The Blind Spot in Your AI Stack (https://www.imperva.com/blog/mcp-server-security-blind-spot-ai-stack/).

Third, the interactions multiplied. It is no longer one train rolling through one tunnel, one prompt in and one response out. It is internal communication between sub-agents, external calls to MCP servers, retrieval from knowledge stores: traffic that never touches the chat window at all.

The honest question: would you know what your agents just did?

The challenge isn’t simply preventing prompt injection attacks anymore. It’s understanding everything the application is capable of doing.

So here is the question worth asking your team this week: if an agent inside one of your applications called a tool it had never called before, would anyone know?

For most organizations, the honest answer is no. Not because the security team is behind, but because the visibility layer for this architecture is only now being built. You cannot govern what you cannot see, and most of what modern AI applications do is currently unseen.

That is where AI application security is heading as a discipline: away from inspecting a single conversation, toward securing the entire AI execution path: discovering every AI asset in the environment, understanding how agents, models, and tools actually relate to each other, and enforcing policy on the interactions that matter.

The chatbot era gave us a clean diagram and a comforting inspection point. The agent era gives us an ecosystem. Security is moving with it. The teams that update their mental diagram first will be the ones that are not surprised later.

Frequently asked questions about agentic AI security

What is the difference between LLM security and agentic AI security?

LLM security protects the conversation: what goes into the model and what comes back out. Agentic AI security protects what happens next – the tools the agent calls, the systems it reaches through MCP, the data it retrieves, and the handoffs between agents. The blast radius of a successful attack grows from a bad reply to a bad transaction.

Why isn’t prompt inspection enough for AI agents?

Because most agentic traffic never touches the chat window. Sub-agent communication, MCP tool calls and retrieval from knowledge stores all happen behind the prompt. An inspection point placed on the user conversation sees none of it.

What are the main agentic AI security risks?

The OWASP Top 10 for Agentic Applications (2026) names agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.

How do you get visibility into what AI agents are doing?

Start with discovery: inventory every AI asset in the environment – models, agents, tools and MCP servers – then map how they relate to each other, then enforce policy on the interactions that matter. You cannot govern what you cannot see.

Does Imperva secure AI agents and MCP servers?

Imperva AI Application Security protects LLM-backed applications today. Thales announced the AI Security Fabric in December 2025, with an MCP security gateway and end-to-end runtime access control for agentic AI interactions on the 2026 roadmap.

Thales’s Imperva AI Application Security protects the AI powering your business applications, from LLM-backed chatbots to agents, RAG pipelines, and MCP-connected tools. Thales announced the AI Security Fabric in December 2025, adding an MCP security gateway and runtime access control for agentic AI interactions to the 2026 roadmap. See how it works here or read more in our white paper: Beyond the LLM Top 10 (Coming Soon)

The post Agentic AI Security: The Chatbot Era Is Already Over appeared first on Blog.

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.