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

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

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

• Единый бинарник собирается, запускается и достигает заполненного графа доступа. Бинарник olivares компилируется в один статический артефакт со встроенным веб-интерфейсом. Его запуск с демонстрационным estate (serve --seed-demo) и проход discover → R/RW-граф → дрейф permitted-vs-observed → инвентаризация проверяется тестовым набором сквозным образом. Учебник воспроизводит ровно этот путь.
• Первоначальная настройка не требует учётных данных. В свежей установке нет учётных данных по умолчанию; движок печатает одноразовый, единократно используемый setup-токен при первом запуске.
• REST API и журнал аудита реальны. Справочник по API отрисовывается из собственного контракта продукта OpenAPI 3.1. Журнал аудита работает только на добавление и связан хеш-цепочкой с контрольными точками, подписанными Ed25519, и может экспортироваться в нескольких форматах SIEM.
• Релизы подписаны и проверяемы офлайн. Подпись, происхождение SLSA, SBOM и OpenVEX можно проверить без доступа к сети, а продукт поставляется с пакетом для air-gap. Релиза с тегом ещё не существует, поэтому здесь описано то, что релиз будет содержать, а не артефакт, который можно скачать и проверить сегодня — та же оговорка, что и в SECURITY.md.

Open core — что открыто, а что enterprise

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

• SSO открыт для одного IdP. Вход через один IdP — OIDC (Authorization Code + PKCE) и SAML 2.0 (подписанные ответы, защита от повторов) — работает в бинарнике по умолчанию без -tags enterprise. Использование более чем одного активного IdP (по арендатору / по домену), принудительное применение SSO (требовать SSO / блокировать вход по паролю) и управляемый SCIM — это зарезервированная enterprise-линейка; активация второго активного 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/распределённый режим — работает в открытом бинарнике без проверки лицензии. Аддитивные дополнения enterprise/ (мультифедерация IdP, content firewall/DLP, усиление хуков, скомпилированный каталог threat-intel, контроль egress серверных инструментов, коннектор CyberArk Conjur и замыкание цикла инцидентов) — это новый код, которого никогда не было в открытом продукте, а не функции, изъятые из него. Проверка лицензии в открытом бинарнике носит характер только аттестации — она никогда ничего не включает, не отключает и не блокирует (см. 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/oracle/mongo/redshift/gcs/ azure-blob/iceberg/openlineage/delta-sharing), все настраиваемые через OLIVARES_SOURCES_CONFIG (в быстром старте подключается реальный источник pgaudit на штатном бинарнике, и дымовой тест это утверждает). Источники документов знаний (gdrive/confluence/notion/sharepoint/s3content) намеренно не являются источниками времени выполнения — они загружаются по требованию запросами на загрузку знаний. Справочник по коннекторам помечает каждый вид.
• По умолчанию используется единый бинарник; распределённая шина событий существует и честна в отношении своей семантики. По умолчанию запускается один бинарник с внутрипроцессной шиной событий. Путь данных от удалённого коллектора к ядру построен и поставляется: краевые коллекторы запускают коннекторы источников локально и проталкивают наблюдения в центральное ядро поверх взаимного TLS с проверкой клиентского сертификата, без входящего слушателя (режим collector). Распределённая шина событий поставлена в рамках работы по масштабированию: гибрид, который сохраняет внутрипроцессную раздачу для локальной доставки (блокирующий backpressure, без локальных потерь) и мостит события между узлами поверх NATS, включается через OLIVARES_BUS_CONFIG (неправильно настроенная конфигурация шины проваливает запуск, а не молчаливо разбивает шину на разделы). Межузловая доставка честно документирована как at-most-once — разрывы моста и потери учитываются в специальных метриках, никогда не молчаливо (мониторинг).
• Управляемое воздействие имеет три честных состояния: live, on-demand и seam. Сегодня продукт широко наблюдает и управляет. Небольшой набор воздействий работает в бинарнике по умолчанию без подготовки: применение FinOps-бюджета (применяющий бюджет на своём пределе отказывает в трате), транспорт диспетчеризации уведомлений (он маршрутизирует, как только настроено назначение), детективные находки/guardrails безопасности и внутрипроцессный синтетический запускатель песочницы (изолированный по конструкции). Ещё несколько подключены по требованию — бэкенд построен и подключён, но остаётся deny-closed или деградированным, пока оператор не подготовит его через env-конфигурацию: модуль VII (deploy) apply/retire (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 и дрейф) не входят в стабильный основной контракт (53 базовых пути); они публикуются как отдельный бета-документ — справочник по маршрутам модулей (обслуживается по адресу /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 (ниже).

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