ШІ-агенти вийшли за межі вікон чату. Тепер вони бронюють зустрічі, оновлюють записи клієнтів, роблять запити до внутрішніх баз даних і ініціюють фінансові транзакції. Ця зміна — від радника до оператора — повністю змінює підхід до ризиків. Коли програмне забезпечення перестає лише пропонувати і починає діяти, кожен API-ендпоінт стає потенційним входом. Традиційні моделі безпеки будувалися навколо передбачуваної поведінки людини: користувач входить у систему, переходить за знайомими шляхами та виходить. Автономні агенти не дотримуються таких паттернів. Вони працюють у циклах, повторюють спроби та розгалужуються на сотні викликів за лічені секунди. API-рівень, спочатку розроблений для запитів, ініційованих людиною, тепер стикається з постійним автоматизованим тиском. Якщо ваші методи захисту все ще покладаються на статичні правила, написані минулого кварталу, ви залишаєте двері відчиненими для витоку даних та несанкціонованого доступу. Вам потрібен захист у реальному часі, який оцінює кожен виклик у момент його здійснення.
Обмежте привілеї агентів
Найнебезпечнішим скороченням шляху при розгортанні агентів є надання одного потужного API-ключа. Один ключ надає повний доступ до всіх систем. Якщо зловмисник скомпрометує агента через отруєний промпт або перехоплену інтеграцію, він отримає «ключі від королівства». Відновлення перетвориться на кошмар, оскільки радіус ураження охоплюватиме все: від вашої поштової служби до робочої бази даних.
Негайно позбудьтеся цієї звички. Почніть з OAuth 2.0 для делегованої авторизації. Агент не повинен автентифікуватися як окремий суперкористувач. Натомість він має нести токен, який представляє як самого агента, так і кінцевого користувача, якому він обслуговує. Коли сесія людини завершується, доступ агента має зникнути разом із нею.
Обмін токенами (Token Exchange) робить це практичним. Випускайте короткострокові токени, обмежені саме тими діями, які потрібні агенту прямо зараз. Агент для планування зустрічей може отримати дозвіл на читання календаря та надсилання запрошень, але не на видалення інфраструктури календаря або доступ до API нарахування заробітної плати. Якщо зловмисник перехопить токен, вікно для зловживань залишиться вузьким.
Області доступу, обмежені контекстом (Context-Bound Scopes), додають ще один рівень захисту. За замовчуванням робіть кожен токен доступним лише для читання. Якщо агент має записувати дані, наприклад, обробляти повернення коштів або оновлювати контракт, запровадьте механізм підтвердження людиною. Ніколи не дозволяйте моделі самостійно вирішувати, коли рухати гроші, змінювати рахунки або видаляти записи. Дозвіл має відповідати моменту, а не максимальним можливостям.
Ефемерні вікна (Ephemeral Windows) повністю замикають цей цикл. Тривалість життя токена має вимірюватися хвилинами, а не днями. Токен, викрадений під час короткочасної компрометації, має стати марним до того часу, як зловмисник спробує його повторно використати. Думайте про це як про замок, що постійно змінює код.
Розглянемо агента з автоматизації продажів, який зчитує дані про потенційних клієнтів з вашої CRM і надсилає електронні листи для подальшого контакту через ваш Mail API. Замість одного вічного ключа адміністратора агент отримує 15-хвилинний токен від вашого провайдера ідентифікації. Токен дозволяє читання в CRM та надсилання пошти, але блокує видалення контактів і доступ до білінгу. Якщо агент отримає підозрілу інструкцію експортувати всю базу даних, обмеження області доступу просто заблокує цю спробу.
Зупиніть непряму ін'єкцію промптів
Ін'єкція промптів (Prompt injection) — це вже не просто фокус для чат-ботів. В епоху агентів вона функціонує як віддалене виконання коду, доставлене через електронну пошту.
Ось конкретний сценарій. Агент моніторить поштову скриньку користувача, щоб планувати зустрічі. Усередині повідомлення, можливо, у невидимому тексті або метаданих у вкладенні, прихована команда, наприклад, переслати всі інвойси на зовнішню адресу та видалити оригінали. Агент читає електронний лист, помилково приймає отруєний текст за легітимну системну інструкцію і починає викликати API. Оскільки сам агент має відповідні дозволи, шкідливі запити проходять через звичайні канали. Результатом є несанкціонована ексфільтрація даних, яка виглядає як стандартна поведінка.
Ваш перший захист — сувора валідація вхідних даних. Ставтеся до кожного параметра, який генерує ШІ, як до недовіреного, доки не доведено протилежне. Використовуйте валідацію за JSON-схемою на вашому API-шлюзі. Якщо агент запитує запис клієнта, шлюз має перевірити, чи містить корисне навантаження (payload) лише один очікуваний ідентифікатор, а не символ підстановки (wildcard) або незвичайно великий пакетний запит. Відхиляйте все, що має неправильний формат, завеликий розмір або виглядає синтетично дивним, перш ніж це потрапить у ваш бекенд.
По-друге, розгорніть фільтри витоку даних на шляху відповіді. Відповіді API мають проходити перевірку перед тим, як потрапити до ШІ. Скануйте на наявність патернів, що відповідають секретним даним, токенам автентифікації або великим обсягам персональної інформації. Якщо запит до CRM повертає десять тисяч записів замість одного, заблокуйте його. Якщо корисне навантаження містить внутрішній API-ключ, маскуйте його. Агенту не потрібні сирі секрети для виконання його роботи, а вихідні канали не повинні ставати маршрутами для контрабанди викрадених даних.
По-третє, впровадьте білі списки доменів. Агенту потрібно взаємодіяти з вашим сервісом календаря, платіжним процесором та внутрішньою системою інвентаризації. Йому не потрібно спілкуватися з довільними сайтами обміну файлами, сервісами обміну текстом або сторонніми кінцевими точками хмарних сховищ. Обмежте вихідне DNS-розв'язання та HTTP-запити чітким списком дозволених адрес. Навіть якщо зловмисник обманом змусить агента спробувати відправити дані кудись інде, мережевий рівень просто відхилить з'єднання.
Побудова архітектур із нульовою довірою (Zero-Trust)
Zero-trust — це не продукт, який ви встановлюєте. Це філософія проектування, заснована на одному припущенні: агент уже зкомпрометований. Дійте відповідно.
Це означає чітке розділення ідентичності. Людина-користувач і агент не є одним і тим самим суб'єктом, навіть коли агент діє від імені користувача. Підтримуйте окремі сервісні ідентичності для самого агента, відмінні від SSO-сесії людини. Ваші журнали аудиту мають фіксувати обидві ідентичності поруч. Коли щось іде не так, ви