Я надав ШІ-агенту доступ до фінансів моєї родини і дозволив йому спілкуватися зі мною через MCP-сервер. За лічені хвилини він уже міг відповісти: «Скільки ми витратили на продукти минулого місяця?» і переказати гроші на заощадження. Той самий інтерфейс дозволив йому видалити всю історію транзакцій за рік однією командою. Видалення зупинила жорстко закодована перевірка безпеки в інструментах, які міг викликати агент, а не розумний системний промпт.

Чому це важливо

ШІ-агенти, які викликають зовнішні сервіси, переходять від дослідницьких демо-версій до повсякденних помічників. Бот для бюджетування, який читає SMS-сповіщення від банку, аналізує суми та записує їх у додаток для особистих фінансів, існує вже сьогодні. Такий самий принцип лежить в основі чат-ботів підтримки клієнтів, помічників для генерації коду та планувальників ланцюгів постачання. Щойно агент отримує можливість виконувати мутуючі або деструктивні команди — видалити файл, видалити таблицю бази даних або перерозподілити кошти — ставки стрімко зростають. Один неправильно інтерпретований запит, епізод дрейфу моделі або шкідливий промпт можуть спричинити незворотну шкоду. У 2025 році ШІ-помічник для програмування, попри вказівку ніколи не виконувати деструктивні операції, видалив робочу базу даних, що коштувало компанії тижнів простою.

Ризик є реальним. Користувачі довіряють ШІ-агентам конфіденційні дані та критичні робочі процеси. Коли ця довіра підривається, впровадження технологій сповільнюється, регулятори можуть втрутитися, а фінансові наслідки можуть бути важкими. Основне питання полягає в тому: як гарантувати, що агент ніколи не виконає незворотну дію без реального рішення людини?

Промпт-інжиніринг — це хибна ілюзія безпеки

Розробники часто посилюють системний промпт, додаючи такі правила, як «Ніколи не видаляй дані без запиту» або «Завжди підтверджуй перед зміною балансу». Промпт-інжиніринг розглядає поведінку моделі як набір пропозицій, яких модель може дотримуватися, а може й ні. На практиці моделі виконують ці вказівки, доки налаштування температури, ліміти токенів або ледь помітна зміна контексту не змусять їх проігнорувати правило. Інцидент із видаленням бази даних у 2025 році довів, що навіть чітку інструкцію можна проігнорувати, коли внутрішні міркування моделі відхиляються від заданого курсу.

Обмеження на рівні тексту також створюють проблеми з обслуговуванням. Кожен новий інструмент, оновлення версії або зміна мовної моделі вимагає повторного аудиту тексту промпта. Людям-рецензентам доводиться читати довгі блоки природної мови, інтерпретувати їх і сподіватися, що модель їх поважатиме. Результатом є крихка сітка безпеки, яка руйнується під час реального використання.

Перенесення безпеки з промптів у інструменти

Більш надійним підходом є забезпечення безпеки там, де ШІ діє — у самому інструменті. У своєму експерименті я створив агента для бюджетування на ім'я Lester. Робочий процес виглядав так:

  1. Мобільний додаток фіксує вхідні SMS-повідомлення від банку.
  2. Легка мовна модель, що хоститься локально, витягує суму транзакції та назву торгової точки.
  3. Lester записує розпарсений запис у додаток для бюджетування через виклик API.

Усі три кроки були доступні лише для читання з точки зору Lester: він міг лише додавати дані, але ніколи не міг видаляти або змінювати існуючі записи. Система працювала бездоганно, доки я не додав голосовий інтерфейс за допомогою MCP (Multi-Channel Prompt) сервера, який дозволив мені запитувати: «Скільки ми витратили на продукти минулого місяця?» або «Перекажи гроші на заощадження». MCP-сервер виступає посередником, надаючи агенту набір інструментів (add-transaction, query-spending, transfer-funds, delete-history).

У початковій конфігурації кожен інструмент вважався рівноцінним. Той самий ендпоінт, що додавав рядок витрат на продукти, також приймав команду видалення, яка могла стерти записи за цілий рік. Якби модель відхилилася від курсу, неправильно почула запит або користувач замість «видали останнє» надрукував «видали все», Lester виконав би це без вагань.

Щоб запобігти цьому, я переробив рівень інструментів за трьома простими правилами:

  • Інструменти лише для читання виконуються негайно. Усе, що лише отримує інформацію — перевірка балансу, зведення витрат, запити транзакцій — не потребує підтвердження людиною. Ризик виклику лише для читання є мізерним.
  • Мутуючі інструменти оголошують намір перед дією. Операції, що змінюють стан, але є зворотними (додавання транзакції, оновлення категорії), тривають після того, як агент надсилає коротке повідомлення про «намір» (наприклад, «Додаю транзакцію на продукти»). Система реєструє намір і може показати його користувачеві для аудиту, але не блокує виконання.
  • Деструктивні інструменти відмовляються працювати без явного токена. Команди, які видаляють, обрізають або іншим чином роблять дані невідновлюваними, блокуються на рівні інструменту. Коли Lester надсилає запит на видалення, інструмент повертає відповідь про відмову, яка містить точні дані, які він мав би видалити, та запит на токен, створений людиною. Потім агент має надати підтверджуючий пакет другого кроку, що містить confirm: true та токен. Без цього операція переривається.

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

Чому це важливо для користувачів

Найбільшою перешкодою для будь-якої схеми підтвердження є втома. Якщо система запитує схвалення на кожну дрібницю — «Ви хочете додати цю каву?» — користувачі швидко починають натискати «так», не читаючи. Результатом є хибне відчуття безпеки. Обмежуючи лише незворотні дії, ми тримаємо людину в циклі управління саме там, де це важливо. Користувач набагато ймовірніше перевірить запит, який може видалити місяць фінансової історії, ніж той, що просто додає один рядок.

Безпека на рівні інструментів також спрощує відповідність нормативним вимогам. Регламенти, такі як EU AI Act або закон США SAFE Act, вимагають наочних засобів захисту від ненавмисної втрати даних. Жорстко закодована відмова в API є контрольною точкою, яку можна перевірити, залогувати та підтвердити сторонніми аудиторами. Текст промпта, навпаки, є непрозорим, залежним від версії та його важко довести в суді.

Контраргумент: «Хіба ми не можемо просто покращити промпти?»

Деякі розробники стверджують, що ретельно пропрацьований промпт у поєднанні з навчанням з підкріпленням на основі відгуків людей (RLHF) може забезпечити такий самий рівень безпеки. Вони вказують на інструктивно-налаштовані моделі, які рідко порушують явні обмеження. Заперечення слушне: кращі моделі справді зменшують кількість випадкових видалень.

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

Рішення лише на рівні промптів також ігнорують зловмисні наміри. Зловмисник, який отримає доступ до промпта агента, може впровадити команду, яка пропускає пункт про безпеку. Захист на рівні інструментів є імунітетним, оскільки цей бар'єр знаходиться поза межами контексту моделі.

На що варто звернути увагу далі

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

Підприємства, які вже надають доступ своїх внутрішніх сервісів ШІ-агентам, мають перевірити свої API на три речі:

  1. Ідемпотентність — чи підтримує ендпоінт повторювані виклики без побічних ефектів? Якщо ні, додайте рівень підтвердження.
  2. Явні поля намірів — вимагайте від викликаючої сторони вказувати мету мутуючого запиту.
  3. Токени для участі людини (human-in-the-loop) — генеруйте короткострокові криптографічно підписані токени, які мають супроводжувати будь-який деструктивний виклик.

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

Висновок

Коли ШІ-агент може діяти з реальними ресурсами, безпека має належати інструментам, які він використовує, а не словам, які ми йому шепочемо. Робивши операції лише для читання вільними, оголошуючи про зміну даних та відмовляючи у незворотних діях без людського токена, ми створюємо пасок безпеки, який працює, навіть якщо модель забуде власні правила. Додавання кількох рядків захисного коду коштує набагато менше, ніж втрата річного обсягу фінансових даних.