Проблема: невозможно управлять тем, что вы не видите
Агенты уже здесь. Помощник по написанию кода с учётными данными базы данных, внутренний RAG-сервис, тихо получивший доступ на запись к объектному хранилищу, плановое задание, которое вызывает MCP-сервер, не зарегистрированный никем. Их предоставили команды, двигавшиеся быстро, а служба безопасности унаследовала радиус поражения, ни разу не увидев карту. У аналитиков есть название для этой картины — неконтролируемый рост числа агентов, agent sprawl, — и лежащий под ней разрыв в управлении поддаётся измерению.
Среди организаций, пострадавших от утечки, связанной с AI, примерно 97% не имели надлежащих средств контроля доступа к AI (IBM Cost of a Data Breach 2025, Ponemon). Это не история о зрелости инструментов; это отсутствие поверхности управления. В то же время Gartner ожидает, что более 40% проектов agentic-AI будут отменены к концу 2027 года, и прогнозирует, что «агенты-защитники» (guardian agents) составят 10–15% рынка agentic-AI к 2030 году (Gartner, пресс-релизы) — рынок закладывает в цену тот факт, что неуправляемые агенты не выживают при столкновении с реальной проверкой безопасности.
Эта закономерность шире, чем команды безопасности. В предварительном, ещё не прошедшем рецензирование исследовании примерно 95% пилотов GenAI не показали измеримого влияния на P&L, а инструменты, купленные на стороне, были успешны примерно вдвое чаще, чем внутренние разработки (MIT «GenAI Divide», проект NANDA, через Fortune, авг. 2025 — предварительно). Какова бы ни была причина, инфраструктура, полная агентов, за которых никто не может отчитаться, — это в точности то условие, при котором и риск утечки, и риск напрасных пилотов усиливаются.
Это чётко ложится на рамку AI TRiSM — управление доверием, рисками и безопасностью для AI — где управление и инспекция времени выполнения существуют как отдельные слои. Olivares AI создан, чтобы быть тем слоем, который обнаруживает, наблюдает и управляет доступом агентов, и он честен в том, где это заканчивается.
Что Olivares AI даёт руководителю по безопасности
Типизированная карта доступа на чтение/запись как поверхность управления
Карта доступа моделирует каждого агента как узел и каждый ресурс, до которого он может дотянуться — базы данных, объектные хранилища, MCP-серверы, API, очереди — как узел, причём каждое ребро типизировано как R (чтение) или RW (чтение-запись). Именно эта типизация R против RW и есть суть: и дрейф от least-privilege, и радиус поражения при инциденте являются функциями доступа на запись, а не просто связности, и плоский список «имеет доступ» скрывает ровно это. Это разведка для защитников — та самая карта, которую захотел бы атакующий, построенная для людей, защищающих инфраструктуру.
Чтение полного графа намеренно является привилегированным, ограниченным рамками тенанта и полностью аудируемым действием, потому что полная карта того, к чему может прикоснуться каждый агент, сама по себе является разведывательной картой. Карта хранит отношение — инициатор, ресурс, R/RW, источник (телеметрии), уверенность, временные метки — и никогда не хранит полезные нагрузки, тела SQL, секреты или PII, которые прошли по ребру. То, что не хранится, не может утечь.
Разрешённое против наблюдаемого: сравнение, которое становится выявленным фактом
Каждое ребро несёт два независимых факта: является ли доступ разрешённым (грант или политика его допускает) и был ли он наблюдаем (телеметрия и нативный аудит показывают, что это происходит). Сравнение между этими двумя слоями и есть управляющий сигнал:
- Неожиданный доступ — наблюдаемый, но не разрешённый. Агент прикоснулся к чему-то, что не покрыто ни одним грантом. Это и есть значимый для безопасности заголовок.
- Неиспользуемые гранты — разрешённые, но никогда не наблюдаемые. Ваш конкретный список для наведения порядка по least-privilege, а не расплывчатое напоминание «проверьте свой IAM».
Сравнение намеренно консервативно. Там, где платформа пока не может твёрдо связать
действующие учётные данные с тем агентом, для которого был написан грант, ребро помечается
reconciliation_pending — честная неопределённость, а не сфабрикованное нарушение. См.
разрешённое против наблюдаемого для полного контракта
сверки.
Достоверность, которая отказывается блефовать
Инструмент безопасности, который преувеличивает то, что знает, хуже, чем его отсутствие.
Каждое ребро несёт две честные оси. Покрытие классификации R/RW распределено по уровням
clean | lossy | opaque — clean там, где нативный аудит делает её однозначной (Postgres
через pgAudit, объектное хранилище через CloudTrail, хранилища данных плюс резервный механизм
на уровне ядра на eBPF), вплоть до opaque-хранилищ (Redis, SQLite, D1), где режим помечается
как unknown, а не угадывается. Атрибуция имеет статус firm там, где сигнал
идентичности отдельного агента сводит доступ к одному агенту, и approximate там, где общая
сервисная учётная запись скрывает, какой агент действовал. Ребро clean/firm и едва
замеченное ребро никогда не отображаются как равно достоверные — прочтите
модель достоверности.
Управление по принципу deny-closed, двойной контроль и kill-switch
Управление построено по принципу read-first и deny-closed. Ядро авторизации работает по принципу deny-by-default и в рамках тенанта, закрывая классы confused-deputy и IDOR по построению. Любая политика на основе атрибутов, которую вы накладываете сверху, может только дополнительно ограничивать — композиция представляет собой пересечение, поэтому политика никогда не может расширить грант.
Там, где продукт ставит действие за шлюз, цикл таков: поверхность что-то предъявляет (дрейф,
выявленный факт) → авторизованный оператор принимает решение → решение фиксируется. Движок
согласования обеспечивает разделение обязанностей (запрашивающий не может сам принять решение
по собственному запросу) и защиту от дублирующего решающего, привязанную к устойчивой
человеческой идентичности — системный токен не имеет идентичности и не может принимать
решения. Действие уровня critical несёт обязательный порог двух человек, взятый из NIST
SP 800-53 AC-3(2), который применяется как при создании, так и заново выводится при принятии
решения, поэтому даже политика оператора, понижающая уровень, не может сделать критическое
действие односторонним. Существует аудируемый клапан break-glass для инцидента в 03:00 —
громкий по построению, с аппаратным повышением полномочий, ограниченный по времени и
принудительно отправляемый на пост-проверку.
Kill-switch — это шлюз запрета масштаба всей инфраструктуры. Его включение намеренно дёшево (уровень администратора, причина, без кворума), потому что остановка, которая ждёт консенсуса, — это не остановка; каждый управляемый шлюз исполнения сверяется со строкой остановки в реальном времени и отказывает в закрытое состояние при ошибке чтения. Повторное включение никогда не бывает односторонним — оно поставлено за свежее согласование с двойным контролем и не имеет пути break-glass, потому что «инфраструктура остаётся остановленной» — это безопасное состояние.
Защищённые от подделки свидетельства
Каждое изменяющее действие добавляется в журнал аудита, допускающий только добавление записей, с цепочкой хешей в той же транзакции, что и само изменение, с указанием реального актора; чувствительные чтения самоаудируются в зафиксированной записи. Переписывание истории поддаётся обнаружению, и журнал никогда не содержит PII. Модуль соответствия сопоставляет эти свидетельства времени выполнения с фреймворками контролей, чтобы оценка питалась наблюдаемой реальностью, а не анкетой.
Что это такое — и чем это не является
- Self-hosted и суверенно. Плоскость управления работает на вашей собственной инфраструктуре и может быть air-gapped. Olivares AI — это открытая, локально развёртываемая платформа (AGPL-3.0). См. модель безопасности и архитектуру.
- Детективно по умолчанию; deny-closed там, где действует. Оно широко наблюдает и управляет; оно не широко исполняет. Там, где оно может предпринять действие, эта поверхность работает в реальном времени, по запросу или является заявленным швом — и каталог модулей отмечает, что именно. Отсутствие принуждения обычно сделано по замыслу.
- До версии 1.0, с опубликованным каталогом из 23 модулей (примерно 20 подключены сегодня). Не всё работает; мы говорим, что именно, а не подразумеваем полное покрытие.
- Air-gap применяется к плоскости управления Olivares, а не к вашим моделям. Размещённая модель, такая как Claude, никогда не бывает air-gapped; только self-hosted-модели (vLLM, Ollama) работают офлайн. В любом случае Olivares управляет доступом.
- Не сертифицировано. Olivares AI спроектирован с ориентацией на SOC 2, ISO/IEC 42001 и EU AI Act; он не имеет сертификации, и мы не заявляем обратного.
У высших учебных заведений и исследовательских инфраструктур есть параллельная версия этой проблемы — широкое использование AI преподавателями и сотрудниками, тогда как формальное управление AI и покрытие политиками допустимого использования отстают (исследование EDUCAUSE, 2025). Если это ваш контекст, см. высшее образование; платформенным командам, обслуживающим инфраструктуру, стоит начать с платформенной инженерии.
Куда двигаться дальше
- Карта доступа — типизированный граф R/RW и наложение «разрешённое против наблюдаемого» на реальном захвате.
- Kill-switch — шлюз запрета масштаба всей инфраструктуры в продуктовых терминах.
- Соответствие — защищённые от подделки свидетельства, сопоставленные с фреймворками контролей.
- Концепции управления — read-first, deny-closed, двойной контроль.
- Сравнение — как Olivares соседствует со шлюзами, наблюдаемостью и башнями контроля.
- Начать работу — увидеть карту на демонстрационной инфраструктуре.