AI Agent Security Framework: Inside Uber ADR

An AI agent security framework is the set of controls that tells you what your agents are doing, whether your defenses actually catch anything, and which sessions deserve a human. Uber just open sourced its own, called ADR, and the most useful thing about it is which agents it treats as the primary risk: the coding agents already installed on your engineers' laptops.

Uber's ADR repository went public under the official uber organization and passed 800 stars on August 5, 2026. The accompanying paper was accepted to MLSys 2026, and the README states the system is deployed in production at Uber. That combination, a production deployment plus a peer-reviewed paper plus running code, is rare enough in agent security to be worth reading closely.

Key Takeaways:

• ADR stands for Agentic AI Detection and Response. It covers four capabilities: observability, benchmarking, detection, and prevention.
• Only three of the four are in the open source release. Prevention is held back, and so is the offline red-teaming engine called ADR Explorer.
• The sensor collects agent intent, tool calls, and execution traces from 7 or more AI coding tools across macOS, Linux, and Windows.
• ADR-Bench ships 303 benchmark tasks, 133 MCP servers, and coverage of 17 agent attack techniques, so you can test whether a defense detects anything before you trust it.
• The detector is deliberately two-tier, because running deep analysis on every agent session costs more than most security budgets allow.

What an AI agent security framework has to cover

Most writing about agent risk stops at the threat list. Prompt injection, over-broad tool permissions, credential exposure, an agent that reads a malicious file and then acts on it. That list is useful, and we have written our own version of it, but a list is not a framework.

A framework has to answer operational questions instead. Which agents are running in this company right now, and on whose machine. What did that agent actually do at 3am. If we deploy a detector, does it catch anything, and how would we know. When it flags a session, who looks at it and how much does looking cost.

ADR is organized around exactly those four questions, which is the clearest signal that it came out of an operations team rather than a research lab. The four components map one to one: Observability answers what is happening, Benchmark answers whether defenses work, Detection answers which sessions are suspicious, and Prevention answers what to block.

What this proved: the useful unit in agent security is not a threat taxonomy, it is a control loop. What it left unsolved: the loop still terminates in a human reviewing flagged sessions, and ADR does not make that person cheaper.

Four capabilities, three of them actually open source

Reading the repository layout carefully matters here, because the announcement and the artifact are not the same size.

So the released package lets you watch agents, test detectors, and detect. It does not let you block, and it does not include the adversarial engine Uber used to make its own detector harder to fool. That is a meaningful gap and the README is upfront about it, which is more than most corporate open source releases manage.

The license is Apache 2.0, with the vendored agentdojo benchmark code under its own MIT license. The benchmark fixtures are explicitly synthetic: fake credentials and emulated environments, published for defensive research.

What this proved: you can adopt the observability and evaluation halves today. What it left unsolved: the enforcement half is still Uber's, so "deployed at Uber" does not mean "deployable by you" in the same shape.

The first target is the coding agent on your engineer's laptop

This is the part that reframes the whole project, and it is buried in the second sentence of the README.

ADR is built to secure two populations. Customer-facing agents, such as AI support bots, are the ones every vendor talks about. The other population is employee-facing agents, and the README names them: Cursor, Claude Code, and Codex. The sensor covers 7 or more AI coding tools across macOS, Linux, and Windows.

That ordering is the insight. At a company the size of Uber, the largest deployed fleet of AI agents was never a product the company shipped. It was the tooling engineers installed themselves, running with their credentials, on their machines, with filesystem and network access, inside the corporate network. Nobody procured it. Nobody threat-modeled it. It arrived through a plugin marketplace.

A security team that starts from "how do we secure our AI product" is solving the second problem first. ADR's design says the first problem is inventory: find out how many coding agents are running, on which platforms, doing what.

What this proved: shadow agent adoption is now a bigger surface than shipped agent features. What it left unsolved: telemetry collection from developer machines is a consent and morale question as much as a technical one, and the repository does not address that.

ADR-Bench: 303 tasks, 133 MCP servers, 17 attack techniques

The benchmark is the piece most teams can use immediately, and the numbers describe its ambition.

303 tasks is large for this category. 133 MCP servers matters because the Model Context Protocol is how most agents now reach tools, which means the tool surface is the attack surface. Coverage of all 17 agent attack techniques is a claim about completeness against a defined taxonomy rather than an open-ended promise.

The reproducibility path is documented: inflate the packed benchmark, run detectors, plot the paper figures. The default detector is ADR's own dual-agent design, and there is a keyless option using llamafirewall for a smoke test, so you can confirm the harness runs before you spend on API calls. Running the full ADR detector requires both Anthropic and OpenAI keys, which is worth knowing before you budget an evaluation.

Part of the suite is vendored from AgentDojo, the prompt injection benchmark from ETH Zurich's SPY Lab. Building on existing academic work rather than inventing a private scoring scheme is the right call and makes cross-paper comparison possible.

What this proved: agent defenses can be measured against a shared task set instead of asserted. What it left unsolved: a taxonomy of 17 techniques is a snapshot, and the techniques will move faster than the benchmark.

Two-tier detection, because reading every session is too expensive

The detector's architecture is a cost decision dressed as an engineering one, and it is the most transferable idea in the project.

Tier one is high-recall triage: cheap, tuned to let very little through, and expected to produce false positives. Tier two applies deeper agentic reasoning to the sessions that survive triage. The design accepts that the expensive analysis cannot run on everything.

This mirrors how mature security operations already work, and it is the opposite of how most agent-monitoring demos are built, where an LLM judges every trace and the pricing only works in a demo. If your agent fleet produces tens of thousands of sessions a week, the question is not whether an LLM can spot a bad one. It is what you are willing to pay per session to find out, and what recall you accept at tier one.

What this proved: detection economics, not detection accuracy, is the binding constraint at fleet scale. What it left unsolved: the repository does not publish per-session cost figures, so you have to measure that yourself.

What ADR does not hand you

Four honest limits, stated because the enthusiastic coverage will skip them.

No enforcement. Prevention is not released. You can observe and detect, then you build your own response.

No hardening loop. ADR Explorer, which red teams the detector before deployment, stays internal. You get the detector without the process that made it robust.

It is a research and engineering artifact, not a product. There is no hosted service, no dashboard you buy, no support contract. Standing this up is a project.

Uber scale is a hidden assumption. A two-tier detector is the right answer when you have a large fleet. If you have twelve engineers using Claude Code, the honest answer is that a tool allowlist and log retention get you most of the value for a fraction of the work.

None of that makes the release less interesting. It makes it a reference architecture rather than a drop-in, and reference architectures from teams running the thing in production are more useful than vendor whitepapers.

What to copy from ADR if you are not Uber

Start with inventory. Before any detector, find out which coding agents are installed across your org, on which operating systems, with which credentials. Most teams discover the number is larger than they guessed. ADR's sensor schema is a reasonable model for what to collect even if you never run the sensor.

Then decide the boundary. The reason agent security is hard on laptops is that the agent runs where you have the least control, with the most privilege, and the least logging. Agents that run in a managed environment instead of on employee machines do not become secure by default, but they collapse the problem to one place you can instrument, which is why where you run agents is a security decision and not only an ergonomics one. If that is the direction you want, MoClaw runs agents in a hosted environment rather than on the developer's own machine.

Then, and only then, evaluate a detector, using ADR-Bench to check that whatever you pick actually fires.

Agent security starts with knowing which agents are already running

The most quotable thing in Uber's release is not a detection rate. It is the ordering of the problem. Uber's security team built observability first, benchmarking second, detection third, and prevention last, and open sourced them in that order.

That order is an argument. It says the failure mode in enterprise agent security is not a missing control, it is a missing inventory: teams buying prevention for agents they cannot yet see. ADR is worth reading as a description of what a company with a real agent fleet decided to build first, and what it decided could wait.

Verified against the GitHub API on August 5, 2026: uber/ADR, Apache-2.0, created April 19, 2026, past 800 stars, first release sensor-v1.0.0 published July 31, 2026.

FAQ

What is an AI agent security framework?

It is a set of controls covering what agents do (observability), whether defenses detect real attacks (benchmarking), which sessions are risky (detection), and what gets blocked (prevention). A threat list is not a framework; a framework has an operational answer for each stage.

Is Uber ADR open source and free?

The released components are Apache 2.0 licensed and free to use. Three of the four capabilities are public. Prevention and the ADR Explorer red-teaming engine are not included in the current release.

How do enterprises secure AI agents?

In practice, by inventorying which agents are running and with what privileges, restricting the tools each agent can reach, logging sessions, and reviewing flagged ones. ADR's contribution is showing that this can be measured with a shared benchmark instead of assumed.

What is ADR-Bench?

A benchmark of 303 tasks spanning 133 MCP servers and 17 agent attack techniques, used to test whether a detector actually catches agent misuse. It vendors part of the AgentDojo prompt injection benchmark.

Does ADR work with Claude Code and Cursor?

Yes. The sensor is built to collect telemetry from Claude Code, Cursor, Codex, and other coding agents, across macOS, Linux, and Windows.