Захист автономних агентів електронної пошти від невидимих Prompt Injection
Malwarebytes попереджає, що автономні ШІ-асистенти виконують приховані інструкції у фішингових листах, які непомітні для людей. Розробникам слід очищати вхідні дані та вимагати схвалення людиною критичних дій.
Чому це важливо
Необхідно додати санітизацію тексту та підтвердження людиною для інструментів агента, перш ніж надавати LLM доступ до електронної пошти чи фінансових дій.
TL;DR
- 01LLM принципово не розрізняють пасивні вхідні дані та керівні системні директиви.
- 02Шари попередньої обробки мають видаляти приховану розмітку до надсилання тексту в контекст.
- 03Критичні операції з фінансами та обліковими записами вимагають обов'язкового підтвердження людиною.
Ключові факти
- Вектор атаки
- Приховані prompt injection у вмісті вхідних електронних листів
- Операції високого ризику
- Здійснення платежів та зміна банківських реквізитів контрагентів
Вразливість парсерів у робочих процесах агентів
Автономні асистенти, що працюють з поштою, стикаються з уразливістю до prompt injection. Як зазначає Malwarebytes, моделі не вміють розрізняти дані для читання та інструкції для виконання. Зловмисники вбудовують команди так, щоб вони залишалися непомітними для людини, але успішно зчитувалися токенізатором під час завантаження в контекст.
Очищення вхідних даних перед передачею в модель
Покладатися на уважність користувачів марно, оскільки шкідливі інструкції приховують технічними методами. Розробник ShipItClean Аполло Рейнс наголошує, що головний захист полягає в попередній обробці: розробники зобов'язані вирізати прихований контент до потрапляння в контекст моделі. Кожен новий метод кодування створює потенційну шпарину в захисті агента.
Обов'язкове залучення людини до критичних операцій
Повну автономію необхідно обмежити для операцій, що змінюють стан системи. Архітектура повинна мати чіткі межі дозволів. Для дій із високим рівнем впливу — проведення платежів або зміни платіжних реквізитів контрагентів — інструменти повинні блокувати автономний виклик і вимагати обов'язкового підтвердження оператором.
✓ Коли використовувати
- Використовуйте під час проектування пайплайнів обробки вхідної пошти, маршрутизації тікетів підтримки та сортування листів.
- Використовуйте під час аудиту прав доступу інструментів у серверах Model Context Protocol для корпоративних агентів.
✕ Коли НЕ варто
- Не дозволяйте поштовим агентам автономно проводити банківські перекази чи змінювати рахунки постачальників.
- Не передавайте необроблений HTML листів безпосередньо в контекстний буфер моделі.
Що зробити сьогодні
- Впровадьте фільтр санітизації HTML для вхідних листів, щоб вирізати приховані стилі та невидимий текст перед формуванням контексту.
- Налаштуйте інструменти агента на обов'язковий прапорець схвалення оператором для транзакцій і зміни реквізитів.