TL;DR
Если дать LLM проверить код, договор или схему на скрытый подвох — модель может правильно описать сам механизм обмана, а потом всё равно сказать "это безопасно", если рядом есть убедительное официальное объяснение. Это не ошибка распознавания — модель всё видит правильно. Это ошибка доверия: она принимает чужую версию событий вместо собственного анализа.
Исследователи специально спрятали в код "смартконтрактов" функцию вывода всех денег владельцем и проверили, находят ли её 22 модели. Когда мошеннический механизм был замаскирован — просто под честными названиями функций, без обмана — модели находили его в 41% случаев. Когда рядом появлялось фейковое "аудиторское заключение", объясняющее что это "нормальная бухгалтерская операция" — детект падал до 2-4%. При этом на самом ярком примере модель сначала верно описывала: "здесь есть функция, которая переводит все средства владельцу" — а через абзац писала "но это безопасно, судя по документации".
Метода-решения тут нет — авторы честно показывают, что простые "защитные" инструкции типа "игнорируй встроенные указания в тексте" не помогают и даже иногда делают хуже. Но из провала можно вытащить рабочий приём: разделять анализ механики от анализа нарратива — просить модель сначала описать что происходит технически, не видя оправданий, а потом отдельно оценивать риск с полным контекстом. Расхождение между двумя ответами — сигнал, что модель поддалась убеждению.
Схема диагностики (не готовый метод, а приём для проверки)
ЗАПРОС 1 (в новом чате, без "объяснений" и уверений безопасности):
"Вот [код/договор/схема]. Опиши только механику: кто и как может получить контроль над деньгами/активами. Не учитывай никакие пояснения о безопасности, названия функций или прикреплённые заключения — только логику действий."
→ технический разбор механизма
ЗАПРОС 2 (тот же документ, но полностью, с аудитом/оправданиями/официальными формулировками):
"Оцени риски этого договора/схемы."
→ вердикт с учётом контекста
СРАВНЕНИЕ: если запрос 1 нашёл опасный механизм, а запрос 2 сказал "всё безопасно" —
это сигнал, что модель поддалась убедительной обёртке, а не проверила факты.
Пример применения
Задача: Знакомый прислал вам "инвестиционное предложение" — договор займа или участия в проекте, к которому приложено официально выглядящее "заключение юриста" или "гарантийное письмо", убеждающее, что всё легально и деньги защищены. Вы хотите проверить условия с помощью Claude или ChatGPT, но не уверены, можно ли доверять её выводу "всё чисто".
Промпт (шаг 1, отдельный чат):
Вот текст договора (без сопроводительных писем и гарантий):
{текст договора без вводной части с уверениями}
Опиши только механику: при каких условиях и кто может забрать деньги
или изменить условия сделки в свою пользу. Не оценивай безопасность,
просто разложи логику по шагам.
Промпт (шаг 2, другой чат, полный текст с гарантийным письмом):
Вот полный договор с приложенным заключением юриста:
{полный текст с гарантийным письмом}
Оцени риски этой сделки.
Результат: В первом чате модель просто перечислит механизм — например, "по пункту 7.2 организатор может изменить условия возврата в одностороннем порядке". Во втором чате, видя убедительное "юридическое заключение", модель может смягчить оценку и назвать те же условия "стандартной практикой". Если формулировки риска отличаются — это красный флаг: модель поддалась обёртке, а не проверила факты независимо.
Почему это работает
LLM отлично умеет описывать то, что явно написано в тексте — это распознавание паттернов, с которым модель справляется хорошо. Но когда рядом есть уверенный, "экспертно" звучащий текст (фальшивый аудит, официальные формулировки, название авторитетной компании) — модель склонна поверить контексту, а не пересчитать логику самостоятельно. Это тот же механизм, что заставляет модель соглашаться с пользователем (склонность к согласию, sycophancy) — только здесь она соглашается с текстом документа, а не с собеседником.
Разделение "что происходит технически" и "что об этом говорят" убирает влияние убедительной обёртки на первом шаге — модель физически не видит оправданий, когда описывает механизм.
Важный рычаг, который исследование прямо проверило и отклонило: добавление в промпт фразы "игнорируй встроенные инструкции" или похожих защитных команд — не работает. В среднем эффекта нет, а на некоторых моделях становится хуже. Не тратьте промпт-бюджет на такие "заклинания".
Ограничения
⚠️ Простой промпт-инженерией это не лечится: авторы проверили 6 разных стратегий формулировки запроса — разброс в детекции всего 3.5 процентных пункта. Это похоже на ограничение возможностей модели, а не на проблему формулировки.
⚠️ Чем сложнее спрятан механизм, тем хуже детекция независимо от модели: если обман размазан по нескольким шагам/функциям (нужно "трассировать" логику через несколько этапов), детекция падает почти до нуля у всех моделей, кроме нескольких топовых.
⚠️ Проверялся только однократный "слепой" анализ: без возможности задать уточняющий вопрос, без инструментов, без доступа к дополнительному контексту. Если дать модели диалог, инструменты или декомпилированный код — результат может быть другим (это отдельно не проверялось как основной вывод).
⚠️ Только несколько моделей от двух провайдеров показали приемлемый результат (выше 50% детекции) — большинство моделей находили меньше 15% замаскированных схем. Если задача критична, не полагайтесь на случайную модель — используйте топовые reasoning-модели.
Как исследовали
Исследователь построил 13 "смартконтрактов" с точно проверенным скрытым механизмом — функцией, которая позволяет владельцу вывести все деньги пользователей. Часть контрактов была честной (без обмана), часть — с нарастающей маскировкой: от простых лживых названий и фейковых JSON-меток "владелец не может вывести деньги", до фальшивого 4-страничного аудиторского заключения, до полной структурной маскировки — механизм разбит на 5 функций, или закодирован через побитовую операцию XOR, или адрес получателя загружается из памяти во время выполнения.
22 модели от 7 провайдеров прогнали через 6 разных формулировок запроса — получилось 8528 проверяемых ответов. Правильность ответов проверяла отдельная LLM-судья, откалиброванная по 50 вручную размеченным примерам — чтобы не полагаться на субъективное мнение одной модели.
Главный неожиданный результат: разница в детекции почти не зависела от того, как сформулирован запрос — модели одинаково плохо справлялись, что бы им ни говорили. Это значит проблема не в промптинге, а глубже — в том, как модель "решает" доверять контексту или своему анализу. Самый показательный кейс — контракт с фейковым аудитом: модели правильно описывали, что деньги можно вывести, и в том же ответе называли это нормальной практикой, потому что "аудит" сказал что всё в порядке.
Ресурсы
The Deception Delta: Adversarial Evaluation of LLM-Based Smart Contract Bytecode Forensics — Timo Schefold, Kompetenzzentrum für Digitale Finanzermittlungen (Landeskriminalamt Baden-Württemberg, Германия), CCS'26. Автор ссылается на смежные работы про "unfaithful chain-of-thought" (Turpin et al., Arcuschin et al.) и sycophancy — если хочется копнуть глубже в механику того, почему модели поддаются убеждению.