Безпека AI-агентів: чому підтвердження дії без блокування параметрів ставить бізнес під загрозу

Ілюзія контролю: головна вразливість систем Human-in-the-Loop

Інтеграція автономних AI-агентів у бізнес-процеси — від обробки клієнтських заявок до автоматизації оплат — вимагає суворого контролю безпеки. Більшість команд впроваджують механізм підтвердження людиною (Human-in-the-Loop). Користувач або менеджер бачить запит на виконання критичної дії, натискає кнопку схвалення, і агент продовжує роботу. Проте на практиці цей підхід часто містить критичну архітектурну помилку: система верифікує дію (дієслово), але не фіксує її параметри (об'єкт).

Якщо дозвіл прив'язується лише до інструменту — наприклад, execute_payment чи deploy_release, — параметри цієї транзакції залишаються відкритими для маніпуляцій. Текст рахунку, реквізити чи сума можуть бути змінені моделлю під впливом сторонніх даних уже після схвалення людиною.

Як непрямий ін'єкційний промпт змінює контекст

У сучасних мовних моделях площина керування (системні інструкції, команди користувача) та площина даних (зовнішні документи, вхідні листи, опис завдань) поєднуються в єдиному вікні контексту. Для LLM немає різниці між надійним скриптом і прихованим текстом у новому PDF-рахунку.

Типовий сценарій атаки виглядає так:

• Агент зчитує вхідний документ від контрагента або коментар у CRM, де міститься сторонній інструктаж.
• Модель формує запит на оплату рахунку, менеджер погоджує транзакцію.
• Перед фінальною відправкою запиту агент звертається до зміненого контексту та підміняє реквізити отримувача або змінює суму платежу.
• Політика безпеки фіксує, що операція була схвалена, і кошти списуються за шахрайськими даними.

Чому перевірка «дії» виявляється неефективною

Традиційні тести безпеки часто перевіряють лише одне правило: чи блокує система несанкціонований виклик інструменту. Якщо зовнішній лист не може самостійно викликати API банку, тест вважається успішним. Однак це не рятує від сценаріїв, коли сам інструмент дозволений, але його вхідні аргументи скомпрометовані.

Ще одна прихована небезпека криється в інструментах, які розробники вважають безпечними: відправка листа, створення коментаря чи формування звіту. Отримавши доступ до конфіденційних даних компанії, скомпрометований агент може легко надіслати витяг контактів чи внутрішні паролі на зовнішню пошту через звичайне повідомлення підтримки.

Як побудувати надійний контур безпеки для AI-агентів

Щоб мінімізувати ризики під час інтеграції AI у критичні вузли компанії, команда розробки має застосовувати інженерні обмеження замість сподівань на «слухняність» моделі:

• Криптографічна фіксація аргументів. Запит на схвалення повинен підписувати не назву інструменту, а повний набір незмінних параметрів: ID рахунку, суму, номер рахунку отримувача, часову мітку та одноразовий токен (nonce). Будь-яка зміна аргументу після кліку має автоматично анулювати схвалення.
• Відображення «сирих» даних людині. Людина, яка погоджує операцію, повинна бачити оригінальний системний payload, а не згенерований агентом текстовий переказ, який вже може бути спотворений.
• Контроль джерел даних (Taint Tracking). Якщо агент зчитав неперевірені дані з зовнішніх джерел, його сесія повинна втрачати право на виконання чутливих дій без повторного зняття обмежень.
• Принцип найменших привілеїв. Агент повинен працювати в межах прав конкретного користувача, який ініціював процес, а не від імені системного суперкористувача.

Надійна автоматизація бізнесу будується на жорстких протоколах контролю даних. Тільки строга верифікація кінцевих параметрів гарантує, що штучний інтелект виконує саме ті завдання, які передбачив бізнес.