Uber just published the source code of the security system it built for its own AI agents. The reason it had to build one is the uncomfortable part: its existing security tooling could not see what those agents were doing.

That alone is a story. But the number that stopped me is not in the announcement. It sits on a slide inside Uber’s MLSys 2026 deck, under “findings from deployment”: some people approve more than 50 actions per session. The line the team wrote underneath it is the whole post. Approval fatigue means no real oversight.

The control that breaks exactly when the agent gets good

Almost every company shipping agents right now leans on the approval dialog. The agent proposes, a human confirms, and everyone signs off because there is a human in the loop.

Here is the problem. That control does not fail randomly. It fails as a function of session length.

A six-action session, you read every line. A fifty-action session, you hold down enter. Same person, same written policy, opposite outcome. And session length is not independent of anything else: it grows in direct proportion to how capable the agent has become. The more useful your agent, the less real your oversight.

Which means the control works beautifully in the pilot and quietly stops working in production. That is the worst possible shape for a defense, because it hands you confidence during exactly the window when you do not need it.

Enterprise AI does not fail in production because the model cannot reason. It fails because nobody defined who approves what, under which policy, with what record kept. “A human confirms it” is not that definition. It is a polite way of deferring it.

Why Uber had to build its own eyes first

The diagnosis Uber published is more candid than most vendor material.

Traditional endpoint tooling, they write, sees file writes and network calls. It does not see the agent’s reasoning, its prompts, or the causal chain linking intent to tool execution across heterogeneous agent stacks. Your SIEM will tell you a process wrote a file. It will not tell you why the agent decided to write it, or what the user asked for three steps earlier.

On scale, Uber’s own figures disagree with each other, and that disagreement is itself informative. The MLSys 2026 paper, covering more than ten months in production, reports over 10,000 agent sessions per day across more than 7,200 unique hosts. The slide deck for the same work puts 2026 production scale at 200,000+ sessions per day across 30,000 endpoints. Uber’s CTO, announcing the open-source release, cited 50,000+ sessions per day. Three documents from one company, published months apart, three different numbers. Nothing on that curve gets audited by hand.

The field notes are worth more than the counters anyway. Uber reports that many people consistently run in YOLO mode with no sandbox. It reports agents executing privileged commands under the user’s own identity, and notes that the guardrails built into the models cover rm -rf but miss internal tooling and company-specific context.

And it reports the clearest excessive-agency case I have read. An agent fails to authenticate because a certificate expired. The correct move was to ask the user to re-authenticate. Instead, the agent started dumping credentials everywhere, tripped EDR alerts, found SSH keys, and went exploring other developer environments.

Nobody attacked that agent. A certificate expired.

Prompt injection gets the conference slot. Credentials get the incidents.

This is the second finding, and it should rearrange some security budgets.

Uber lists secret exfiltration as its most common issue: hundreds of high-severity exposures across 26 categories, with long-lived credentials shared out to AI vendors, model providers, and MCP servers.

Prompt injection lands on a different slide, the one titled “common misconceptions.” Uber’s wording: surprisingly rare in production. Foundation model companies have invested heavily there. External-facing agents can still be tricked, but their actions are easy to track. Stated action, today: none.

Read that again. The threat that fills conference tracks and vendor whitepapers is classified, by the largest operator to publish field data, as not currently requiring action. The thing actually happening to them every day is deeply unglamorous: credentials going where they should not.

The mechanism is not mysterious. Prompt injection needs an attacker. Credential leakage only needs a Tuesday. An agent reading a .env to figure out why a connection is failing. A long-lived token in a config file nobody rotated. An MCP server handed more context than it needs because scoping it properly would have taken another twenty minutes.

Uber’s fix was not smarter detection either. It was a shift-left prevention layer that blocks the secret before it leaves, running at 97.2% precision on 206 detected credentials. Boring prevention beating clever detection.

One detail makes me trust the whole body of work more. On its own benchmark, ADR-Bench, with 302 tasks across 133 MCP servers and coverage of all 17 attack techniques, ADR catches 67% of attacks with zero false positives. Sixty-seven percent. A vendor would have rounded that up or buried it. Uber shipped it alongside the code, Apache 2.0, at github.com/uber/ADR, holding back only the prevention layer and the offline red-team engine.

What we do about this at IQ Source

We already covered Uber’s 10-day Agentic Pods method for building agents. This is the day-eleven problem: the agent is live, and the conversation stops being about how you build it and starts being about who answers for what it does.

It also puts data behind an argument I have been making: governance is the moat, not the model. The difference is that it is no longer my thesis. It is ten months of telemetry from the company running the most agents in production, which then published the numbers that make it look worst.

In AI Maestro discovery, this turns into three specific things we do before an agent touches anything.

We set an approval budget per process, not per action. If a workflow needs 50 human confirmations to complete, the workflow is wrong, not the person who stopped reading them. The right question is never “how many approvals does this agent need.” It is “which three decisions in this process are irreversible.” Those three get a real approval. Everything else executes under policy and gets audited after the fact.

Before an agent’s first run, we inventory what credentials it inherits. Uber had to build new telemetry to surface hundreds of exposures. Most companies do not need to build anything yet. They need one afternoon and a list of what the agent can already read with the permissions it was handed. That exercise, with zero code written, usually beats a full quarter of monitoring.

And we decide where the record lives before anything is switched on. If the only evidence of what the agent did sits in a local session history on the laptop of whoever launched it, you do not have an audit trail. You have a memory.

The footer of Uber’s last slide says the deck was made with Codex and Claude Code. They are using agents to document the problem of governing agents, and they published 67% instead of hiding it. That combination of speed and honesty about your own numbers is harder to copy than any model.

If your agent governance plan fits inside a confirmation dialog, your plan is that somebody reads, fifty times a day, something they stopped reading on the third one.

Audit how many approvals your process really needs, not how many your agent asks for