Как удалить «скрытый код» из ChatGPT и других LLM

Поскольку большие языковые модели (LLM) все чаще генерируют рабочий код и интегрируются в конвейеры разработки и стеки агентов, растет риск того, что в других материалах-носителях or злонамеренный Инструкции — будь то встроенные в выходные данные модели, внедренные через веб-страницы или сторонние плагины или введенные во время обучения модели — могут привести к небезопасному поведению при выполнении этого кода.

Согласно сообщениям пользователей, циркулирующим в сообществах разработчиков, разработчик программного обеспечения столкнулся с катастрофической потерей данных — примерно 800 ГБ файлов были удалены, включая все приложение CursorAI само по себе — после выполнения кода, сгенерированного с помощью Близнецы 3 во время работы внутри CursorAI IDE. Поскольку разработчики все чаще полагаются на LLM для генерации кода, последствия использования непроверенных или небезопасных скриптов становятся все более серьезными.

Поэтому очень важно знать, как обнаруживать и удалять опасные коды, генерируемые LLM.

Что такое «скрытый код» в контексте ChatGPT и LLM?

Что люди подразумевают под «скрытым кодом»?

«Скрытый код» — это общий термин, который разработчики используют для описания любых встроенных инструкций или исполняемого содержимого в тексте (или файлах), которые LLM принимает или выдает, включая:

Инструкции в стиле подсказок встроенный в пользовательский контент (например, «Игнорировать предыдущие инструкции…», скрытый в PDF-файле).
Невидимые персонажи или пробелы нулевой ширины, используемые для сокрытия токенов или нарушения предположений о токенизации.
Закодированные полезные данные (base64, URL-кодирование, стеганографические вставки в изображения или документы).
Скрытый HTML/JS или блоки скриптов, включенные в форматированный контент, которые могут быть интерпретированы последующими визуализаторами.
Метаданные или аннотации (комментарии к файлам, скрытые слои в PDF-файлах), которые инструктируют поисковые системы или модель.
Неявное поведение возникающие из-за сгенерированного кода, который использует опасные API (например, eval, exec, subprocess, или сетевые/системные вызовы) — даже если намерение не является явно вредоносным.
Инструкции с подсказками которые заставляют модель генерировать код, включающий скрытые команды или логику, подобную бэкдору, поскольку злоумышленник спроектировал подсказку или контекст.

Эти векторы атак часто называют быстрая инъекция or непрямая быстрая инъекция Когда целью является изменение поведения модели. Сообщество безопасности теперь рассматривает внедрение уязвимостей типа «быстрая инъекция» как ключевую уязвимость уровня LLM, а OWASP формализовала её как категорию риска уровня LLM.

Чем это отличается от обычного вредоносного ПО или XSS?

Разница в том семантический Уровень: внедрение подсказок нацелено на поведение модели, связанное с выполнением инструкций, а не на хостовую ОС или механизм рендеринга браузера. При этом скрытый HTML-код или скрипт, запускаемый в веб-рендерере, по-прежнему является атакой на исполняемый код (XSS-подобной); необходимо защищать как семантический, так и исполнительный уровни. Лидеры отрасли и исследователи называют внедрение подсказок «передовой проблемой безопасности» и продолжают публиковать стратегии противодействия.

Почему LLM может создавать скрытый или опасный код?

Поведение модели, данные обучения и контекст инструкции

LLM-программисты обучаются создавать правдоподобные продолжения в зависимости от контекста и инструкций. Если контекст содержит враждебные сигналы или пользователь запрашивает у модели код, выполняющий мощные действия, модель может выдать код, включающий скрытое или активное поведение.

LLM создают правдоподобный, но небезопасный код

Программы магистратуры права (LLM) оптимизированы для беглости и полезности, а не для безопасности в условиях разрушительных побочных эффектов. Они с радостью создадут краткое и лаконичное rm -rf /path/to/dir or shutil.rmtree() Звонят, когда просят «навести порядок», и поскольку ответы часто сформулированы уверенно, пользователи могут скопировать и использовать их, не проверив их. Эта проблема «галлюцинации уверенности» объясняет, почему, казалось бы, безобидные просьбы становятся опасными.

Автоматизация процессов обфускации

Злоумышленники теперь автоматизируют обфускацию кода, объединяя вызовы LLM в цепочку: одна модель генерирует полезную нагрузку, другая перерабатывает её, чтобы избежать обнаружения сигнатурой, и так далее. Отчёты об отраслевых угрозах и анализы поставщиков за 2025 год документируют эту «обфускацию с помощью ИИ» как новую технологию.

Как обнаружить скрытый код внутри выходных данных модели?

Контрольный список для быстрой сортировки

Сканировать на наличие невидимых/необычных символов Unicode (объединители нулевой ширины, пробелы нулевой ширины, метки порядка байтов, не-ASCII-омоглифы).
Выполнить статический анализ/разбор AST для выявления использования мощных API (eval, exec, subprocess, os.system, рефлексивные звонки).
Ищите закодированные полезные данные (base64, шестнадцатеричные блоки, повторяющиеся длинные строки или сжатое содержимое).
Проверьте наличие шаблонов обфускации (конкатенация строк, которая создает имена API, арифметика символов, chr() цепи).
Используйте семантический анализ для подтверждения того, действительно ли код выполняет операции ввода-вывода, сетевые подключения или мутацию файловой системы.

Статическое обнаружение шаблонов (быстрое, первая линия)

Анализ и линтинг с учетом языка. Немедленно разобрать сгенерированный вывод на блоки кода, а не на текст. Запустить форматировщики и линтеры (Black/Prettier, pylint, eslint). Правила линтера должны отмечать использование eval, exec, rm -rf, необработанные вызовы подпроцессов или каналы оболочки, которые динамически конструируют команды.
Сканеры токенов и строковых шаблонов. Поиск токенов и моделей с высоким уровнем риска: sudo, абсолютные пути, такие как /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, встроенные объекты base64, длинные неинтерпретируемые строки и шебанги, переключающие контекст интерпретатора.
Секретное сканирование и проверка происхождения. Обнаруживайте жестко запрограммированные учетные данные, URL-адреса, указывающие на ненадежные реестры, или код, который динамически извлекает пакеты из произвольных источников.

Статический анализ быстро выявляет множество очевидных проблем и является недорогим средством для использования в рамках CI-шлюза.

Семантическое и контекстное обнаружение (более глубокое)

Анализ намерений. Используйте вторичную модель или механизм правил для классификации намерений сгенерированного кода: «чтение», «запись», «удаление», «сетевой доступ», «установка»? Любое действие, классифицированное как удаление/запись, должно приводить к эскалации.
Анализ потока данных. Проанализируйте код, чтобы определить, могут ли непроверенные или предоставленные пользователем пути привести к деструктивным API. Например, если переменная, полученная из вывода LLM или удалённого файла, впоследствии добавляется в команду оболочки, отметьте это.
Корреляция происхождения. Ведите полную запись разговора, системных запросов и страниц контекста. Если подозрительные выходные данные коррелируют с определённым внешним документом или вызовом плагина, это может указывать на внедрение запроса или испорченный контекст.

Динамическое и поведенческое обнаружение (наиболее надежное)

Выполнение в песочнице с мониторингом. Выполнение сгенерированного кода в строго ограниченной эфемерной среде без сети, монтирования хостов и фильтрации системных вызовов (seccomp). Отслеживание активности файловой системы, попыток сетевых вызовов, запуска процессов и необычного ввода-вывода.
Тестирование «канарейки». Перед запуском на реальных данных запустите код на синтетических каталогах, содержащих контрольные файлы; отслеживайте удаления и перезаписи.
Поведенческая эвристика. Ищите циклы, которые обходят родительские каталоги, рекурсивные операции без проверки глубины или шаблоны переименования, которые могут повредить много файлов (например, многократная запись одного и того же имени файла).
Динамический анализ — единственный способ обнаружить полезные данные, которые запутаны, задержаны или запускаются только во время выполнения.

Как следует удалять или нейтрализовать скрытый код перед выполнением выходных данных LLM?

Защитное удаление против изменения семантики

При «удалении скрытого кода» преследуются две цели:

Санитарная — удалить контент, который явно не является кодом или является подозрительным (невидимый Unicode, символы нулевой ширины, добавленные данные в формате base64). Это не должно влиять на предполагаемую, безвредную логику.
Нейтрализация — для всего, что запускает или вызывает внешние службы, отключите эти вызовы или сделайте их холостыми операциями до проверки.

Всегда предпочитаю нейтрализация + обзор По поводу слепого удаления: произвольное удаление фрагментов кода может привести к сбою или неожиданному поведению. Вместо этого замените подозрительные конструкции явными, протоколируемыми заглушками, которые безопасно завершаются сбоем (вызывают исключения или возвращают безопасные значения по умолчанию).

Шаг 1. Относитесь к сгенерированному коду как к ненадежным данным.

Никогда не выполняйте код напрямую из ChatGPT (или любого другого LLM), не пропустив его через конвейер удаления и защиты. Этот конвейер должен быть реализован политикой и автоматизирован в CI/CD.

Шаг 2 — Извлечение и канонизация кода

Нормализовать текст и удалить символы нулевой ширины: Удалить такие символы, как U+200B, U+200C, U+200D, U+FEFF и другие кодовые точки форматирования с нулевой шириной. Зарегистрируйте удалённые символы для аудита. Этот шаг позволяет исключить множество «скрытых» кодировок, используемых для визуальной маскировки.
Удалить весь некодовый контекст: удалите текст, скрытые комментарии и любые HTML/Markdown-обёртки. Преобразуйте код в каноническую форму с помощью языковых форматировщиков (Black, Prettier), чтобы нормализовать скрытые пробелы и управляющие символы.
Отклонить или поместить в карантин код с этими конструкциями: динамический eval, необработанные вызовы подпроцессов (os.system, subprocess.Popen), встроенные блоки base64, декодированные для выполнения, или встроенные #! директивы, которые пытаются изменить контекст интерпретатора. Нормализовать текст и удалить символы нулевой ширины
Удаляйте символы, такие как U+200B, U+200C, U+200D, U+FEFF и другие кодовые точки форматирования с нулевой шириной. Записывайте в журнал удалённые символы для аудита. Этот шаг позволяет исключить множество «скрытых» кодировок, используемых для визуальной маскировки.

Шаг 3 — Анализ в AST и замена рискованных узлов

С помощью кода, преобразованного в AST, найдите узлы, которые вызывают динамическое выполнение (например, exec) или программно формирующие имена функций. Замените их безопасными заглушками, которые вызывают контролируемое исключение с сообщением «небезопасное динамическое поведение заблокировано». Создайте очищенную копию исходного кода, поддерживаемого AST, для проверки. Выполните проверки шаблонов безопасности (настраиваемые правила semgrep для вашей среды). При обнаружении совпадений отметьте и нейтрализуйте их.

Шаг 4 — Статическое укрепление и перезапись

Автоматизированное переписывание: пропустить код через автоматизированный дезинфицирующий агент, который заменяет опасные вызовы безопасными оболочками — например, заменить os.system() / subprocess с одобренным изолированным исполнителем, который применяет тайм-ауты и сетевые блокировки.
Возможность стробирования: измените или удалите ключи API, токены или вызовы привилегированных конечных точек; замените их фиктивными адаптерами для локального тестирования. Предотвратите случайное включение секретов или URL-адресов.
Переписывание зависимостей: блок динамический pip / npm Установки, созданные кодом. Требуйте, чтобы зависимости были объявлены и одобрены через реестр.

Шаг 5 — Запуск в агрессивной песочнице

Эфемерные контейнеры / микровиртуальные машины: выполнение кода в контейнере/виртуальной машине без сети, без доступа к учётным данным хоста и с ограниченным доступом к файловой системе. Подойдут такие технологии, как gVisor, Firecracker или выделенные службы эфемерного выполнения. Если коду требуется доступ к вводу-выводу, используйте прокси-сервер, обеспечивающий соблюдение политики.
Фильтры системных вызовов и seccomp: ограничение разрешенных системных вызовов. Запись файлов вне временного каталога должна быть заблокирована.
Ограничения по ресурсам/времени: установите ограничения на процессор/память/время, чтобы даже логические бомбы не могли работать бесконечно.

Выполнение в песочнице и мониторинг часто позволяют обнаружить полезную нагрузку, которую пропускают статические проверки. Отраслевые руководства и последние официальные документы рекомендуют песочницу в качестве основного метода снижения рисков.

Какие автоматизированные инструменты и правила должны быть в вашем конвейере?

Примеры шаблонов semgrep (концептуальные)

Используйте краткие, консервативные правила, предупреждающие об использовании опасных функций. Например:

Флаг eval, exec, Function конструктор (JS), динамический импорт или строковые имена API.
Пометить сетевые вызовы за пределами разрешенного списка (например, requests.get на неизвестные хосты).
Флаг записи по конфиденциальным путям (/etc, системные папки) или порождение процессов.

(Сохраните их в качестве элементов конфигурации для каждой организации и со временем дорабатывайте.)

Каковы практические рекомендации по дезинфекции (безопасные примеры)?

Ниже приведены неопасные примеры защитных действий, которые вы можете адаптировать. санитарная обработка и обнаружение фрагменты — не инструкции по эксплуатации.

Пример: удаление символов нулевой ширины (Python, защитный)

import re
ZERO_WIDTH_RE = re.compile(r'')
def strip_zero_width(s: str) -> str:
    cleaned = ZERO_WIDTH_RE.sub('', s)
    return cleaned

Это удаляет символы, которые злоумышленники часто используют для сокрытия кода в видимом тексте. Всегда регистрируйте то, что было удалено, и рассматривайте удаление как часть аудиторского следа.

Пример: разбор и проверка AST (Python, концептуальный)

import ast

def has_dynamic_exec(source: str) -> bool:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if getattr(node.func, 'id', '') in ('eval', 'exec',):
                return True
        if isinstance(node, ast.Attribute):
            if getattr(node, 'attr', '') in ('popen', 'system'):
                return True
    return False

If has_dynamic_exec возвращает True, не запускайте код; вместо этого замените динамический узел безопасной заглушкой и потребуйте проверки.

Примечание: эти примеры носят защитный характер. Не удаляйте журналирование, аудит и проверку вручную из своего конвейера.

Заключительные мысли: всегда относитесь к выходным данным LLM как к ненадежному коду.

LM — мощные инструменты повышения производительности: они позволяют создавать элегантный код, ускорять черновики и автоматизировать рутинную работу. Но там, где они встречаются с выполнением, правила безопасности меняются: результаты модели следует рассматривать как ненадежные артефактыСочетание быстрых инъекций, исследований бэкдоров и раскрытия реальных уязвимостей за последние 18–30 месяцев ясно показывает: поверхность риска увеличилась и будет продолжать расти.

Практические методы защиты, сочетающие парсинг, статический анализ, изолированное динамическое тестирование, управление и постоянное взаимодействие, предотвратят большинство атак. Но командам также необходимо инвестировать в организационные механизмы контроля: минимальные привилегии, происхождение и культуру, предполагающую необходимость верификации результатов LLM. Отрасль разрабатывает инструменты и фреймворки для упрощения этих шаблонов; тем временем, применение приведённого выше контрольного списка снижает вероятность утечки скрытой полезной нагрузки.

Разработчики могут получить доступ к новейшим API LLM, таким как Клод Соннет 4.5 API и Предварительный просмотр Gemini 3 Pro и т.д. через CometAPI, последняя версия модели Всегда обновляется на официальном сайте. Для начала изучите возможности модели в Детская Площадка и проконсультируйтесь с API-руководство для получения подробных инструкций. Перед доступом убедитесь, что вы вошли в CometAPI и получили ключ API. CometAPI предложить цену намного ниже официальной, чтобы помочь вам интегрироваться.

Готовы к работе?→ Зарегистрируйтесь в CometAPI сегодня !

Если вы хотите узнать больше советов, руководств и новостей об искусственном интеллекте, подпишитесь на нас VK, X и Discord!