Платформа, яка керує ШІ-агентами на вашій інфраструктурі, є продуктом безпеки. Якщо вона перебільшує те, що покриває, вона дає хибне відчуття безпеки — що гірше за відсутність інструменту взагалі. Тому ця сторінка є явним контрактом: що працює сьогодні, що на етапі проектування, і що поза межами навмисно. Решта документації дотримується цього. Де продукт ще щось не покриває, сторінка говорить про це, а не натякає, що покриває.
Olivares AI знаходиться в стадії до 1.0 та має відкрите ядро. Ставтеся до глибини на рівні модулів як до незавершеної роботи, якщо сторінка не стверджує інше.
Що працює сьогодні
- Один бінарний файл завантажується з заповненим графом доступу. Бінарний файл площини управління компілюється в один статичний артефакт із вбудованим веб-інтерфейсом. Завантаження його проти синтетичного демонстраційного середовища та проходження виявлення → граф R/RW → відхилення дозволеного від фактичного → інвентаризація перевіряється наскрізь тестовим набором. Швидкий старт відтворює цей шлях.
- Перший запуск без облікових даних. Свіжа установка не має облікових даних за замовчуванням. При першому завантаженні, коли користувачів ще немає, рушій створює одноразовий, одноразового використання токен налаштування та виводить його в stdout (ніколи в журнали); ви обмінюєте його на створення першого адміністратора.
- REST API та аудиторський журнал є реальними. Публічна поверхня описана власним контрактом продукту OpenAPI 3.1. Аудиторський журнал тільки для додавання та з ланцюжковим хешуванням, з підписаними контрольними точками, і може бути експортований у формати SIEM для офлайн перевірки.
- Підписання релізів побудовано й перевіряється офлайн — докази публікуються з першим публічним релізом. Кожен тегований реліз несе підписи cosign, провенанс SLSA та SBOM (SPDX і CycloneDX). Усе це можна перевірити без мережевого доступу. Підписання на основі ключів (не OIDC) підтримується для ізольованих конвеєрів збірки, і пакет для ізольованої роботи поставляється для установок без вихідного з’єднання.
Що на етапі проектування або до 1.0
Каталог — це 29 модулів; усі підключені у стандартній установці сьогодні. Див. довідник модулів для статусу кожного модуля.
Точність карти R/RW є багаторівневою, за задумом
Точність залежить від того, що джерело може довести, і карта доступу показує це чесно, а не імітуючи впевненість. Див. точність для повної моделі.
- Покриття є
cleanна сховищах із нативним аудитом (SQL, об’єктне сховище, сховища даних/озера даних),lossyна документних та векторних сховищах, де ребра існують, але грубі, таopaqueтам, де взагалі немає пасивного сигналу читання/запису (наприклад Redis, SQLite, D1). Де читання проти запису не може бути визначене, ребро позначається якunknown. - Атрибуція є
firm, коли джерело несе ідентифікацію по кожному агенту, і зводиться доapproximate, коли спільний сервісний обліковий запис приховує це. Усе невирішене залишаєтьсяapproximate— ніколи мовчки не підвищується до сфабрикованого агента.
Джерела: хостові спостерігачі підключені; деякі конектори завантажуються на вимогу
Корінь композиції реєструє хостові спостерігачі R/RW у стандартному шляху serve, конфігуровані через конфігурацію джерел. Кілька конекторів джерел побудовані, але ще не підключені до стандартного serve — наприклад, джерела документів знань, які завантажуються на вимогу запитами інгесту, а не працюють як постійні спостерігачі. Посібник підключення джерела та довідник модулів позначають, що є що.
За замовчуванням один бінарний файл; розподілена шина є опціональною
Стандартна установка працює як один бінарний файл із внутрішньопроцесною шиною подій — блокуючий зворотний тиск, без локальних втрат. Розподілений міст NATS побудований та підключений для масштабованої високої доступності, увімкнений через конфігурацію шини; помилкова конфігурація шини зупиняє завантаження, а не мовчки розділяє. Міжвузлова доставка через міст чесно задокументована як at-most-once (внутрішньопроцесне захоплення є межею стійкості); втрати враховуються у метриках, ніколи мовчки.
Кероване виконання має три чесних стани
Платформа спостерігає та керує широко; вона не здійснює масове виконання. Прочитайте дозволений проти фактичного, щоб зрозуміти, чому ця межа важлива. Виконання належить до трьох станів:
- Live у стандартному бінарному файлі, без налаштування: застосування бюджету FinOps (бюджет, що застосовується, при ліміті відхиляє витрату — внутрішньопроцесний, завжди підключений), відправка сповіщень після налаштування призначення, детективні висновки безпеки та внутрішньопроцесний синтетичний runner пісочниці.
- On-demand — бекенд побудований та підключений, але закритий за замовчуванням або деградований до моменту, поки оператор не налаштує його: deploy
apply/retire(503до налаштування виконавця), orchestration fire та voice dispatch (закриті за замовчуванням до налаштування диспетчера), ізольоване середовище виконання sandbox/red-team (синтетичне до налаштування), та виконання моделі (503до налаштування облікових даних виводу). - Seam — оголошений, закритий за замовчуванням інтерфейс без бекенду.
Ізольованість стосується площини управління, а не виводу Claude
Це найважливіший виняток. Площина управління — управління та спостереження — працює повністю самостійно і може бути ізольованою: один вузол, підписаний офлайн реліз, пакет для ізоляції.
Сам Claude не є самостійно розгортуваним. Anthropic не публікує ваги, тому будь-який вивід Claude досягає API Anthropic, напряму або через Bedrock / Vertex / Foundry. У Olivares AI ці точки виводу закриті при помилці: без облікових даних виводу суддя LLM пропускається, а ембедінги повертаються до локального ембедера без вихідного з’єднання. “Ізольований” тут означає, що ваша площина управління та спостереження та їхні дані залишаються всередині вашого периметру — це не означає, що Claude працює офлайн. Тільки моделі, які ви дійсно розгортаєте самостійно (наприклад через vLLM або Ollama під модулем управління моделями), можуть працювати ізольовано; брокерські фронтирні моделі не можуть. Див. підключення Claude Code та безпека.
Не всі маршрути модулів є в публічному контракті API
Деякі точки доступу модулів (наприклад граф та відхилення карти доступу) є доступними, але навмисно не є частиною опублікованого документа OpenAPI; їхні контракти на рівні полів знаходяться у типізованих інтерфейсах продукту. Довідники CLI та конфігурації покривають операційну поверхню; контракт OpenAPI — це основна поверхня REST, а не весь продукт.
Не сертифікований
Olivares AI розроблений відповідно до SOC 2, ISO 27001 та EU AI Act — він не сертифікований за жодним із них. Див. відповідність, що означає “розроблений відповідно до” та які докази платформа створює.
Що продукт навмисно не робить
- Ніяких наступальних функцій. Це не фреймворк командування та контролю і він не сканує чужі облікові дані. Карта доступу — це розвідка для захисників для керування власною інфраструктурою — перегляд є привілейованою, обмеженою орендарем, повністю аудитованою дією. Оборонна лінія є навмисною.
- Ніякого нативного форвардера Splunk S2S. Пересилання до Splunk — це задокументована позиція (направте Universal Forwarder на файл, до якого площина управління додає, або відправляйте через Splunk HEC), не нативний передавач Splunk-до-Splunk.
- Ніяких вихідних webhook у контракті REST. Документ OpenAPI не визначає
webhooks. Підписана вихідна доставка існує як внутрішнє призначення сповіщень, а вхідна точка SCIM Security-Event-Token є приймачем — жодне з них не є webhook OpenAPI. - Ніякого дотренування до v1. Дотренування моделей (модуль управління моделями) є пост-v1. Його відсутність — це рішення, а не прогалина.
Примітка щодо експорту аудиту
CLI експорт журналу підтримує cef, syslog та otlp. Шлях push подій до SIEM відображає ширший набір діалектів (включаючи OCSF та LEEF), коли налаштований приймач. Pull експорт є правильною формою для архівування WORM та офлайн перевірки.
Якщо ви знайдете команду, яка не поводиться як задокументовано, це помилка в документації або продукті — будь ласка, повідомте про це. Ця сторінка є якорем довіри; все інше підпорядковується їй.