Після підключення джерела та того, як карта доступу показує, що кожен агент може читати та записувати, наступне завдання — керувати цим: вирішити, хто і що може діяти, і зробити кожне рішення записаним фактом. Ця сторінка описує робочий процес затвердження — рівні ризику, подвійний контроль, аварійний доступ та журнал, до якого вони всі прив’язані.
Управління закрите за замовчуванням. Суб’єкт без ролі в орендарі отримує відмову; немає неявного дозволу. Продукт спостерігає широко, але не здійснює масове виконання — де він керує дією, він робить це закрито за замовчуванням, ніколи як загальний виконавець.
Модель авторизації
Кожен виклик управління проходить через те ж ядро авторизації, що й решта 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. Рівень визначає, скільки людського
контролю вимагає дія, перш ніж вона може бути виконана.
Рівень не зберігається на рядку затвердження. Він перераховується з поточного набору політик плюс вбудоване замовчування при кожному рішенні, тому зміна політики набирає чинності негайно, і застарілий знімок ніколи не може тримати планку нижче живої класифікації (закрито за замовчуванням).
| Рівень | Контроль за замовчуванням |
|---|---|
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, тому переписування історії криптографічно виявляється, і
журнал ніколи не містить PII. Для зовнішньої, незмінної копії, яку просить аудитор, журнал
надається як автентифікований pull-експорт на /v1/audit/export, з значеннями format
cef, leef, syslog, otlp та ocsf. Кожен експортований запис несе поля цілісності ланцюга,
тому SIEM або WORM сховище може перевірити ланцюг офлайн — відокремлений підпис
захищає від компрометації лише бази даних, а позасерверна копія — від повністю компрометованого
хоста.
Чесний обсяг
Ядро авторизації, рушій затвердження та журнал працюють сьогодні. Що ще розвивається — це більш повна поверхня огляду для операторів — повна консоль черги затвердження; точки доступу та серверні інваріанти поставляються, полірований інтерфейс — це шлях вперед. Як і з рештою платформи, це відкрите ядро до 1.0: прочитайте Чесність і обмеження для того, що є живим проти проектного напрямку. Olivares AI розроблений відповідно до SOC 2, ISO 27001 та EU AI Act контролів, не сертифікований проти них.
Пов’язане
- Управління — модель авторизації та позиція самоаудиту повністю.
- Дозволений проти фактичного — відхилення, на які ці рішення діють.
- Підключення джерела — підключення сигналів, з яких будується відхилення.
- Аварійний вимикач — поступова аварійна зупинка для середовища.