What is agent detection and response?

Agent detection and response (ADR) is the practice of recording what AI agents do, deciding which of those actions are attacks or policy violations, and stopping the next action rather than filing a report about the last one. It covers tool calls, MCP traffic, shell commands, file access, model requests and the credentials an agent uses, tied to one session, one identity and one policy decision. The category exists because the actions that matter happen inside an agent's own process, where a network gateway has no traffic to inspect and an endpoint detection product has no process to watch.

This page defines the term, describes the signals an ADR capability needs, and lists the questions worth asking a vendor. It is written for the security leader who already runs EDR over those same laptops and needs to know what the new layer is for.

Why the term appeared

Endpoint detection and response watches operating system activity: process creation, network connections, file system and registry changes, logins. That model works because malware announces itself with a new process, a new file, or a new connection to somewhere it should not be.

A coding agent breaks that assumption. One long-lived 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 that the agent started talks to it over a pipe on the same machine, so a call to that server produces no network event either. The evidence that a read of ~/.aws/credentials happened, and that the same session then opened a connection to somewhere new, sits in the agent's own tool-call stream, not in the process table.

The vendors that name this category are not wrong to name it. The detection seat is genuinely different from the endpoint seat, because the event to detect is a tool invocation with arguments, a policy decision, and a model's intent, and the response is a decision about the next call.

The signals an ADR capability needs

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's session, resolved through your identity provider
Tool name and arguments	The event that decides whether the action was risky, for example a path, a URL or 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	The model request metadata
Policy decision	Without it a denial is unarguable a week later	The local policy engine
Credential use	Distinguishes a file read from a read that put a lease on the wire	The secrets broker and the policy decision
Process tree	Correlates a shell command the agent spawned with the tool call that asked for it	Host telemetry
Network egress	The last chance to stop an exfiltration that a tool call started	The endpoint and the local policy engine

An inventory is the prerequisite for all of it. You cannot attribute an action to an agent you never saw, and you cannot write a rule about an MCP server you cannot name. A program that starts with detection and no inventory spends its first month rediscovering which tools are installed.

Three shapes of detection

These are the three questions a detection layer answers, in increasing order of how hard they are to build and how useful they are.

Per-call rules. Does this specific call violate a written rule? A deny for reads of credential paths, an allowlist for MCP servers, a block on a command pattern. It is deterministic, cheap, and it catches the mistakes and the shortcuts. It does not catch a sequence where every individual call is legal.

Sequence and trajectory. Did this session reach a state that should not be reachable? "After reading a secret, block network egress" is the canonical example, and it cannot be written as a per-call rule, because the read is allowed and the request is allowed. It needs state per session and a comparison of positions, not booleans. A worked version of that rule, including the state machine, is on the semantic policy examples page.

Baseline and drift. Is this agent behaving unlike itself, or unlike the rest of the fleet? A tool that appears in one session and nowhere else, a model version change, a new MCP server on forty machines at once. This is where a fleet view earns its keep, and it is the shape that needs history rather than a single event.

Most incidents in an agent fleet are caught by the first two. The third is what tells you a rollout went sideways before a developer reports it.

What response means, and what it does not

Response in this category is often described as if it were endpoint containment: isolate the machine, kill the process, quarantine the file. Those actions were built for malware and they are disproportionate for a tool call. Killing a developer's editor and terminal because a policy was violated teaches everyone to route around the control.

The responses that fit an agent are narrower, and they land on the next call rather than on the host:

• Deny the call in front of you, with the rule and the reason attached to the decision.
• Hold the session until a person approves, where the action is legitimate but not routine.
• Revoke the credential lease, so the access the agent was using stops working without stopping the agent.
• Record the decision, including the policy text, the model, the server version and the session history, so review happens from evidence instead of from memory.

The last one is not administration, it is the product. A detection without a record of the decision that produced it becomes an argument about what happened.

ADR and prevention are one system

Agent detection and response is usually paired with agent policy governance: prevention decides what an agent may do, detection decides what it did. Sold as separate products they drift, because two policy languages and two audit logs cannot answer one auditor's question.

The cleaner arrangement is one policy engine and one record, with prevention and detection reading the same source. That is how the platform is built here: prevention is policy evaluated on the endpoint before the call, detection is the same decisions plus fleet-level correlation, and both write to one signed chain. The platform page describes the two pillars and which modules sit in each.

A worked example

A developer asks an agent to fix a failing deployment. The agent reads .env to get the database URL, then attempts to send a diagnostic payload to a paste service.

1. The read of .env is allowed by policy, and the decision records the path and the tool. The session state now reads secret_read = true.
2. The egress attempt matches the sequence rule "after reading a secret, do not allow network egress outside the approved hosts". A per-call allowlist would have permitted it, because the destination is legitimate for other work.
3. The decision is a deny with a rule identifier, the tool, the target, and the session state that produced it.
4. The record is signed and streamed to the telemetry pipeline, where a correlation rule picks up the same session attempting the same destination from a second tool.
5. The developer sees a refusal with a reason and a path to request an exception, instead of a blocked laptop.

That sequence, and the policy text behind it, is the artifact an ADR product has to be able to produce. A list of alerts about unusual network activity is not the same thing.

Questions to ask a vendor

1. Does it see a local stdio MCP call, which never crosses the network?
2. Can it attribute a call to a session and a person, or only to a process and a host?
3. Can it deny the call before it executes, or only alert after it is logged?
4. Does the record carry the policy decision and the rule that produced it?
5. Does it work with the network unplugged, or does policy stop when the cloud does?
6. Does it cover agents that run in CI or in a cloud runtime, where no endpoint is enrolled?
7. What does it put on the endpoint: user space, a kernel driver, or a proxy the agent can bypass?
8. Where does the evidence go, in what format, and for how long?
9. Can you export the chain and verify it independently? The audit export docs describe what verification should prove.
10. Does it require a second policy language beside the one you already run?

How Alyria covers agent detection and response

Alyria Beacon is a signed, user-space daemon for macOS, Linux and Windows with no kernel driver, which is what lets it sit beside the EDR you already run instead of replacing it. It inventories the AI tooling and MCP configuration on each endpoint, including stdio servers that never touch the network, and it observes process and config-level activity from user space. That observation is the detection half: it flags out-of-band processes and agent activity that never reaches a gateway.

The prevention half runs on the same agent. Lyra policy is evaluated locally on every MCP and model call, deterministically and offline, so a denial is available before the action rather than after it, and it starts in monitor mode so you can see what enforcement would have done. Umbra supplies short-lived credentials injected at the moment of use, which makes revoking a lease a real response option rather than a theoretical one. Spectra collects the OpenTelemetry from every endpoint and routes it to Alyria Cloud or into your own SIEM, where correlation and trajectory analysis turn decisions into detections. Observatory is the console over all of it, with SSO and role-scoped access, and every decision lands in one signed, tamper-evident chain.

The endpoint side is Alyria Beacon, the policy model is Lyra, the signal layer is Spectra, and the platform overview shows how a request moves through them.

Try it with Alyria

Run Alyria Beacon in monitor mode for a week and read the decisions it would have enforced. A read of a secret followed by an outbound request is one decision across the session, not two unrelated events. Start free and read the rollout guide.

Frequently asked questions

Is agent detection and response a replacement for EDR? No. EDR covers the operating system, which is still where malware, credential dumping and lateral movement live. ADR covers the tool calls and model requests that EDR has no event for. Run both.

Is it the same as AI detection and response? The acronym has been used for several things. Some vendors mean detection over model inputs and outputs, some mean endpoint detection with an AI label. Ask which events a product actually observes before comparing two of them.

Do we need an agent on every endpoint? To detect agent activity continuously, yes. Client configuration is local by design and stdio MCP traffic never reaches the network, so a gateway or a network sensor cannot see it. That is the same reason the MCP inventory problem needs a collector.

Which agents does it cover? Alyria Beacon covers Claude Code, Cursor, Codex, Copilot and the framework agents and direct-provider CLIs on enrolled machines. The integrations pages carry the per-tool detail.

How long does the evidence last? Decisions are signed and streamed to Alyria Cloud or your SIEM, so retention follows whatever you already run for security data. Export and verification are documented in the audit export guide.

Where does this fit next to a gateway? A gateway governs traffic that passes through it; an endpoint governs the call where it is made. The comparison guide sets out which surfaces each layer can see.