После подключения источника и когда карта доступа показывает, что каждый агент может читать и записывать, следующая задача — управлять этим: решить, кто и что может действовать, и сделать каждое решение записанным фактом. Эта страница описывает рабочий процесс согласования — уровни риска, двойной контроль, экстренный обход и журнал, к которому они все привязаны.
Управление работает по принципу запрета по умолчанию. Принципал без роли в тенанте получает отказ; неявных грантов нет. Продукт наблюдает широко, но не исполняет повсеместно — где он управляет действием, он делает это в режиме запрета по умолчанию, никогда как универсальный исполнитель.
Модель авторизации
Каждый вызов управления проходит через то же ядро авторизации, что и остальной API: сначала RBAC, привязанный к одному тенанту, с опциональным внешним слоем политики сверху.
Роли образуют лестницу — viewer (чтение), editor (запись), admin (IAM тенанта), owner
(всё в тенанте). Чтение карты доступа намеренно не самый низкий уровень:
карта того, к чему может обратиться каждый агент — это дорожная карта разведки, поэтому она предоставляется с editor и выше,
привязана к тенанту и каждое чтение записывается в журнал.
Опциональная точка принятия решений на основе политики (встроенный Cedar или OPA по HTTP) может наложить правила на основе атрибутов сверху. Она компонуется как пересечение — RBAC ∩ нативный ABAC ∩ внешний PDP — и имеет один инвариант:
Слой политики может только забрать доступ, никогда добавить. Политика может отклонить то, что RBAC бы разрешил; она никогда не может предоставить то, что RBAC отклоняет. Неправильно настроенный или недоступный PDP завершается отказом, и отключение внешнего PDP никогда не оставляет запросы без управления — нативные RBAC и ABAC продолжают управлять.
Уровни риска
Управляемое действие классифицируется по одному из четырёх уровней — low, medium, high,
critical — на основе таксономии рисков OWASP AI-agent. Уровень определяет, сколько
человеческого контроля требуется действию для продолжения.
Уровень не хранится на записи согласования. Он пересчитывается из текущего набора политик плюс встроенного значения по умолчанию при каждом решении, поэтому изменение политики вступает в силу немедленно и устаревший снимок никогда не может удерживать планку ниже живой классификации (запрет по умолчанию).
| Уровень | Контроль по умолчанию |
|---|---|
low / medium | назначается только явной политикой |
high | по умолчанию для всего, что попадает в очередь согласования — одно человеческое согласование |
critical | обязательный минимум двух человек (см. ниже) |
Встроенный набор critical покрывает действительно необратимое: развёртывание и вывод из эксплуатации,
удаление и стирание данных, изменения безопасности и аварийного выключателя, хранение
и ротация ключей, и вывод NHI из эксплуатации. Политика согласования с явным risk_tier может повысить или
понизить значение по умолчанию для действия — это аудируемое слово оператора — но она никогда не может понизить
действие critical ниже минимума двойного контроля.
Запросы на согласование и двойной контроль
Запрос на согласование открывается в режиме запрета по умолчанию и с ограничением по времени: он начинается ожидающим, несёт время истечения и ничего не авторизует, пока достаточное количество людей не решит. Соответствующая политика согласования авторитетна для порога и таймаутов, поэтому запрашивающий никогда не может снизить собственную планку.
Три инварианта обеспечиваются на стороне сервера, а не по соглашению:
- Разделение обязанностей. Запросивший не может решать свой собственный запрос. Привязано к стабильной идентичности пользователя, а не к строке учётных данных, которую один человек мог бы варьировать.
- Одно решение на человека. Уникальный индекс поддерживает гонку дублирования решающих; один человек не может засчитаться дважды для порога.
- Привязка истечения. Истекший запрос никогда не может получить обязывающее решение — эффективный статус пересчитывается при каждом решении, с очисткой или без.
Для действий critical порог ограничен снизу двумя различными человеческими согласующими (NIST
SP 800-53 AC-3(2) двойная авторизация). Минимум обеспечивается и при создании запроса
(сохранённый порог никогда не может начинаться ниже двух), и повторно в точке решения
(запрос, созданный до того, как действие стало критическим, всё равно не может пройти с одним
человеком). Один согласующий никогда не может удовлетворить критическое действие.
Решение critical дополнительно требует аппаратно-подтверждённой сессии: решающий
человек должен иметь свежее повышение WebAuthn или PIV (AAL3). Системный токен не несёт
человеческой гарантии и отклоняется — системный токен не может согласовывать.
Каждое решение добавляет неизменяемую строку в след решений запроса и событие журнала, записывающее решение, результирующий статус и уровень риска, при котором оно было принято.
Экстренный обход
Двойной контроль имеет предохранительный клапан для инцидента в 03:00, когда второй согласующий недоступен. Admin — всегда реальный человек, никогда системный токен — активирует ограниченный по времени экстренный грант, позволяющий управляемому действию продолжиться без кворума. Путь никогда не бывает тихим:
- Активация требует обоснования, самоаудируется в журнал в той же транзакции и генерирует критическую находку в шину уведомлений.
- Каждое использование добавляет неизменяемую строку и событие журнала, указывающее грант, действие и субъект. Действие, выполненное в режиме экстренного обхода, навсегда отличимо от правильно согласованного.
- Грант ограничен по времени — по умолчанию один час, жёсткий максимум 24. «Экстренная ситуация», которая требует больше — это режим работы, а не экстренная ситуация, и должна проходить через обычный двойной контроль.
- Принудительная пост-ревизия. Новый грант не может быть активирован, пока любой предыдущий не проверен, и проверку должен провести другой человек, не активатор. Нельзя накапливать экстренные ситуации, чтобы избежать контроля.
Экстренный обход ослабляет отсутствующий кворум; он никогда не отменяет явный человеческий отказ. Запрос, который кто-то намеренно отклонил, остаётся отклонённым.
Гарантия записанных решений
Какова бы ни была глубина рабочего процесса над ним, управленческое решение — записанный факт. Мутирующие действия добавляются в аудиторский журнал с реальным действующим лицом в той же транзакции, что и изменение, а чувствительные чтения (карта доступа, сам журнал) самоаудируются в зафиксированной записи. Вы не можете сделать неуправляемое изменение, которое журнал молча забудет.
Журнал является только для добавления, хеш-цепочкой и подписан Ed25519. Каждая запись несёт seq,
prev_hash, hash и sig, поэтому перезапись истории криптографически обнаруживаема, и
журнал никогда не содержит персональные данные. Для внешней, неизменяемой копии, которую запрашивает аудитор, журнал
предоставляется как аутентифицированный pull-экспорт по /v1/audit/export, с форматами
cef, leef, syslog, otlp и ocsf. Каждая экспортированная запись несёт поля целостности цепочки,
поэтому SIEM или WORM-хранилище может перепроверить цепочку офлайн — отделённая подпись
защищает от компрометации только базы данных, а внехостовая копия — от полностью скомпрометированного
хоста.
Честный охват
Ядро авторизации, движок согласования и журнал работают сегодня. Что ещё развивается — это более богатая поверхность рассмотрения для оператора — полная консоль очереди согласования; эндпоинты и серверные инварианты поставлены, полированный UI — это путь вперёд. Как и с остальной платформой, это open-core до версии 1.0: читайте Честность и ограничения для того, что работает vs что в проекте. Olivares AI спроектирован для соответствия SOC 2, ISO 27001 и EU AI Act, а не сертифицирован по ним.
Связанные материалы
- Управление — модель авторизации и позиция самоаудита полностью.
- Разрешённый и наблюдаемый — дрейф, на который действуют эти решения.
- Подключение источника — подключение сигналов, из которых строится дрейф.
- Аварийный выключатель — градуированная экстренная остановка для окружения.