Представлено NTT DATA AIVista
Дослідження VentureBeat, проведене в червні, виявило, що 69% підприємств все ще використовують ШІ-агенти, які діляться обліковими даними, що є практикою, пов’язаною з вищим рівнем інцидентів безпеки та майже-інцидентів.
Але на VB Transform 2026 Мукеш Каркі, технічний директор NTT DATA AIVista, та Маянк Упадх’яй, головний спеціаліст з безпеки та довіри Snowflake, стверджували, що виправлення ідентифікації — це лише перший крок. Підприємствам також потрібна авторизація на основі дій та захищені від несанкціонованого доступу аудиторські журнали, вбудовані в кожну взаємодію агента, якщо вони збираються безпечно розгортати автономні системи у великих масштабах.
«Ці організації повинні мати можливість довести своїм аудиторам у спосіб, що добре захищений від несанкціонованого доступу, що записи, які показують, що вони зробили, дійсно доводять те, що вони роблять», — сказав Каркі. «А доказовість — це, по суті, ваша ліцензія на діяльність у регуляторному середовищі».
Чому спільні облікові дані спричиняють інциденти безпеки агентських ШІ
Проблема, за словами Упадх’яя, полягає в тому, що багато припущень були перенесені з попереднього покоління програмного забезпечення.
«У традиційному світі програмного забезпечення людина десь клацає, і програмне забезпечення робить щось дуже детерміноване, і ви знаєте, який API воно викличе», — сказав він. «Але у світі агентів програмне забезпечення має власний мозок і постійно переналаштовується. Якщо ви надасте цьому програмному забезпеченню більше дозволів, ніж йому потрібно для конкретної мети, агенти за своєю природою є дослідницькими, тому вони намагатимуться багато різних речей, і у вас будуть ненавмисні побічні ефекти».
Вбудовування одного статичного ключа API посилює ризик, додав він.
«Це дуже поганий патерн, якщо у вас є один ключ API, ви вставляєте його в агента, і він спілкується від імені будь-кого з певним SaaS-сервісом, тому що тоді ви надаєте цьому агенту об’єднання потреб усіх», — сказав він, зазначивши, що другий режим збою є судовим, оскільки «щось може піти не так, і ви не зможете віднести це до правильного агента».
Обмежені облікові дані — це лише початок у регульованих галузях
Каркі, чиї клієнти переважно працюють у сферах страхування, охорони здоров’я та фінансів, вважає обмежені облікові дані базовою вимогою.
«У регуляторних умовах агент, який не має широкого доступу за допомогою спільних облікових даних, не буде працювати, періодично», — сказав Каркі. «Наявність облікових даних із обмеженим доступом — це лише відправна точка. Насправді існують два шарові обмеження. Одне — це юрисдикція, в якій працює агент, а потім — це юрисдикція або правила цієї організації».
Наприклад, агент із врегулювання претензій у штаті Вашингтон працює відповідно до інших правил, ніж агент у Каліфорнії, додав він, і кожна справа про відшкодування збитків є різною.
«Цих обмежених облікових даних недостатньо, тому що вони повинні бути засновані на діях та правилах у момент вчинення дії», — додав він.
Де аналогія зі співробітником для ШІ-агентів не працює
Аналогія зі співробітником, стверджував Каркі, працює лише до певної межі. Агентам все ще потрібно вивчати унікальний контекст організації, подібно до того, як це робить новий співробітник. Але, на відміну від людей, підприємства не можуть реалістично будувати довіру з тисячами агентів з часом.
«Зірковий співробітник в одній організації може не бути найкращим співробітником, коли він переходить в іншу організацію, не тому, що він став гіршим, а тому, що йому бракує контексту цього нового місця, і те саме стосується агентів», — сказав Каркі. «Якщо кожен співробітник має 100 агентів, ви не можете сказати, що збираєтеся вводити цих агентів в експлуатацію та перевіряти їх».
Упадх’яй вважає, що аналогія зі співробітником повинна ставити агентів на один щабель нижче в організаційній ієрархії.
«Ставтеся до них як до стажерів», — запропонував він. «Вони мають добрі наміри, але не завжди знають, що роблять, і ви повинні за ними стежити, поки поступово будуєте довіру».
На платформі Snowflake адміністратори можуть встановлювати загальноплатформові обмеження, такі як операції лише для читання, тоді як розробники додатково звужують дозволи агента під час запуску кожної сесії.
Трирівневий підхід до управління ШІ-агентами
Щодо того, де належить управління, Каркі каже, що сумнівів немає.
«Управління повинно відбуватися під час кожної дії агента, і воно повинно знаходитися поза агентом», — пояснив він. «Це єдиний спосіб, яким ви зможете довести пізніше, що агент здійснив дію, яку йому було дозволено здійснити».
Упадх’яй розділив управління на три рівні:
Рівень агента охоплює ідентифікацію, дозволи на інструменти та управління MCP.
Рівень моделі займається непрямим впровадженням підказок і дозволяє моделям працювати всередині VPC клієнта, щоб підказки залишалися невидимими для постачальника моделі.
Рівень даних охоплює доступ із найменшими привілеями, архітектуру без копіювання та контроль доступу на основі ролей.
Щоб агенти працювали належним чином, необхідне управління на всіх трьох рівнях.
Що підприємствам слід перевірити в першу чергу
Для підприємств, які перевіряють управління існуючими ШІ-агентами, Упадх’яй рекомендує почати з двох місць. Перше — це перевірка дозволів для статичних секретів, найбільшого виправленого вектора атаки. Далі — боротьба з тіньовим ШІ за допомогою шлюзу MCP, щоб розробникам більше не доводилося запускати нелегальні сервери MCP з відкритим кодом під своїми столами, а адміністраторам було видно, хто з чим спілкується з сервером MCP.
Існує компроміс між обмеженнями та можливостями, і це можна вирішити на рівні завдань, використовуючи оцінку впевненості для відкликання автономного виконання для дій із високим ризиком, а пісочниці як проміжний шлях. Але Каркі застерігає підприємства, які вже масштабують свої агентські системи.
«Багато з цього не можна виправити після того, як у вас запущена агентська система, і ще важче виправити, якщо вам доведеться довести своїм аудиторам, чому саме агент поводився так, як він поводився», — пояснив він. «Доказовість повинна бути побудована з нуля під час розробки системи».
Спонсорські статті — це контент, створений компанією, яка або платить за публікацію, або має ділові відносини з VentureBeat, і вони завжди чітко позначені. Для отримання додаткової інформації зв’яжіться з [email protected].
Дізнатися більше на: venturebeat.com