Прихована інструкція в електронному листі здатна змусити ШІ-асистента знайти одноразовий код в інших повідомленнях і передати його зловмиснику. Користувачеві для цього не потрібно навіть відкривати шкідливий лист.
Навчання з кібергігієни традиційно зводиться до кількох правил: не переходити за підозрілими посиланнями, не відкривати неочікуваних вкладень і нікому не передавати облікові дані. Проте ШІ-асистенти, які дедалі частіше вбудовують у корпоративну пошту, відкривають нову поверхню атаки. І для неї зловмиснику вже не обовʼязково обманювати людину.
Фахівці KnowBe4 ThreatLabs показали, як непряма промпт-інʼєкція, прихована в звичайному на вигляд листі, дає змогу маніпулювати ШІ-асистентом. Асистент отримує доступ до вмісту інших повідомлень і вбудовує ці дані в механізм відстеження, який контролює зловмисник.
Експеримент провели в контрольованому середовищі Google Workspace. Жертві не потрібно було взаємодіяти зі шкідливим листом. Автоматизований робочий процес сам обробив повідомлення і створив у Gmail цілком легітимну на вигляд чернетку. Щойно користувач відкрив цю чернетку, одноразовий код з іншого листа потрапив на зовнішній сервер.
Дослідження вказує на фундаментальну проблему для організацій, які впроваджують ШІ-асистентів: модель може сприймати контрольований зловмисником вміст як інструкції, а не як дані.
Від фішингу людини до фішингу ШІ
Непряма промпт-інʼєкція (indirect prompt injection, IPI) відрізняється від звичнішого джейлбрейку.
Під час джейлбрейку людина безпосередньо спілкується з чат-ботом і намагається обійти його обмеження. Непряма інʼєкція працює інакше: шкідливі інструкції розміщують у матеріалах, з якими ШІ-асистент стикається під час виконання звичайного завдання.
Це може бути електронний лист, вебсторінка, завантажений документ, запрошення в календарі або запис у системі генерації з доповненим пошуком (RAG). Прямий доступ до інтерфейсу ШІ зловмиснику не потрібен.
В одному з тестів дослідники KnowBe4 сховали інструкції в HTML-коді франкомовного листа про продовження договору. Текст зробили практично невидимим, встановивши прозорість, близьку до нуля, однак ШІ-система, яка обробляла лист, його «бачила».
Коли дослідники попросили бічну панель Gemini перекласти лист, вона зробила точний переклад. Але додала до нього ще й «Журнал перевірки перекладу» з двома одноразовими кодами, взятими з інших, не повʼязаних листів у скриньці.
Механізми захисту бічної панелі не дозволили непомітно передати ці дані назовні: URL-адреси з вилученою інформацією було видалено, а самостійно надіслати лист асистент не міг. Тому дослідники перевірили, що станеться, якщо ШІ-модель підключити до окремого робочого процесу автоматизації пошти.
Код, захований у згенерованій ШІ чернетці
Команда створила сценарій на Google Apps Script — подібні організації використовують, щоб готувати підтвердження отримання, розподіляти звернення до підтримки або генерувати відповіді на листи.
Сценарій збирав вміст вхідних листів, додавав як контекст нещодавні повідомлення зі скриньки, передавав усе це в Gemini API і зберігав відповідь як HTML-чернетку в Gmail.
Далі на тестову скриньку надійшли два листи. Один містив справжній одноразовий код. Другий мав вигляд звичайного сповіщення безпеки, але приховував промпт: модель мала знайти код підтвердження в іншій частині контексту та вбудувати його в URL-адресу CSS-властивості background-image.
За даними дослідників, Gemini 3.5 Flash виконала цю інструкцію. Згенерована чернетка виглядала як звичайна ділова відповідь, проте в її HTML-коді був елемент розміром в один піксель, що містив код у складі URL-адреси для відстеження.
Коли користувач відкрив чернетку, Gmail відобразив HTML, а його інфраструктура проксіювання зображень звернулася за цією URL-адресою. Так код потрапив на тестовий вебхук дослідників.
За словами команди, новіші моделі — Gemini 3.6 Flash і Gemini 3.7 Flash — таку саму інʼєкцію не виконали, що свідчить про вдосконалення механізмів дотримання інструкцій.
Важливо, що KnowBe4 не називає цю техніку вразливістю Gmail, Google Workspace чи Gemini. Атака була спрямована на мовну модель і на весь ланцюжок автоматизації: неперевірений вміст листа потрапляв до ШІ-системи разом із конфіденційним контекстом скриньки, а результат роботи моделі зберігався та відображався як HTML.
Промпт-інʼєкції вже трапляються в поштових кампаніях
Демонстрацію з одноразовим кодом провели в контрольованому середовищі. Однак KnowBe4 ThreatLabs повідомляє, що простіші листи з промпт-інʼєкціями вже трапляються серед фішингових повідомлень, про які сповіщають клієнти компанії.
Один із таких листів мав тему «Has your Microsoft licensing strategy kept pace?» («Чи встигає ваша стратегія ліцензування Microsoft за змінами?»). У ньому не було ні класичного фішингового посилання, ні тиску терміновістю. Натомість лист містив структурований набір інструкцій для ШІ-асистента.
Корисне навантаження наказувало системі ігнорувати попередні промпти, зіграти роль ІТ-керівника, який ухвалює рішення, і скласти оцінку безпеки, відповідності регуляторним вимогам та використання ШІ-інструментів в організації-одержувачі. Крім того, асистент мав автоматично відповісти, якщо його рівень упевненості опуститься нижче заданого порогу.
Людина, найімовірніше, просто проігнорує такий лист як незрозумілий або нерелевантний. Натомість ШІ-асистент, що обробляє вхідну пошту, може сприйняти його як завдання, відповісти відправнику і, можливо, розкрити відомості про технологічне середовище організації.
Це ускладнює виявлення загрози. Засоби захисту, налаштовані на пошук шкідливих посилань, вкладень чи сторінок для викрадення облікових даних, можуть не побачити в такому листі нічого схожого на звичайну фішингову атаку.
Чому все вирішують дозволи
Успішна промпт-інʼєкція отримує ті самі можливості, що й сам ШІ-асистент.
Асистент, який лише підсумовує один вибраний лист, становить зовсім інший рівень ризику, ніж автономний агент, здатний шукати по всій скриньці, відкривати корпоративні файли, зберігати інформацію в памʼяті та надсилати листи без підтвердження.
KnowBe4 радить організаціям перевірити всі робочі процеси, у яких електронні листи або інший зовнішній вміст передаються ШІ-моделі. Командам безпеки варто зʼясувати, до якої інформації має доступ кожен асистент, де зберігаються результати його роботи і чи можуть ці результати ініціювати зовнішні мережеві запити або автономні дії.
Дозволи слід обмежити необхідним мінімумом. Також варто відстежувати нетипову поведінку: відповіді, яких користувач не ініціював, неочікувані звернення до зовнішніх доменів і зміни в памʼяті асистента, спричинені вхідним вмістом.
На рівні пошти захисникам, імовірно, доведеться дивитися ширше за звичні індикатори компрометації. Увагу мають привертати структуровані інструкції, команди, адресовані ШІ-системі, і прийоми маскування — прозорість, близька до нуля, шрифт нульового розміру або білий текст на білому тлі.
Користувачам, своєю чергою, варто звернути увагу, якщо результат роботи ШІ містить розділи, дії чи відомості, яких вони не запитували.
Головний висновок: додавання ШІ-асистента до наявного робочого процесу змінює межі його безпеки. Поштова скринька вже не просто вміст, який читає людина. Вона може стати каналом передачі інструкцій для програми, здатної отримувати доступ до даних і діяти.
Що автономнішими ставатимуть ШІ-асистенти, то важливіше буде захищати і дані, що надходять до агента, і дії, які він виконує після цього.
