What is application detection and response (ADR)?
Application detection and response (ADR) is an application security approach that detects and stops attacks from inside running applications. Because it watches real code paths, library calls, and requests at runtime, it catches abuse that looks like normal traffic from the outside.
ADR platforms operate directly within the application environment rather than at the perimeter or network layer. That inside view fills a long-standing gap in web application security, where most controls stop at the network edge.
When threats are detected, ADR solutions alert security teams with highly contextual information. The goal is to stop application attacks before they escalate.
The 2026 Cloud Threat Report
Wiz Research traced how cloud intrusions in 2025 started: mostly weaponized vulnerabilities, exposed secrets, and misconfigurations. It's a useful baseline for tuning your own runtime detections.
How ADR evolved from WAFs and RASP
For years, teams secured the application layer with network firewalls and web application firewalls (WAFs), which are popular for their easy setup. But WAFs operate at the perimeter and rely on rule-based filtering of network traffic, which often turns into an unmanageable set of changing rules. Blind to what happens once a request reaches your code, they often deter only low-level attacks.
That blind spot matters as attackers go after unpatched flaws. A joint advisory from CISA, the FBI, and the NSA found attackers exploited more zero-day vulnerabilities to compromise enterprise networks in 2023 than in 2022.
Runtime Application Self-Protection (RASP) came next, integrating directly into applications for deeper, runtime-level visibility into application-layer threats. However, RASPs require extensive developer involvement, creating operational friction. They also lack visibility into the broader infrastructure and container environments, which limits them in cloud-native setups.
That friction came from how those tools hooked in: RASP relied on language-specific agents or SDKs embedded in the runtime, sometimes modifying bytecode. Each request picked up extra latency, and the instrumentation could conflict with APM or other agents already in place. Newer tools skip that step with non-intrusive sensors built on eBPF, a Linux kernel technology whose user-space probes (uprobes) read in-memory execution and call stacks from outside the app. That means no code changes, no recompilation, and no agent bloat.
This gap led to ADR, which balances WAF's ease of implementation with RASP's deep application insight. Using runtime observability and behavior-based detection, it responds to in-app threats in real time, including vulnerabilities that surface only after deployment.
How does ADR work?
ADR runs in two phases: it detects suspicious behavior inside the application, then responds with context the SOC can act on. It watches for two kinds of threats:
External threats: Threat actors attempting to compromise deployed applications from the outside, such as by sending malicious requests.
Internal threats: Supply chain attacks where attackers inject malicious code by compromising open-source libraries used in the application.
Once a threat is found, the response phase gives the security operations center (SOC) detailed threat intelligence to understand what happened and prevent repeats.
Application monitoring
ADR monitoring records what the application actually does at runtime: which functions run, which libraries load, and where data flows. It relies on software instrumentation: monitoring code embedded in the application, or tools that track code execution and user interactions in real time. That runtime record is what runtime application protection uses to spot anomalous behavior.
Profiling of open-source libraries
Some ADR vendors profile open-source libraries, tracking their behavior under regular conditions. With a baseline in place, these platforms can detect deviations that may indicate an attacker has modified the library code. This helps address supply chain attacks where attackers insert malicious code into third-party components.
In 2024, a contributor nearly slipped an SSH backdoor into the xz compression library, in what became known as the XZ Utils backdoor. Profiling is built to catch exactly that: trusted code suddenly doing something new.
Anomaly detection
ADR platforms apply behavioral analysis and machine learning (ML) to monitoring data, flagging drift from the established baseline. Unusual API requests or unauthorized login attempts then generate alerts for investigation. That behavioral approach is what makes anomaly detection effective against novel attacks.
Threat analysis and alerting
After a potential attack is detected, ADR systems analyze its severity and possible impact. During this phase, the platform correlates the detected anomaly with known attack patterns and vulnerabilities. Paired with monitoring context, that analysis becomes an actionable alert. Compare how the same shell spawn shows up in each tool:
Traditional EDR alert:
Process /bin/sh spawned by parent process python3 (PID 2145)
ADR alert (event call stack):
HTTP POST /api/v1/upload -> app.routes.process_file() -> yaml.unsafe_load() -> os.system("/bin/sh")The EDR analyst can't tell which endpoint, user, or code path triggered it, while ADR points straight to the vulnerable yaml.unsafe_load() call. That's a ticket a developer can pick up the same day.
Automated response
Some ADR platforms can respond on their own: blocking a malicious request, killing a rogue process, or isolating a compromised workload. For high-confidence threats, containment can start before an analyst opens the alert.
Perimeter and host tools tend to respond at a coarse level: a WAF blocks a connection or an IP, and EDR may isolate a host or stop a container, which can interrupt legitimate users. Because ADR understands application context, it can end one malicious worker thread or revoke a compromised session or JSON Web Token (JWT). It can even trigger an automated pull request that patches the vulnerable function, all without taking the service down.
Detección de Amenazas por IA Explicada
La detección de amenazas por IA utiliza analíticas avanzadas y metodologías de IA como aprendizaje profoundo (DL) y procesamiento de lenguaje natural (PLN) para evaluar el comportamiento del sistema, identificar anomalías y rutas de ataque potenciales, y priorizar las amenazas en tiempo real.
Leer más
ADR vs other detection and response approaches
Each detection and response tool watches a different layer, and ADR is the one inside the application. AI detection and response, one part of AI runtime security, applies the same idea to models and agents.
What is the difference between ADR and EDR?
EDR (Endpoint Detection and Response) protects end users' endpoint devices, such as laptops, mobile phones, servers, IoT devices, and smartwatches, against threats. EDR monitors devices for malicious activity while ADR protects applications, which may be running on those devices.
What is the difference between ADR and XDR?
While ADR focuses on securing applications at runtime, XDR (Extended Detection and Response) unifies security tools across networks, cloud environments, endpoints, and data. ADR collects telemetry from applications, whereas XDR consolidates data from all these sources into a centralized hub.
What is the difference between ADR and CDR?
CDR (Cloud Detection and Response) secures cloud environments by detecting and mitigating attacks targeting cloud workloads, services, and platforms. While CDR focuses on protecting the cloud infrastructure, ADR safeguards applications, including those running in that cloud.
What is the difference between ADR and SIEM?
A SIEM collects and correlates logs from across your environment, but it only knows what those logs record. Applications often log little about how their own code behaves. ADR generates application-layer detections that feed the SIEM, so analysts see in-app evidence next to network, identity, and cloud events.
Watch 5-min demo
See Wiz Defend pick up a runtime threat and walk through the investigation, including the code and cloud resources behind it.
What are the benefits of application detection and response?
The payoff shows up in the SOC queue and in how fast incidents close:
Sharper threat discovery: Behavioral analysis shows attack patterns as they unfold, including ones perimeter controls never see.
Fewer false positives: Behavioral context separates real attacks from harmless anomalies, so analysts focus on genuine risks.
Faster incident response: Attacks surface while they're happening, with precise context attached. Teams contain them sooner, limit the blast radius, and spend less time troubleshooting.
Stronger resilience: Ongoing monitoring and threat detection give the SOC a clear view of what's happening inside the application.
Cleaner audit evidence: Logged detections and response actions show auditors that runtime controls work, supporting frameworks such as PCI DSS and ISO 27001.
Fewer false positives usually matters most day to day. An alert with the code path attached is quick to confirm or dismiss.
CDR vs EDR vs XDR: What's the difference?
Wade through the alphabet soup of detection and response technologies to understand where they overlap and how they differ.
Leer más
Common use cases of application detection and response
These scenarios show where in-app visibility changes the outcome.
Detecting and responding to anomalous behavior
From inside the application, ADR can spot unauthorized access attempts, spikes in database queries, or sudden changes in API request patterns.
Say your e-commerce application sees an unusual burst of checkout requests within seconds. In-app threat detection can match that pattern to known attack signatures like card-testing attacks.
ADR also flags users reaching for features they don't have access to. That gives teams an early lead on compromised accounts.
Detecting API abuse
Many API security risks look like valid traffic at the gateway, but ADR sees each call from inside the application. It can flag unusual call sequences, like a client jumping straight to a payment endpoint without the usual session steps.
It also catches broken object-level authorization (BOLA) style abuse, where one account walks through other users' record IDs. Bulk scraping and business logic abuse, like replaying a refund flow, show up the same way: as request patterns no real user would produce.
Defending AI workloads and agentic tool calls
Prompt injection hides instructions inside text an AI system reads, like a user message or a retrieved document. Those instructions don't need to be visible to a human, only parsed by the model. So WAFs and API gateways that inspect traffic at the edge likely see ordinary text and let it through. EDR doesn't help much either, since it only sees that Python or an agent worker spawned a subprocess.
ADR fills that gap from the application layer, where the agent's tool-call handler lives. When an injected prompt pushes that handler to run an unauthorized function or shell command, ADR sees the call and the code path behind it.
Collecting threat intelligence
ADR systems aggregate user behavior, performance fluctuations, application logs, and known threat feeds into a knowledge base for stopping application attacks.
Threat intelligence helps your team understand the tactics, techniques, and procedures (TTPs) employed by threat actors against your application. Teams use that data to fix existing flaws, harden defenses, and make better incident response decisions.
Preventing exploitation of zero-day vulnerabilities
A standout ADR capability is protecting applications from zero-day vulnerabilities in custom code and third-party libraries. (Zero-day vulnerabilities are security issues not yet known to the public, with no patch available.)
Firewalls and antivirus software can't stop them because they only recognize known threats. Google Threat Intelligence Group tracked 90 zero-days exploited in the wild in 2025, up from 78 in 2024. Commercial surveillance vendors, which sell exploit tools to their customers, definitively or likely used 18 of them.
The library baselines described earlier do the heavy lifting here. When a trusted package suddenly spawns a shell or calls an unknown host, ADR flags the drift before any CVE exists. In practice, that shell is often the first visible sign of remote code execution.
Prioritizing vulnerabilities with runtime context
Pre-deployment scanners report everything that could be exploitable. Static testing (SAST) flags risky code, dynamic testing (DAST) probes the running app, and software composition analysis (SCA) lists vulnerable dependencies. None of them see what actually runs in production.
ADR adds that evidence: which packages load, which functions execute, and which endpoints get traffic. A critical CVE in a library that never loads can wait, while a medium-severity flaw on a reachable path moves up. That cuts long lists of application vulnerabilities down to what matters.
Application Vulnerability Scanning: Definition & Guide
Application Vulnerability Scanning is the automated process of detecting security weaknesses in software applications before attackers exploit them.
Leer más
Wiz's approach to application detection and response
An attack on application logic can look like ordinary traffic until the workload does something unexpected. The Wiz Runtime Sensor supplies that kernel-level signal through eBPF. Application detection and response in Wiz Defend layers function-level visibility from inside the app on top, showing what the code did before any process spawned.
Say an attacker exploits unsafe deserialization, and the app opens a reverse shell. Without ADR, security teams only know that sh was spawned under a Python or Node process. With ADR, Wiz captures the in-memory Event Call Stack. It traces the shell to the exact vulnerable function inside the application, such as a PyYAML UnsafeConstructor or an AI agent's tool handler.
That turns a vague process alert into a specific function to fix. For AI workloads, Wiz Defend also flags threats like prompt injection. Each AI detection carries a context tag showing whether a rule fired on an agent, a workload, or an identity.
The Red, Blue, and Green Agents work from the same runtime evidence. The Red Agent validates exploitable logic flaws across web apps and APIs. When a threat fires, the Blue Agent investigates using ADR event call stacks plus cloud identity context.
Next, the Green Agent traces the issue to the responsible repository, owner, and code, then generates a code fix and opens a pull request. Workflows can trigger containment playbooks or require human approval. Wiz Code completes the feedback loop by mapping risks from runtime back to the exact code, commit, and owner. It also secures development from the IDE to deployment.
Request a demo to explore how Wiz can secure your cloud environment.
See for yourself...
Pick one of your own applications and see how a runtime detection traces back to the code and cloud resources behind it.
