Проблема: ви не можете керувати тим, чого не бачите
Агенти вже там. Асистент із написання коду з обліковими даними бази даних, внутрішній RAG-сервіс, який непомітно отримав доступ на запис до об’єктного сховища, заплановане завдання, яке викликає MCP-сервер, що його ніхто не реєстрував. Їх розгорнули команди, що рухаються швидко, і відділ безпеки успадковує радіус ураження, ніколи не побачивши карти. Аналітики мають назву для цієї форми — розростання агентів — і прогалина в керуванні під нею є вимірюваною.
З організацій, які зазнали пов’язаного з AI порушення безпеки, приблизно 97% не мали належних засобів контролю доступу до AI (IBM Cost of a Data Breach 2025, Ponemon). Це не історія про зрілість інструментів; це відсутність поверхні контролю. Водночас Gartner очікує, що понад 40% проєктів з агентного AI буде скасовано до кінця 2027 року, і прогнозує, що «агенти-охоронці» становитимуть 10–15% ринку агентного AI до 2030 року (Gartner, прес-реліз) — ринок закладає у ціну той факт, що некеровані агенти не переживають зіткнення зі справжнім переглядом безпеки.
Цей патерн ширший за команди безпеки. У попередньому, ще не рецензованому дослідженні приблизно 95% пілотів GenAI не показали вимірюваного впливу на прибутки та збитки, а зовнішньо придбані інструменти мали успіх приблизно вдвічі частіше за внутрішні розробки (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
Керування орієнтоване насамперед на читання і працює за принципом deny-closed. Ядро авторизації працює за принципом deny-by-default і обмежене тенантом, закриваючи за побудовою класи confused-deputy та IDOR. Будь-яка політика на основі атрибутів, яку ви налаштуєте поверх, може лише додатково обмежувати — композиція є перетином, тож політика ніколи не може розширити грант.
Там, де продукт ставить дію на шлюз, цикл такий: поверхня щось показує (відхилення,
виявлення) → авторизований оператор приймає рішення → рішення фіксується. Рушій
схвалення примусово забезпечує розподіл обов’язків (той, хто запитує, не може
прийняти рішення за власним запитом) та захист від повторного приймача рішення,
прив’язаний до стабільної людської ідентичності — системний токен не має
ідентичності й не може приймати рішення. Дія рівня critical несе обов’язковий
поріг двох осіб, узятий із NIST SP 800-53 AC-3(2), який примусово застосовується
як під час створення, так і повторно виводиться під час прийняття рішення, тож
навіть політика оператора, яка знижує рівень, не може зробити критичну дію
одноосібною. Існує аудитований клапан break-glass для інциденту о 03:00 —
гучний за побудовою, з апаратним посиленням, обмежений у часі та примусово
відправлений на post-review.
Kill switch — це шлюз заборони на рівні всієї інфраструктури. Задіяння навмисно дешеве (рівень адміністратора, причина, без кворуму), тому що зупинка, яка чекає на консенсус, не є зупинкою; кожен керований шлюз приведення в дію звіряється з рядком зупинки наживо та спрацьовує за принципом fail-closed у разі помилки читання. Повторне ввімкнення ніколи не є одноосібним — воно поставлене на шлюз свіжого схвалення з подвійним контролем і не має шляху break-glass, тому що «інфраструктура залишається зупиненою» — це безпечний стан.
Захищені від підробки докази
Кожна дія, що змінює стан, додається до журналу аудиту, що лише доповнюється, із ланцюжком хешів у тій самій транзакції, що й зміна, із зазначенням реального актора; чутливі читання самі себе аудитують у зафіксованому записі. Перезапис історії виявний, і журнал ніколи не містить PII. Модуль відповідності зіставляє ці докази часу виконання з фреймворками контролю, тож оцінка живиться спостережуваною реальністю, а не опитувальником.
Чим це є — і чим воно не є
- Self-hosted і суверенне. Площина контролю працює на вашій власній інфраструктурі й може бути air-gapped. Olivares AI — це відкрита, придатна до self-hosting платформа (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 — шлюз заборони на рівні всієї інфраструктури у продуктових термінах.
- Відповідність — захищені від підробки докази, зіставлені з фреймворками контролю.
- Концепції керування — насамперед читання, deny-closed, подвійний контроль.
- Порівняти — як Olivares стоїть поряд зі шлюзами, спостережуваністю та control tower.
- Почати роботу — побачте карту на демонстраційній інфраструктурі.