Technical Context
Омоглиф-атаки (homoglyph / homograph) — это класс уязвимостей, где злоумышленник подменяет символы в тексте на визуально похожие Unicode-символы из другого алфавита или диапазона. Человек и (что хуже) автономный агент на базе LLM часто воспринимают строку «как ту же самую», хотя байтово и семантически это разные токены/домены/команды. Классический пример: microsoft.com vs miсrosoft.com, где «c» может быть кириллической «с» (U+0441).
Почему это особенно опасно именно для agentic-систем (автономных агентов, tool-use, RPA+LLM): у них есть «руки» — доступ к браузеру, терминалу, Git, CRM, платежам, внутренним API. Если агент неверно распознаёт URL/команду, он способен сам перейти по ссылке, скачать бинарник, выполнить скрипт или отправить секреты на поддельный endpoint.
Техническая причина: расхождение визуального и машинного представления
- Unicode confusables: разные code point’ы выглядят одинаково (кириллица/латиница, математические символы, fullwidth-формы).
- Отсутствие строгой нормализации до токенизации: LLM видит другой набор токенов, а окружение (bash/браузер/URL-парсер) интерпретирует строку иначе, чем ожидал разработчик.
- Склейка с RAG/памятью агента: «скомпрометированный тред» или заметка в knowledge base может содержать подменённые ссылки/команды, которые агент позже воспроизводит как «проверенные».
- Провал naive-фильтров: простые регулярки «запретить кириллицу» не ловят 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.