Існує чітка тенденція в розгортанні агентів: шлюз (gateway) — це перший елемент контролю, до якого звертаються команди, але саме до нього вони найменш готові. Це пов’язано з тим, що шлюзи розміщуються поверх рівнів ідентифікації та атрибуції, яких переважно немає.
Перший рівень ризику не є гіпотетичним. У червні CISA додала вразливість LiteLLM до свого каталогу відомих експлуатованих вразливостей після того, як зловмисники почали її використовувати. Помилка дозволяла виконувати команди на хості через сам шлюз, а в поєднанні з другою вразливістю вона не вимагала жодних облікових даних. Це була одна з семи поширених вразливостей та загроз (CVE), розкритих у цьому одному AI-шлюзі за місяць. Саме цей рівень багато підприємств прагнуть використати першим для захисту своїх AI-агентів.
Розглядаючи архітектуру безпеки агентів, елементи контролю шлюзу не повинні бути першими. Вони мають бути п’ятими.
Більшість моделей зрілості безпеки агентів описують елементи контролю, які компанії потребуватимуть у майбутньому. На мою думку, вони схильні упускати складнішу проблему опису сценарію “brownfield”: в якому порядку слід розташовувати ці елементи контролю разом із вже встановленою системою керування ідентифікацією та доступом (IAM)?
Якщо площина керування не знає, який агент діє, хто делегував завдання, яке завдання має виконати агент і які облікові дані використовуються, то контекст є неповним. Шлюз може блокувати явні порушення політик, але йому буде складно відрізнити виправдану дію від дії, яка технічно допустима, але операційно недоречна.
Шаблон збою стає очевидним під час послідовного розташування цих елементів контролю для виробничих розгортань агентів: забезпечення дотримання (enforcement) відбувається рано, тоді як контекст ідентифікації та атрибуції, від якого воно залежить, ще не розроблено. Безпека агентів функціонує як ланцюжок залежностей, де кожен елемент контролю залежить від контексту, згенерованого вище за потоком.
Неправильна відправна точка
Подумайте про маршрутизацію трафіку агентів через новий шлюз виконання. Агент фінансової звітності намагається змінити запис у виробничому середовищі. Шлюз автентифікує токен користувача та перевіряє виклик API. Чого він не може побачити, так це те, що запит ініційовано агентом, що агент виконує більш обмежену функцію, або що запит є частиною ланцюжка інструментів, викликаного ненадійним артефактом.
Облікові дані дійсні. Виклик API допустимий. Дія суперечить меті делегування. Шлюз присутній, але його підтримка, здається, відсутня, тому дорогий елемент контролю застосовується до дуже малої частини загальної картини.
Обмеження привілеїв агента тими, що належать людині-представнику, є корисним, щоб агент не перевищував повноважень особи, яку він обслуговує. Однак наявність стелі привілеїв не створює окремої атрибуції. Двадцять агентів можуть діяти під дозволами однієї людини, але все одно потребуватимуть унікальних ідентифікаторів, журналів аудиту, профілів поведінки та шляхів відкликання.
Розгортання з обмеженням залежностей
Я називаю цей процес розгортанням з обмеженням залежностей. Вихідні тести (upstream exit tests) повинні бути задоволені, перш ніж будь-який подальший елемент контролю вважатиметься операційно завершеним. Одночасна розробка подальших елементів контролю є допустимою.
Ось шість воріт та докази їхньої ефективності:
|
Ворота |
Контроль |
Оперативний доказ ефективності |
|
1 |
Інвентаризація агентів та відповідальне володіння |
Кожен виробничий агент має назву власника, мету, затверджені інструменти та стан життєвого циклу |
|
2 |
Чітка ідентичність агента та контекст делегування |
Система може ідентифікувати агента, його власника та представника, від імені якого він діє |
|
3 |
Облікові дані, обмежені завданням та короткотривалі |
Зкомпрометований агент не може отримати доступ до ресурсів, не пов’язаних із його призначеним завданням |
|
4 |
Атрибутована телеметрія |
Виконане завдання можна відтворити від ініціації до кінцевого результату |
|
5 |
Контроль виконання в реальному часі |
Рішення щодо політик враховують контекст агента, представника, завдання та дії, а не лише дійсність токена |
|
6 |
Базові показники поведінки та шлях аварійного вимкнення в масштабі всієї системи |
Ефективний авторитет агента може бути припинений скрізь, де він досягає |
Шість воріт залежностей для елементів контролю безпеки агентів. Кожен контроль контекстуалізований воротами над ним. З аналізу виробничих розгортань агентів автором.
Почніть з агентів, яких ви можете назвати
Для початку визначте виробничих агентів у фреймворках з відкритим кодом, хмарних рішеннях, SaaS-сервісах та інструментах розробника. Для кожного запишіть власника, відповідальність, стадію життєвого циклу, дозволені інструменти, домени даних та джерела облікових даних.
Якщо пропустити цей крок, організація втратить першу годину реагування на інциденти, намагаючись з’ясувати те, що мало б бути очевидним. Інвентаризація ідентифікує актив, яким керує кожен подальший елемент контролю.
Агенту потрібна власна ідентичність, але він не повинен втрачати людину, що стоїть за ним
Агент не повинен бути “захований” у токені розробника, спільному обліковому записі служби чи сесії людини. Простого знання про те, хто викликає, не достатньо. Площина керування потребує додаткового контексту делегування: хто делегував завдання, яке конкретне завдання було доручено агенту виконати, і до яких ресурсів агент потребує доступу. Ідентичність визначає, хто здійснив виклик. Делегування — це відповідь на питання, чий авторитет він використовує і з якою метою.
Після розриву цього зв’язку, подальші журнали будуть приписувати агенту фінансової звітності співробітника, чий токен він позичив, і кожна його дія буде приписуватися комусь, хто її не починав.
Обмежте повноваження, перш ніж аналізувати поведінку
Після того, як агент буде ідентифіковано, слід обмежити його можливості. Обмеження доступу повинні бути обмежені в часі завданням та інструментами й ресурсами, необхідними для його виконання. Це може бути реалізовано за допомогою функцій керування ідентифікацією та доступом (IAM), таких як робоча ідентичність (workload identity), обмін токенами, умовний доступ та короткотривалі права доступу, які організація вже має.
Згідно з дослідженням Teleport 2026, що охопило 205 керівників з питань безпеки, масштаб доступу перевищує прогнозуючу здатність галузі, зрілості або самозаспокоєння щодо прогнозування інцидентів, пов’язаних зі ШІ. Наприклад, в організаціях з надмірними привілеями для ШІ повідомлялося про 76% інцидентів, тоді як інциденти зі ШІ траплялися у 17% організацій з найменшими привілеями. Це свідчить про те, що масштаб доступу в ланцюжку залежностей є більш важливим, ніж контекстно-залежне виконання в реальному часі.
Основний принцип — монотонне делегування. Кожна передача відповідальності повинна зберігати або зменшувати авторитет; ні за яких обставин вона не повинна збільшувати авторитет. Для агента фінансової звітності це означає, що агент, який може переглядати один реєстр, на відміну від агента, який успадковує доступ співробітника до всіх систем, доступних цій людині.
Виправте атрибуцію перед автоматизацією контролю
Більшість аудиторських стеків можуть фіксувати, до якого ресурсу було здійснено доступ і які облікові дані його дозволили. У розгортаннях агентів, які я переглядав, це найчастіше пропущене “ворота”. Перед використанням адаптивної політики виконання зв’яжіть будь-який відповідний виклик інструменту з ідентичністю агента, ініціюючим представником, ідентифікатором завдання, батьківською дією та результатом. Після цього перегляньте телеметрію: для одного виконаного завдання спробуйте відстежити ініціатора, агента, який його виконав, авторитет, під яким дія була здійснена, використані інструменти та результат. У регульованих середовищах нагляд, який не є атрибутованим, не може бути виправданим.
Тепер шлюз виправдовує свою вартість
Шлюз може використовувати зареєстровані ідентичності, явне делегування, обмежені облікові дані та атрибутовану телеметрію, щоб запитати, чи уповноважений цей агент виконувати цю дію для цього представника, в рамках цього завдання, стосовно цього ресурсу. Хоча облікові дані користувача можуть надавати права на запис для агента фінансової звітності, шлюз має ситуаційний контекст і тому визначає, що це виходить за межі сфери застосування. Це точка найбільшої цінності контролю. Найсуворіші заходи контролю повинні застосовуватися на незворотних межах — платежі, зміни політики доступу, видалення, модифікації виробничого середовища та експорт даних.
Виявлення та шлях аварійного вимкнення йдуть останніми
Базові показники поведінки розробляються останніми, оскільки для встановлення стандарту необхідна виділена та атрибутована діяльність агента. Тоді команди безпеки зможуть виявляти аномальні шаблони використання інструментів, несподіваний доступ між доменами та відхилення від призначених завдань. Стримування — це більше, ніж просто вимкнення одного об’єкта каталогу: належний шлях аварійного вимкнення передбачає вимкнення ідентичності агента, анулювання активних та похідних облікових даних, блокування активації інструментів, припинення активних завдань та ізоляцію робочого навантаження, що містить агента.
Почніть, не замінюючи вашу IAM
Розробка абсолютно нової програми ідентифікації не є необхідною. Якщо наявний постачальник ідентифікації не розглядає агентів як нативні об’єкти, почніть з авторитетного реєстру, пов’язаного з існуючими робочими ідентичностями. Після цього розширте ідентифікатори агентів та завдань як довірені контексти виконання, впровадьте короткотривалі облікові дані для зменшення успадкованих привілеїв і включіть ці ідентифікатори до журналів викликів інструментів для подальшого введення в шлюз. Модель залежностей залишається незмінною, оскільки підтримка постачальників розвивається.
Прогалини в контролі вимірювані. У опитуванні Okta 2026 лише 34% керівників заявили, що їхня організація завжди застосовує однаковий рівень суворості безпеки до свого агентського персоналу, як і до свого людського персоналу. Останній елемент ланцюжка не може бути застосований першим для закриття цієї прогалини.
Що робити протягом наступних 30 днів
Почніть з 10 виробничих агентів. Для кожного визначте власника, мету, дозволені інструменти та облікові дані. До цього часу у вас має бути основа для реєстру агентів та, можливо, перші уявлення про управління.
Перевірте атрибуцію. Дізнайтеся, чи може IAM та журналювання відрізняти кожного агента від людини або служби, яка делегувала завдання. Якщо такий вид диференціації неможливий, шлюз працюватиме без видимості.
Відтворіть одне завершене завдання агента в ланцюжку дій, від початку до кінця, включаючи подальші наслідки. Там, де ланцюжок розривається, саме там ваше розгортання зазнає невдачі.
Додавання подальшого контролю перед необхідним контекстом руйнує безпеку агентів. Моделі зрілості описують пункт призначення. Порядок збірки допоможе вам дістатися туди, не порушуючи виробничі процеси.
Нік Кейл — провідний інженер, що спеціалізується на корпоративних AI-платформах та безпеці.
Ласкаво просимо до спільноти VentureBeat!
Наша програма для запрошених авторів — це місце, де технічні експерти діляться своїми знаннями та надають нейтральні, не пов’язані з комерційними інтересами глибокі аналізи ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємств.
Оригінал статті: venturebeat.com