Что такое Olivares AI?

Olivares AI интегрирует AI, который вы запускаете, управляет им и защищает его — на одной машине или во всей инфраструктуре, один источник истины: Claude Code на самом глубоком уровне, Codex и Grok Build рядом, дополняя их, а не конкурируя с ними. По мере того как вы задействуете всё больше моделей, агентов, MCP-серверов и инструментов в реальной, разнородной инфраструктуре, одновременно усложняются две вещи: сделать AI действительно полезным и удержать его под контролем. Это одинаково верно и для одной self-hosted-машины, и для регулируемой инфраструктуры; различается масштаб, а не природа.

Olivares AI делает и то, и другое. С одной стороны, он даёт вашему AI то, что нужно для работы — контекст, доступ к нужным ресурсам, управляемые сессии. С другой — даёт вам гранулярные права, политики, бюджеты и аудиторские доказательства, чтобы запускать всё это: какая модель и какой агент к чему может обращаться, какие данные они трогают, что им разрешено выполнять, что они тратят, и доказательство, которое вы можете предъявить регулятору.

Всё работает как единый self-hosted бинарник на ваших собственных хостах. Обязательной телеметрии нет, а исходящий трафик управляющей плоскости по умолчанию отсутствует. За ваш периметр выходит только то, что вы настроили для передачи наружу: обращения к API ваших моделей, подключённые вами выходы SIEM/webhook и внешний поставщик эмбеддингов, если вы его настроили. Это свойство архитектуры и вашей конфигурации; это описание, а не гарантия.

Одна возможность: карта доступа на чтение/запись

Среди этих возможностей — карта доступа R/RW. Для каждого инициатора (агента, нечеловеческой идентичности, сессии) она строит ребро к каждому ресурсу, которого тот касается, классифицированное как read, write, read-write или unknown, и помеченное:

откуда пришёл сигнал (SignalSource) — OpenTelemetry от кооперативного агента, классификация READ/WRITE из Postgres pgAudit, запись AWS CloudTrail, подстраховка на уровне ядра eBPF/Tetragon, MCP-аннотация (рассматриваемая как недоверенная и подтверждаемая, никогда не доверяемая в одиночку), объявленный грант политики или сигнал агент-к-агенту (A2A); и
насколько доверять атрибуции (Confidence) — attributed, когда она твёрдо привязана к идентичности отдельного агента, approximate, когда она выведена (общая служебная учётная запись или хранилище с потерями).

В её центре — diff: Разрешено против Наблюдаемого. Разрешённые рёбра берутся из объявленных грантов; наблюдаемые рёбра берутся из реальной телеметрии и аудита. Сравнение их выявляет неожиданные доступы (агент читает таблицу, которую ему никогда не предоставляли), неиспользуемые гранты (право, которое ни один агент так и не задействовал) и рёбра в ожидании сверки (доступ, который система пока не может твёрдо атрибутировать).

Продукт честен в отношении точности. Покрытие разбито по уровням: clean на хранилищах с нативным аудитом (SQL, объектное хранилище, хранилища данных), lossy на некоторых хранилищах (документные/векторные) и невозможно реконструировать пассивно на других (например, Redis, SQLite, D1). Там, где нельзя определить природу чтения/записи, режим — unknown; продукт никогда не фабрикует классификацию.

Платформа, а не одна функция

Карта доступа — одна возможность среди многих. Продукт — это модульная платформа (в духе Grafana или Backstage): один движок плюс модули плюс коннекторы, спроектированный так, что любой модуль подключается без переархитектуры остального. Он поставляется с 30 модулями — инвентаризация и живые сессии, карта R/RW, оркестрация агентов (A2A, в разработке), управление MCP и навыками, идентичность и нечеловеческая идентичность, развёртывание, знания и контекст, безопасность и guardrails, управление моделями и провайдерами, стоимость/FinOps, evals и тестовая песочница, red-teaming, комплаенс и доказательства, внутренний каталог, выходные интеграции и SIEM-push, голос/realtime и здоровье/SLA — плюс платформенные возможности, не входящие в число 30 (собственный API и manage-as-code, мультиарендность, исполнительные дашборды) — в общей сложности 158 интеграций (число, измеренное по коду скриптом scripts/check-public-counts.sh). Несколько возможностей находятся в pre-v1 или являются закрытыми по deny точками до их предоставления; документация явно указывает, какие именно.

См. каталог модулей для полного списка и обзор архитектуры для того, как движок и модули сочетаются вместе.

Как он наблюдает: сначала чтение, минимум данных

Olivares AI работает по принципу read-first: движок наблюдает через логи, OpenTelemetry и eBPF; он не находится в пути данных агента, поэтому отказ коллектора никогда не нарушает ваш продакшен-трафик. И он спроектирован по принципу минимума данных: граф доступа хранит отношения — инициатор → ресурс, чтение/запись, источник сигнала, достоверность, временная метка — никогда payload-ы, тела SQL, секреты или PII. То, что не хранится, не может утечь.

Именно поэтому он также пригоден для self-hosting и дружелюбен к air-gap: обязательной телеметрии нет, а исходящий трафик управляющей плоскости по умолчанию отсутствует. За ваш периметр выходит только то, что вы настроили для передачи наружу: обращения к API ваших моделей, подключённые вами выходы SIEM/webhook и внешний поставщик эмбеддингов, если вы его настроили. Olivares AI в этот список не входит: поставщик никогда не находится на пути данных. К нему обращаются только тогда, когда вы сами что-то у него запрашиваете — olivares upgrade или загрузка коммерческих надстроек и их обновлений по подписке, — но никогда как побочный эффект работы. И olivares upgrade --endpoint направляет даже это на ваше собственное зеркало. Это сильный аргумент для резидентности данных, GDPR и air-gapped сред.

Куда двигаться дальше

Попробуйте: туториал «от нуля до графа» запускает единый бинарник и достигает заполненного графа «Разрешено против Наблюдаемого».
Поймите: обзор архитектуры и модель безопасности и угроз.
Эксплуатируйте: self-hosting и установка в air-gapped среде.