Uber ADR Watches Your Coding Agents by Reading Their Logs, Secrets Included
Uber's open-source agentic detection and response tool needs no hooks or proxies. That makes it easy to deploy, and it makes its output one of the most sensitive files on the machine.
Every coding agent on your laptop is already keeping a diary. Claude Code, Codex, Cursor, Copilot CLI and Gemini CLI write their sessions to disk as JSONL files or SQLite databases, full of prompts, tool calls and tool results. Most developers never open them.
Uber's ADR, short for Agentic AI Detection and Response, opens all of them. It is climbing the Trendshift board this week, and its design makes a bet worth understanding before you install it: you do not need to instrument an agent to watch it, because the agent already wrote down everything it did.
That bet mostly pays off. It also creates a new file you will have to protect.
What ADR is
The README lays out the system in components, and five matter here. Discovery inventories installed AI apps, CLI agents, IDE extensions, local model runtimes and MCP servers. Sensor captures "agent intent, tool use, and execution traces." Benchmark ships more than 300 tasks across 134 MCP servers. Detection uses a "two-tier architecture" that pairs "high-recall triage with deeper agentic reasoning." Prevention, the part that would stop an action before it runs, is "not included in the current open-source release."
The README says ADR is "Deployed in production at Uber" and "Accepted to MLSys 2026." The license is Apache-2.0, and the only tagged release so far is ADR Sensor v1.0.0 from July 31, 2026.
So what you get today is visibility and after-the-fact detection. Keep that framing. ADR tells you something went wrong. It does not stop it.
The mechanism: no hooks, just files
Most agent-security tools sit in the path. They proxy model traffic, register a permission hook, or wrap the shell. ADR's sensor does none of that. Its Sensor README says it reads agent telemetry through direct file access: JSONL and JSON logs for Claude, Copilot CLI, Gemini CLI and others in your home directory, SQLite databases for Cursor and Warp, and Codex's JSONL files plus its SQLite catalogs. Environment variables like CODEX_HOME and COPILOT_HOME override the default paths.
The support table covers 11 agents on macOS and 10 each on Linux and Windows. By default the sensor looks back 14 days by file modification time, and --all-history reaches further.
I like this design for the same reason I like log-based monitoring anywhere. It works on agents you did not configure, it survives agent upgrades as long as the log format holds, and it adds nothing to the agent's hot path. A hook can be disabled by the session it is guarding. A log file written after the fact is harder to argue with.
Each parsed session becomes an AgentEvent with session metadata (username, hostname, OS, model), conversation text, tool names, arguments and results, token counts, and session context including permissions and MCP servers.
Read that list again, slowly. Tool arguments and results.
The problem: the sensor output is a secrets store
The Sensor README says it plainly: "Tool arguments and results can contain source code, credentials, or other sensitive content copied from the local environment." If your agent ran cat .env, the result is in the agent's log, and now it is in ADR's output too.
That output goes to three places. Local JSON or JSONL files, by default in ./output. An optional session cache under your XDG cache directory or the Windows AppData equivalent. And, if you configure it, an OpenTelemetry endpoint, where each session goes out as an adr.agent.session log record whose body is the full event. On that export path the README is explicit that the sensor applies "no redaction or field projection," so "prompts, responses, tool arguments, tool results, usernames, hostnames, and local paths can be transmitted."
This is my position, and it is the reason for the article. ADR's value comes from collecting exactly what an attacker would want, from every agent on the machine, into one place. That is fine. Security tools always hold sensitive data. But a detection tool that copies credentials off a laptop into a central log pipeline has moved those credentials from one developer's home directory into a system with many more readers. If you adopt ADR, the sensor output deserves the same handling as the secrets it is looking for.
What detection costs, and what it claims
The Detection README names its defaults in config: a gpt-4o triage stage and a claude-sonnet-4-6 reasoning stage. That is why setup asks for both ANTHROPIC_API_KEY and OPENAI_API_KEY. In practice, session content you analyze goes to OpenAI and Anthropic models. Check that against your data agreements before you run it on real sessions.
On its own benchmark, the README reports ADR at a precision of 1.000 and a recall of 0.667 with zero false positives, against LlamaFirewall at 0.167 precision and 40 false positives. Treat those as the maintainers' numbers on the maintainers' benchmark. The Detection README says the "Benchmark fixtures include synthetic credentials, prompt-injection payloads, and emulated vulnerable MCP servers." A recall of 0.667 also means that, on Uber's own tests, about a third of attacks went unflagged.
The benchmark covers categories like credential exposure, data exfiltration, scope violations and control-flow hijacking, plus AgentDojo-style prompt injection.
Put this into practice
Start small, and start with Discovery and the sensor, not the full pipeline.
1. Install the sensor somewhere you control. The README gives pip install adr-sensor, or pip install "adr-sensor[otel]" for OpenTelemetry export. Run it first on a single machine, writing to local files only.
2. Treat ./output as sensitive from the first run. Run it from a directory on an encrypted volume, keep it out of any synced or backed-up folder, and never inside a git repo. The default output location is relative to where you launch it, which is easy to forget.
3. Read what it captured before you ship it anywhere. Open a few AgentEvent records and search them for your own tokens. You will learn more about your agents' habits in ten minutes than from any dashboard, and you will see exactly what an OTLP export would send.
4. Use the quieter flags. --log-file-content-free drops message text from runtime logs, and --no-save disables local file output. The structured diagnostics already exclude prompts, tool arguments, paths and session IDs.
5. Put redaction in front of OpenTelemetry. Since the sensor does none on export, add a processor in your collector that strips or hashes tool results before anything leaves the machine.
6. Run the Detection benchmark in a sandbox only. The README calls it a "research artifact" whose pinned dependencies "carry known CVEs," and asks for a container or VM.
Honest limitations
There is no prevention in the open-source release. ADR detects after the session is already written to disk. If an agent exfiltrated a key, ADR can tell you it happened, not stop it.
Log-reading depends on log formats the agent vendors own and can change. The sensor's parser-health diagnostics exist for a reason, and a silent format change can blind it for one agent while the others look fine.
The benchmark is self-run on synthetic data, and the README's own table has a dash where LlamaFirewall's recall should be, so the comparison is thinner than the headline suggests. I would not quote those numbers to a security team as independent results.
Detection sends session content to two external model providers by default. For some teams that ends the evaluation right there, unless they can point the detector at models they host themselves, which I have not tested.
And the 14-day default lookback means anything older sits outside the first scan, which matters if you are investigating rather than monitoring.
What to decide this week
ADR's core insight holds up: your coding agents already produce the audit trail, and reading it is cheaper than intercepting it. The open question is where that trail ends up. Before you install the sensor, decide who should be able to read a full copy of every tool result your agents saw, then build the storage to match. If the answer is "only me," keep it local. If it is "the security team," redact first. Either way, make the choice on purpose, because the sensor will not make it for you.
Sources: uber/ADR README, ADR Sensor README, ADR Detection README, ADR releases, Trendshift.
Medium metadata
- Title: Uber ADR Watches Your Coding Agents by Reading Their Logs, Secrets Included
- Subtitle: Uber's open-source agentic detection and response tool needs no hooks or proxies. That makes it easy to deploy, and it makes its output one of the most sensitive files on the machine.
- Tags: AI Agents, Cybersecurity, Claude Code, Open Source, DevSecOps
- Canonical: fervorai.dev