Автономні AI-агенти перетворюються з експериментальних інструментів на повноцінних цифрових співробітників enterprise-рівня. Вони здатні самостійно аналізувати фінансові звіти, взаємодіяти з корпоративними базами даних та ініціювати транзакції через API. Проте разом із цією автономністю виникає критичний виклик для архітекторів безпеки — надмірна агентність (Excessive Agency). Коли штучному інтелекту надають повноваження без належних архітектурних обмежень, корпоративний контур опиняється під загрозою, яку неможливо нівелювати класичними міжмережевими екранами.
Анатомія Excessive Agency: чому AI-агент стає найнебезпечнішим користувачем
OWASP у своєму актуальному фреймворку (Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025) визначає Excessive Agency як самостійний і критичний клас ризику. Ця вразливість виникає, коли AI-агенту надається більше дозволів, функціональності або автономії, ніж необхідно для виконання його цільової задачі.
Проблема часто полягає в архітектурних спрощеннях. Розробники можуть надати агенту універсальні API-ключі, які мають права на читання та запис усього масиву даних, щоб забезпечити «гнучкість» моделі. Практика тестування безпеки свідчить, що до 49% потенційних векторів атак на інтегровані системи GenAI пов'язані саме з надмірними правами доступу. Водночас лише 13% архітектур передбачають ізоляцію виконання згенерованого коду або викликів інструментів.
Три типові сценарії, що ілюструють проблему:
- Сценарій 1 (Надмірні дозволи): AI-агент для реферування внутрішніх документів отримує права на запис (write-access) у базу даних через занадто широкі API-scopes, що створює ризик несанкціонованої модифікації даних.
- Сценарій 2 (Надмірна функціональність): Агент для аналізу коду ненавмисно звертається до внутрішніх API-ендпоінтів, оскільки система не має обмежень на рівні окремих атрибутів.
- Сценарій 3 (Надмірна автономія): Агент, намагаючись виконати нестандартний запит, самостійно викликає сторонній несертифікований інструмент і передає йому чутливі корпоративні дані.
Моделювання загроз: погляд через MITRE ATLAS та NIST AI RMF
Для розуміння того, як зловмисники експлуатують автономність моделей, інженери використовують базу знань MITRE ATLAS. Вона описує реальні тактики атак на системи ШІ. Один із найнебезпечніших векторів — непряма ін'єкція інструкцій (Indirect Prompt Injection). Зловмисник розміщує шкідливу інструкцію в документі або листі, який має обробити агент. Сприйнявши інструкцію як легітимну, агент із надмірними правами може самостійно виконати деструктивну дію в системі.
Саме тому NIST у своєму фреймворку Artificial Intelligence Risk Management Framework (AI RMF 1.0) наголошує: для систем ШІ в критичній інфраструктурі важливо оцінювати контекст використання, надійність та підзвітність, а не фокусуватися виключно на точності (accuracy) моделі. Система, що точно відповідає на запити, але здатна безконтрольно викликати системні API, є небезпечною.
Архітектурний щит: Sandboxing та Principle of Least Privilege
Щоб запобігти наслідкам Excessive Agency, архітектура повинна містити жорсткі межі (containment). Основою є принцип найменших привілеїв (PoLP). Агент не повинен взаємодіяти з базами даних напряму. Усі дії мають проходити через API Gateway із суворою валідацією параметрів.
Для інструментів, що виконують код або складні обчислення, обов'язковою є ізоляція середовищ (sandboxing). Контейнери, у яких агент запускає скрипти або викликає утиліти, повинні мати обмеження на час виконання, використання пам'яті та заблокований доступ до внутрішньої мережі.
Model-Driven Security: перенесення безпеки в ядро платформи
Традиційний підхід на основі ролей (RBAC) зазвичай авторизує користувача загалом, і AI-агент, що діє від його імені, успадковує всі повноваження в рамках сесії. Цього недостатньо для безпечної автономії. Необхідний перехід до Model-Driven Security — архітектури, де політики доступу не є надбудовою, а інтегровані безпосередньо в доменну модель.
Прикладом застосування такого підходу є системи, побудовані на low-code платформі UnityBase (спільна розробка компаній Intecracy Group, де ключовим розробником виступає InBase). У цій платформі безпека реалізується на рівні ядра через механізми Row-Level Security (RLS) та Attribute-Level Security. Навіть якщо AI-інструмент (наприклад, інтегрований модуль AI Центр) виходить за межі контексту через prompt-маніпуляцію, ORM-шар платформи фізично заблокує доступ до рядків або атрибутів, на які в агента немає явного дозволу в межах конкретної операції.
Такий фокус на безпечній архітектурі підтримується міжнародними стандартами. Наприклад, компанія Softengi застосовує стандартизовані підходи до управління ШІ (підтверджено сертифікацією ISO/IEC 42001:2023) при розробці аналітичних і прогнозних рішень, гарантуючи, що безпека є первинною вимогою на етапі проектування систем.
Audit Trail та Human-in-the-Loop
Щоб виявити ризики до того, як вони спричинять інциденти, хмарні провайдери та фреймворки (як-от AWS Well-Architected Framework) рекомендують регулярно проводити архітектурні огляди (architectural reviews). Для AI-систем це означає впровадження двох обов'язкових компонентів:
Перший — наскрізне логування (Audit Trail). Система повинна фіксувати не лише кінцевий результат, а й процес вибору інструментів та проміжні кроки міркування агента.
Другий — впровадження патерну Human-in-the-Loop (HITL) для критичних операцій. Будь-яка дія, що стосується зміни фінансових даних, модифікації інфраструктури або надсилання конфіденційної інформації, має потребувати авторизації людиною-оператором.
Матриця архітектурного обмеження агентності (Agency Containment Matrix)
| Критерій (Вектор) | Традиційний (вразливий) підхід | Безпечний (архітектурний) підхід |
|---|---|---|
| Рівень доступу (Data Access) | Широкі API-ключі та базовий RBAC у межах сесії користувача | Row-Level Security (RLS) та обмеження на рівні атрибутів у ядрі платформи |
| Середовище виконання (Execution) | Вільний виклик інструментів та скриптів у загальному середовищі | Ізольовані контейнери (Sandboxing) з обмеженням мережі та часу (timeouts) |
| Авторизація дій (Authorization) | Повна автономія прийняття рішень для всіх типів операцій | Human-in-the-Loop: обов'язкове підтвердження критичних операцій (запис, видалення) |
| Аудит та моніторинг (Audit Trail) | Логування виключно кінцевого стану або результату виконання | Наскрізне логування кожного кроку (Chain of Thought) та зовнішніх API-викликів |
Поширені питання
Що таке Excessive Agency у контексті OWASP Top 10 для LLM 2025?
Це клас архітектурного ризику, що виникає, коли AI-агенту надаються надмірні дозволи, ширша функціональність або зайва автономія порівняно з тим, що необхідно для виконання його завдання. Це дозволяє скомпрометованій моделі виконувати несанкціоновані дії в системі.
Як реалізувати принцип найменших привілеїв (PoLP) для автономних AI-агентів?
Агенти повинні взаємодіяти з даними виключно через обмежені API, які суворо валідують параметри кожного запиту. Доступ до інфраструктури та виконання коду має відбуватися в ізольованих пісочницях (sandboxing) без прямого доступу до загальної корпоративної мережі.
Чому традиційний RBAC не захищає від помилок автономних AI-систем?
RBAC зазвичай надає доступ на рівні всієї сесії користувача. Якщо агент успадковує ці права, він отримує повний доступ до всіх даних, які може бачити користувач. Для обмеження AI потрібна Model-Driven Security з контролем на рівні окремих записів (Row-Level Security) та атрибутів.