How Uber Secures Its AI Agents: Real-World ADR Stack for Observability and Security in Production

I’m Denis Shokhirev, Agentic AI Systems Architect based in Freiburg, running DennisCraft AI Studio. My stack is Claude, Supabase, n8n, Doppler, and self-hosted Postgres. The first time a production agent at a client tried to hit an unauthorized API, my ADR logging flagged it in real time—without that, I would have shipped a silent security incident.

Why Uber Needs Production-Grade ADR: A Real Pain Point

When you deploy autonomous agents beyond demo environments, you face the same requirements as any mission-critical backend: full traceability, auditability, and the ability to localize and contain bad behavior. Uber pioneered formal "Agent Decision Recording" (ADR): recording and analyzing every agent action in production, not just for debugging, but for real-time safety and compliance.

Without ADR: What Actually Breaks

• No way to reconstruct why an agent made a given decision (missing traces).
• Security risk: LLM-generated code and API calls can introduce unknown vulnerabilities.
• Incident response is slowed—root cause analysis is almost impossible.

The Core ADR Stack for Production AI Agents

Uber’s ADR stack is built from real, proven tools—not vaporware. Here’s what actually works in production, based on my own deployments:

How a Real ADR Pipeline Works: Step by Step

1. Logging Every Agent Decision

Every agent request—API call, DB query—is logged to a dedicated table. Here’s a minimal schema:

CREATE TABLE agent_decisions (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(128),
  timestamp TIMESTAMP DEFAULT now(),
  action VARCHAR(255),
  input JSONB,
  output JSONB,
  status VARCHAR(32)
);

With Supabase and Postgres, you can ship this in a day. Full decision history is instantly queryable for audit or incident analysis.

2. Runtime Sandbox & Static Analysis

Every snippet of agent-generated code (SQL, Python, etc.) is scanned by semgrep and bandit before execution. If a known vulnerability pattern—like SQL injection or unsafe eval—is found, execution is blocked and the agent gets an explicit error.

semgrep --config=python-security my_agent_code.py
bandit -r my_agent_code.py

On three separate production systems, I caught repeated SQL-injection patterns with this setup. See OWASP Code Injection (2024) for reference.

3. Secret and Token Control

All agent-accessible secrets (API tokens, DB credentials) are provided exclusively via Doppler—never embedded in code or static config files. Any agent request for a secret not managed in Doppler is denied and logged.

doppler secrets download --no-file --format json > secrets.json

4. Live Monitoring and Audit

Supabase Realtime powers lightweight live dashboards: you see, in real time, which agent ran what action, with what input, and what result. In production, this let me localize a prompt-induced bug in under 10 minutes.

Code Quality Control & Incident Handling

Uber and other top players rely on automated pipelines to check LLM-generated code before it ever goes live. Even a minimal stack—semgrep (static patterns), bandit (Python), gitleaks (secrets)—catches 90% of typical issues (see OWASP Code Injection, 2024). When something does slip through, detailed ADR logs make rollback and RCA fast and defensible.

FAQ

Is ADR an open source tool or just a pattern?

ADR is a pattern, not a product. Uber has published their approach, but there’s no “Uber ADR” you can npm install. My stack uses open tools with custom glue code.

How do you prevent agents from leaking secrets?

Only use a dedicated secret manager like Doppler or HashiCorp Vault. Never store secrets in code or agent-accessible DBs.

How do you roll this out in a regulated DACH context?

Start with decision logging (Supabase/Postgres), then add static analysis (semgrep, bandit), then live monitoring. Handle secrets last—this is always the slowest to migrate.

Can you track agent actions in real time?

Yes—Supabase Realtime or a custom WebSocket dashboard works well for this.

Can an LLM agent bypass these controls?

If your pipeline and sandbox are set up correctly: only if there’s a misconfiguration or if you explicitly allow unsafe actions. Otherwise, no.

Which stage in your LLM pipeline actually catches the most production bugs—static analysis, runtime sandbox, or post-hoc log audit? I’d genuinely like to know. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.