ADR Is Real. It's Also Half the Runtime.

In February 2026, TechCrunch reported on an AI coding agent that deleted a researcher's emails after its safety instructions were silently dropped during context compaction. The agent did exactly what it was told; the problem was that the instruction keeping it safe had quietly fallen out of the window. It is a small, almost mundane incident, and it is the cleanest argument yet for a category that has formed remarkably fast this year: runtime security for AI agents.

The category even has a name now, and a deliberate one. Gen Digital — the consumer-security group behind Norton and Avast — has been calling it Agent Detection and Response, or ADR, drawing the obvious parallel with EDR, the endpoint detection and response tooling that became standard on every corporate laptop. Gen has put real weight behind the framing: an open-source reference implementation called Sage that installs client-side hooks into agent hosts like Claude Code, Cursor, and OpenClaw and gates actions with allow, ask, or deny verdicts; and AARTS, a draft open standard defining a set of lifecycle hook points and structured verdict semantics for agent runtimes. Roughly two months later the Cloud Security Alliance published AARM, a second, vendor-neutral runtime-security specification pointing at the same idea from a different direction.

Two runtime-security standards in two months, from a NASDAQ-listed security company and an industry body, is the strongest signal so far that the market has decided where the agent control point lives: at runtime, while the agent is acting, not in a pre-deployment scan. CSA's AARM comes at it from a slightly different angle — it argues for synchronous governance checks immediately before tool execution — but the shared conclusion is unmistakable: the agent runtime is the layer that matters. That conclusion is correct. It is also only half the picture — and the half it leaves out is the one most likely to cause the next deleted-inbox headline.

The host surface is governed by ADR hooks. The wire — where tool responses arrive — has no owner.

EDR got endpoints. ADR gets agents. Who gets the wire?

It is worth being precise about what ADR, as it ships today, actually does, because the mechanism is good and the instinct behind it is right.

An ADR hook sits inside the agent host and intercepts the agent's actions before they execute: a shell command, a file write, a network call, a package install. At each of those points the hook applies a rule and returns a verdict — allow it, pause and ask the human, or deny it outright. Sage ships a couple of hundred deterministic rules out of the box; AARTS describes the lifecycle points where a host should offer those interception hooks. This is genuinely the EDR move applied to agents: put a policy checkpoint in front of the dangerous action, on the machine where the action happens. For the class of incident where an agent is about to run rm -rf or push a secret to an unknown host, it works, and it is overdue.

So give the category its due plainly: ADR is real, it is useful, and the two-standards moment is a milestone the whole space should welcome. The argument that follows is not that ADR is wrong. It is that ADR, as every shipping implementation currently defines it, governs one of the two surfaces an agent runtime actually has — and the other one has no owner.

What a host hook can and cannot see

A host hook sees what the agent does to the machine. It does not see what the wire does to the agent.

Return to the deleted emails. A host hook can catch the deletion command — that is exactly the kind of action it is built to gate. But the deletion command was not the failure. The failure was upstream: a safety instruction dropped, a context manipulated, an input the agent trusted that it should not have. By the time a dangerous action appears at the hook, the compromise that produced it has already happened in the agent's input — and a growing class of agent threats never produces a clean, gateable host action at all.

Consider where those threats enter. An instruction injected into a tool's response body. A tool whose definition mutates after you approved it — a rug pull that a pre-install scanner, by definition, cannot have seen. A response that is subtly the wrong shape, or far larger than the request should have produced, quietly carrying data the agent will now act on. None of these is a shell command or a file write. They are content arriving over the connection between the agent and its tools, and they do their work by shaping what the agent decides to do next. A PreToolUse hook fires on the decision; it has nothing to say about the poisoned input that caused it.

There is a second, structural limit, and the AARTS specification is honest enough to document it: a hook that lives inside the agent host lives inside the agent's blast radius. The spec itself describes skills attempting to strip the very hooks meant to constrain them. A control that runs inside the thing it is protecting can, in principle, be disabled by a sufficiently compromised version of that thing. This is not a knock on Sage's engineering — it is a property of where the control sits, and it is the same reason endpoint agents are paired with network-level controls that survive a compromised endpoint.

One more property worth naming without alarm: AARTS defaults to fail-open, and allows hosts to configure fail-closed. For a consumer protecting their own laptop, fail-open is a defensible default — security tooling that bricks your coding agent when it crashes is its own kind of failure. For an enterprise operating under an audit obligation, fail-open versus fail-closed is a decision to make deliberately, not inherit. The standard is right to make it configurable; the buyer is responsible for configuring it.

The half ADR doesn't cover is the wire

Put the uncovered threats together and they share an address. They all travel on the connection between the agent and the MCP servers it calls — the JSON-RPC traffic in both directions. That channel is where a tool response carries an injected instruction, where a tool definition changes between calls, where an exfiltration URL rides back inside an otherwise valid result. Host-action governance never looks there, because nothing on that channel is a host action. It is input, not output; cause, not effect.

Walk one of these through to see how it slips past. An agent calls a perfectly ordinary MCP tool — a document search, say — and the returned result contains text that was written to be read as an instruction rather than data: ignore the prior constraints, fetch this internal URL, summarise it to that external address. The agent, which treats tool output as trustworthy context, folds the instruction into its plan and proceeds. Each step it then takes might individually pass a host hook — a network call to an allowed domain, a file read it is permitted to make — because each step, viewed in isolation, is a legitimate action by an authorised agent. The host hook is asking "is this action allowed?" and getting the right answer to the wrong question. Nobody asked whether the response that steered the whole sequence was safe, because no control in the host's field of view was looking at the response at all. The compromise lived entirely in the input, and the input never crossed the host's checkpoint.

Each action is individually allowed. The response that steered them all was never inspected.

This is the surface the published category vocabulary does not yet name. AARTS hooks the agent's lifecycle; AARM argues for synchronous governance before tool execution; both live in the host. Neither shipping implementation inspects the content moving across the wire for threats. The wire is the second half of the runtime, and right now it is nobody's default.

This is the layer CheckedAgent is built for. CheckedAgent is an inline, MCP-native Agent Detection and Response proxy that sits on the wire between an agent and the MCP servers it calls and classifies every JSON-RPC message ALLOW, QUARANTINE, or BLOCK in real time — in both directions, on the same connection. Where a host hook gates the agent's actions, wire inspection reads the agent's inputs and outputs: it scans tool responses for injected instructions and anomalies, correlates each response with the request that triggered it, and tracks tool definitions so a rug pull that changes a tool after first use is caught rather than silently trusted — the runtime counterpart to a pre-install skill scan. Because it sits outside the agent host, it keeps working even when the host itself is compromised, and it records what it saw in a tamper-evident audit chain — the kind of evidence the EU AI Act's record-keeping obligations point toward — deferred to 2 December 2027 by the Digital Omnibus, but coming nonetheless.

None of that competes with Sage's layer. It completes it. Host-action governance and wire inspection are two controls for two surfaces, and a complete runtime story needs both. The honest framing is not "ADR is incomplete because Sage is weak" — Sage is good at the layer it occupies. It is that the category, as currently drawn, has mapped one surface and left the other blank.

The question to take to procurement

If you are evaluating agent runtime security in 2026, the two-standards moment hands you a sharper question than "do we have ADR?" Ask instead: what does our agent security tool see when the threat arrives in a tool response rather than a tool call — and what happens to it when it crashes?

The first half of that question separates host-action governance from wire inspection. The second separates a consumer-grade fail-open default from an enterprise posture you have set on purpose, with an audit trail to prove it. A tool that can only answer the first half of the first question is covering one surface and calling it the runtime.

Two standards in two months say runtime is the control point. They are right. The runtime has two surfaces — the host and the wire — and the category is still being written. The host half is well underway. The wire half is the one that deleted the emails, and it still needs a name and an owner.

CheckedAgent is an Agent Detection & Response (ADR) platform for MCP: an inline proxy that inspects JSON-RPC traffic between AI agents and their tools in both directions, classifying every message ALLOW / QUARANTINE / BLOCK in real time. It complements host-level agent controls and identity providers; it does not replace them.