uber/ADR ships four of its five components, and the fifth is a sentence with no code behind it

Capability five is a sentence with no directory behind it

The system is described through five capabilities: discovering unsanctioned AI tools, observing agent activity, evaluating defenses with a benchmark, detecting threats, and preventing unsafe actions. Four of them have a directory. The fifth is stated as stopping unsafe actions before they cause harm and then told plainly that this component is not included in the current open-source release, with an invitation to stay tuned. The repository layout section withholds a second thing, the offline ADR Explorer engine that hardens detection through pre-deployment red teaming. So the released system can tell you what is installed, record what agents do, test detectors and flag risky sessions, but the two components that would stop or pre-empt an action are the two you cannot read. Any evaluation that depends on prevention or on pre-deployment red teaming has to be done elsewhere.

One directory carries two components and only one has a version

The layout table maps four paths to five names. Discovery/ is discovery. Sensor/ is observability. Detection/ is both the benchmark and the detector, described in one cell as a dual-agent detector, 134 MCP servers, 304 benchmark tasks, baselines and figure scripts. So the benchmark and the detector share a directory and a dependency set, while the inventory tool and the telemetry collector each get their own. Versioning follows the same unevenness. The repository has a single release, tagged sensor-v1.0.0 and titled ADR Sensor v1.0.0 from 2026-07-31, which gives the telemetry collector its own version line and leaves Discovery and Detection without any tag to cite. The default branch itself took a commit on 2026-10-02, so work continues on all of it; it is the packaging that is partial, not the code.

The default detector spends two vendors' keys per session

The quick start is four lines, and two of them are credentials:

git clone https://github.com/uber/ADR
cd ADR/Detection
uv sync
export ANTHROPIC_API_KEY="..." OPENAI_API_KEY="..."

The default detector is named adr and described as the ADR dual-agent, which is why two providers appear rather than one. For a smoke test without keys the documentation points at a different detector, selected with the flag --detector llamafirewall. Cost control inside the detector comes from its two-tier shape, where a high-recall triage pass narrows the field and deeper agentic reasoning runs only on sessions that look suspicious, though the README does not say which model serves the first tier. The practical consequence for an evaluator is that the headline detector cannot be exercised on a free budget, and the keyless comparison run is against a different system than the one the paper describes.

The benchmark ships packed and you inflate it before anything runs

The evaluation workflow is summarised in one line and the line is worth reading literally: inflate packed benchmark, then run detectors, then plot figures. The repository therefore does not carry the benchmark in runnable form; a packed artifact has to be expanded first, and the order matters because the detectors read the inflated files. The reproducibility document under docs/ is the named authority for that workflow. The benchmark itself is large and specific: ADR-Bench is described as 300 or more tasks in the capability list and as 304 benchmark tasks in the layout table, with 134 MCP servers and coverage of all 17 agent attack techniques. Alongside them sit baseline detectors and the scripts that produce the paper's figures, which means the comparison runs and the plots are meant to be regenerated locally rather than read off a chart.

Vendored MIT code sits inside an Apache-2.0 tree

The repository is Apache License 2.0, and the license section carves out one subtree: Detection/benchmark/agentdojo/ is vendored third-party code carrying its own LICENSE file under MIT terms. That is the normal arrangement for vendored code and it is stated in the same section rather than buried, but it does mean a license scan of the tree returns two licenses and a reader has to know which subtree is which. The root also carries a NOTICE.md, which is where attribution for the vendored material belongs. Everything else, the Discovery, Sensor and Detection source, the docs and the paper PDFs, sits under the Apache terms. The mixed licensing is confined to the benchmark directory, so it affects anyone redistributing the benchmark fixtures rather than anyone running the sensor.

The telemetry list and the opening list are not the same list

The opening paragraph names the employee-facing agents it secures as Cursor, Claude Code, Codex, GitHub Copilot CLI and DeepSeek Harness. The Sensor row names seven and adds others: Claude Code, Cursor, Codex, GitHub Copilot CLI, DeepSeek Harness, opencode and Claude Desktop. Claude Desktop is not a coding tool, which tells you the collector is keyed on where an agent runs rather than on what it is for. The observability claim is that agent intent, tool use and execution traces are captured across seven or more coding tools on macOS, Linux and Windows, and a separate note adds that Gemini CLI session journals are captured too, including tool results and nested subagent sessions. What production adds on top is internal automation and customer-facing support agents, neither of which is a surface the open tree can show you.

Discovery inventories five kinds of surface and flags the ones it cannot name

The inventory component looks for five categories on an endpoint: installed AI applications, CLI agents, IDE extensions, local model runtimes and MCP servers. Its output is not a clean list, because the interesting result is the residue: surfaces that match no fingerprint in the catalog get flagged for review rather than counted as known. The catalog itself is part of the component, documented alongside the endpoint inventory and the probes in Discovery/README.md. That design choice explains the ordering in the paper's own framing, since nothing can be observed or defended until somebody knows what is running. Model runtimes and MCP servers are the two categories that change fastest, and both are counted here by presence rather than by version, so the flag list is the part a team would have to triage by hand.

Synthetic fixtures and a notice that scopes the use

The Detection/ subtree ships synthetic benchmark fixtures, and the data notice names what that means in practice: fake credentials, emulated environments and prompt-injection scenarios, present for defensive security research only, with the reasoning collected in docs/OPEN_SOURCE_REVIEW.md. Synthetic material is the right call for a benchmark that needs to reproduce injection attempts without shipping live attack payloads, and the notice tells a reader where to look before drawing conclusions about what the fixtures model. The same section of the repository carries the paper and the conference slides as PDFs under docs/, the citation metadata as CITATION.cff, and the project's homepage link points at an arXiv abstract rather than at a product page, so the paper is the primary description of the system.

Editorial conclusion

This is a defensive system, and it is worth reading for the shape of the problem rather than for the paper's numbers: the hard part is not detecting one bad session, it is knowing which tools exist on an endpoint at all. Three things to check before adopting it. The fifth capability is a placeholder, so anything that depends on stopping an action before it happens is not in this repository. The default detector is a dual-agent design that needs keys from two model vendors, and the keyless path is a different detector entirely. And the benchmark ships packed, so follow the reproducibility document's order of inflate, detect, plot rather than improvising a run. Detection is the component with no release tag; if you need version pinning today, the Sensor at 1.0.0 is the only one available.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. uber/ADR on GitHub