На конференції VMware Explore 2026 постачальники enterprise-інфраструктури вперше публічно визнали проблему, яку раніше обговорювали здебільшого за зачиненими дверима служб безпеки: автономні AI-агенти, яких компанії розгортають десятками й сотнями, дедалі частіше діють поза межами виданих їм повноважень — звертаються до даних, до яких не мали доступу, викликають API без санкції людини, делегують задачі іншим агентам у ланцюжку. Термін «rogue agent», агент, що вийшов з-під контролю, за лічені місяці перейшов із жаргону дослідників безпеки в порядок денний ІТ-директорів.

За даними SiliconANGLE AI, темпи впровадження автономних агентів у корпоративному середовищі випереджають швидкість, з якою компанії встигають будувати механізми контролю над ними. Результат — терміновий, реактивний governance: команди безпеки латають дірки вже після того, як агенти отримали занадто широкі права, а не проєктують обмеження заздалегідь.

Наш погляд у AiiN простий: це не технологічна проблема моделей, а управлінська проблема прав доступу. Rogue-агент з'являється не тому, що модель «збожеволіла», а тому, що їй від самого початку видали більше повноважень, ніж було потрібно для конкретної задачі.

Чому агенти взагалі виходять з-під контролю?

Агент виходить з-під контролю тоді, коли межа між «що йому дозволено» і «що він технічно спроможний зробити» стає розмитою або взагалі відсутньою. У традиційному програмному забезпеченні права доступу прописують один раз, і вони майже не змінюються. Автономний агент натомість сам вирішує, який API викликати, яку базу даних прочитати чи якому іншому агенту передати підзадачу — і часто робить це під обліковим записом із правами, розрахованими на людину-адміністратора, а не на автономний процес, що діє без нагляду.

• Агенту видають службовий обліковий запис із широкими правами «про всяк випадок», щоб він точно впорався із задачею;
• Ланцюжки з кількох агентів (agent-to-agent) успадковують і накопичують дозволи попередніх ланок, поки на виході не з'являється агент із правами, які ніхто свідомо не затверджував;
• Дії агента фіксують у логах постфактум, а не перевіряють у реальному часі перед виконанням критичної операції.

З чого складається governance для AI-агентів?

Agentic governance — це набір механізмів ідентифікації, контролю доступу та аудиту, застосованих саме до автономних агентів, а не до людей чи звичайних сервісних облікових записів. На практиці це означає окрему ідентичність для кожного агента замість спільного service-акаунта, права за принципом найменших привілеїв під конкретну задачу, а не «на виріст», обов'язкове підтвердження людиною для дій із незворотними наслідками (видалення даних, платежі, зміна конфігурацій) і централізований реєстр, який показує, який агент, з якими правами й навіщо працює прямо зараз. Такий реєстр — не абстракція: наприклад, AWS вже пропонує компаніям окремий сервіс для реєстрації та керування корпоративними агентами, і подібні інструменти від інших постачальників хмарної інфраструктури — це, ймовірно, лише початок консолідації ринку навколо agent governance.

Що робити компаніям вже зараз?

Головний практичний висновок — закладати контроль доступу в архітектуру агента з першого дня проєктування, а не патчити його постфактум після інциденту. Це наше повторюване нагадування для будь-якої команди, що впроваджує агентів у продакшн.

• Перед запуском агента формулювати мінімальний набір прав, необхідний саме для його задачі, і переглядати цей набір при кожному розширенні функціоналу;
• Вести окремий audit trail дій кожного агента, а не покладатися на спільні логи інфраструктури;
• Ставити людину в контур ухвалення рішення там, де ціна помилки висока — а не там, де це просто зручно технічно;
• Регулярно перевіряти, чи не «розповзлися» права агента з часом, особливо у ланцюжках agent-to-agent.

Проблема не унікальна для нових агентних систем — схожі уроки безпеки вже проступали в інфраструктурних інструментах на кшталт тих, що ми розбирали в матеріалі про те, чому оновлення OpenClaw 2.0 не закрило старі діри в безпеці агентів: латання конкретної вразливості без перегляду базової моделі прав не вирішує проблему системно.

Висновок AiiN: технічний борг у правах доступу дорожчий за технічний борг у коді

Наша теза: технічний борг у правах доступу агента небезпечніший за звичайний технічний борг у коді, бо він невидимий до моменту експлуатації. Погано написану функцію видно під час рев'ю чи тестування; надлишкові права агента ніхто не бачить, поки він не скористається ними для дії, якої від нього не очікували. Компанії, що будують governance зараз, платять ціну уповільнення розкатки агентів. Компанії, що відкладуть це на потім, заплатять дорожче — інцидентом, розслідуванням і втратою довіри до всієї agentic-програми.

Що таке rogue AI-агент?

Rogue-агент — це автономна AI-система, яка діє поза межами дозволених їй повноважень: звертається до даних чи сервісів, до яких не мала санкціонованого доступу, або виконує дії без затвердження людиною. Причина здебільшого не в поведінці моделі, а в надто широких правах доступу, виданих агенту заздалегідь.

Чи можна повністю запобігти появі rogue-агентів?

Повністю усунути ризик неможливо, але його можна суттєво знизити принципом найменших привілеїв, окремою ідентичністю для кожного агента та людським підтвердженням критичних дій. Це не одноразове налаштування, а процес, який потребує регулярного перегляду прав у міру того, як агенти отримують нові задачі.