Впровадження автономних AI-агентів в enterprise-контур перетворює їх на «суперкористувачів» із безпосереднім доступом до системних API. Коли великій мовній моделі (LLM) делегується можливість самостійно вирішувати, який інструмент викликати, які параметри передати та як інтерпретувати результат, класичні методи контролю доступу виявляються недостатніми для запобігання критичним інцидентам безпеки.
Архітектори та CISO дедалі частіше стикаються з ризиком Excessive Agency (надмірної агентності), коли AI-агенту надаються ширші права доступу до систем і корпоративних даних, ніж це дійсно необхідно для виконання конкретної бізнес-задачі. Якщо права надані на рівні всього сервісу, а не конкретного методу чи запису, це створює прямий вектор для неконтрольованих дій, фінансових втрат або витоку конфіденційної інформації через маніпуляції з контекстом.
Анатомія загрози Excessive Agency: чому AI-агент — це не просто ще один користувач
У традиційних системах користувач взаємодіє з інтерфейсом, який жорстко обмежує його дії заздалегідь закодованими сценаріями (use cases). З автономними ШІ-агентами ситуація кардинально змінюється: вони оперують неструктурованим контекстом і генерують запити до API динамічно, спираючись на системний промпт та поточне завдання.
Якщо права доступу не обмежені детально, зловмисник через Prompt Injection може змусити агента виконати деструктивні операції в межах його широких системних повноважень. Наприклад, AI-агент, що має доступ до API CRM-системи, може випадково або через зовнішню маніпуляцію експортувати всю базу клієнтів, якщо його права не обмежені на рівні конкретних методів API.
Методологія NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0) наголошує на необхідності обов'язкового оцінювання контексту використання, надійності та безпеки AI-систем — особливо, коли йдеться про інтеграцію в критичну інфраструктуру. ШІ-агент не може розглядатися як звичайний інтеграційний сервіс зі статичним API-токеном; це динамічний виконавець, чия недетермінована поведінка потребує жорсткого обмеження середовища виконання.
Класифікація ризиків за OWASP 2025 та MITRE ATLAS: де ламається традиційний RBAC
OWASP виділяє Excessive Agency як окремий критичний клас ризику для GenAI у своєму звіті Top 10 Risks for LLMs and Gen AI Apps 2025. Цей ризик виникає через надання моделям надмірних повноважень при інтеграції з інструментами (plugins та tools).
Традиційний контроль доступу на основі ролей (RBAC) виявляється вразливим з кількох причин:
- Недетермінованість викликів: модель сама вирішує, коли викликати функцію видалення замість читання, якщо опис функції здається їй релевантним у поточному контексті.
- Сліпа довіра до вхідних даних: агент може отримати інструкцію з ненадійного джерела (наприклад, зчитати вхідний email із вбудованим шкідливим запитом) і виконати дію від імені всієї системи.
Фреймворк MITRE ATLAS структурує подібні тактики атак на AI-системи, що дозволяє проводити моделювання загроз (threat modeling). Техніки непрямого впровадження інструкцій (Indirect Prompt Injection) демонструють, як легко обійти зовнішні фільтри, якщо сам агент має надмірні системні права.
Реальний приклад: автономний агент для автоматизації закупівель, якому надано широкі права на створення рахунків, може ініціювати транзакції без належного підтвердження. Достатньо надіслати йому специфікацію з прихованим текстом про ініціацію оплати, і агент може виконати платіж як легітимну інструкцію. За статистикою галузевих впроваджень, близько 49% організацій стикаються з проблемою недостатньої верифікації параметрів динамічних запитів, і лише 13% реалізують жорстку архітектуру перевірки на рівні кожного мікро-виклику API.
Архітектурні рубежі захисту: ізоляція середовищ (sandboxing) та мікро-привілеї
Для мінімізації ризиків Excessive Agency архітектори повинні впроваджувати багаторівневу систему захисту, адже жоден промпт-інжиніринг не гарантує безпеки від обходу фільтрів. Основними архітектурними рубежами є:
- Принцип найменших привілеїв (PoLP) на рівні API: доступ має надаватися виключно до конкретних методів з обов'язковою валідацією схем запитів. Якщо агенту потрібно лише читати статус, він не повинен мати доступу до методів оновлення.
- Sandboxing (ізоляція середовищ виконання): запуск коду або скриптів, які генеруються агентом, у суворо ізольованому контейнері, щоб обмежити доступ до внутрішньої мережі компанії та файлової системи.
- Human-in-the-loop (HITL): обов'язкове залучення людини-оператора для верифікації критичних транзакцій, які ініціює ШІ.
Model-driven security як фундамент: чому безпека має бути в ядрі даних
Спроба захистити ШІ-агента лише шляхом написання обмежувальних інструкцій у системному промпті є недостатньою. Надійна архітектура вимагає, щоб безпека була закладена безпосередньо на рівні платформи зберігання даних (model-driven security).
Для побудови стійких до атак систем у консорціумі Intecracy Group використовується low-code платформа UnityBase (спільна розробка компаній консорціуму, де InBase є ключовим, але не єдиним розробником). Безпека в UnityBase закладена в ядро платформи через механізми метаданих домену (Domain metadata), обмеження доступу на рівні рядків (Row-Level Security, RLS) та атрибутів (attribute-level security).
Це означає, що правила доступу жорстко задекларовані в моделі. Якщо AI-агент (наприклад, розроблений компанією Softengi для кастомного аналітичного рішення) буде скомпрометований через Prompt Injection, він фізично не зможе вийти за межі дозволених йому бізнес-сутностей. Якщо для сервісного акаунту налаштовано RLS на перегляд документів лише одного департаменту, ядро просто не поверне інші дані, незалежно від згенерованого ШІ запиту. Саме такі механізми використовуються під час інтеграції модулів (на кшталт «AI Центру» або рішень із AI-розпізнавання) в enterprise-документообіг, запобігаючи несанкціонованому доступу до конфіденційної інформації.
Побудова наскрізного Audit Trail для автономних дій ШІ
Коли машини самостійно ухвалюють рішення, базового логування помилок стає недостатньо. Необхідно будувати наскрізний Audit Trail, який фіксує повний ланцюжок: початковий запит, переданий моделі контекст, рішення моделі та фінальний результат виконання API-виклику. У UnityBase цей процес автоматизовано завдяки підсистемі аудиту та логування (DataHistory), що дозволяє відстежувати аномальну активність ШІ в реальному часі.
Відповідно до AWS Well-Architected Framework, регулярний архітектурний аудит допомагає виявити потенційні вразливості в ML-навантаженнях до того, як вони стануть production-інцидентами. Безпека автономних систем — це безперервний процес моніторингу та адаптації правил доступу.
Матриця контролю ризиків Excessive Agency при інтеграції AI-агентів
| Критерій контролю | Слабкий контроль (Традиційний підхід) | Цільовий контроль (Enterprise-стандарт) |
|---|---|---|
| Рівень доступу до API | Доступ до всього API сервісу за загальним токеном | Обмеження доступу на рівні конкретних методів (PoLP) та обов'язкова верифікація параметрів запиту |
| Ізоляція виконання | Запуск коду/скриптів агента безпосередньо в мережевому контурі | Запуск у ізольованому контейнері (Sandboxing) без доступу до внутрішньої мережі |
| Авторизація даних | Довіра до логіки фільтрації самого ШІ-агента | Примусове застосування RLS (Row-Level Security) на рівні ядра СУБД/платформи |
| Контроль транзакцій | Повна автономія виконання фінансових чи системних операцій | Обов'язковий шлюз Human-in-the-loop (HITL) для критичних дій |
Поширені питання
Що таке Excessive Agency у класифікації OWASP LLM 2025?
Excessive Agency (надмірна агентність) — це клас ризику, що виникає, коли AI-агенту надаються надлишкові права доступу, дозволи чи інструменти. Це створює вразливість: у разі маніпуляції контекстом або успішної атаки Prompt Injection агент може виконувати несанкціоновані деструктивні дії у суміжних бізнес-системах.
Як реалізувати принцип найменших привілеїв (PoLP) для інтегрованого AI-агента?
Необхідно обмежити доступ агента до API на рівні окремих мікро-методів та примусово валідувати параметри кожного запиту. Крім того, слід використовувати механізми Row-Level Security (RLS) на рівні ядра платформи чи бази даних, щоб агент міг звертатися виключно до тих записів, які стосуються його поточної задачі.
Чому традиційного RBAC недостатньо для захисту від атак на бізнес-логіку через ШІ?
RBAC обмежує доступ статично на рівні ролі, розраховуючи на детерміновані дії користувача через обмежений інтерфейс. ШІ-агент натомість генерує запити динамічно. Без ізоляції середовища виконання та обмежень на рівні самого ядра даних агент може бути використаний зловмисником як інструмент для обходу закладеної бізнес-логіки.