У новому випуску подкасту IBM Security Intelligence експерти з кібербезпеки обговорюють одну з найменш «гламурних», але найкритичніших тем ери автономних систем — ідентичність та доступ для AI-агентів. Coalition for Secure AI запропонувала розширену модель IAM (Identity and Access Management), яка намагається відповісти на просте, але фундаментальне запитання: якщо штучний інтелект починає діяти як суб’єкт, якого ми запускаємо в наші системи, то ким він є з точки зору безпеки?
Відповідь коаліції радикальніша, ніж може здатися. Вона пропонує перестати ставитися до агентів як до «надбудови» над людськими обліковками й почати сприймати їх як окремі, повноцінні цифрові особистості з власними правами, обмеженнями та ланцюжками відповідальності. І це може суттєво змінити те, як організації проєктують безпеку в епоху автономних AI-сервісів.
Чому старий IAM ламається на AI-агентах
Традиційні системи IAM будувалися навколо людей та, у кращому разі, сервісних акаунтів. Є працівник, є його роль, є набір прав у корпоративних системах. Є мікросервіс — у нього свій технічний обліковий запис. Усе це більш-менш вкладається в класичні моделі ролей, груп, політик доступу.
AI-агенти руйнують цю логіку з кількох причин.
По-перше, вони діють автономно. Агент може ініціювати дії, викликати інші сервіси, запускати ланцюжки інструментів, приймати рішення на основі контексту, який змінюється в реальному часі. Це не просто «скрипт», який виконує один заздалегідь визначений виклик API.
По-друге, вони часто працюють «від імені» когось іншого. Агент може виконувати завдання від імені співробітника, команди, сервісу чи навіть іншого агента. У класичній IAM-моделі це часто вирішується через запозичені облікові дані: токен користувача, спільний сервісний акаунт, загальний ключ доступу. Саме тут починаються проблеми з відстеженням і відповідальністю.
По-третє, агенти постійно перетинають межі систем. Вони можуть за один сценарій пройти через кілька внутрішніх сервісів, зовнішніх API, інструментів автоматизації, хмарних платформ. Кожен такий «стрибок» — нова поверхня атаки, новий контекст політик і логування.
У результаті організації стикаються з типовим набором головного болю: кому насправді належить дія, виконана агентом? Чи мав він право це робити? Як обмежити його можливості так, щоб він міг виконати завдання, але не став ідеальним інструментом для зловмисника у разі компрометації?
Coalition for Secure AI пропонує відповідь у вигляді розширеної IAM-моделі, яка виходить із простої передумови: AI-агенти мають бути першокласними ідентичностями, а не «пасажирами» на людських акаунтах.
Окремі цифрові особистості: кінець епохи «позичених» обліковок
Один із ключових принципів запропонованого фреймворку — вимога чітко відокремлених ідентичностей для AI-агентів. Жодних позичених людських обліковок, жодних спільних сервісних акаунтів, через які одночасно працюють люди, скрипти й агенти.
У практичному вимірі це означає, що кожен агент отримує власну, унікальну цифрову особистість у системі IAM. У нього є свій ідентифікатор, свої ключі, свої політики доступу, свої журнали аудиту. Якщо агент виконує дію в системі, у логах це відображається як дія конкретного агента, а не як абстрактна активність «користувача Петренка» чи «service-account-ci-pipeline».
Цей підхід вирішує одразу кілька проблем.
По-перше, зникає «туман війни» навколо того, хто насправді виконав дію. Якщо облікові дані людини використовуються і нею самою, і агентом, і ще кількома автоматизованими процесами, розібратися в інциденті стає майже неможливо. Окрема ідентичність агента робить кожну його операцію чітко атрибутованою.
По-друге, зменшується ризик зловживань через спільні акаунти. Класичний сервісний обліковий запис, який використовують десятки систем, — це мрія будь-якого атакувальника. Компрометація такого акаунта відкриває двері в півкорпорації. Якщо ж кожен агент має власну, вузько обмежену ідентичність, потенційний збиток від її захоплення суттєво зменшується.
По-третє, стає можливим гнучке керування життєвим циклом агентів. Окрему ідентичність можна створити, активувати, призупинити, відкликати, ротути ключі, змінювати політики доступу — усе це без впливу на людей чи інші сервіси, які раніше «ділили» з агентом облікові дані.
Фактично, коаліція пропонує перенести на агентів ті ж принципи, які сучасні організації вже намагаються застосовувати до людей: жодних спільних акаунтів, чітка персоналізація, прозорий аудит. Але з урахуванням того, що ці «користувачі» — не люди, а автономні системи, які можуть масштабуватися й розмножуватися значно швидше.
Нуль постійних привілеїв: агенти живуть на «дієті доступу»
Другий фундаментальний принцип фреймворку Coalition for Secure AI — нульові постійні привілеї для AI-агентів. Ідея проста: агент не повинен мати жодних широких, довготривалих прав у системі «про всяк випадок». Усе, що йому потрібно, він має отримувати лише на час виконання конкретного завдання, у мінімально необхідному обсязі.
Це продовження концепцій рольового доступу, zero trust та just-in-time-підходів, але застосованих до агентів як до окремого класу суб’єктів.
У традиційних сценаріях автоматизації часто можна побачити протилежну картину. Щоб «не ламати пайплайн», сервісному акаунту дають широкі права: читати й писати в репозиторії, розгортати в продакшн, змінювати конфігурації, керувати секретами. Якщо такий акаунт використовує ще й AI-агент, він автоматично отримує надлишкові можливості.
Фреймворк коаліції пропонує іншу модель. Агент стартує з нульовими постійними привілеями. Коли йому потрібно виконати дію — наприклад, прочитати конкретний документ, змінити налаштування окремого сервісу чи запустити обмежений скрипт — він запитує тимчасовий доступ. Система IAM видає йому вузький токен або делегований повноваженнями контекст, який діє лише протягом короткого часу і лише в межах чітко визначеного ресурсу.
Якщо агент або його облікові дані будуть скомпрометовані, зловмисник отримає не «золотий ключ» до всієї інфраструктури, а лише крихітний, тимчасовий фрагмент доступу, який швидко втратить чинність. Це різко знижує потенціал для масштабного зловживання.
Крім того, модель нульових постійних привілеїв дисциплінує самих розробників і інтеграторів. Щоб агент міг виконати завдання, потрібно чітко описати, які саме ресурси йому потрібні, на який час і в якому режимі. Це змушує проєктувати сценарії використання AI більш усвідомлено, замість «дати йому адмінку, а там розберемося».
Ланцюжки авторитету: як повернути людину в контур відповідальності
Ще одна важлива складова фреймворку Coalition for Secure AI — вимога простежуваних ланцюжків авторитету для всіх дій, які агент виконує «від імені» людей. Ідея полягає в тому, що будь-яка операція агента має бути пов’язана з чіткою, формалізованою делегацією від конкретної людини або ролі.
У класичній моделі з позиченими обліковими даними це майже неможливо. Якщо агент використовує токен користувача, у логах усе виглядає так, ніби дію виконав сам користувач. Якщо ж агент працює через спільний сервісний акаунт, то взагалі незрозуміло, хто стоїть за конкретною операцією.
Розширена IAM-модель пропонує будувати явні ланцюжки: людина (або роль) делегує агенту обмежений набір повноважень, агент може делегувати частину цих повноважень іншому агенту або інструменту, і так далі. Кожен крок цього ланцюжка має бути зафіксований, а кожна дія — прив’язана до нього.
У підсумку, коли виникає питання «хто дозволив агенту змінити цю конфігурацію?» або «на якій підставі він отримав доступ до цього набору даних?», відповідь можна знайти, пройшовши по ланцюжку авторитету назад — аж до конкретної людини, яка надала початкову делегацію.
Це не лише про аудит після інциденту. Така модель створює й запобіжники в реальному часі. Якщо агент намагається виконати дію, яка не вкладається в межі делегованих йому повноважень, система IAM може її заблокувати або вимагати додаткового підтвердження від людини. Таким чином, людина залишається кінцевим джерелом авторитету, навіть якщо більшість операцій виконують автономні системи.
У світі, де AI-агенти дедалі частіше приймають рішення, що мають фінансові, правові чи операційні наслідки, наявність такого прозорого ланцюжка відповідальності стає не просто питанням «гарної практики», а потенційною вимогою регуляторів і партнерів.
Контроль на кожному «стрибку»: безпека як маршрут, а не точка
Четвертий наріжний камінь фреймворку Coalition for Secure AI — вимога безпекових контролів на кожному «хопі», тобто на кожному етапі, де агент взаємодіє з новим інструментом, сервісом чи системою.
У традиційних архітектурах безпека часто концентрується на «вході» в систему: автентифікація, авторизація, можливо, сегментація мережі. Далі всередині довіреної зони діє припущення, що суб’єкт уже «свій» і може вільно пересуватися між сервісами.
AI-агенти роблять таку модель особливо небезпечною. Один агент може за кілька секунд пройти шлях, який людині зайняв би години: від внутрішнього API до зовнішнього SaaS, від бази даних до CI/CD-системи, від системи моніторингу до хмарної консолі. Якщо кожен із цих «стрибків» не контролюється окремо, будь-яка помилка в політиках або компрометація на одному етапі відкриває шлях для стрімкого латерального руху.
Фреймворк коаліції пропонує дивитися на маршрут агента як на послідовність контрольованих переходів. Кожен раз, коли агент звертається до нового інструменту, мають спрацьовувати окремі механізми:
перевірка того, хто саме цей агент (через його окрему ідентичність),
оцінка, чи має він право виконувати саме цю дію в цьому контексті (з урахуванням нульових постійних привілеїв і тимчасових токенів),
логування й моніторинг конкретної операції з прив’язкою до ланцюжка авторитету.
Це перетворює безпеку з «воріт» на «серію шлюзів», через які агент проходить у міру того, як взаємодіє з різними системами. Такий підхід складніший у реалізації, але він значно зменшує ризики, пов’язані з тим, що один скомпрометований елемент дасть змогу агенту «пробігтися» по всій інфраструктурі.
Особливо це важливо в умовах, коли AI-агенти часто працюють у гібридних середовищах: частина інструментів — у хмарі, частина — онпрем, частина — у сторонніх постачальників. Контроль на кожному хопі дозволяє застосовувати політики безпеки послідовно, незалежно від того, де фізично розташований сервіс.
Менше латерального руху, менше зловживань: що дає модель «агент як перша особа»
Усі ці принципи — окремі ідентичності, нуль постійних привілеїв, ланцюжки авторитету, контроль на кожному хопі — сходяться в одній стратегічній меті: зменшити можливості для латерального руху й зловживань у разі, якщо агент або його облікові дані будуть скомпрометовані.
У класичній моделі з позиченими обліковками сценарій атаки виглядає тривіально. Зловмисник отримує токен користувача або сервісного акаунта, який має широкі права. Далі він може використовувати всі можливості, що були надані людині чи сервісу, без чіткої відмінності між їхніми діями й власними. Латеральний рух стає питанням часу й креативності.
У моделі Coalition for Secure AI ситуація інша.
По-перше, компрометація агента не дає автоматичного доступу до людських акаунтів. Агент — окрема ідентичність із власними, обмеженими правами. Людські токени не «вшиті» в нього, а делегуються через контрольовані механізми.
По-друге, навіть якщо зловмисник захопить облікові дані агента, він отримає лише те, що агент має у вигляді тимчасових, вузьких привілеїв. Щоб розширити доступ, йому доведеться проходити ті ж самі механізми делегації й контролю на кожному хопі, які спроєктовані з урахуванням моніторингу й обмежень.
По-третє, будь-яка спроба використати агента поза межами його звичайних сценаріїв роботи буде помітною в логах. Окрема ідентичність і ланцюжки авторитету дозволяють будувати поведінкові моделі: які дії агент зазвичай виконує, у яких системах, з якою частотою. Відхилення від цієї моделі стають сигналом для розслідування.
У сукупності це не робить AI-агентів «безпечними за замовчуванням», але переводить їх із категорії «ідеальний інструмент для зловмисника» у категорію «керований, відстежуваний суб’єкт із обмеженим потенціалом шкоди». Для організацій, які вже сьогодні експериментують з автономними агентами в продакшні, така зміна парадигми може виявитися критичною.
Висновок: IAM має еволюціонувати разом з агентами
Поки великі гравці ринку будують коаліції навколо виявлення вразливостей і AI-посиленої оборони, Coalition for Secure AI звертає увагу на менш помітний, але фундаментальний шар — те, як ми взагалі моделюємо суб’єктів у цифрових системах.
AI-агенти вже не вписуються в старі уявлення про «користувача» й «сервісний акаунт». Вони автономні, багатокрокові, здатні діяти від імені людей і взаємодіяти з десятками інструментів за один сценарій. Спроба втиснути їх у наявні IAM-схеми через позичені обліковки й спільні акаунти створює ідеальні умови для інцидентів, які буде важко виявити й ще важче розслідувати.
Розширена IAM-модель, запропонована коаліцією, пропонує інший шлях: визнати агентів першокласними ідентичностями, посадити їх на «дієту доступу» з нульовими постійними привілеями, відновити людський авторитет через простежувані ланцюжки делегації й розтягнути безпеку на кожен хоп їхнього маршруту.
Це не магічне рішення й не готовий продукт, а радше напрямок еволюції для корпоративних систем доступу. Але в умовах, коли автономні AI-системи швидко переходять із лабораторій у критичні бізнес-процеси, питання вже не в тому, чи потрібна така еволюція, а в тому, наскільки швидко організації зможуть її реалізувати.