Управління в Olivares AI побудоване на двох принципах, які можна утримати в голові одночасно: спостерігай перед тим, як застосовувати, і коли застосовуєш, за замовчуванням — відмова. Продукт створює карту та аудитує те, до чого кожен агент має доступ, задовго до блокування будь-якої дії, а шлюзи, які він використовує, закриті за замовчуванням.
Спочатку читання: спостереження перед застосуванням
Стандартна позиція платформи — детективна, а не превентивна. Вона будує карту доступу читання/запису шляхом поглинання журналів, OpenTelemetry та нативного аудиту поза основним потоком — вона ніколи не знаходиться на шляху даних агента, тому колектор, що вийшов з ладу, не може зупинити продакшн. З цієї карти вона порівнює дозволене з фактичним та показує відхилення для оцінки людиною.
Це важливо для того, як ви читаєте решту цієї сторінки. Продукт спостерігає та керує широко; він не здійснює масове виконання. Де він може виконати дію на вашій інфраструктурі, ця можливість належить до одного з трьох типів, і каталог модулів позначає який:
- live — підключено і працює сьогодні (вузький набір);
- on-demand — бекенд побудований і підключений до точки ін’єкції, але залишається закритим за замовчуванням або деградованим до моменту, поки ви не налаштуєте його (виконавець, диспетчер, облікові дані виводу);
- seam — оголошений, закритий за замовчуванням інтерфейс без бекенду в стандартному бінарному файлі.
Тому відсутність застосування правил зазвичай є задумом, а не упущенням. Спочатку читання означає, що чесним замовчуванням є спостерігати та записувати, а блокувати лише ті поверхні, які ви явно увімкнули.
Модель авторизації, в рамках якої ви керуєте
Кожне кероване рішення проходить через те ж ядро авторизації, яке захищає решту API. Три властивості варто засвоїти перед тим, як щось змінювати.
RBAC закритий за замовчуванням. Суб’єкт без членства в орендарі отримує відмову — немає
неявного дозволу. Дозволи обмежені орендарем, а обробник діє лише на одному
орендарі, до якого прив’язаний запит, що закриває класи confused-deputy та IDOR за
конструкцією. Ролі формують драбину: viewer читає, editor записує, admin керує
IAM орендаря, owner має все. Читання графа доступу навмисно є привілеєм від
editor і вище — повна карта того, до чого кожен агент може дістатися, є розвідувальним маршрутом — і кожне таке
читання записується в аудиторський журнал.
Політика може лише обмежувати. Поверх RBAC можна підключити точку прийняття рішень на основі атрибутів. Композиція є перетином — RBAC ∩ нативний ABAC ∩ зовнішній PDP — тому політика може лише додатково обмежити те, що RBAC вже дозволив; вона ніколи не може розширити дозвіл. Це забезпечується примусово, а не є конвенцією. Ви обираєте максимум один зовнішній рушій:
# Вбудований Cedar (чистий Go, без сайдкара) або OPA через HTTP. За замовчуванням: немає.
OLIVARES_PDP_ENGINE=cedar # або: opa | noneЗ Cedar ви пишете правила forbid; порожній набір правил залишає рішення RBAC чинним.
З OPA ваш Rego має бути дозвільним за замовчуванням, де відсутній результат або будь-яка помилка транспорту
закривається. Недійсна конфігурація PDP вимикає лише зовнішній PDP і журналює
факт — нативний ABAC та RBAC продовжують керувати, і помилковий рушій ніколи не залишає
запит без управління. Кожне обмеження, яке PDP застосовує, аудитується.
Рівні ризику та мінімум подвійного контролю
Дії, які потрапляють до черги схвалення, класифікуються за чотирма рівнями ризику — low,
medium, high, critical — за таксономією OWASP AI-agent. (Це окрема
вісь від рівнів відповідності EU AI Act; не плутайте їх.) Рівень перераховується
з живої політики при кожному рішенні з безпеки, ніколи не читається зі збереженого знімка, тому
зміна політики набирає чинності негайно, і застарілий рядок ніколи не може тримати планку нижче
поточної класифікації.
Дія рівня critical має обов’язковий мінімум двох осіб: щонайменше два різних людських
затверджувачі, згідно з NIST SP 800-53 AC-3(2) подвійна авторизація. Мінімум забезпечується двічі
— при створенні (збережений поріг ніколи не може починатися нижче нього) та перераховується при прийнятті рішення (знижений або
застарілий рядок все одно не може пройти з одним затверджувачем) — тому навіть операторська політика,
яка явно знижує рівень, не може зробити критичну дію одноосібною. Вбудований
набір критичних дій — це незворотні, що формують інфраструктуру: розгортання та виведення з експлуатації,
видалення даних, зміни безпекового застосування, зберігання та ротація ключів, та повторне увімкнення
інфраструктури після аварійного вимикача.
Нижчі рівні не змінюють механіку рушія — схвалення, яке вже існує, вимагає принаймні одну людину — вони є словником, на який спираються інші контролі (наприклад, підвищення аутентифікації при критичній дії).
Шлюз затвердження за участю людини (HITL)
Де продукт блокує дію, цикл такий: поверхня представляє (відхилення від карти доступу, висновок модуля безпеки) → авторизований оператор вирішує → рішення записується в аудиторський журнал. Рушій затвердження, який це забезпечує, працює сьогодні: запит відкривається закритим за замовчуванням, прив’язаний до хешу плану та обмежений у часі. Інваріанти забезпечуються серверною стороною на основі стабільної ідентичності користувача (системний токен не має ідентичності і не може приймати рішення):
- Розділення обов’язків — запитувач ніколи не може вирішити свій власний запит.
- Захист від дублювання рішень — одна людина рахується один раз до порогу.
- Закінчення терміну — обчислюється при читанні, тому прострочений запит ніколи не може прив’язатися навіть до того, як очищення матеріалізує закінчення терміну.
Що ще розвивається — це більш повна консоль для операторів; точки доступу та рушій доступні вже сьогодні. Посібник Керування та затвердження описує поточний процес.
Залежність, яка робить все це достовірним — ідентифікація по кожному агенту. Аудит відносить діяльність до облікового запису, а не по суті до агента; спільний сервісний обліковий запис зводить атрибуцію до рівня ідентичності — чесно показано як висновок, ніколи не відновлено мовчки. Див. дозволений проти фактичного та точність щодо того, як це впливає на сигнал, яким ви керуєте.
Аварійний доступ: аудитований запобіжний клапан
Подвійний контроль потребує запобіжного клапана для інциденту о 03:00, коли один затверджувач недоступний. Аварійний доступ — це цей клапан, і він навмисно голосний. Активація вимагає рівня admin та реальну людину (системний токен відхиляється), апаратно верифіковане (AAL3) підвищення, письмове обґрунтування та активно записану сесію як передумову. Дозвіл обмежений у часі — за замовчуванням одна година, максимум один день — і прострочений дозвіл нічого не може авторизувати.
Поки дозвіл активний, дія в межах дії може виконуватися без кворуму затвердження, але кожне використання додається до незмінного журналу та аудиторського журналу, називаючи дозвіл, дію та суб’єкт — дія, виконана за аварійним доступом, назавжди відрізняється від затвердженої. Примусовий пост-огляд закриває цикл: новий дозвіл не може бути активований, поки попередній не переглянутий, і огляд повинен бути від іншої людини, ніж активатор.
Аварійний вимикач: загальний шлюз заборони
Аварійний вимикач — це аварійна зупинка одним кліком, і він навмисно інвертує звичну ергономіку. Увімкнення навмисно дешеве — рівень admin, обов’язкова причина, без кворуму затвердження, без підвищення, без аварійного доступу — тому що зупинка, яка чекає консенсусу, не є зупинкою. Рівень впевненості сесії увімкнення записується для криміналістики; зловживання увімкненням коштує лише доступність, що є безпечним напрямком.
Рядок зупинки є єдиним джерелом правди. Кожен керований шлюз виконання перевіряє його живим при кожній дії та закривається при помилці — точна протилежність контракту бюджетних шлюзів із відкриттям при помилці, тому що нечитаний стан зупинки ніколи не повинен означати “працювати”. Увімкнення також скасовує роботу в черзі, до якої шлюзи не можуть дістатися: кожне очікуюче затвердження виконання скасовується в тій же транзакції, щоб намір до зупинки не міг дозріти до дозволу, який запуститься, коли інфраструктура повернеться. Дії управління самі звільнені — зупинка зупиняє агентську інфраструктуру, ніколи контролі, які нею керують.
Повторне увімкнення ніколи не є одноосібним. Воно закрите на нове затвердження з подвійним контролем (мінімум
critical двох різних людей, структурно перевірений при перемиканні, тому знижена
політика не може зробити його одноосібним), і навмисно немає шляху аварійного доступу для
повторного увімкнення: “інфраструктура залишається зупиненою” є безпечним станом. Примусовий пост-огляд незалученою
людиною закриває інцидент.
Гарантія записаних рішень
Незалежно від глибини робочого процесу над ним, рішення управління є записаним фактом. Мутаційні дії додаються до аудиторського журналу з реальним актором у тій же транзакції, що й зміна, і чутливі читання (граф доступу, сам журнал) самоаудитуються у зафіксованому записі. Журнал тільки для додавання та з ланцюжковим хешуванням, кожен запис несе поля цілісності ланцюга, тому переписування історії виявляється і він ніколи не містить PII. Ви не можете зробити некеровану зміну, яку журнал мовчки забуде.
Пов’язане
- Дозволений проти фактичного — відхилення, на які ці рішення діють.
- Точність — наскільки впевнений сигнал під рішенням.
- Керування та затвердження — поточний процес затвердження, крок за кроком.
- Аварійний вимикач — загальний шлюз заборони в термінах продукту.
- Чесність і обмеження — закрита за замовчуванням, детективна позиція повністю.