What is AIDR? AI detection and response, defined.

01 / AIDR, defined

The detection-and-response model, pointed at the AI runtime.

AIDR stands for AI detection and response. The name borrows directly from a lineage security teams already know. EDR (endpoint detection and response) watches the endpoint. NDR watches the network. XDR (extended detection and response) correlates across both. AIDR takes that same model, continuous observation plus a response action, and applies it to a new surface: the AI runtime.

The AI runtime is the layer where AI actually executes inside your organization. It has three moving parts:

• Prompts. What employees and systems send to a model, including the data that rides along inside the prompt.
• Agents. AI that takes actions, calls tools, reads files, and chains steps rather than just answering a single question.
• Models. The hosted and local models being called, sanctioned or not, including the coding assistants embedded in your developers' editors and terminals.

Classic EDR cannot see most of this. A prompt sent from a browser tab, a coding agent calling a tool over MCP, an employee pasting a customer list into a chat assistant. These are AI-runtime events, not endpoint-process events. That gap is the reason a separate AIDR category exists at all.

02 / Where the term came from + analyst status

A vendor-coined term that sits inside AI TRiSM.

Be precise here, because the market is not. AIDR is vendor terminology. It was coined by security vendors who wanted a familiar three-letter handle (the "-DR" suffix) for AI-runtime security. It is a useful shorthand. It is not, however, a formal analyst category, and you should not claim it is.

The umbrella Gartner actually recognizes is AI TRiSM, which stands for AI Trust, Risk and Security Management. AI TRiSM is the broad practice of governing the AI you build and the AI you adopt: model governance, trustworthiness, data protection, runtime defense, and the controls that keep all of it auditable. AIDR products generally live inside the runtime-security slice of AI TRiSM.

So the honest framing is straightforward:

• AI TRiSM is the analyst-recognized umbrella for the whole discipline.
• AIDR is a vendor-coined name for the detect-and-respond slice of it.
• Both point at the same underlying problem: AI you did not build, running where you can barely see it.

If a vendor tells you "AIDR is a Gartner category," treat that as a reason to read the rest of their claims carefully. It is not.

03 / The six market pillars

What AIDR products actually do.

Vendors weight these differently, but the AIDR market converges on six pillars. Read them as a buyer's checklist: any tool calling itself AIDR should have an answer for each.

04 / The gap detection leaves behind

Detection is half the job. Proof is the other half.

Here is the structural problem with detection-first AIDR, and it shows up in two places.

First, detection is not evidence. A live alert feed tells you AI is happening right now. It does not, on its own, give an auditor what they ask for: a signed, dated record, mapped to a named control, showing that a human owns the policy and that the logs were retained for the required period. Detection answers "is it happening?" Evidence answers "can you prove it happened, and that you governed it?" Those are different deliverables, and the second one is what survives an audit, a customer security review, or a regulator's request under the EU AI Act.

Second, most AIDR ships as a heavy endpoint sensor. The detection-vendor instinct is to drop the same kind of kernel-level endpoint agent that powers EDR. That instinct misses the layer where employees actually use AI:

• The browser, where most chat-assistant use lives, often in personal accounts an endpoint sensor never inspects.
• The desktop, where local AI apps and pasted data move outside the network's view.
• The CLI and the coding agents, where Claude Code, Cursor, and GitHub Copilot operate inside the terminal and editor, not as a process an endpoint sensor flags.
• MCP, the protocol agents use to call tools, which a network-centric or endpoint-centric tool simply does not understand.

So the workforce, desktop, CLI, and MCP layer, the exact place shadow AI concentrates, is the blind spot of the heavy-sensor approach. Detection that cannot see where AI runs, and cannot produce the record an auditor accepts, leaves the two jobs that matter most undone.