Штучні інтелектуальні агенти (AI-агенти) наразі мають ширший доступ та більше підключень до корпоративних систем, ніж будь-яке інше програмне забезпечення в середовищі. Це робить їх більшою поверхнею для атак, ніж будь-що, чим доводилося керувати командам безпеки раніше, і галузь ще не має для цього відповідної структури. “Якщо цей вектор атаки буде використано, це може призвести до витоку даних або навіть гірших наслідків”, — зазначив Спірос Ксантос, засновник і генеральний директор Resolve AI, під час нещодавньої події VentureBeat AI Impact Series. Традиційні рамки безпеки побудовані навколо людської взаємодії. На цій же події Йон Аніано, старший віце-президент з продуктів та CRM-додатків Zendesk, зазначив, що поки що не існує узгодженої структури для AI-агентів, які мають власні “персони” та можуть працювати автономно. Еволюція агентних ШІ відбувається швидше, ніж підприємства встигають створювати захисні механізми, а протокол Model Context Protocol (MCP), хоч і знижує складність інтеграції, лише погіршує проблему. “Зараз це невирішена проблема, тому що це Дикий Захід”, — сказав Аніано. — “У нас навіть немає визначеного технічного протоколу взаємодії між агентами, на який погодилися б усі компанії. Як збалансувати очікування користувачів з тим, що робить вашу платформу безпечною?”
MCP залишається “надзвичайно дозвільним”
Підприємства все частіше підключаються до серверів MCP, оскільки вони спрощують інтеграцію між агентами, інструментами та даними. Однак, за його словами, сервери MCP, як правило, є “надзвичайно дозвільними”. Він стверджував, що вони “насправді, ймовірно, гірші за API”, оскільки API, принаймні, мають більше контролю для застосування до агентів. Сучасні агенти діють від імені людей на основі явних дозволів, таким чином встановлюючи людську підзвітність. “Але в майбутньому можуть бути десятки, сотні агентів зі своєю власною ідентичністю, своїм власним доступом”, — сказав Ксантос. — “Це стає дуже складною матрицею”. Навіть незважаючи на те, що його стартап розробляє автономні AI-агенти для SRE (Site Reliability Engineering) та системного менеджменту, він визнав, що галузь “абсолютно не має структури” для автономних агентів. “Все залежить від нас і від тих, хто створює агентів, щоб визначити, які обмеження їм надати”, — сказав він. І клієнти повинні мати можливість довіряти цим рішенням. Він зазначив, що деякі існуючі інструменти безпеки пропонують детальне налаштування доступу — наприклад, Splunk розробив метод надання доступу до певних індексів у базових сховищах даних, — але більшість з них є ширшими та орієнтованими на людину. “Ми намагаємося розібратися з цим за допомогою наявних інструментів”, — сказав він. — “Але я не думаю, що вони достатні для епохи агентів”.
Хто несе відповідальність, коли ШІ неправильно аутентифікує користувача?
В Zendesk та інших постачальників платформ управління взаємовідносинами з клієнтами (CRM) ШІ залучений до багатьох взаємодій з користувачами. Аніано зазначив, що наразі це відбувається “в такому обсязі та масштабі, які ми, як бізнес та суспільство, раніше не могли собі уявити”. Ситуація може стати складною, коли ШІ допомагає людям-операторам; ланцюг аудитів може перетворитися на лабіринт. “Отже, тепер у вас є людина, яка розмовляє з людиною, яка розмовляє з ШІ”, — зазначив Аніано. — “Людина дає вказівку ШІ виконати дію. Хто винен, якщо це неправильна дія?” Це стає ще складнішим, коли залучено “кілька елементів ШІ та кілька людей”. Щоб запобігти виходу агентів з-під контролю, Zendesk дотримується “дуже суворих” правил щодо доступу та обсягу їх повноважень; однак клієнти можуть визначати власні захисні механізми відповідно до своїх потреб. У більшості випадків ШІ може отримати доступ до джерел знань, але не пише код і не виконує команди на серверах, сказав Аніано. Якщо ШІ викликає API, це “декларативно розроблено” та санкціоновано, а дії чітко визначені. Однак, попит з боку клієнтів переповнює ці сценарії, і “ми зараз тримаємо ворота”, — сказав він. Галузь повинна розробити конкретні стандарти для взаємодії агентів. “Ми вступаємо у світ, де завдяки таким речам, як MCP, що може автоматично виявляти інструменти, нам доведеться створювати нові методи безпеки для прийняття рішень щодо того, з якими інструментами ці боти можуть взаємодіяти”, — сказав Аніано. Щодо безпеки, підприємства справедливо стурбовані, коли ШІ бере на себе завдання автентифікації, такі як надсилання та обробка одноразових паролів (OTP), SMS-кодів або інших методів двофакторної автентифікації, сказав він. Що станеться, якщо ШІ неправильно автентифікує або ідентифікує когось? Це може призвести до витоку конфіденційних даних або відкрити двері для зловмисників. “Зараз існує спектр, і наприкінці цього спектру сьогодні — людина”, — сказав Аніано. Однак, “наприкінці спектру завтра може бути спеціалізований агент, розроблений для виконання такого ж інтуїтивного або людського рівня взаємодії”. Самі клієнти перебувають на спектрі впровадження та комфорту. У певних компаніях, особливо у фінансових установах чи інших високорегульованих середовищах, люди все ще повинні брати участь в автентифікації, зазначив Аніано. В інших випадках, старі компанії або “стара гвардія” довіряють лише людям автентифікувати інших людей. Він зазначив, що Zendesk експериментує з новими AI-агентами, які “трохи більше пов’язані з системами”, і працює з обраною групою клієнтів над впровадженням захисних механізмів.
Незабаром з’явиться постійна авторизація
У майбутньому агенти можуть стати більш надійними, ніж люди, для виконання деяких завдань, і їм будуть надані дозволи, “значно ширші”, ніж у людей сьогодні, сказав Ксантос. Але до цього ще далеко, і, здебільшого, страх перед тим, що щось може піти не так, стримує підприємства. “І це правильний страх, чи не так? Я не кажу, що це погано”, — сказав він. Багато підприємств ще не готові до того, щоб агент виконував усі етапи робочого процесу або повністю замикав цикл самостійно. Вони все ще хочуть людського перегляду. Resolve AI знаходиться на порозі надання агентам постійної авторизації в кількох випадках, які є “загалом безпечними”, наприклад, у кодуванні; звідти вони перейдуть до більш відкритих сценаріїв, які не є надто ризикованими, пояснив Ксантос. Але він визнав, що завжди будуть дуже ризиковані ситуації, де помилки ШІ можуть “мутувати стан виробничої системи”, як він висловився. Зрештою, проте: “Очевидно, шляху назад немає; це рухається швидше, ніж, можливо, навіть мобільні технології. Отже, питання в тому, що ми з цим робитимемо?”
Що команди безпеки можуть зробити зараз
Обидва спікери вказали на проміжні заходи, доступні в межах існуючих інструментів. Ксантос зазначив, що деякі інструменти, зокрема Splunk, вже пропонують детальні елементи керування доступом на рівні індексів, які можна застосовувати до агентів. Аніано описав підхід Zendesk як практичну відправну точку: декларативно розроблені виклики API з чітко санкціонованими діями, суворі обмеження доступу та обсягу повноважень, а також людський перегляд перед розширенням дозволів агентів.
Основний принцип, як зазначив Аніано: “Ми завжди перевіряємо ці ворота і дивимося, як ми можемо розширити отвір” — тобто, не надавайте постійної авторизації, доки не перевірите кожне розширення.
Як захиститися (Порада ІТ-Блогу):
1. **Ретельно переглядайте дозволи AI-агентів.** Надавайте лише мінімально необхідні права доступу. Уникайте надання агентам повного доступу до критичних систем, особливо тих, що пов’язані з автентифікацією та фінансовими даними, якщо це не є абсолютною необхідністю.
2. **Впроваджуйте багаторівневу автентифікацію (MFA).** Для доступу до систем, де використовуються AI-агенти, переконайтеся, що ваші облікові записи захищені за допомогою MFA. Це додає додатковий рівень безпеки, який ускладнює зловмисникам доступ, навіть якщо вони отримають облікові дані агента.
За матеріалами: venturebeat.com