Agentic detection and response (ADR) is the emerging answer to a simple problem: your endpoint tools can see an AI agent run a command, but they cannot see why it ran it. This guide explains what ADR is, what it detects, how a reference architecture works, how it differs from guardrails and SIEM, and what telemetry you need to start this quarter.
Key Takeaways
- ADR is a detection layer for AI agents: it captures prompts, reasoning context, and tool calls, then scores behavior against a baseline and known attack patterns.
- EDR and SIEM are not blind to agents, but they lack the causal context (what content led to which action), which is where most agent attacks live.
- Uber's ADR paper (arXiv 2605.17380) reports a production deployment on 7,200+ hosts and 10,000+ agent sessions per day, and an ADR-Bench evaluation of 17 attack techniques across 133 MCP servers.
- Guardrails, ADR, and SIEM are complementary. Guardrails prevent at a point in time, ADR detects across sessions, and SIEM correlates with everything else.
- Detection quality is bounded by telemetry quality. Start with identity, tool-call, and context capture before buying anything.
- ADR supports, but does not satisfy on its own, logging obligations such as EU AI Act Article 12.
Why EDR Misses AI Agent Attacks
Consider a coding agent with access to a repository, a shell, and a cloud CLI. A poisoned README tells it to "verify the environment" by printing environment variables and posting them to a webhook. From the host's perspective, a trusted developer-tools process ran env and made an outbound HTTPS request. Every signal EDR relies on, such as a signed binary, a known parent process, and a normal user context, looks benign.
This is the telemetry gap. EDR was built on the assumption that malicious behavior produces anomalous process behavior. Agent attacks often produce normal process behavior driven by anomalous instructions. The Uber ADR paper frames the same limitation: endpoint tools see file writes but not the agent's reasoning, its prompts, or the causal chain that connects an instruction to an action.
In practice, we see three consequences when teams rely on host telemetry alone:
None of this means EDR is obsolete. It remains the right control for the host. ADR adds the layer that explains what the agent was trying to do.
What Agentic Detection and Response Detects
ADR targets behaviors specific to systems that take instructions from natural-language context and act through tools. The categories below map closely to the OWASP Agentic AI threats and mitigations work and to techniques catalogued in MITRE ATLAS.
Goal hijacking and indirect prompt injection. Content the agent retrieved (a web page, a ticket, a document, an email) changes what it does next. Signals include a tool call whose purpose does not follow from the user's request, or a sudden change in the target of actions after a retrieval step. See our deep dive on indirect prompt injection in agentic AI.
Tool-call anomalies and unauthorized tool chaining. The agent calls a tool it has never used for this workflow, or combines tools in a sequence (read secret, then send network request) that no legitimate task requires. Tool poisoning through malicious MCP server descriptions belongs here too; see MCP tool poisoning defense.
Credential exposure. Secrets appear in prompts, tool arguments, or tool outputs. In Uber's deployment this was the most productive category operationally: the paper reports hundreds of credential exposures across 26 categories, and a shift-left prevention layer that detected 206 credentials at 97.2% precision. That precision figure applies to the credential detector, not to all ADR detections, a distinction worth keeping straight when you read vendor summaries.
Reasoning or memory poisoning. Persistent context (memory stores, skills, system prompts) is modified so that later sessions behave differently. Detecting this requires comparing behavior across sessions, which a per-request guardrail cannot do. We cover the defensive side in AI agent memory poisoning defense.
Cross-session credential reuse and lateral movement. A token issued in one agent context shows up in another, or an agent starts acting on systems outside its usual scope. Our write-up on living off the agent attacks describes how attackers use an agent's own legitimate permissions for this.
The Uber Case Study: What the Evidence Shows
The most substantial public evidence for ADR is ADR: An Agentic Detection System for Enterprise Agentic AI Security, by researchers at Uber, MIT, and Oxford, presented at MLSys 2026. It is worth reading the actual numbers, because several secondary summaries blur them.
Architecture. The system has three components: an ADR Sensor that collects telemetry from agents using MCP, an ADR Explorer that performs offline red teaming (including evolutionary generation of hard attack variants), and an ADR Detector that runs two-tier online detection, pairing fast triage with slower context-aware reasoning. The two-tier design addresses the third problem the authors name: running an LLM over every event is too expensive.
Production scale. The authors report more than ten months of operation, over 7,200 unique hosts, and more than 10,000 agent sessions per day.
Benchmark. ADR-Bench covers 302 tasks, 17 attack techniques, and 133 MCP servers. The paper reports zero false positives with 67% of attacks detected, and a 2x to 4x F1 improvement over three baselines (ALRPHFS, GuardAgent, and LlamaFirewall). On the public AgentDojo prompt-injection benchmark, it reports detecting all attacks with three false alarms across 93 tasks.
How should a security leader read this? Two honest points. First, 67% detection with zero false positives is a strong result for a research system, but it also means a third of benchmark attacks were missed, so ADR is a layer in a defense-in-depth stack, not a final control. Second, these are the authors' own benchmark and deployment results. Treat them as evidence the approach works, and run your own evaluation against your own agents before drawing conclusions about any product.
ADR Architecture: From Telemetry to Response
Whether you buy or build, a working ADR pipeline has the same stages.
1. Telemetry collection (the sensor). Capture, at minimum, per event: agent ID, session ID, user or workload identity, the model input (including retrieved content with its source), the tool call (name, arguments, result, duration), and policy decisions. For MCP agents, the MCP client or a gateway is the natural collection point. For frameworks that support OpenTelemetry, emit spans for model calls and tool calls so the data flows to systems you already operate.
2. Normalization. Map events to a stable schema so detections do not break when you swap frameworks. Tag each tool with a risk class (read-only, write, external egress, credential-bearing).
3. Behavioral baseline. For each agent or agent type, learn which tools it uses, in what order, against which resources, and at what volume. Baselines for agents are noisier than for service accounts because behavior legitimately varies with the prompt, so start with coarse features such as tool set and egress destinations.
4. Detection. Combine cheap deterministic rules (secret patterns in arguments, a write tool called immediately after untrusted retrieval) with an escalation tier that applies a model or heuristic over the full session context. This mirrors the Uber two-tier design.
5. Response. Options range from alert-only, to step-up approval for a high-risk tool call, to session termination and credential revocation. Gen Digital's ADR module in its Agent Trust Hub takes the inline route, evaluating actions at execution time and returning allow, ask, or deny. Inline enforcement reduces dwell time but adds latency and a risk of blocking legitimate work, so most teams phase it in after a period of observation.
6. Integration. Forward high-fidelity alerts and full session records to the SIEM so analysts can pivot from an agent event to identity, network, and cloud logs. The forensics side is covered in our AI agent breach investigation guide.
ADR vs LLM Guardrails vs SIEM: The Three-Layer Model
These controls get conflated, and the confusion leads to gaps or to paying for the same coverage twice.
| Layer | Primary question | Time horizon | Strength | Typical blind spot | |---|---|---|---|---| | LLM guardrails | Is this input or output acceptable? | Single request | Prevents known-bad content and policy violations | Multi-step attacks where each step looks fine | | ADR | Is this agent behaving like it should? | Session and cross-session | Intent, tool chains, credential exposure | Needs good telemetry; misses what it was not tuned for | | SIEM | What else happened around this event? | Enterprise-wide, long retention | Correlation, investigation, compliance reporting | No native understanding of agent context |
The practical rule: guardrails stop what you can describe in advance, ADR catches what only looks wrong in context, and the SIEM ties it to the rest of the environment. For the preventive side of that stack, see our AI agent runtime security CISO guide and the broader LLM security monitoring guide.
Buy, Build, or Assemble
The market is young, so there is no settled answer. A reasonable decision frame:
- Build or assemble if your agents are few, built on a single framework, and you have detection engineers. The Uber paper releases ADR-Bench, the sensor, and the detection framework, which is useful both as a reference design and as an evaluation yardstick.
- Buy if agents are spread across teams and vendors (coding assistants, SaaS copilots, home-grown agents) and you need endpoint-level coverage without instrumenting each one. Evaluate on three questions: what telemetry does it actually capture, can you export the raw records to your SIEM, and what is the false positive rate on your workloads, not the vendor's.
- Do neither yet if you cannot yet enumerate your agents. Inventory comes first; you cannot baseline what you have not found.
Logging Obligations and the EU AI Act
Teams sometimes cite the wrong article here, so precision helps. Article 11 of the EU AI Act concerns technical documentation. The logging requirement for high-risk AI systems is in Article 12, which requires that such systems technically allow automatic recording of events over their lifetime. Article 26 obliges deployers to keep the logs under their control for a period appropriate to the intended purpose, and at least six months unless other law says otherwise. The text is available on the EU AI Act explorer.
ADR telemetry, particularly tool-call records and the inputs that triggered them, is a strong candidate source for those logs and for post-incident reconstruction. Two caveats. Not every agent is a high-risk system under the Act, so check classification first. And logging prompts may capture personal data, so retention, access control, and minimization need a legal review. Our guide to Article 73 incident reporting covers how this evidence feeds serious-incident obligations. The NIST AI Risk Management Framework similarly expects ongoing monitoring under its Manage function, which ADR operationalizes for agents.
Getting Started: Minimum Viable ADR Telemetry Checklist
You can make real progress without a purchase. Work through this list in order:
Conclusion
Agentic detection and response fills a real gap: when an agent is steered by its context, host and network tools see only normal activity. ADR restores the missing causal chain by capturing what the agent read, decided, and did. The evidence so far, led by Uber's production deployment and ADR-Bench results, is promising but not a guarantee, and detection is only as good as the telemetry behind it. Start with identity, tool-call logging, and context provenance, add a handful of high-signal detections, and expand toward inline response as confidence grows.
If you want to know what your agents expose today, run a free scan to baseline your AI attack surface, then use the checklist above to close the telemetry gaps it surfaces. You can also browse more guidance on the BeyondScale blog.
Check your AI endpoint against these findings
SecureTom runs a free quick scan on any AI endpoint in about a minute. No signup needed.
