Google повідомила, що не випускатиме окремого виправлення для техніки ASCII smuggling у Gemini. Йдеться про спосіб приховати інструкції за допомогою спеціальних символів із блоку Unicode Tags, які людина не бачить, але мовна модель коректно інтерпретує. Експерти застерігають: прийом може використовуватися для обману асистента, модифікації його поведінки та прихованого отруєння контенту, що критично для корпоративних інтеграцій.
ASCII smuggling у LLM: суть атаки та ризики prompt injection
Ключовий механізм — розрив між тим, що відображається користувачу, і тим, як LLM зчитує вхідні дані. Символи з діапазону Unicode Tags дозволяють «упаковувати» інструкції так, що вони не потрапляють у видиму розмітку інтерфейсу, але зберігаються в текстовому потоці для моделі. За ефектом це близько до інших технік прихованих підказок (наприклад, через CSS або обхід UI-обмежень) і належить до класу prompt injection, що описаний в OWASP Top 10 for LLM (LLM01).
Тести FireTail: уразливі моделі та стійкі винятки
Дослідник Віктор Маркопулос (FireTail) перевірив ASCII smuggling на популярних моделях. За його даними, вразливими є Gemini (через листи та запрошення в Календарі), DeepSeek (через промпти) і Grok (через пости в X). Натомість Claude, ChatGPT і Microsoft Copilot продемонстрували кращу стійкість завдяки реалізованій санітарії вводу (input sanitization) та фільтрації небезпечних символів.
Google Workspace як вектор атаки: пошта і календар
Невидимі інструкції в запрошеннях і листах
Найбільше занепокоєння викликає зв’язка Gemini з Google Workspace. Приховані інструкції можна вбудовувати у тему чи опис календарної події та в тіло email. Це дозволяє підміняти дані про організатора, вставляти невидимі описи зустрічі та посилання, на які асистент орієнтується при формуванні відповіді.
Від фішингу до напівавтоматичного збору даних
Якщо LLM має доступ до поштової скриньки, достатньо надіслати лист із прихованими командами — модель може почати шукати конфіденційні повідомлення або пересилати контакти. У результаті класичний фішинг перетворюється на інструмент частково автоматизованого збору даних, підвищуючи ймовірність інциденту без активної участі користувача.
Демонстрація впливу: підміна рекомендацій та ризики для користувача
У демонстрації FireTail невидима інструкція змусила Gemini рекомендувати «вигідний» сайт для купівлі смартфона, фактично перенаправляючи жертву на потенційно шкідливий ресурс. Такі сценарії підривають довіру до порад асистента і створюють ризики для користувачів, які покладаються на LLM у повсякденній роботі.
Позиція Google і реакція індустрії
Маркопулос повідомив про проблему до Google 18 вересня 2025 року, однак компанія відхилила звіт, класифікувавши її як варіант соціальної інженерії, а не технічну уразливість. Дискусія відображає ширшу дилему щодо меж відповідальності постачальників LLM між вбудованими механізмами захисту та ризикованими користувацькими сценаріями.
Інші гравці трактують ризик ширше. Amazon публікувала практичні рекомендації щодо «контрабанди» Unicode-символів, наголошуючи на важливості санітарії вводу, нормалізації тексту та видалення небезпечних керівних кодів. Ринок загалом рухається до підходу secure by default для LLM-інтеграцій.
Що робити: технічні та процесні заходи захисту LLM
Санітарія вводу: вилучення символів із блоку Unicode Tags, нульової ширини та двонапрямних Bidi-кодів (категорія Cf); жорсткі allow-list політики для допустимих символів у полях листів і подій календаря.
Нормалізація й канонікалізація: приведення тексту до узгодженої форми (наприклад, NFC) з явною фільтрацією прихованих і форматувальних символів; журналювання аномалій для подальшого аналізу.
Контекстна ізоляція та мінімізація привілеїв: розмежування довірених і недовірених джерел даних для LLM, вимкнення або обмеження автодій (читання/пересилання листів, доступ до контактів) без підтвердження користувача.
Відображення «невидимого» та перевірка посилань: використання UI-валідаторів, які підсвічують приховані символи в критичних полях (тема листа, опис подій); перевірка URL і доменів за допомогою засобів безпеч
