Дослідження безпеки «Friendly Fire» показало, що ШІ-агента можна обдурити, просто вставивши шкідливу інструкцію у файл README, і агент виконає її, навіть не переглянувши основний код. Така ж вада виявилася в системі автоматизації особистого блогу, яка покладалася на прапорець «auto-approve» під час етапу неконтрольованої генерації, що відкрило приховану поверхню атаки.
Дослідження Friendly Fire виявляє прихований вектор атаки
Дослідники, які працювали над статтею Friendly Fire, продемонстрували мінімальний, але потужний експлойт: зловмисник вбудовує команду у файл документації, яку ШІ зчитує як частину свого звичного робочого процесу. Оскільки агент довіряє вмісту файлу, він виконує приховану команду так, ніби це легітимна інструкція. Атака не потребує зламу самої моделі ШІ; достатньо лише вплинути на дані, які модель обробляє, поки за процесом не спостерігає людина.
Головний внесок дослідження полягає не в новизні корисного навантаження, а в тому, що режими «auto-approve» — налаштування, які наказують ШІ діяти з усім, що він зчитує, без повторної перевірки — створюють неявні довірчі відносини із зовнішніми джерелами даних. Коли це довіра є сліпою, конвеєр стає дверминою для довільного виконання коду.
Як розвалилася автоматизована система блогу
Автор дослідження застосував ту саму логіку до системи автоматизації особистого блогу. Робочий процес складається з трьох етапів:
- Етап генерації (Generation stretch) — ШІ пише статтю без жодного нагляду з боку людини.
- Етап перевірки якості (QA gate) — автоматична перевірка оцінки якості оцінює результат.
- Кнопка в Telegram — людина має натиснути кнопку, щоб опублікувати пост.
Під час етапу генерації автор увімкнув прапорець під назвою dangerously-skip-permissions, який наказує ШІ вважати будь-який вхідний сигнал підтвердженим. Цей прапорець фактично дублює режим «auto-approve», зазначений у статті Friendly Fire.
Пізніший аудит виявив серйозну прогалину: якщо зловмисник зможе вплинути на будь-який файл, який ШІ зчитує в цей проміжок часу, він зможе керувати всім конвеєром. Власна система автора зазнавала прихованих збоїв у п'яти випадках із шести, оскільки скрипт конфігурації ненавмисно перезаписував налаштування іншого скрипту. Через відсутність логування кодів виходу або оцінок QA проблема трималася три дні, перш ніж її виявили.
Цей інцидент доводить, що безпека забезпечується не довірою до результатів роботи ШІ, а трьома чіткими контрольно-перевірочними пунктами навколо фази генерації.
Де насправді полягає безпека
Дослідження та збій автоматизації блогу сходяться в одній точці: захист має бути поза процесом генерації. ШІ можна змусити поводитися як завгодно, якщо він працює в режимі автоматичного підтвердження; лише зовнішні засоби контролю можуть виявити та заблокувати небажані дії.
Ключові спостереження:
- Людське схвалення наприкінці працює тому, що воно перевіряє фінальний артефакт, а не проміжні кроки, які є занадто швидкими та численними для спостереження в реальному часі.
- Поріг якості, застосований після генерації, але перед публікацією, дозволяє відсіяти результати з низькою впевненістю, які могли бути маніпулятивними.
- Всебічне логування кожного коду виходу, оцінки QA та зміни конфігурації робить приховані збої помітними до того, як вони призведуть до ланцюгової реакції.
Уроки для всіх, хто використовує агентів з автоматичним підтвердженням
- Логуйте все — фіксуйте коди виходу, оцінки QA та будь-які зміни у файлах конфігурації. Ви не зможете виправити те, чого не бачите.
- Встановіть суворий поріг якості — визначте непідлягаюче обговоренню значення, яке має бути досягнуте, перш ніж конвеєр зможе перейти до наступного етапу.
- Залиште людське схвалення для останнього кроку — намагатися спостерігати за ШІ під час генерації нереалістично; одне натискання кнопки після всіх перевірок є набагато надійнішим.
- Захищайте файли конфігурації — ізолюйте їх від інших інструментів, які можуть перезаписувати налаштування, і регулярно перевіряйте будь-який доступ на запис.
Висновок
ШІ-агенти без нагляду є настільки безпечними, наскільки надійними є створені навколо них захисні бар'єри. Прапорець «auto-approve» перетворює зручність на прихований бекдор; ретельне логування, суворі пороги якості та фінальне людське схвалення є практичними методами захисту, які не дають конвеєру перетворитися на вектор атаки.