Как Uber защищает своих AI-агентов: реальный стек ADR для наблюдаемости и безопасности в проде

Denis Shokhirev

19 Sep 2026 — 2 min read

Я — Денис Шохирев, архитектор агентных AI-систем из Фрайбурга. В DennisCraft AI Studio я запускаю автономных агентов для B2B в DACH на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Первый же публичный инцидент: на проде агент Uber пытался запросить внешнюю API, которой не было в политике — и только из-за чёткой ADR-архитектуры это не превратилось в баг на клиента.

Зачем Uber нужен production-grade ADR: реальный кейс

Когда AI-агент выходит за пределы песочницы, к нему применяются те же требования, что и к обычному сервису: полная наблюдаемость, аудит, возможность быстро локализовать и купировать вредные действия. Uber одними из первых начали формализовать Agent Decision Recording (ADR) — процесс логирования и анализа решений AI-агентов в реальном времени.

Проблемы без ADR

Нельзя проследить, почему агент принял то или иное решение (нет трассировки).
Риски безопасности: уязвимости на уровне сгенерированного кода или обращений к API.
Сложно внедрять SRE-подходы: инциденты реплицируются, а RCA невозможен.

Базовые элементы ADR-стека для AI-агентов

Uber, как и многие, строит стек на реальных инструментах. Ниже — мой опыт, где каждое звено проверено в проде.

Компонент	Роль	Инструменты
Сбор решений агента	Логирование каждого action/decision	Supabase, Postgres
Анализ/аудит	Статический и динамический анализ кода, compliance	semgrep, bandit, gitleaks
Оркестрация	Управление цепочками, интеграции	n8n
Secret management	Изоляция ключей и токенов	Doppler
Live monitoring	Онлайн-трассировка действий агента	custom dashboards, Supabase Realtime

Как устроен реальный ADR pipeline: по шагам

1. Логирование решений агента

Каждый запрос агента (например, к внешней API или к базе) логируется в отдельную таблицу. Структура простая:


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)
);

Через Supabase и Postgres это реализуется за 1 день, вся история решений доступна для анализа.

2. Runtime sandbox + статический анализ

Все LLM-генерируемые куски кода (например, SQL или Python snippets), которые агент собирается выполнить, прогоняются через semgrep и bandit до выполнения. Если найден паттерн вроде SQL-инъекции или небезопасного eval — агенту возвращается error, действие блокируется.


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

На трёх реальных продовых внедрениях я ловил одни и те же паттерны SQL-инъекций именно этим способом.

3. Контроль секретов и токенов

Все токены и секреты (API-ключи, DB credentials) отдаются агенту только через Doppler — ни один ключ не лежит в исходниках или в переменных окружения ноды. При попытке агента получить секрет, не находящийся в Doppler, действие блокируется.


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

4. Live мониторинг и аудит

Supabase Realtime позволяет строить дешёвые live-дэшборды для мониторинга действий агента: кто, когда, с каким инпутом принял решение, какой action был выполнен. В проде это помогало за 10 минут локализовать ошибку, которую агент допустил из-за неверного промпта.

Контроль качества кода и реакция на инциденты

Uber и другие крупные игроки используют автоматизированные пайплайны для контроля кода, который LLM-агенты генерируют на лету. Даже простой набор: semgrep (поиск паттернов), bandit (Python), gitleaks (секреты) — закрывает 90% типовых уязвимостей (см. OWASP Code Injection, 2024).

В случае инцидента — все данные доступны для RCA, rollback, быстро делается patch, агент выводится из rotation.

FAQ

ADR — это open source или internal-паттерн?

ADR — это паттерн, не продукт. Uber публиковал подходы, но open source-реализации как "Uber ADR" нет. Я использую свой микс на базе реальных инструментов.

Как защитить агента от утечки секретов?

Только отдельный secret management (Doppler, Vault). Никогда не хранить ключи в коде или базах данных, которые агент может читать напрямую.

Как внедрять этот стек в DACH-бизнесах?

Стартовать с логирования решений через Supabase, затем добавить статический анализ (semgrep, bandit), live-мониторинг, секреты — последним этапом.

Можно ли отслеживать действия агента в real time?

Да, через Supabase Realtime или кастомные WebSocket дэшборды.

LLM-агент может обойти этот контроль?

Если пайплайн и sandbox настроены правильно — только при ошибке в конфиге или если агенту прямо разрешено выполнять небезопасные действия.

На каком этапе у вас в пайплайне ловится больше всего критических багов — статический анализ, sandbox или аудит логов? Пишите — сравню с собственными данными. Я делаю бесплатный аудит стека для DACH-команд, кто реально выводит AI в прод. Пишите в LinkedIn или @ger_dennis_ai.