AI coding agents have moved from personal productivity experiments into corporate development environments, and the security model is starting to catch up. Uber’s newly opened ADR repository is a useful signal because it does not treat Claude Code, Cursor, OpenAI Codex CLI, Cline, Claude Desktop, Warp Terminal or opencode as ordinary editors with a little autocomplete. It treats them as systems that read prompts, observe repositories, select tools, call shells, touch files, interact with MCP servers and sometimes handle credentials-like material. That chain is not visible enough if the security team only watches processes and file events.

Security operations dashboard tracking AI coding agent actions

What Uber actually opened

ADR stands for Agentic Detection and Response, not the familiar architecture-decision-record acronym. The GitHub repository describes it as an enterprise security system for AI agents and says it has been deployed at Uber. At the time of publication the public repository was under Apache-2.0, written primarily in Python, had about 1,334 stars and 112 forks, and had been updated on August 10, 2026. Those numbers are not the main story, but they show that the release landed while the agent-security conversation is already active.

The project is not a single magic scanner. The top-level framing is four-part: observability, benchmark, detection and prevention. The open-source release includes the sensor, ADR-Bench and detector components. The prevention layer and some internal exploration tooling are not part of the current release. That distinction matters for teams that want to learn from the architecture without pretending that a GitHub clone becomes a production SOC control by itself.

The accompanying paper, accepted to the MLSys 2026 Industry Track, gives the stronger context. Its abstract names three persistent problems in enterprise agent security: limited observability, insufficient robustness and high detection cost. It also says the system has operated at Uber for more than ten months, across more than 7,200 unique hosts, processing more than 10,000 agent sessions per day. The paper further reports hundreds of credential exposures across 26 categories and describes a shift-left prevention layer with 97.2% precision and 206 detected credentials. Those figures should be read as Uber’s reported deployment evidence, not as a guarantee for another company’s environment.

Why EDR and SIEM see too little

Traditional endpoint detection and response is good at questions such as which process wrote a file, which binary opened a socket, which child process started, or which host touched a suspicious domain. That remains necessary. The problem is that an AI agent introduces a missing layer between user intent and operating-system event. A shell command may be benign in isolation, but risky when it came from a prompt-injected issue, an untrusted document, or an agent loop that misunderstood the task.

A SOC analyst who sees “process wrote .env” has a narrow fact. For agentic development the better question is wider: what did the user ask, what context did the model read, what intermediate reasoning or plan did the agent expose, which tool calls were proposed, which ones were executed, what policy applied, and what outcome followed? Without that session-level chain, the team can detect symptoms while missing cause.

This is why ADR’s emphasis on agent sessions is important. The Sensor README describes parsers for logs from several employee-facing tools, including Claude Code, Cursor IDE, Cline, Claude Desktop, OpenAI Codex CLI, Warp Terminal and opencode, with platform differences across macOS, Linux and Windows. It normalizes events into a schema with fields such as session ID, timestamp, chat history, tools, model, project path and session context. That is the vocabulary EDR normally lacks.

The MCP and tool-call problem

The most consequential part of the agent stack is not the chat window. It is the tool boundary. A coding agent becomes operationally powerful when it can read a repository, call git, run tests, browse internal docs, open a ticket, invoke a deployment helper, query a database, or use an MCP server that wraps another system. Each connector can be useful; together they create a rights graph that may be hard to see.

The ADR material treats that graph as a detection target. ADR-Bench is described as roughly three hundred scenarios; the detection documentation refers to 303 scenarios, 261 benign and 42 malicious, with 17 attack techniques and 133 MCP servers. The precise count is less important than the shape of the benchmark: it tries to test agent behavior where malicious instructions, synthetic credentials and vulnerable MCP services appear in realistic workflows.

That is also why the open-source notes carry a warning. The benchmark material includes synthetic attack content and pinned dependencies with known CVEs for reproducibility. It is meant for isolated evaluation, not for casual execution inside production infrastructure. A professional team should treat it like security test equipment: useful, controlled and separated from systems that hold real secrets.

What changes for engineering leaders

For a CTO or head of engineering, the practical message is not “ban agents” and not “install any one project.” The message is that AI-assisted development now needs an operational layer. The first step is inventory: which agent tools are allowed, where their logs live, what operating systems are in scope, which repositories are reachable, and which actions can run unattended. Many organizations cannot answer those questions today because adoption happened through individual developers before policy caught up.

The second step is least privilege. Agents should not inherit every credential, shell permission and browser session available to the developer by default. Credential gateways, per-task tokens, short-lived access, repository-scoped permissions and clear rules for MCP servers are no longer nice extras. They are the difference between a productivity tool and an unreviewed automation account with a human face.

The third step is auditability. Logs should show not only the final command but the chain from prompt to tool call to outcome. That does not mean storing everything forever. Agent telemetry can contain code snippets, internal tickets, prompts, customer details and strings that resemble secrets. A safe ADR-like program needs retention limits, redaction, access controls, separation of duties and a way to send useful signals into SIEM without turning the logging system into a new sensitive-data lake.

What changes for security teams

For security teams, ADR points to a new detection surface. A suspicious agent session may not look like malware. It may look like a normal developer machine running a normal editor. The anomaly might be a tool sequence, a prompt pattern, a sudden read of credential locations, a generated script that reaches outside the expected network, or an MCP server that turns a documentation lookup into an action against a live system.

That means rules must combine context. Process telemetry alone is too shallow; pure prompt scanning is too brittle; model-output inspection alone misses what actually executed. The useful unit is the session: inputs, context, tools, file and network effects, and policy decisions. Mature teams will want detections that can explain why an action was risky, not only that a command matched a regular expression.

This will also pressure vendors. IDE makers, cloud workspaces, terminal tools, agent frameworks and MCP platforms will be asked for exportable, structured logs. Security teams will want schemas that preserve causality without exposing more content than necessary. If every tool records a different private format, enterprise adoption becomes harder and incident response becomes guesswork.

The market signal around agents

The direct Hacker News submission about Uber’s ADR was small, but adjacent discussions have been much livelier. Threads about cloud coding agents, credential gateways and agent sandboxes show the same concern from different angles: where should an agent run, which credentials should it see, how isolated is the workspace, what does one thread or one VM cost, and who is accountable when automation crosses a boundary? Those are operational questions, not novelty questions.

That context matters because ADR is not an isolated curiosity. It sits beside cloud sandboxes for agents, credential brokers that keep secrets out of prompts, runtime monitors for AI applications and policy engines for developer workspaces. The industry is slowly replacing “let a model drive my laptop” with managed agent infrastructure. Security monitoring is one piece of that transition.

The historical analogy is imperfect but useful. Enterprises did not adopt cloud by simply letting every team create unmanaged accounts forever; they eventually built identity, logging, cost controls, policy and incident response around cloud use. AI coding agents are heading toward the same normalization. The tools may start in a developer’s terminal, but the risk belongs to the business.

What to do this quarter

A realistic company can begin without building a full ADR program. Start with a written map of approved agent tools and their data paths. Require developers to disclose which agents can execute commands, which can access browsers, which can use MCP servers and which can read private repositories. Separate casual completion tools from agents that can modify the filesystem or call external services.

Next, reduce ambient credentials. Use dedicated development tokens instead of long-lived personal tokens where possible. Keep production secrets away from general agent sessions. Review shell profiles, local .env files, package-manager tokens, cloud credentials and SSH keys. If agents run in cloud workspaces or sandboxes, define what is copied in and what is deliberately absent.

Then collect the logs you can collect today. Editor logs, shell histories, terminal transcripts, MCP gateway events, Git commits, pull requests and CI runs can already be correlated. The correlation will be imperfect, but it will teach the security team where the gaps are. When a vendor later offers better agent-session telemetry, the organization will know what questions to ask.

Finally, test with controlled scenarios. Do not point a benchmark containing attack payloads at production. Use an isolated repository and synthetic secrets. Ask whether the team can tell when an agent read a sensitive file, followed a hostile instruction from an issue, attempted a network call, or modified code outside the requested scope. If the answer is no, the company has found its first agent-security backlog.

The caveat: monitoring can become its own risk

The instinct to “log everything” is dangerous here. Agent sessions may include source code, unreleased product plans, vulnerability notes, customer support data, internal architecture diagrams and pasted secrets. A careless observability layer could become a more concentrated breach target than the original endpoints. The security control therefore needs its own security model.

Good practice means collecting the minimum useful context, redacting aggressively, encrypting telemetry, limiting who can read raw sessions, setting retention by sensitivity and documenting how employees are informed. It also means distinguishing between detection evidence and behavioral surveillance. Developers need to know what is recorded and why. Without that trust, agent monitoring will be treated as another black-box control and teams will route around it.

The bottom line

Uber’s ADR release is important because it names a gap that many companies are about to feel. AI coding agents are not just editors, and they are not full employees. They are delegated systems that convert prompts and context into tool use. Existing EDR and SIEM layers still matter, but they do not naturally understand that causal chain.

The next phase of corporate AI development will be decided less by which agent writes code fastest and more by which organization can make agent work observable, bounded, reviewable and recoverable. The question is no longer whether developers will use AI coding agents. The question is what conditions must exist so that agentic coding does not become a blind spot in security, compliance and engineering accountability.