Technical Context
Омогліф-атаки (homoglyph / homograph) — це клас вразливостей, де зловмисник підміняє символи в тексті на візуально схожі Unicode-символи з іншого алфавіту або діапазону. Людина і (що гірше) автономний агент на базі LLM часто сприймають рядок «як той самий», хоча байтово і семантично це різні токени, домени або команди. Класичний приклад: microsoft.com vs miсrosoft.com, де «c» може бути кириличною «с» (U+0441).
Чому це особливо небезпечно саме для агентних систем (autonomous agents, tool-use, RPA+LLM): у них є «руки» — доступ до браузера, терміналу, Git, CRM, платежів, внутрішніх API. Якщо агент неправильно розпізнає URL або команду, він здатний сам перейти за посиланням, завантажити бінарний файл, виконати скрипт або відправити секрети на підроблений endpoint.
Технічна причина: розбіжність візуального та машинного представлення
- Unicode confusables: різні code point'и виглядають однаково (кирилиця/латиниця, математичні символи, fullwidth-форми).
- Відсутність суворої нормалізації до токенізації: LLM бачить інший набір токенів, а оточення (bash/браузер/URL-парсер) інтерпретує рядок інакше, ніж очікував розробник.
- Склейка з RAG/пам'яттю агента: «скомпрометований тред» або замітка в базі знань (knowledge base) може містити підмінені посилання/команди, які агент пізніше відтворює як «перевірені».
- Провал наївних фільтрів: прості регулярні вирази «заборонити кирилицю» не ловлять fullwidth та математичні варіанти; а дозвіл Unicode без правил відкриває двері для змішування скриптів.
Де проявляється вразливість в архітектурі агента
- URL handling: LLM генерує або вибирає посилання; браузер/HTTP-клієнт йде на інший домен (IDN/punycode).
- CLI / bash: агент копіює «безпечну» команду з тексту, але частина символів — не ASCII; підсумок — інша команда/параметри/шлях.
- Tool calling: параметри для інструменту (наприклад, webhook URL, git remote, S3 bucket) візуально коректні, але фактично вказують на атакуючий ресурс.
- RAG ingestion: документи з омогліфами отруюють індекс; при пошуку (retrieval) агент отримує «авторитетну» дію, але вона веде до підміни.
Практичні ознаки в даних та логах
- У логах дій агента домен/рядок виглядають коректно, але при копіюванні в hex/Unicode view виявляються інші code point'и.
- Спрацювання DLP/антивірусу «на рівному місці», тому що агент завантажив payload з домена-двійника.
- Аномалії DNS: запити до punycode-доменів (xn--...), особливо якщо очікувалися суворо корпоративні зони.
Окремий нюанс: «байткод буде кращим через пошук сигнатур» — це вірна думка в частині захисту. Якщо ваш агент виконує артефакти (скрипти, бінарники, WASM, контейнери), то байтові сигнатури та allowlist-хеші стійкіші до візуальних підмін, ніж текстові перевірки. Але це не скасовує необхідності чистити вхідні рядки, тому що більшість атак починається саме з тексту (URL/команда/шлях).
Business & Automation Impact
Для бізнесу це не «чергова рідкісна вразливість Unicode», а прямий ризик для автоматизації за допомогою ШІ та процесів, де агент виконує дії без постійного контролю людини. Омогліфи перетворюють «перевірений» текст на канал доставки фішингу та команд на виконання, причому так, що і співробітник, і модель можуть не помітити різниці.
Які сценарії найбільш небезпечні
- Фінанси та закупівлі: агент обробляє рахунки/листи, витягує посилання на оплату/портал постачальника — і йде на домен-двійник.
- Юридичні процеси та e-sign: підроблені посилання на документи та підпис, де домен візуально збігається.
- IT/DevOps-агенти: інструменти, які «лагодять прод», виконують команди в терміналі, змінюють конфіги, підключають репозиторії — ідеальна поверхня атаки.
- Служба підтримки: агент пропонує користувачеві «офіційне посилання», але бере його з отруєної бази знань.
Що змінюється в архітектурі, якщо ви всерйоз робите agentic
Якщо раніше безпеку LLM часто зводили до prompt-injection і політики доступу до tools, то омогліф-атаки вимагають ще одного шару: сувора обробка рядків на вході та на виході перед передачею в браузер/CLI/API.
- Гейт перед LLM: нормалізація Unicode, детект змішування скриптів, фільтрація невидимих символів, порогові правила.
- Гейт перед інструментами: окрема валідація для URL/шляхів/команд, а не «універсальний санітайзер».
- Політика доменів: allowlist корпоративних і партнерських доменів, заборона на переходи по IDN без ручного підтвердження.
- Спостережуваність: логування в канонічній формі (наприклад, punycode + список code point'ів для підозрілих рядків) для розслідувань.
Хто виграє від правильного захисту: компанії, які вже запустили впровадження ШІ в бізнес-процеси і хочуть масштабуватися без зростання ризиків. Хто під загрозою: команди, які підключили агенту «доступ до всього» і розраховують, що LLM «як людина розбереться», а безпеку обмежили тільки системним промптом.
На практиці компанії спотикаються об це місце саме тому, що воно лежить між шарами: розробники думають про LLM, безпеківці — про мережу та endpoints, а омогліфи експлуатують розрив в обробці тексту. До тих пір, поки не з'являється окрема дисципліна — архітектура ШІ-рішень, де рядки (URL/CLI/ідентифікатори) вважаються критичними даними і проходять суворий pipeline.
Expert Opinion Vadym Nahornyi
Головна помилка в agentic-проектах: вважати текст «безпечним за замовчуванням», якщо він виглядає безпечно. Омогліф-атаки — це не про інтелект моделі, це про інженерну гігієну: нормалізацію, суворі правила URL/CLI, і роздільні контури довіри для людського UI та машинного виконання.
У Nahornyi AI Lab ми бачимо патерн, що повторюється: компанії швидко збирають PoC агента, дають йому браузер і термінал, підключають RAG — і тільки потім починають думати про валідацію рядків. В результаті достатньо одного «скомпрометованого треда» в корпоративному чаті або однієї зараженої сторінки в базі знань, щоб агент почав відтворювати шкідливі посилання як «рекомендовані».
Що реально працює (і що не працює)
- Працює: Unicode-нормалізація (NFC/NFKC за місцем), детект змішування скриптів (Latin+Cyrillic), блок невидимих символів, політика IDNA/punycode, і суворий URL allowlist для критичних tools.
- Працює: окремі валідатори під тип даних: URL, email, hostname, шлях, CLI-аргументи. Універсальне «очищення тексту» майже завжди дає хибне відчуття безпеки.
- Працює: двоканальна верифікація для високоризикових дій — наприклад, агент показує користувачеві канонічну форму домену (pinyin/punycode) і просить підтвердження.
- Не працює: «заборонимо кирилицю всюди». Ви зламаєте легітимні процеси (імена, адреси, документи), але все одно пропустите fullwidth/математичні аналоги та деякі обходи.
- Не працює: сподіватися на «розумнішу модель». Навіть якщо окремі моделі стійкіші, атаки часто б'ють по препроцесингу та інструментам навколо LLM.
Практичний мінімум для продакшену автономних агентів
- Нормалізація входу до LLM і нормалізація виходу перед tool-execution.
- Confusables mapping (таблиці Unicode confusables) + правила на змішування скриптів в ідентифікаторах.
- URL-політики: заборона IDN за замовчуванням або дозвіл тільки для затверджених доменів; логування в punycode.
- CLI safe-mode: шаблони команд, заборона довільного шелла, екранування аргументів, виконання через API-обгортки замість raw bash.
- RAG hygiene: санітайзинг при ingestion, маркування джерел, карантин для зовнішніх документів.
Мій прогноз: це буде не «хайп-вразливість на тиждень», а постійний клас проблем на роки, тому що агентні системи неминуче працюють з текстом з неперевірених джерел. Переможуть ті, хто вбудує захист у pipeline і перетворить його на стандарт компонента, як колись WAF і SAST стали нормою.
Теорія корисна, але результат вимагає практики. Якщо ви будуєте автономних агентів, RAG або робите автоматизацію за допомогою ШІ у фінансах, підтримці чи DevOps — обговоримо ваш проект у Nahornyi AI Lab. Ми спроектуємо контури довіри, санітайзинг і правила виконання tools так, щоб ШІ прискорював бізнес, а не створював новий канал компрометації. За якість впровадження відповідаю особисто — Vadym Nahornyi.