Честность и ограничения

Control plane для ИИ — это продукт безопасности. Если он преувеличивает то, что покрывает, он даёт ложное ощущение защищённости — что хуже, чем полное отсутствие инструмента. Поэтому эта страница — явный контракт о том, что работает сегодня, что запланировано и что намеренно вынесено за рамки. Остальная документация придерживается его: команды в учебниках и практических руководствах предназначены для запуска как написано, а там, где продукт пока чего-то не покрывает, страница так и говорит, а не намекает на обратное.

Доставка событий NATS: Мост Core NATS и NATS JetStream требуют Business Identity & Scale. Community доставляет события внутри процесса.

Что работает сегодня

Единый бинарник собирается, запускается и достигает заполненного графа доступа. Бинарник olivares компилируется в один статический артефакт со встроенным веб-интерфейсом. Его запуск с демонстрационным estate (serve --seed-demo) и проход discover → R/RW-граф → дрейф permitted-vs-observed → инвентаризация проверяется тестовым набором сквозным образом. Учебник воспроизводит ровно этот путь.
Первоначальная настройка не требует учётных данных. В свежей установке нет учётных данных по умолчанию; движок печатает одноразовый, единократно используемый setup-токен при первом запуске.
Официальные CLI Codex, Grok и OpenCode могут выполнять сеансы провайдера. Движок регистрирует эти драйверы при запуске. При запуске сеанса он использует новейшую проверенную управляемую установку, затем CLI из своего PATH. OLIVARES_SESSION_RUNTIME_CODEX_BIN, OLIVARES_SESSION_RUNTIME_GROK_BIN и OLIVARES_SESSION_RUNTIME_OPENCODE_BIN переопределяют этот выбор. Если исполняемый файл не найден, запуск отклоняется. Запуски идут через профиль провайдера. CHANGELOG.md [26.9.0] не утверждает совместимость с аутентифицированной официальной учётной записью Grok.
REST API и журнал аудита реальны. Справочник по API отрисовывается из собственного контракта продукта OpenAPI 3.1. Журнал аудита работает только на добавление и связан хеш-цепочкой с контрольными точками, подписанными Ed25519, и может экспортироваться в нескольких форматах SIEM.
Релизы подписаны и проверяемы. Подпись, происхождение SLSA, SBOM и OpenVEX можно проверить. Проверка пока не полностью обходится без сети: бесключевой проверке нужен материал доверенного корня Sigstore, а у шага SLSA нет офлайн-режима. Продукт поставляется с пакетом для air-gap. Следующий выпуск — 0.4, ещё не опубликован. До публикации собирайте из исходного кода.

Open core — что открыто, а что коммерческое

Продукт построен по модели open core: бинарник по умолчанию (AGPL) — это вся платформа управления, а небольшая, аддитивная коммерческая линейка (Business и Enterprise; enterprise/, собираемая только с -tags enterprise и никогда не попадающая в публичный бинарник) содержит зарезервированные функции. Для повседневной работы важны две границы, и открытая сборка отвечает за них честно, а не имитирует их:

SSO открыт для одного IdP. Вход через один IdP — OIDC (Authorization Code + PKCE) и SAML 2.0 (подписанные ответы, защита от повторов) — работает в бинарнике по умолчанию без -tags enterprise. Использование более чем одного активного IdP (по арендатору / по домену), принудительное применение SSO (требовать SSO / блокировать вход по паролю) и входящий SCIM-сервер — это Business (Identity & Scale); активация второго активного IdP возвращает multi_idp_requires_enterprise — явное продуктовое ограничение, а не фальшивый 501.
Лимита пользователей нет — учётные записи безлимитны в любой редакции. Community, Business и Enterprise self-hosted допускают неограниченное число учётных записей при любом состоянии лицензии: действующей, истёкшей или отсутствующей. Лимит в три активные учётные записи, действовавший до 2026-07-27, полностью снят (шов мест остаётся в коде как no-op совместимости и ничего не отклоняет), а истечение лицензии никогда не ограничивает, не отключает и не удаляет учётную запись. Коммерческая модель — это срочное право на модули, а не оплата за место.
Остальная часть платформы открыта. Полный цикл управления — инвентаризация, R/RW-карта доступа, политики RBAC/ABAC/Cedar, запечатанный журнал аудита, FinOps, соответствие требованиям, выгрузка в SIEM, MCP — работает в открытом бинарнике без проверки лицензии. Маршрутизация к лидеру в активно-пассивной HA и edge-коллектор относятся к Business. Аддитивные модули enterprise/ — это новый код, которого никогда не было в открытом продукте, а не функции, изъятые из него; какая возможность входит в какую редакцию, написано один раз — в docs/editions.md в репозитории. Проверка лицензии в открытом бинарнике носит характер только аттестации — она никогда ничего не включает, не отключает и не блокирует, кроме того, что для установки комплекта обновления, не указывающего редакцию community, нужна действующая лицензия (см. Open core и лицензирование).

Что находится на стадии проектирования или до 1.0

Olivares AI находится до версии 1.0. Проектные документы продукта явно указывают, что значительная часть платформы местами находится на стадии проектирования даже там, где движок уже работает. Считайте глубину на уровне модулей незавершённой работой, если страница не утверждает иного.

Покрытие R/RW-карты многоуровневое — по замыслу. Точность зависит от того, что может доказать источник. Оно чистое на хранилищах с нативным аудитом (SQL через pgAudit, объектное хранилище через CloudTrail, хранилища/озёра данных), с потерями на некоторых хранилищах (документ/вектор) и невосстановимое пассивно на других (например, Redis, SQLite, D1) — где чтение и запись различить невозможно, ребро помечается как unknown. Атрибуция твёрдая, когда источник несёт идентичность по каждому агенту, и схлопывается до approximate, когда общая служебная учётная запись её скрывает. Продукт показывает это честно; он не выдумывает уверенность.
Канонические источники R/RW подключены в штатном serve. Корень композиции регистрирует наблюдателей уровня хоста — pgaudit, s3cloudtrail, ebpf, runtime и источник интроспекции mcp — наряду с наблюдателями хранилищ/озёр данных (snowflake/databricks/bigquery/mssql/mongo/redshift/gcs/ azure-blob/iceberg/openlineage/delta-sharing), все настраиваемые через OLIVARES_SOURCES_CONFIG (в быстром старте подключается реальный источник pgaudit на штатном бинарнике, и дымовой тест это утверждает). Источники документов знаний (gdrive/confluence/notion/s3content) намеренно не являются источниками времени выполнения — они загружаются по требованию запросами на загрузку знаний. Справочник по коннекторам помечает каждый вид.
По умолчанию используется единый бинарник; распределённая шина событий существует и честна в отношении своей семантики. По умолчанию запускается один бинарник с внутрипроцессной шиной событий. Путь данных от удалённого коллектора к ядру построен и поставляется: краевые коллекторы запускают коннекторы источников локально и проталкивают наблюдения в центральное ядро поверх взаимного TLS с проверкой клиентского сертификата, без входящего слушателя (режим collector, функция Business). Распределённая шина событий поставлена в рамках работы по масштабированию: гибрид, который сохраняет внутрипроцессную раздачу для локальной доставки (блокирующий backpressure, без локальных потерь) и мостит события между узлами поверх NATS, включается через OLIVARES_BUS_CONFIG (неправильно настроенная конфигурация шины проваливает запуск, а не молчаливо разбивает шину на разделы). Межузловая доставка честно документирована как at-most-once — разрывы моста и потери учитываются в специальных метриках, никогда не молчаливо (мониторинг).
Управляемое воздействие имеет три честных состояния: live, on-demand и seam. Сегодня продукт широко наблюдает и управляет. Небольшой набор воздействий работает в бинарнике по умолчанию без подготовки: применение FinOps-бюджета (применяющий бюджет на своём пределе отказывает в трате), транспорт диспетчеризации уведомлений (он маршрутизирует, как только настроено назначение), детективные находки/guardrails безопасности и внутрипроцессный синтетический запускатель песочницы (изолированный по конструкции). Ещё несколько подключены по требованию — бэкенд построен и подключён, но остаётся deny-closed или деградированным, пока оператор не подготовит его через env-конфигурацию: модуль VII (deploy) apply/retire (только Business: в Community 501, иначе 503, пока не подготовлен executor), оркестрация модуля IV fire и диспетчеризация голоса модуля XVI (оба deny-closed, пока не настроен диспетчер), изолированная на уровне ОС среда песочницы/red-team (синтетическая / DEGRADED до подготовки), модельный семантический поиск (по умолчанию лексический и только публичный) и выполнение модели в модуле X (503, пока не подготовлены учётные данные инференса). Тем, что остаётся объявленным, deny-closed seam вообще без бэкенда, является спящий зонд телеметрии голоса (распределённая шина событий покинула этот список, когда был поставлен мост NATS — см. выше). Каталог модулей помечает для каждого модуля статус Govern/Observe и Actuate; ничто не заявляет, что действует там, где не действует. (Это исправляет более раннюю трактовку, которая перечисляла голос, среду песочницы/red-team и семантический поиск как «live» — они работают по требованию: проверено на штатном запуске serve --seed-demo, 2026-06-08.)
Air-gap применяется к control plane, но не к инференсу Claude. Control plane работает полностью self-hosted и может быть air-gapped (SQLite на одном узле, подписанный офлайн-релиз, пакет для air-gap). Сам Claude не подлежит self-hosting — Anthropic не публикует веса, — поэтому любой инференс Claude обращается к API Anthropic, напрямую или через Bedrock/Vertex/Foundry. «Air-gapped» здесь означает, что плоскость управления и наблюдения и её данные остаются внутри вашего периметра; это не означает, что Claude работает офлайн. Модели, которые вы действительно self-host (например, через vLLM/Ollama в рамках модуля XXIII), могут работать air-gapped; брокерируемые передовые модели — не могут.
Маршруты модулей — это отдельный, бета-контракт. Эндпоинты модулей (например, граф access map и дрейф) не входят в стабильный основной контракт (137 базовых путей); они публикуются как отдельный бета-документ — справочник по маршрутам модулей (обслуживается по адресу /openapi.beta.json). Бета означает, что формы могут меняться с предварительным уведомлением, а детализация на уровне полей по-прежнему живёт в типизированных интерфейсах продукта. Справочник по основному API документирует стабильную поверхность; это не вся поверхность продукта.

Чего продукт намеренно не делает

Никаких наступательных функций. Olivares AI не является фреймворком command-and-control и не сканирует чужие учётные данные. Access map — это мощный инструмент разведки для защитников, чтобы управлять собственным estate — его просмотр является привилегированным, ограниченным арендатором, полностью аудируемым действием. Эта оборонительная линия намеренна и держится явной (см. модель угроз).
Никакого нативного форвардера Splunk S2S. Пересылка в Splunk — это документированная посадка — направьте Universal Forwarder на файл, к которому control plane дописывает, или проталкивайте через Splunk HEC, — но не нативный эмиттер Splunk-to-Splunk. Практическое руководство по Splunk явно указывает, какой поток есть какой.
Никаких исходящих webhooks в контракте REST. Документ OpenAPI не определяет никаких webhooks. Исходящая подписанная доставка существует как внутренний коннектор назначения уведомлений, а эндпоинт SCIM Security-Event-Token является входящим приёмником — ни то ни другое не является webhook OpenAPI. См. справочник по API.
Тонкая настройка моделей (модуль XXIII) — после v1. Её отсутствие — это решение, а не пробел.

Где документация отмечает пробел выше по потоку

Несколько вещей, которые эта документация выявляет, являются пробелами в продукте, сообщёнными командам, владеющим соответствующим контрактом, а не замазанными здесь:

Зафиксированный файл OpenAPI, который отрисовывает сайт, теперь перегенерируется из — и проверяется CI байт в байт против — собственного генератора движка, поэтому он больше не отстаёт от него (более ранний пробел по эндпоинтам был согласован). Более ранняя недодокументированность списка форматов /v1/audit/export также была исправлена выше по потоку: и сводка, и сообщение о неверном запросе строятся из реестра форматов движка (audit.FormatList()), поэтому больше не могут разойтись — этот раздел сохраняет запись, потому что более ранние издания этой документации сообщали о пробеле, и потому что та же гниль до 2026-07-25 скрывала leef и ocsf также из справки и автомодули CLI.
Путь push журнала аудита поставлен в рамках работы по интероперабельности SIEM/ITSM: подписка на событие audit.recorded включает по каждому арендатору насос журнала, который пересылает запечатанные записи at-least-once в настроенный приёмник (Splunk HEC, Sentinel, Datadog, New Relic или HMAC-подписанный webhook). Экспорт через pull остаётся правильной формой для WORM-архивирования и офлайн-повторной проверки. См. push в ваш SIEM и практическое руководство по Splunk. Чего всё ещё не существует — так это нативного эмиттера протокола S2S Splunk (ниже).

Если вы обнаружите команду, которая ведёт себя не так, как задокументировано, это баг в документации или в продукте — пожалуйста, сообщите о нём.