Згідно з оновленим рейтингом OWASP Top 10 для LLM 2025, ризик «Excessive Agency» (надмірна автономність) став критичною загрозою для корпоративних систем. При інтеграції автономних AI-агентів в ECM-платформи ми надаємо моделі право діяти від імені користувача або системи. Проблема виникає, коли агент виходить за межі своїх функціональних обов'язків, виконуючи операції, що не були передбачені архітектурою безпеки.
Чому RBAC не витримує викликів автономних агентів
Класичний Role-Based Access Control (RBAC) розрахований на статичні ролі користувачів. Проте AI-агенти оперують безпосередньо через API. У такій моделі RBAC часто стає «вузьким місцем», оскільки не враховує контекст кожного окремого запиту. Агент може ініціювати послідовність викликів, які технічно дозволені для призначеної йому ролі, але є порушенням бізнес-логіки. Згідно з галузевими оцінками, до 49% ризиків безпеки в AI-інтеграціях пов'язані з неконтрольованим доступом до даних через відсутність контекстного аналізу запитів.
Excessive Agency: як LLM виходить за межі повноважень
OWASP виділяє Excessive Agency як окремий клас ризиків для GenAI-застосунків, де модель виконує дії, що перевищують її призначення. Наприклад, агент, призначений для аналізу публічних звітів, через помилку в логіці отримує доступ до конфіденційних HR-документів, оскільки його технічний токен має ширші права доступу. Також агент може виконувати запис у базу даних через API, оминаючи перевірку прав, якщо RBAC налаштований лише на рівні сесії користувача, а не на рівні конкретного запиту до сутності.
Від статичних ролей до динамічної безпеки на рівні атрибутів
Ефективним рішенням є перехід до безпеки на рівні атрибутів (Attribute-level security), де кожен запит валідується через метадані домену. Платформа UnityBase, на якій побудовані такі рішення як Megapolis.DocNet та Scriptum, реалізує модель безпеки, що дозволяє контролювати доступ до даних незалежно від того, хто ініціював запит — людина чи AI-агент. Це дозволяє обмежити доступ агента лише до необхідних атрибутів об'єкта, мінімізуючи ризик несанкціонованого витоку.
Архітектурні методи захисту: пісочниці та аудит
Безпека має бути багаторівневою. Використання ізольованих середовищ (пісочниць) дозволяє обмежити область видимості даних. Важливим є моніторинг аномалій: якщо активність агента демонструє 13% відхилення від звичних патернів роботи, система повинна автоматично обмежувати доступ до завершення аудиту. Подальша робота має базуватися на принципах threat modeling (наприклад, за методологією MITRE ATLAS), що допомагає виявляти потенційні шляхи експлуатації моделі.
Чек-лист перевірки безпеки AI-агента в ECM
- Чи обмежений доступ агента лише до необхідних атрибутів об'єкта?
- Чи проходить кожен запит агента через валідацію метаданих домену?
- Чи ізольований агент у середовищі з обмеженими правами запису?
- Чи ведеться детальний лог усіх дій агента для аудиту?
- Чи налаштована система сповіщень про аномальну активність (наприклад, 13% відхилення від звичних патернів)?
Поширені питання
Чому RBAC не захищає від AI-агентів?
RBAC базується на статичних ролях, тоді як AI-агенти працюють динамічно. Вони можуть виконувати запити, що технічно дозволені роллю, але порушують бізнес-логіку.
Що таке Excessive Agency в контексті LLM?
Це ризик, при якому модель виконує дії, що виходять за межі її призначення, отримуючи доступ до даних або функцій, які не були передбачені архітектурою безпеки.
Як реалізувати Attribute-level security в ECM-системі?
Необхідно впровадити валідацію метаданих на рівні домену, де кожна операція перевіряється на відповідність контексту, а не лише на наявність прав доступу у користувача.