Кабина управления для AI-агентов, работающих в вашей инфраструктуре

Вы уже держите дашборды для всего остального в вашем парке: хостов, очередей, хранилищ данных, пути запроса. А затем появляется десяток AI-агентов — копилоты, MCP-серверы, задания по расписанию, экземпляр Claude Code, который кто-то подключил к продакшену, — и у вас нет единого места, которое отвечало бы на первый вопрос оператора: что работает и до чего на самом деле может дотянуться каждая из этих сущностей?

Это тот же паттерн, что и неуправляемая теневая инфраструктура, за исключением того, что эти рабочие нагрузки держат учётные данные и действуют самостоятельно. Среди организаций, переживших связанный с AI инцидент безопасности, около 97% не имели надлежащего контроля доступа AI (IBM Cost of a Data Breach 2025, Ponemon). У индустрии уже есть для этой причины название — agent sprawl (разрастание агентов), — и Gartner ожидает, что более 40% проектов agentic-AI будут свёрнуты к концу 2027 года (Gartner), зачастую потому, что никто не смог безопасно их эксплуатировать, как только они начали множиться.

Что получает оператор

Olivares AI — это открытая, локально размещаемая платформа, которая работает там, где работают ваши агенты. Она обнаруживает их, строит карту доступа по чтению и записи для того, к чему прикасается каждый из них, и даёт вам элементы управления для регулирования и аудита этого доступа. Для SRE или системного администратора пять свойств важнее списка функций.

Пассивный — не на пути запроса

Обнаружение строится из телеметрии и нативного аудита источников вне основного потока. Представление о работоспособности и надёжности является потребителем шины событий, а не зондом, открывающим сокеты в вашу инфраструктуру — живучесть выводится из наблюдаемой активности, а агент, который перестаёт что-либо отправлять, сам по себе является сигналом. Поскольку Olivares не является прокси или сайдкаром перед вашими агентами, сбой Olivares не может вывести их из строя. Единственные поверхности, которые вообще оказываются inline, — это опциональные шлюзы воздействия, которые вы решаете подключить, и они отказывают в режиме fail-closed.

Один локально развёрнутый статический бинарный файл

Он разворачивается как единый статический бинарный файл со встроенной веб-консолью — никакого парка агентов, который надо распространять, никакого Kubernetes-оператора для control plane, который надо обслуживать. Хранилище — это чистый Go-SQLite (Postgres для мультиарендности), так что нет C-тулчейна, с которым пришлось бы бороться. Вы устанавливаете один файл, запускаете его под выделенным сервисным пользователем — и у вас есть кабина управления. Смотрите установку и self-host.

Control plane работает внутри вашего периметра и может работать air-gapped — ваши данные управления и наблюдения никогда его не покидают. Одна оговорка, которую операторам стоит держать в голове: это не офлайн-AI. Размещённые модели вроде Claude по-прежнему обращаются к API поставщика; air-gapped означает, что данные вашего парка остаются дома, а не что модель работает локально. Полностью офлайн работают только действительно локально размещаемые модели (vLLM, Ollama). Подробнее в безопасности и архитектуре.

OTel-нативный приём данных

Путь приёма данных опирается на семантические соглашения OpenTelemetry GenAI наряду с OCSF, форматами SIEM и W3C Trace Context — поэтому та телеметрия, которую вы уже отправляете, и есть та телеметрия, которую он читает. Одна честная граница: Olivares коррелирует ваш журнал управляемых событий по W3C trace_id; он не хранит полные OTel-спаны. Длительности и статусы в представлении трассировок — это окна событий журнала, а не реконструированные данные спанов. Полные спаны остаются в вашем собственном OTLP-коллекторе, где им и место. Olivares сообщает вам, кто к чему прикоснулся и было ли это разрешено — это не замена вашему бэкенду трассировки. (Смотрите страницу сравнения, чтобы понять, где он стоит рядом с LiteLLM/Langfuse.)

Пробы и работоспособность, как у любого сервиса, который вы запускаете

Бинарный файл предоставляет эндпоинты, которые ваш оркестратор уже ожидает:

GET /livez     liveness  — запущен ли процесс
GET /readyz    readiness — обслуживает ли он (и не является ли холодным резервом)
GET /healthz   liveness, не требующий проверки инициализации, для scrapers
GET /metrics   экспозиция Prometheus

/readyz возвращает 503, когда базовое хранилище недоступно, вместо того чтобы зависать, поэтому балансировщик нагрузки выводит узел из ротации, а не отправляет трафик в чёрную дыру. Помимо этого, модуль XXII отслеживает работоспособность, SLA и аптайм самих агентов и MCP-серверов — что функционирует нормально, что деградировано и что от чего зависит — и выдаёт находки down/degraded/recovered/SLA-breach в вашу существующую систему оповещения (Slack, PagerDuty, SIEM). Он производит сигнал; он не пытается быть вашим уведомителем.

Read-first, с настоящей остановкой всего парка

Olivares по умолчанию детективный и закрытый (deny-closed). Он наблюдает и регулирует широко; он не воздействует широко. Но когда агент выходит из-под контроля в 3 часа ночи, оператору нужен один рычаг, который работает без церемоний, — поэтому kill-switch настоящий и создан для того, чтобы им пользовались:

• Активация дешёвая. Уровень администратора, одна обязательная причина, один клик. На активацию нет шлюза согласования и нет повышения прав — аварийная остановка, которая ждёт кворума, не является остановкой. Область всего парка запрещает каждую управляемую поверхность воздействия для арендатора (tenant); область агента останавливает одного агента на всех поверхностях, на которых он может быть назван.
• Повторное включение — нет. Снятие остановки требует dual-control (двух разных людей), и за ним следует обязательное пост-ревью, которое должен подписать третий, непричастный человек. «Парк остаётся остановленным» — это безопасное состояние.
• Он отказывает в режиме fail-closed. Каждый шлюз воздействия сверяется с актуальным состоянием остановки на каждом вызове и запрещает действие при ошибке чтения — нечитаемая остановка никогда не означает «вперёд».

Будьте честны с собой насчёт области действия: остановка ровно настолько широка, насколько широки подключённые вами шлюзы. Она не может заморозить поверхность, в которую у Olivares нет шва. Это осознанный компромисс системы, работающей по принципу read-first, — и именно поэтому обнаружение и карта идут первыми.

Чем это является — и чем не является

• Это пассивная, локально развёрнутая кабина управления: обнаружить агентов, построить карту их доступа на чтение/запись, следить за их работоспособностью и держать остановку всего парка в одном клике.
• Это не inline-прокси, бэкенд трассировки или система, которая молча перекраивает ваших агентов. Воздействие — это opt-in, по требованию и закрытое по умолчанию (deny-closed) — каждый шов вы подключаете осознанно.
• Это продукт версии до 1.0 и open-core. Каталог перечисляет 23 модуля возможностей; примерно двадцать подключены сегодня, остальные находятся на стадии проектирования или относятся к периоду после v1. Справочник модулей отмечает, что работает в реальности.
• Это не сертифицированный продукт. Olivares проектируется в направлении SOC 2, ISO/IEC 42001 и EU AI Act — он не обладает этими сертификациями и не будет на них претендовать. Смотрите безопасность, чтобы увидеть честную позицию.
• Достоверность разбита на уровни и показывается именно так. Покрытие по чтению против записи — clean на хранилищах с нативным аудитом, lossy на некоторых хранилищах документов/векторов и unknown там, где его нельзя реконструировать пассивно (Redis, SQLite, D1); атрибуция по отдельным агентам — firm только когда сигнал это поддерживает, и approximate за общей учётной записью. Ничего не угадывается. Смотрите достоверность.

С чего начать

• Поднимите его: self-host, затем быстрый старт для синтетического парка.
• Подключите первый сигнал: подключите источник.
• Разберитесь в модели: разрешённое против наблюдаемого и карта доступа.
• Смежные с оператором роли: платформенная инженерия и руководители безопасности.