Home / AIDR
The category

AIDR — AI Detection & Response.

Security grew a Detection & Response category for every layer it learned to defend. The plugins and AI agents your developers run are the newest layer — high-privilege, fast-growing, and unmonitored. AIDR is the category for it: detect the risk in every plugin, skill, and MCP server, and respond before it runs.

EDR
Endpoints
NDR
Network
XDR
Cross-layer
AIDR
AI agents & plugins

The lineage

EDR — Endpoint Detection & Response

Watches processes and binaries on the host. It does not inventory the plugins running inside your developers' tools, or score their permissions.

NDR — Network Detection & Response

Watches traffic and lateral movement. Blind to what a local IDE extension or MCP server does with the access it already has on the endpoint.

XDR — Extended Detection & Response

Correlates signals across endpoint, network, identity, and cloud. The plugin and AI-agent layer simply isn't one of its telemetry sources.

AIDR — AI Detection & Response

Detection & response for the AI-agent and plugin execution layer — the skills, MCP servers, and extensions that agents and developers run with full privilege. This is the layer PluginSec defends.

Why now

Why the plugin layer needs its own category.

The surface didn't exist at scale a few years ago. Now it's everywhere — and nothing in your stack was built to govern it.

AI agents went mainstream

Claude, Codex, Gemini, and Antigravity run skills and MCP servers as local processes with tool access — a brand-new, fast-growing, high-privilege surface with almost no review.

Developers install everything

Thousands of IDE and browser extensions, plus package-manager tools that execute code on install and on silent update — each one unvetted code running as the developer.

Existing D&R can't see it

EDR, NDR, and XDR model processes, traffic, and identities — not individual plugins, skills, or MCP servers. The layer is a blind spot, so it needs its own detection and response.

The "D"

Detection — a verdict on every plugin.

Continuous inventory and dedicated threat intel for the whole plugin layer.

Continuous Plugin SBOM

Inventory every IDE extension, browser extension, AI-agent skill, MCP server, and global package install — name, publisher, version, declared permissions, and content hash. Metadata only; source never leaves the device.

Threat-intel verdicts

Correlate each plugin against our analysis and leading feeds, returning a verdict — clean, suspicious, or malicious — per plugin and per version.

Plugin-layer techniques

Catch what generic signatures miss: rug-pulls, typosquatting, over-privileged scope creep, MCP tool poisoning, and credential exfiltration. See the threat model and the full coverage list.

The "R"

Response — stop it before it runs.

Detection without response is just a report. AIDR enforces.

Allowlist enforcement on the endpoint

The agent enforces your allowlist — block, quarantine, or warn — so a plugin with a malicious or suspicious verdict is stopped before it executes, not flagged after the fact.

Audit trail & SIEM

Every allow/deny decision is logged with who, what, and when, and streams to your SIEM — an auditable record for the whole plugin layer.

Metadata in, verdict out

Your source code and our threat intel each stay on their own side. Endpoints only ever receive a yes / no.

What we believe

The AIDR principles.

1

The plugin & AI-agent layer is its own attack surface

It deserves dedicated detection and response — not a footnote bolted onto an endpoint agent.

2

Detection without response is just a report

A verdict only matters if it turns into enforcement before the code runs.

3

Metadata in, verdict out

Your source and our intel stay on their own sides; the endpoint gets the answer, never the burden.

4

One agent, every plugin class

IDE, browser, AI-agent, and package-manager plugins in a single inventory and a single allowlist.

5

Independent and vendor-neutral

Governing your plugin layer should never lock you into one browser, OS, or platform vendor.

FAQ

Common questions.

What is AIDR?
AIDR — AI Detection & Response — is detection and response for the plugin and AI-agent layer. It continuously detects risk in the components your developers and AI agents run (IDE and browser extensions, agent skills, MCP servers, and package-manager installs) and responds by enforcing an allowlist on the endpoint before they execute.
How is AIDR different from EDR or XDR?
EDR watches OS processes and binaries; NDR watches network traffic; XDR correlates across endpoint, network, identity, and cloud. None of them inventory or risk-score individual plugins, skills, or MCP servers. AIDR is detection and response for that specific layer and complements EDR and XDR rather than replacing them.
Is AIDR the same as AI-SPM or securing AI models?
No. AIDR as we use it covers the AI-agent and plugin execution layer — the skills, MCP servers, and extensions agents and developers run. It is not LLM/model alignment or AI-application posture management (AI-SPM).
Do I still need AIDR if I have EDR?
Yes. EDR will not tell you that a VS Code extension rug-pulled to a malicious version, that an MCP server was poisoned, or that a typosquatted npm package was installed globally. Those threats live in the plugin layer that EDR does not model.
Is AIDR a real category or just marketing?
It is an emerging framing, and what we mean by it is concrete: detection (a Plugin SBOM plus threat-intel verdicts) and response (allowlist enforcement on the endpoint) for the plugin and AI-agent layer. The need is real even though the acronym is new.
Request access

Bring AIDR to your fleet.

PluginSec is enterprise-only and onboarded by invitation. Tell us about your team and we'll set up a demo.

Request access How we compare →