Зі зростанням автономності AI-агентів їхнє використання переходить від експериментів до реальної автоматизації корпоративних бізнес-процесів. Проте інтеграція штучного інтелекту створює критичну загрозу для ІТ-безпеки підприємств — ризик «надмірної агентності» (Excessive Agency). Згідно з класифікацією OWASP (Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025), цей клас загроз виникає, коли інтелектуальному агенту надають занадто широкі повноваження, дозволяючи йому виконувати дії поза межами очікуваної поведінки.
Для технічних лідерів та архітекторів це серйозний виклик: як делегувати рутинні операції підконтрольним AI-агентам, не надаючи їм необмежених прав на виконання критичних транзакцій? Вирішення лежить не у спробах зробити саму велику мовну модель (LLM) «безпечною» через промпти, а в жорсткому архітектурному обмеженні її агентності за допомогою детермінованих стандартів оркестрації (BPMN) та бізнес-правил (DMN).
Анатомія Excessive Agency: чому AI-агенти виходять з-під контролю згідно з OWASP
Коли розробники створюють AI-агента, вони зазвичай дають йому доступ до набору API та інструктують його базовим промптом. Агент аналізує запит, самостійно планує послідовність дій і вирішує, який інтерфейс викликати. Саме в цій автономності криється фундаментальна вразливість. За класифікацією OWASP, ризик Excessive Agency виникає через три основні чинники:
- Надмірна функціональність (Over-privileged APIs): агенту доступні методи API, які йому не потрібні для виконання безпосередньої задачі (наприклад, можливість запису чи видалення даних замість їх читання).
- Надмірні дозволи (Over-privileged Access): сервісний акаунт, під яким працює агент, має занадто високі права в цільовій системі.
- Відсутність верифікації (Lack of Verification): система сліпо довіряє вихідним даним від LLM, не перевіряючи їх на відповідність бізнес-логіці.
Розглянемо два реальні приклади, які ілюструють ці загрози в корпоративному середовищі:
- AI-агент, що має доступ до API фінансової системи, намагається виконати транзакцію, яка не передбачена схемою процесу. Це може статися через успішну атаку типу Prompt Injection або галюцинацію моделі.
- Агент приймає рішення про надання знижки клієнту, що прямо суперечить таблиці рішень DMN, яка є єдиним джерелом істини для бізнес-правил компанії.
BPMN 2.0 як зовнішній обмежувач: чому оркестрація має бути детермінованою
Щоб усунути ризик Excessive Agency, необхідно позбавити AI-агента ролі оркестратора процесу. ШІ не повинен самостійно вирішувати, який крок буде наступним. Цю функцію має виконувати детермінований workflow-двигун, що працює за міжнародним стандартом BPMN 2.0 (опублікованим також як ISO/IEC 19510:2013).
У такій архітектурі AI-агент стає виконавцем конкретного, ізольованого кроку процесу. Він отримує на вхід лише ті дані, які необхідні для цієї задачі, і повертає результат у строго визначеному форматі. Самим же потоком, переходами та викликом системних API керує BPMN-двигун. Такий підхід забезпечує видимість стану кожного інстансу процесу та унеможливлює ситуацію, коли ШІ перестрибує через обов'язкові етапи узгодження. BPMN не усуває ризики самої LLM, але надійно обмежує радіус ураження в межах однієї задачі.
Розділення обов'язків за допомогою DMN: забираємо у ШІ право на свавільні рішення
Окрім контролю за потоком процесу, важливо обмежити логіку прийняття рішень. Якщо AI-агент має оцінити ризики або розрахувати параметри угоди, ці правила не повинні бути зашиті в його системний промпт.
Для цього використовується стандарт DMN (Decision Model and Notation). DMN дозволяє винести бізнес-правила з коду та потоку процесу в окремі таблиці рішень. AI-агент у цій схемі виконує лише підготовчу функцію: він збирає та структурує дані (наприклад, аналізує скаргу чи договір) і передає їх як вхідні параметри. Остаточне рішення приймає детермінований DMN-двигун на основі жорстко зафіксованих правил, які ШІ не здатний змінити.
Архітектура безпечного workflow: ізоляція API та рольовий доступ (RBAC/RLS)
Для впровадження керованих AI-агентів потрібна надійна інфраструктурна платформа. Наприклад, low-code платформа Scriptum (продукт з портфеля рішень технологічного альянсу Intecracy Group) використовує механізми платформи UnityBase для контролю процесів. Завдяки такій архітектурі, кожен крок агента обмежується на кількох рівнях:
- Обмеження на рівні метаданих: єдина модель Domain metadata визначає чіткі межі даних та API, до яких агент взагалі може мати доступ.
- Рольовий доступ (RBAC): сервісний акаунт агента отримує мінімально необхідний набір ролей.
- Безпека на рівні рядків (RLS): механізм RLS обмежує видимість даних для агента лише тими записами, які безпосередньо стосуються поточного BPMN-процесу.
Для систем із підвищеними вимогами до безпеки офіційна сторінка платформи UnityBase рекомендує використовувати Enterprise або Defence редакції, які додають підтримку розширеного аудиту та додаткових механізмів автентифікації.
Аудит та логування дій AI-агентів у критичних корпоративних процесах
Останній ешелон захисту від Excessive Agency — абсолютна прозорість та можливість ретроспективного аналізу. Використання механізму Audit Trail (зокрема модуля DataHistory в UnityBase) дозволяє вести повний аудит дій агента через event logs для значна частина критичних транзакцій. Логуванню підлягають: вхідний промпт, сирий результат роботи LLM, рішення DMN-двигуна та конкретні зміни в базі даних. Це забезпечує відповідність вимогам регуляторів та дозволяє застосовувати інструменти Process Mining для раннього виявлення аномалій.
Матриця контролю агентності: порівняння архітектурних підходів
| Архітектурний підхід | Ризик Excessive Agency | Механізм контролю та обмеження |
|---|---|---|
| Автономний агент (без BPMN) | Максимальний | Відсутній. Агент сам викликає API та формує потік процесу. |
| Агент у жорсткому BPMN-процесі | Низький | Агент виконує лише одну ізольовану задачу у схемі, оркестрацію здійснює рушій. |
| Агент з інтеграцією DMN | Мінімальний | Бізнес-правила зафіксовані в таблиці рішень, ШІ не може їх змінити. |
Підсумовуючи: безпечна інтеграція штучного інтелекту вимагає архітектурної дисципліни. Замість спроб навчити LLM правилам безпеки, ІТ-архітектори мають будувати навколо неї жорсткий зовнішній каркас із детермінованих процесів BPMN 2.0, таблиць рішень DMN та суворої рольової моделі на рівні платформи.
Поширені питання
Як стандарт BPMN 2.0 допомагає запобігти ризику Excessive Agency в LLM?
BPMN 2.0 перебирає на себе функцію оркестрації процесу. AI-агент більше не вирішує, яку дію виконати наступною — він лише виконує ізольоване завдання в межах жорстко визначеної схеми, де всі переходи та виклики API контролюються двигуном процесу.
Чи можна використовувати DMN для обмеження фінансових рішень AI-агента?
Так, DMN виносить бізнес-правила в декларативні таблиці рішень. AI-агент лише збирає дані, а остаточне рішення приймає DMN-двигун на основі зафіксованих правил, які ШІ не може змінити або проігнорувати.
Як налаштувати аудит дій AI-агентів у корпоративних системах?
Необхідно логувати всі вхідні промпти, відповіді LLM, рішення DMN та зміни в базі даних через системний Audit Trail (наприклад, модуль DataHistory). Це забезпечує повний аудит дій агента в event logs для аналізу безпеки.