AI agent detection and response (AI ADR)
Definition
AI agent detection and response is the practice of recording what AI agents do, deciding which of those actions are attacks or policy violations, and stopping the next action instead of filing a report about the last one.
The unit of detection is the tool call: a name, its arguments, the MCP server it reaches, the credential it uses and the model that produced it, bound to one agent session and one human identity. The category exists because the decisions that matter happen inside a long-lived agent process, where a network gateway has no traffic to inspect and an endpoint product has no process to watch.
This entry covers what AI ADR is, how it differs from EDR and XDR, the detect, contain and respond loop as it applies to agents, and the practical steps to build it without breaking the teams that use agents every day.
Why it matters
Agents are no longer an experiment on a few laptops. In the 2026 Stack Overflow developer survey, 73 percent of respondents said they use coding assistants and agents daily, and coding agents were the top AI use case at 66 percent (Stack Overflow, October 2026). Every one of those sessions makes tool calls that no existing security product records.
The failure modes are measured, not theoretical. In the largest public agent red-teaming competition, 1.8 million attacks against 22 frontier agents produced more than 60,000 successful policy violations, and the authors reported that nearly all agents exhibited policy violations for most behaviors within 10 to 100 queries (arXiv 2507.20526). The UK cyber authority is blunt about why: current models do not enforce a security boundary between instructions and data inside a prompt (NCSC, December 2025). Prompt injection remains the top entry on the OWASP list for LLM applications (OWASP LLM01:2025).
Analysts expect the gap to cost projects, not just incidents. Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing cost, unclear value and inadequate risk controls (Gartner, June 2025). Detection and response is the control that lets a program keep running after its first bad day.
How it works
How AI ADR differs from EDR and XDR
EDR watches the operating system: process creation, file and registry changes, network connections, logins. XDR correlates those signals with email, identity and cloud telemetry so an analyst can follow one intrusion across products. Both assume the thing worth detecting announces itself as a process, a file or a connection.
A coding agent breaks that assumption. One claude, codex, cursor-agent or node process stays alive for an hour and makes hundreds of decisions inside it. A tool call is a function call in that process, not a process launch. A local MCP server the agent started talks to it over a pipe on the same machine, so the call produces no network event either. The evidence that a session read a credential file and then opened a connection somewhere new lives in the agent's tool-call stream.
| Signal | Why it matters | Where it is visible |
|---|---|---|
| Agent identity and session | Attributes an action to a person and a run, not just a process ID | The client session, resolved through your identity provider |
| Tool name and arguments | Decides whether the action was risky: a path, a URL, a shell string | The tool-call stream inside the agent process |
| MCP server identity and version | Separates a sanctioned server from one that appeared in a config file last week | The client configuration and the server handshake |
| Model and version | Explains a behavior change, and matters when a decision is reviewed months later | Model request metadata |
| Policy decision | Without it a denial is unarguable a week later | The local policy engine |
| Credential lease | Distinguishes a file read from a read that put a secret on the wire | The secrets broker and the policy decision |
| Egress destination | The last chance to stop an exfiltration a tool call started | The endpoint |
The detect, contain and respond loop
Detection has three shapes, in increasing order of difficulty. Per-call rules ask whether this specific call violates a written rule, which is deterministic and catches the mistakes. Sequence rules ask whether the session reached a state that should not be reachable, such as a secret read followed by an outbound request, and need state per session rather than a boolean. Baseline and drift ask whether this agent is behaving unlike itself or unlike the fleet, which needs history and a fleet view.
Containment for agents is narrower than containment for malware. You do not isolate the machine or kill the editor. You deny the next call, require an approval, revoke a credential lease, or cut egress for that session. Each of those is a policy decision, so each of them belongs in the same record as the detection that triggered it.
Response is the part most programs skip. It means an owner, a runbook that says who decides, and a way to answer the auditor's question about what happened afterwards. A detection with no response path is a dashboard.
How to implement it
- Inventory first. You cannot attribute an action to an agent you never saw, or write a rule about an MCP server you cannot name. Inventory the agents, CLIs, versions and MCP servers on each endpoint before you build a detection.
- Fix the event schema. Record session, agent identity, tool, arguments, MCP server, model, policy decision, credential lease and egress destination. Choose the schema before you choose the product, because it is the thing you will live with.
- Run in monitor mode. Record what enforcement would have decided without blocking anything. This is how you prove the rules are right before a developer loses an hour to a false positive.
- Write rules in that order: per-call denies for credential paths and unsanctioned servers, then sequence rules for data flow, then drift rules for the fleet.
- Send the signal to where your SOC already works. OpenTelemetry into your SIEM beats a new console nobody opens, and it lets your existing correlation rules apply to agent activity.
- Rehearse the response. Deny, require approval, revoke the lease, notify the developer, and keep a record that closes the loop for audit.
- Set retention from the questions you must answer, not from the size of the disk.
How Alyria handles it
Alyria (alyria.ai) delivers AI ADR as one loop on the endpoint. Beacon, the signed user-space agent, inventories every AI tool, version and MCP server on a machine, then evaluates policy on every MCP call locally, at the point where the call originates, with no cloud round trip. It deploys read-only and starts in monitor mode, so you see what enforcement would have done before anything is blocked. Lyra writes the policy once, capability by capability, and every decision lands in one signed, hash-chained audit record. Spectra collects that signal as OpenTelemetry and routes it to Alyria Cloud or to your own SIEM, and Observatory turns it into fleet posture, policy decisions and an exportable record for audit. Umbra issues short-lived credential leases at the moment of use, so a detection can revoke the next one. Start with the free Agent Exposure Report, which inventories the agents and MCP servers on your endpoints in about 30 minutes.
Related standards
- NIST AI RMF: MEASURE and MANAGE, which assume continuous monitoring and a defined response.
- ISO/IEC 42001: the AI management system clauses on operational control and monitoring.
- EU AI Act: record-keeping for high-risk systems, which requires the log to exist before the incident.
- OWASP Top 10 for Agentic Applications: ASI08 cascading failures and ASI10 rogue agents.
- OWASP Top 10 for LLM Applications: LLM06 excessive agency.
- SOC 2: CC7 monitoring, and the evidence trail an auditor samples.
Frequently asked questions
- Is AI ADR the same thing as EDR?
- No. EDR watches operating system activity such as process launches, file writes and outbound connections. AI ADR watches agent decisions: the tool call, its arguments, the MCP server it reaches, the credential it uses and the model that produced it, all bound to one session and one human identity.
- Can an AI gateway or an MCP proxy do this instead?
- A gateway sees traffic that crosses the network. A local MCP server that a coding agent starts over a pipe produces no such traffic, and framework agents call model providers through their own libraries. You still need a control point on the endpoint, where the decision is made.
- What should an AI ADR product record first?
- Session identity, the tool name and arguments, the MCP server identity and version, the model and version, the policy decision and the credential lease. Everything else is correlation on top of that record.
- Does detection and response mean blocking developers?
- It should not. The response that matters for agents is a decision about the next call: deny it, require an approval, or let it run under monitoring. Killing a developer's editor for a policy violation teaches the team to route around the control.
- How long should agent activity be retained?
- Long enough to answer the questions your auditors and regulators ask, which usually means months rather than days, and long enough to compare a session against a baseline. Retain the policy decision with the action, otherwise a denial is unarguable a week later.