The attacker used to look like an attacker. A strange request. A known exploit. A suspicious IP address. Something security teams could recognize, investigate, and block. Today, the attacker can look much more legitimate.
At Radware, we see this as one of the next challenges for application security. The impostor does not always try to break through the door. Sometimes, it walks through the same door as everyone else and tries to look like it belongs there.
The challenge for AI Threat Detection is becoming less about recognizing something that is already known, and more about recognizing when something that looks legitimate starts behaving differently. And as applications evolve, the impostor keeps changing.
The attack may start with a new vulnerability. Then it may appear as a browser session, a valid API request, an AI client using an exposed tool, or an autonomous agent making decisions on its own. The interface changes. The behavior changes. The attack surface changes. Security has to change with it.
The Impostor Finds a New Way In
The first problem is often the simplest: the attack is new.
When a new vulnerability is disclosed, there may be no established attack signature to rely on. Security teams may know that a vulnerability exists, but turning that knowledge into effective protection takes time. This creates a window between vulnerability disclosure and the moment an application is actually protected.
The impostor does not need to use an old technique. It can take advantage of something defenders have not seen before. This changes the role of AI threat detection. Instead of relying only on known patterns, security needs to help identify emerging threats, understand the vulnerability behind them, and accelerate the creation of protection before attacks become widespread.
But even when the attack is not new, recognizing the attacker is becoming harder.
The Impostor Uses a Browser
The next disguise is much more familiar: the browser.
Modern applications are built around browser interactions. JavaScript runs on the client. Cookies and tokens maintain sessions. Users move through multiple pages and workflows. Requests are generated dynamically and often look exactly like legitimate application traffic. An attacker can use the same browser technologies.
This makes the traditional question - “Is this a bot?” less useful on its own. The more important question becomes: “Does this actor behave like a trusted user?”
A request can be technically valid while the behavior behind it is suspicious. The actor may create sessions, execute JavaScript, maintain cookies, follow application flows, and make requests at rates designed to look human. Looking at individual requests is no longer enough. Security needs context around the actor and its behaviour.
The impostor is no longer simply trying to hide a malicious request. It is trying to look like a legitimate user.
The Impostor Has a Valid API Call
APIs take this problem one step further.
An API request can have a valid token. It can use a real endpoint. Its parameters can follow the expected schema. Nothing about the individual request looks malicious. And yet, the way the API is being used can still be an attack.
An actor may access resources it has never accessed before, make an unusual sequence of calls, change request patterns, or perform actions at a scale or frequency that does not match normal usage. The API contract has not necessarily been violated. The impostor has learned how to use the contract against the application.
This is why API security cannot stop at validating whether a request is syntactically correct or whether the identity is valid. Understanding normal API behavior and identifying deviations become increasingly important.
The security question moves from “Is this request valid?” to “Does this usage make sense for this actor?” This is another shift in AI Threat Detection: the individual request may be perfectly legitimate, while the behavior across many requests tells a very different story.
And now the impostor has another place to go.
The Impostor Gets Access to the Tools
AI applications are changing what an application can expose.
With the Model Context Protocol (MCP), AI clients can discover and interact with tools and resources made available by an application. A capability that was once used through a traditional API can now become something an AI client can discover and invoke.
That creates a new security visibility problem. Security teams need to understand what is exposed in the MCP manifest, which tools and resources exist, which clients are trying to access them, and how those capabilities are actually being used.
The challenge is not only protecting the MCP server itself. It is understanding what the application is making available through the protocol and what actors are trying to do with those capabilities.
This is where API and MCP security start to overlap. APIs expose application functionality. MCP can expose that functionality as capabilities that an AI client can discover and use. The same underlying application logic can therefore be reached through different interfaces and by very different types of actors.
The impostor has moved from abusing a request to exploring what it can make the application do.
The Impostor Becomes an Agent
Then the interaction changes again.
A traditional application request has a relatively simple flow: input, processing, and response. An AI agent can do much more. It can receive instructions, reason about it, decide what to do next, call a tool, retrieve information, perform an action, use the result, and continue.
The important change is that the system is no longer simply responding. It is acting.
This creates a security problem that cannot be solved by looking only at the original prompt or the final response. A prompt may be allowed. The model's response may be allowed. But the action taken afterward may still create risk.
For example, an agent may have legitimate access to several tools. The security challenge is understanding whether the sequence of decisions and actions is appropriate for the context in which the agent is operating.
The impostor has gone from requesting an action to deciding which actions to take. That is a very different security problem. And it means application security can no longer be defined only by the interface through which a request arrives.
One Impostor. Multiple Layers of Defense.
The browser, the API, MCP, and the agent may look like different security domains. From the application's perspective, they are connected. They are different ways for an actor to interact with the same application, data, tools, and capabilities.
That is the security challenge Radware is addressing: security needs to follow the actor, not just the interface.
The request may change. The identity may change. The protocol may change. The capabilities being accessed may change. What should not change is the need to understand what is happening and apply the right layer of protection.
This is also changing the role of Application Security Management. If these interactions are connected from the attacker's perspective, managing them as completely separate security problems creates gaps between the layers. This is where Radware's AI-driven application security capabilities work together with existing application protection.
Finding New Attacks Faster: Exploit Shield uses AI and vulnerability intelligence to help identify emerging threats and accelerate protection against newly discovered vulnerabilities.
When the Impostor Uses a Browser: Agent Trust Management extends the security view beyond whether traffic looks like a human or a bot, helping establish trust around the actor interacting with the application.
When the Impostor Has a Valid API Call or Reaches, an AI Tool: Behavioral API Security looks beyond individual valid requests to understand how APIs are being used. MCP Protection extends visibility and protection into the MCP layer, including visibility into the MCP manifest, WAF protection, and DDoS protection.
When the Impostor Becomes an Agent: LLM Firewall protects the interaction with the model, while Agentic AI Protection extends security into the behavior, decisions, tools, and actions of AI agents.
These capabilities are not replacements for the protection already deployed. They are additional layers. Because attackers do not stop when one door is protected. They come back and test another door. Another identity. Another API. Another tool. Another path into the application.
The goal is not to build one perfect defense for one type of interaction. It is to maintain security as the same actor moves between different interfaces and capabilities.
Treating browser security, API security, MCP security, and agent security as completely separate problems is becoming a dangerous assumption. The same actor can move between them, and security architecture needs to move with it.
Effective AI Threat Detection therefore becomes part of a broader Application Security Management strategy: continuously understanding what is happening across the application, identifying how the attack surface is changing, and applying the right protection layer as the interaction evolves.
The Impostor Will Keep Knocking
The new frontier of application security is not about finding one perfect way to recognize an attacker. It is about understanding the actor behind the interaction, understanding its behaviour, and protecting the actions it can take - regardless of the disguise it chooses.
The impostor may change its identity. It may change its interface. It may change its protocol. It may even change from making requests to making decisions. But the objective remains the same: find a way to use the application in a way it was never intended to be used.
AI Threat Detection is therefore not just about detecting the next attack. It is about giving application security the context to recognize when the way an application is being used starts to change.
The question for security teams is no longer simply whether they can detect a malicious request.
Does your security architecture understand the request - or does it understand the actor?