What is agentic endpoint security in simple terms?

A control that sits on the endpoint and watches how people and their AI agents use AI: which tools are running, what gets sent to them, what comes back, which tools an agent calls, and what leaves the machine. It exists because that activity looks completely ordinary to every other control in a normal stack.

Is this the same thing as AIDR?

Yes. AIDR, for AI detection and response, is the earlier name for the same category, and you will still see it used. The term moved because the interesting risk moved: a chat window leaks what someone pastes, while an agent leaks what it reads and acts on things nobody watched. Agent detection and response, or ADR, is the same idea with the acronym people already think in.

How is it different from EDR?

EDR judges processes. An agent doing precisely what it was asked to do is not a process anomaly, and the request it makes is a legitimate binary opening an encrypted session to a trusted domain. The signal only exists in the content and the sequence, and the endpoint is the last place that content is readable.

Why the endpoint rather than a gateway?

Because a request can be refused or rewritten only while its bytes are still local and still unsent, and because a gateway only sees what is routed through it. Shadow AI and locally-run agents are, by definition, the traffic that never reaches one. A gateway is a good second control and a poor only one.

What is prompt injection, and why does this category matter for it?

Injection is instructions arriving inside content the model reads: a web page, an issue, a README, a tool result. It matters here because the endpoint sees both halves, the content that arrived and the actions taken afterwards, which is what turns a suspicion into a timeline.

Is it a mature category?

No. The names are still moving, the products in it disagree about scope, and detection content for injected instructions is young enough to need tuning in your own environment. The underlying problem is not speculative, which is why the category formed at all.

The category /

What is agentic endpoint security?

Agentic endpoint security is endpoint security for how a workforce and its AI agents use AI: what people send to AI tools, what those tools send back, which tools an agent calls on its own, and what leaves the machine as a result.

Also called agent detection and response (ADR) by people who think in EDR and NDR terms, and endpoint AI security when the audience is not a security team. The earlier name for the same category was AIDR, and it is still in wide use.

Why the endpoint, and why now

The risk moved into content, and then it moved into behaviour. A developer pasting a production database URL into a chat window is not anomalous at the process layer, the file layer or the network layer. It is an ordinary binary opening an ordinary TLS connection to a domain your allowlist already trusts, so every control in a normal stack looks straight at it and sees nothing.

Then the tools stopped being chat windows. An assistant now reads a repository, calls an API, runs a command and decides what to do next, on a laptop that holds production credentials, while nobody watches. The unit of risk is no longer a single request. It is a sequence of decisions taken by a model that will follow instructions it finds inside content it was asked to read.

Only the plaintext and the sequence tell you anything, and the endpoint is the one place that has both before they leave. That is the whole reason the category sits beside EDR rather than inside a gateway.

The four layers

01
Visibility
Every AI tool and agent running across the fleet, including the ones nobody declared. Discovery needs no plaintext, since a process and a destination are enough, so it reaches tools released after your last policy review rather than only the ones already on a list.
02
Detection
What is actually in the traffic: credentials in a pasted config, personal data in an uploaded spreadsheet, instructions hidden in a page an agent fetched, a tool call that touched something it should not have. This needs the plaintext, which is why it happens on the device.
03
Response
A timeline to investigate against, an alert into the tools you already run, and the ability to isolate a device. Detection without a response path is a report nobody reads on a Monday.
04
Governance
One policy applied across every model, agent and integration, with each decision logged and exportable. The other three layers stand on this one.

The surface it covers

Four separate problems sit under the one category, in roughly this order of interest. Most organisations arrive caring about one of them and discover the other three on the way.

Agents and tool calls

What goes wrong: A coding assistant with shell access, an MCP server holding a token far broader than the task, an agent that runs unattended for an hour and is trusted with credentials because the task needed them.
What it watches for: Which tools an agent called, what came back, and which files, credentials and endpoints it touched along the way.

Retrieved and returned content

What goes wrong: A model reads a web page, an issue, a dependency README or a tool result that carries instructions aimed at the model rather than at the reader, and follows them.
What it watches for: Injected instructions arriving in a response or a tool result, and what the assistant did in the turns that followed.

Prompts and uploads

What goes wrong: A production connection string in a debugging question, a customer list attached to a summarise request, proprietary source pasted into a chat window.
What it watches for: Secrets, personal data and regulated content in the plaintext of the request, evaluated before the bytes leave the device.

Shadow AI

What goes wrong: Tools and agents nobody procured, on personal accounts, on managed devices. The inventory you asked people for is an undercount every time.
What it watches for: Every AI process and destination on the fleet, including tools that appear on no list and were released last week.

How it works, step by step

01
Discover. Identify the AI tools and agents in use from the process and the destination. No plaintext is required at this stage, which is what lets discovery cover a tool that was released last week.
02
Inspect. For onboarded tools, read the traffic on the device while it is still unsent: the prompt, the attachment, the tool call, and the response coming back.
03
Decide. Policy runs against that content and returns one of three actions. Block refuses the request, mask removes the sensitive span and lets the rest through, alert records it and stays out of the way.
04
Record. Every decision becomes a timeline entry: which tool, which agent run, which rule, which action, on which device. Exportable, because the audit is the point of the governance layer.
05
Respond. Findings land in the SIEM and the queue you already work, and a device can be isolated when something has clearly gone wrong.

Worth saying plainly: detection content for the newer failures, injected instructions in particular, is younger than detection content for secrets and personal data. Run those rules in monitor mode first and promote them once you know the false positive rate on your own traffic.

Against EDR, NDR and AI gateways

None of these replaces another. The point of the table is to show where the coverage stops, because the gap between them is where agent activity currently sits.

	EDR	Network / NDR	AI gateway	Agentic endpoint security
Primary telemetry	Process, file and registry events	Flow records and TLS metadata	Requests routed through it	AI requests, responses and tool calls on the device, in plaintext
Core question	Is this process malicious?	Is this connection unusual?	Is this API call permitted?	What is inside this request, and what did the agent do next?
Sees shadow AI	No	Destination only	Only what is routed through it	Yes, every AI process on the fleet
Sees what is in a prompt	No	No, the session is encrypted	Sanctioned traffic only	Yes
Sees injected instructions in a response	No	No	Sometimes, for what it routes	Yes
Sees agent tool calls	Process names, no arguments	No	No	Yes, the call and the result
Can stop it before it sends	Not applicable	No, only after the fact	Yes, for traffic that reaches it	Yes, on the device, unsent
Category maturity	Established	Established	Established	New, and moving quickly

How it differs from what you run

vs EDR: EDR asks whether a process is malicious. Nothing about a trusted binary posting to a reputable domain is anomalous, and an agent doing exactly what it was asked to do is not a process anomaly. The risk sits in the content and the sequence, which EDR has no reason to read.
vs Classic DLP: DLP watches the channels it was designed for: email, file shares, removable media. Agent traffic is an interactive TLS session to a trusted domain carrying content that was typed, pasted, or read out of a repository by the agent itself.
vs AI gateway or proxy: A gateway sees what is routed through it, which is the sanctioned API traffic and nothing else. That is worth having, and it is why a gateway belongs behind an endpoint control rather than instead of one: shadow AI is exactly the traffic that never gets routed through a gateway in the first place.
vs Browser extension: An extension sees the browser. It does not see a desktop app, a coding assistant in an IDE, or a command-line agent, and those are where the highest-value context now travels.
vs Agent sandboxes: A sandbox constrains what an agent can reach. It does not tell you what the agent actually did, what came back, or what left the machine, and it stops at the boundary of the runtime it wraps. The two are complementary.
vs AI-powered security tools: A product that uses a model to triage your alerts is not this category. It is defined by what it watches, not by what it is built with, and what it watches is your workforce and their agents using AI.

The line that decides what a control can do

A guardrail can rewrite or refuse a request only while the bytes are still on the device and still unsent. After that point every control is alerting, because no product can un-send a prompt. Ask any vendor where their inspection happens: that single fact decides whether they can stop something or only tell you about it afterwards.

The second question is how much they see at all. Knowing that a tool is in use is a different fidelity from holding its plaintext, and the honest answer is that discovery covers everything while inspection covers what has been onboarded and tested. Sighted, recorded and inspected are the three states, and they are not interchangeable.

How a security team uses it

Inventory and triage

Start with the list of AI tools and agents actually in use, ranked by how much leaves through each. That list is usually the first honest picture an organisation has, and it is the thing procurement and legal ask for.

Detection engineering

Policies are rules with conditions and actions, so they are written, tested in monitor mode, and promoted to enforcement once the false positive rate is known. The same loop as any other detection content.

Incident response

When a key turns up somewhere it should not be, the question is what was sent, by which agent, from which device, and when. A prompt and tool-call timeline answers it in minutes instead of by interview.

Threat hunting

Agent transcripts are a hunting ground: tool calls that touched credentials, instructions that arrived inside fetched content, runs that continued unattended for an hour.

What to ask a vendor

Where does inspection happen? On the device before the request is sent, or somewhere downstream, where the only remaining option is to tell you what already happened.
What does discovery cover versus what does inspection cover? Every honest answer has two numbers, because the first needs no plaintext and the second needs per-tool work.
Does it see the agent, or only the chat window? Tool calls, tool results and MCP servers are where the category earns its name.
Does it see anything outside the browser? Desktop apps, IDE assistants and command-line agents are where the highest-value context now travels.
What happens to the plaintext it reads? Whether it stays on the device, what is retained, and who can read it afterwards.
Can a rule mask rather than block? Blocking a request people need produces a workaround by lunchtime.

The bottom line

This is not a replacement for anything you run. It is the control for a surface the rest of the stack was never built to see: legitimate people and their agents, using legitimate tools, sending and reading content that happens to matter. The category is young and the vendors in it disagree about scope, so judge them on two things that are easy to check. Where does inspection happen, and what fraction of the AI tools and agents on your fleet does it actually reach.

Frequently asked questions

What is agentic endpoint security in simple terms?: A control that sits on the endpoint and watches how people and their AI agents use AI: which tools are running, what gets sent to them, what comes back, which tools an agent calls, and what leaves the machine. It exists because that activity looks completely ordinary to every other control in a normal stack.
Is this the same thing as AIDR?: Yes. AIDR, for AI detection and response, is the earlier name for the same category, and you will still see it used. The term moved because the interesting risk moved: a chat window leaks what someone pastes, while an agent leaks what it reads and acts on things nobody watched. Agent detection and response, or ADR, is the same idea with the acronym people already think in.
How is it different from EDR?: EDR judges processes. An agent doing precisely what it was asked to do is not a process anomaly, and the request it makes is a legitimate binary opening an encrypted session to a trusted domain. The signal only exists in the content and the sequence, and the endpoint is the last place that content is readable.
Why the endpoint rather than a gateway?: Because a request can be refused or rewritten only while its bytes are still local and still unsent, and because a gateway only sees what is routed through it. Shadow AI and locally-run agents are, by definition, the traffic that never reaches one. A gateway is a good second control and a poor only one.
What is prompt injection, and why does this category matter for it?: Injection is instructions arriving inside content the model reads: a web page, an issue, a README, a tool result. It matters here because the endpoint sees both halves, the content that arrived and the actions taken afterwards, which is what turns a suspicion into a timeline.
Is it a mature category?: No. The names are still moving, the products in it disagree about scope, and detection content for injected instructions is young enough to need tuning in your own environment. The underlying problem is not speculative, which is why the category formed at all.

Keep reading

The platform is this argument as a product: what the sensor installs, what it can see, and where the data goes.
Agent oversight and MCP security cover the agentic half in practice.
Glossary defines shadow AI, prompt injection, MCP, AI DLP and the rest.

See it on your own fleet.

One sensor, deployed through your MDM, showing every AI tool and agent in use and what is leaving the device.