uber/ADR: a four-part agent security stack where prevention is still missing
ADR secures enterprise AI agents through observability, security benchmarking, and threat detection. Deployed at Uber.
At a glance
- What is it?
- ADR is Uber's open-source toolkit for finding AI agents on endpoints, recording what they do, benchmarking their defences, and triaging suspicious sessions. Discovery, Sensor, Bench and Detector ship under Apache-2.0; the prevention component and the ADR Explorer engine do not.
- Who is it for?
- Adopt ADR if you already run Cursor, Claude Code, Codex or similar agents on managed endpoints and you need an inventory plus a normalised telemetry schema before you can reason about agent risk at all. Do not adopt it expecting an inline enforcement layer: the README states that ADR Prevention is not in the current open-source release, so blocking an unsafe tool call is out of scope for this code.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ADR targets: agents nobody agreed to install
Most enterprise security tooling assumes a known set of applications. Coding agents break that assumption. A developer can install Cursor or a CLI agent, wire up one or more MCP servers, and start executing shell commands and file edits within minutes, with no ticket and no review. The README frames ADR Discovery as the answer to that: it inventories installed AI applications, CLI agents, IDE extensions, local model runtimes and MCP servers on an endpoint, and flags unknown surfaces for review. The audience is the enterprise security team, not the individual developer. The README names two populations explicitly: employee-facing agents such as Cursor, Claude Code and Codex, and customer-facing agents such as AI support agents. That split matters because the telemetry and the risk model differ. An employee agent touching a local repository is a data-exfiltration question. A support agent talking to customers is a prompt-injection and brand-safety question.
Four shipped components and one deliberate hole
The repository layout maps cleanly onto the capability list. Discovery/ holds the endpoint inventory, probes and a fingerprint catalogue. Sensor/ collects and normalises agent telemetry from Claude Code, Cursor, Codex, opencode, Claude Desktop and others, across macOS, Linux and Windows. Detection/ bundles both the benchmark and the detector: a dual-agent detector, 133 MCP servers, 303 benchmark tasks, baselines and figure scripts. docs/REPRODUCIBILITY.md describes the workflow for reproducing benchmark detection and the paper figures. The fifth capability in the README's list, ADR Prevention, is marked as not included in the current open-source release. The offline ADR Explorer engine, described as hardening ADR Detection through pre-deployment red teaming, is also absent. So the released stack covers discover, observe, benchmark and detect. It stops short of acting on what it finds. That is a defensible release boundary, but it changes what you can build. You can produce a finding. You cannot ship the block.
How the detector splits triage from reasoning
The README describes ADR Detection as a two-tier architecture: high-recall triage first, then deeper agentic reasoning for suspicious sessions. The design intent is cost control. Running a full agentic analysis over every recorded session would be expensive and slow, so a cheap pass narrows the field and the expensive pass only sees what survives. The default detector is named `adr`, described as the ADR dual-agent detector, which fits that two-stage shape. A second option, `llamafirewall`, exists for keyless smoke tests, which is useful when you want to confirm the pipeline runs before spending API credit. What the README does not give is the triage rule itself, the thresholds, or how sessions are promoted from tier one to tier two. Anyone evaluating detection quality will need to read Detection/README.md and the paper rather than the top-level README.
Getting the benchmark running
The quick start is short and assumes uv for dependency management. Clone the repository, change into Detection/, run `uv sync`, then export `ANTHROPIC_API_KEY` and `OPENAI_API_KEY`. The default detector is `adr`; pass `--detector llamafirewall` if you want a keyless smoke test instead. The full evaluation path is documented separately in docs/REPRODUCIBILITY.md and follows three stages: inflate the packed benchmark, run the detectors, then plot the figures. The benchmark itself is substantial on paper: 303 tasks, 133 MCP servers, and coverage of all 17 agent attack techniques according to the README. One caveat is stated plainly in the data notice. Detection/ ships synthetic fixtures, including fake credentials and emulated environments, for defensive security research only. That is the right call for a public release, but it means the numbers you reproduce are numbers on synthetic scenarios, and your own traffic will look different.
The Sensor's normalisation schema is the real adoption cost
Discovery and Detection are the parts people talk about. Sensor is the part that decides whether the project fits your fleet. It collects and normalises telemetry from Claude Code, Cursor, Codex, opencode, Claude Desktop and others, across three operating systems. Normalisation is the hard part. Each of those tools emits its own event shapes, and a unified schema means every new agent version is a potential mapping break. The README lists a release, sensor-v1.0.0, dated 2026-07-31, which suggests the schema is versioned rather than free-floating. That helps, but it also means an upgrade can change field semantics under a downstream detector or SIEM rule. If your detection logic keys off specific normalised fields, treat a Sensor major version bump as a migration, not a routine pull. The README does not publish a schema stability guarantee, so confirm the field contract in Sensor/README.md before you build on it.
Where ADR is the wrong tool
Two cases stand out. First, if your requirement is enforcement, ADR as released cannot meet it. The README is explicit that Prevention is not in the open-source release. A stack that discovers, observes, benchmarks and detects still leaves the unsafe action unblocked. Second, if you do not run managed endpoints, Discovery has little to inventory. The fingerprint catalogue and probes assume you can inspect machines. For a small team running agents on personal laptops with no endpoint management, the Discovery component has no surface to work with, and you are left with Sensor plus Detector, which is a much narrower product. There is also a scale question the README does not answer: it gives task and MCP server counts for the benchmark, but not the throughput or storage cost of continuous telemetry collection across a large fleet.
How it differs from generic LLM firewalls
The obvious comparison is a prompt-level firewall such as LlamaFireWall, which the repository itself offers as a keyless baseline detector. The difference is the unit of analysis. A firewall inspects a prompt or a completion at the boundary and decides whether to allow it. ADR's Sensor records agent intent, tool use and execution traces, and the Detector reasons over whole sessions, which is why it can use a two-tier design with a reasoning stage. That lets ADR catch behaviour that only looks wrong in sequence, such as a chain of individually benign tool calls. The trade-off runs the other way too: a session-level system sits behind the action, so its output is a finding rather than a block, and it needs storage and compute that a boundary filter does not. ADR-Bench is the other differentiator. With 303 tasks and 133 MCP servers, it gives you a way to measure a detector rather than take its accuracy on faith.
Licence, maintenance and what to check first
ADR is Apache-2.0, which permits commercial use and modification, and the repository carries a CITATION.cff alongside the BibTeX entry for the MLSys 2026 paper. One licensing detail needs attention rather than legal advice: Detection/benchmark/agentdojo/ is vendored third-party code under its own MIT licence, so a compliance review should treat that directory separately from the rest of the tree. Maintenance signals are mixed. The last push is dated 2026-09-08, the Sensor reached v1.0.0 in July 2026, and the project is not archived, so it is active. But the two missing pieces, Prevention and the ADR Explorer engine, are the ones the README flags as future work, and there is no date attached. Plan for a stack that finds problems and hands them to a human, and check Detection/README.md for the `--detector` options and docs/REPRODUCIBILITY.md for the inflate, run, plot sequence before you size the work.
Editorial conclusion
Adopt ADR if you already run Cursor, Claude Code, Codex or similar agents on managed endpoints and you need an inventory plus a normalised telemetry schema before you can reason about agent risk at all. Do not adopt it expecting an inline enforcement layer: the README states that ADR Prevention is not in the current open-source release, so blocking an unsafe tool call is out of scope for this code. Before committing, verify three things against your own environment: that the Sensor's supported tool list covers the agents you actually deploy, that your macOS, Linux and Windows fleet matches the platforms the Sensor README names, and that you have budget for two model providers, since the default detector path expects both ANTHROPIC_API_KEY and OPENAI_API_KEY.
Community notes