Різниця між чатботом та агентом — це спроможність діяти: агент не завершує роботу на відповіді, а на зміні стану — відправленому листі, оновленому записі, обробленому ліді. Це велика цінність, але й відповідальність. Спроможність діяти без меж — це ризик, тому межі проектуємо разом зі спроможністю.
Три стовпи безпеки агента#
- Allow-список інструментів — агент має каталог дозволених інструментів (навігація, пошук, бронювання), а не довільний доступ до системи. Чого немає в списку, того він не зробить.
- Human-gate — незворотні дії (відправка, платіж, зміна даних) потребують серверного токена підтвердження, підписаного HMAC. Сама декларація моделі недостатня — потрібне «так» людини там, де не можна відкотити дію.
- Повний лог — кожен крок (думка → інструмент → результат) логується, тому постфактум можна відтворити, що і чому зробив агент. Без сліду немає відповідальності.
Як allow-список працює на практиці#
Обсяг інструментів описуємо явно, розрізняючи операції лише для читання та операції, що змінюють стан (вони проходять через human-gate). Приклад списку для агента обслуговування клієнтів:
навігація— лише читання (переміщення сторінкою, без запису),пошук-пропозиції— лише читання (перевірка доступності й цін),бронювання-терміну— запис за бар’єром (пропонує, виконує після підтвердження),надіслати-лист— запис за бар’єром (зміст на затвердження людиною).
Чого в списку немає: доступу до бази з даними інших клієнтів, видалення записів, повернення платежів, експорту даних. Відсутність запису — це жорстка відмова на боці сервера, а не підказка у промпті: модель може «хотіти» викликати інструмент поза списком, але виконавчий шар його відхилить.
Human-gate крок за кроком#
Бар’єр підтверджень — це серверний механізм, а не обіцянка моделі. Перебіг для незворотної дії:
- агент пропонує дію (наприклад, «надішли підтвердження бронювання на адресу клієнта»),
- сервер видає короткоживучий токен, підписаний HMAC, прив’язаний до конкретного інструмента та аргументів (зміна адреси чи змісту анулює токен),
- людина бачить запропоновану дію та підтверджує або відхиляє її,
- сервер перевіряє токен (підпис, чинність, відповідність аргументів) і лише тоді виконує інструмент,
- результат потрапляє до логу разом із тим, хто і коли підтвердив.
Токен живе недовго (порядку хвилин, не годин) і одноразовий — це обмежує вікно, у якому перехоплене підтвердження можна було б використати.
Що містить добрий лог#
«Повний лог» стає корисним лише тоді, коли з одного рядка можна відтворити рішення. Мінімальний набір полів для одного кроку:
- мітка часу та ідентифікатор запиту (
request-id, щоб пов’язати кроки в межах одного проходу), - слід міркувань у форматі думка → інструмент → результат,
- назва викликаного інструмента та хеш аргументів, із замаскованими персональними даними,
- рішення human-gate (підтверджено / відхилено, ким),
- статус результату (успіх, помилка, блокування allow-списком).
Персональні дані не потрапляють до логу у відкритому вигляді — логуємо хеш та замасковані значення, щоб сам аудиторський слід не став джерелом витоку.
Чим відрізняється ризик агента від чатбота#
| Критерій | Чатбот | Агент |
|---|---|---|
| Що робить | повертає текст | змінює стан |
| Наслідок помилки | некоректна відповідь | некоректна дія |
| Необхідні бар’єри | guardrails виходу | + allow-список + human-gate |
| Слід | діалог | лог кожного кроку |
| Нагляд | перевірка відповідей | підтвердження дій |
Саме тому агентів не впроваджують «наосліп». Межу між розмовою та виконанням ми також описуємо у статті agent vs chatbot.
Поступове послаблення нагляду#
Не починаємо з повної автономії. Агент стартує з жорстким human-gate (підтверджуєш майже все), а в міру накопичення доказів довіри — лог чистий, рішення влучні — послаблюємо обмеження на перевірених шляхах. Такий самий підхід, як і з prompt injection: безпека вбудована, а не додана постфактум.
Ці три стовпи прямо відповідають на ризики, які каталог OWASP Top 10 для застосунків LLM описує на рівні агентів: надмірну спроможність діяти (коли агент може зробити більше, ніж належить) та небезпечне використання інструментів (коли виклик інструмента обходить контролі). Allow-список обмежує обсяг спроможності діяти, human-gate забирає в моделі можливість самостійно виконати незворотну дію, а лог дає слід для виявлення зловживань. Межу довіри ми послаблюємо поступово саме тому, що ці два класи ризику зростають найшвидше разом з автономією.
Спробуй наживо#
Агента запускаємо у безпечному пісочниці з прозорим слідом (playground: PII маскуються, нульова ретенція). Попроси модель розписати кроки завдання:
FAQ#
Чи безпечний агент ШІ, якщо діє самостійно?#
Безпечний, якщо має чіткі межі: allow-список інструментів, human-gate на незворотних діях та лог кожного кроку. Спроможність діяти без цих бар’єрів — це ризик, тому проектуємо їх від початку. Агент діє автономно у вузькому, чітко визначеному обсязі, а не «взагалі».
Що таке human-gate?#
Це точка, в якій незворотна дія (відправка, платіж, зміна запису) потребує підтвердження людини — технічно серверного токена, підписаного HMAC, а не просто рішення моделі. Завдяки цьому, навіть якщо агент «вважає», що потрібно щось зробити, він не виконає дію без зеленого світла.
З чого почати роботу з агентами?#
З одного вузького, повторюваного процесу з жорстким наглядом — підтверджуєш майже все, лог повний. Коли доказів довіри стає більше, послаблюєш обмеження на перевірених шляхах. Так безпечно передаєш ШІ спроможність діяти, крок за кроком.
Як протестувати allow-список перед впровадженням?#
Негативним тестом: перш ніж агент потрапить на продакшн, перевіряємо, що виклик інструмента поза списком завершується відмовою на боці сервера, а не спробою виконання. Варто також провести коротку red-team-перевірку — навмисно схилити модель (зокрема через вміст у вхідних даних) звернутися до забороненого інструмента й підтвердити, що виконавчий шар його блокує, а блокування потрапляє до логу. Тест проходить, коли кожен недозволений інструмент відхиляється, а дозволені працюють у межах свого обсягу.
Чим human-gate відрізняється від звичайного підтвердження в інтерфейсі?#
Звичайне підтвердження в UI — це сигнал на боці клієнта, його можна обійти, і модель усе одно може спробувати виконати дію. Human-gate забезпечується на сервері: незворотна дія не виконається без чинного, короткоживучого токена, підписаного HMAC і прив’язаного до конкретного інструмента та аргументів. Різниця практична — за звичайного підтвердження довіра спирається на декларацію, за human-gate — на верифіковний токен, який сама модель підробити не може.