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

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

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

Що отримує оператор

Olivares AI — це відкрита, self-hostable платформа, яка працює там, де працюють ваші агенти. Вона виявляє їх, будує карту доступу на читання/запис щодо того, чого торкається кожен з них, і дає вам засоби керування та аудиту цього доступу. Для SRE чи системного адміністратора п’ять властивостей важать більше, ніж перелік функцій.

Пасивна — не в шляху запиту

Виявлення будується з телеметрії та власних журналів аудиту джерел поза смугою (out of band). Подання про справність і надійність є споживачем шини подій, а не зондом, який відкриває сокети у вашу інфраструктуру — активність виводиться зі спостережуваної діяльності, а агент, який перестає надсилати події, сам є сигналом. Оскільки Olivares не є проксі або sidecar перед вашими агентами, збій Olivares не може вивести їх з ладу. Єдині поверхні, що будь-коли перебувають у шляху, — це опціональні шлюзи активації, які ви вирішуєте підключити, і вони відмовляють за замовчуванням (fail closed).

Один self-hosted статичний бінарний файл

Розгортається як єдиний статичний бінарний файл з вбудованою вебконсоллю — немає парку агентів, який треба розкочувати, немає Kubernetes-оператора панелі керування, за яким треба наглядати. Сховище — це pure-Go SQLite (Postgres для багатоорендних розгортань), тож немає C-набору інструментів, з яким треба боротися. Ви встановлюєте один файл, запускаєте його під виділеним сервісним користувачем — і отримуєте кабіну пілота. Див. встановлення та self-host.

Панель керування працює всередині вашого периметра і може працювати в air-gapped режимі — ваші дані з керування та спостереження ніколи його не залишають. Одне застереження, яке операторам варто тримати в голові: це не офлайн-AI. Хостовані моделі на кшталт Claude однаково звертаються до API постачальника; air-gapped означає, що дані вашого парку лишаються вдома, а не те, що модель працює локально. Лише по-справжньому self-hostable моделі (vLLM, Ollama) працюють повністю офлайн. Докладніше в розділах безпека та архітектура.

OTel-native приймання даних

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

Зонди та справність, як у будь-якого сервісу, що ви запускаєте

Бінарний файл надає кінцеві точки, на які ваш оркестратор уже розраховує:

GET /livez     liveness  — чи процес запущено
GET /readyz    readiness — чи він обслуговує (і не є холодним резервом)
GET /healthz   setup-exempt liveness для скрейперів
GET /metrics   Prometheus exposition

/readyz повертає 503, коли резервне сховище недосяжне, замість того щоб зависати, тож балансувальник навантаження виводить вузол з ротації замість того, щоб поглинати запити в чорну діру. Понад те, модуль XXII відстежує справність, SLA та аптайм самих агентів і MCP-серверів — що справне, що деградувало і що від чого залежить — і надсилає висновки про падіння/деградацію/ відновлення/порушення SLA у ваш наявний канал (Slack, PagerDuty, SIEM). Він виробляє сигнал; він не намагається бути вашою системою сповіщень.

Спершу читає, з реальною зупинкою всього парку

Olivares за замовчуванням детективна та типово закрита (deny-closed). Вона широко спостерігає й керує; вона не активує широко. Але коли агент дає збій о третій ночі, оператору потрібен один важіль, який спрацьовує без церемоній, — тож kill-switch реальний і створений для використання:

• Активація дешева. Рівень адміністратора, одна обов’язкова причина, один клік. Немає шлюзу затвердження і немає підвищення прав на активацію — аварійна зупинка, яка чекає на кворум, не є зупинкою. Масштаб усього парку відмовляє в кожній керованій поверхні активації для орендаря; масштаб агента зупиняє одного агента на кожній поверхні, де його можна назвати.
• Повторне ввімкнення — ні. Зняття зупинки вимагає подвійного контролю (dual-control) (двох різних людей) і супроводжується обов’язковим подальшим розбором, який має підписати третя, непричетна особа. «Парк лишається зупиненим» — це безпечний стан.
• Воно відмовляє за замовчуванням (fails closed). Кожен шлюз активації звіряється з живим станом зупинки під час кожного виклику й відмовляє за помилки читання — нечитабельний стан зупинки ніколи не означає «вперед».

Будьте чесними із собою щодо масштабу: зупинка така ж широка, як і шлюзи, які ви підключили. Вона не може заморозити поверхню, в яку Olivares не має шва. Це свідомий компроміс системи, що спершу читає, — і саме тому виявлення й карта йдуть першими.

Що це таке — і чим воно не є

• Це пасивна, self-hosted кабіна пілота: виявляйте агентів, складайте карту їхнього доступу на читання/запис, стежте за їхньою справністю та тримайте зупинку всього парку за один клік.
• Це не вбудований проксі, бекенд трасування чи система, яка нишком перекомутовує ваших агентів. Активація — за вибором, на вимогу і типово закрита (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, потім швидкий старт для синтетичного парку.
• Підключіть перший сигнал: підключення джерела.
• Зрозумійте модель: дозволене проти спостережуваного та карта доступу.
• Суміжні з оператором ролі: платформна інженерія та керівники з безпеки.