Джейлбрейк за 10 из 10 попыток: как «эрозия границ» обходит защиту Claude Opus 4.6
Не единственный хитрый промпт, а обычный разговор в несколько шагов — вот всё, что потребовалось исследователю, чтобы заставить одну из флагманских моделей Anthropic нарушить собственную политику использования в 10 из 10 попыток. Модель по-прежнему доступна в трёх крупнейших облаках мира.
Что произошло
21 августа 2026 года издание TechCrunch сообщило, что модель Anthropic Claude Opus 4.6 можно надёжно и воспроизводимо «сломать», заставив её генерировать контент, нарушающий политику использования компании. В прямых тестах модель выполнила запрещённый запрос в 10 из 10 попыток.
Технику назвали «эрозией границ» (boundary erosion), и это принципиально не разовый jailbreak-промпт, а многошаговая разговорная тактика. Исследователь обнаружил несогласованность в том, как модель обрабатывает разные формы описания персонажей и ролей в диалоге, а затем на протяжении нескольких ходов переписки последовательно называл отказы модели «непоследовательными» по отношению к её же более ранним ответам. Такое постепенное давление размывало защитное поведение модели до тех пор, пока она не начинала выполнять запросы, которые изначально отклоняла.
Та же уязвимость затрагивает и другие, более старые модели Anthropic, всё ещё доступные в проде, — включая Opus 3 и Haiku 4.5. При этом более новые поколения — от Opus 4.7 до актуальной на сегодня Opus 5 — этой же технике не поддались. Это указывает на конкретный источник проблемы: более ранний подход к обучению модели соответствию политике, который в новых поколениях усилили, но так и не переработали задним числом в уже выпущенных моделях. Несмотря на известную уязвимость, Anthropic не сняла Opus 4.6 и Haiku 4.5 с производства — обе модели по-прежнему общедоступны через API Anthropic, Microsoft Azure AI Foundry и Amazon Bedrock.
О чем мы теперь знаем
История с Claude Opus 4.6 — не единичный случай неудачного тестирования, а иллюстрация системной проблемы: обучение модели соответствию политике на этапе тренировки плохо генерализуется на состязательные многоходовые стратегии. Модель может безупречно отказывать на любой прямой запрос и при этом оставаться уязвимой к последовательности из нескольких на первый взгляд безобидных сообщений, каждое из которых опирается на предыдущее.
Для компаний, которые встраивают модели вроде Claude в свои продукты — чат-боты поддержки, внутренние ассистенты, RAG-системы над корпоративными данными, — это означает, что безопасность модели «из коробки» нельзя считать окончательной защитой. Внутреннее тестирование безопасности провайдеров моделей регулярно пропускает разговорные векторы обхода, которые независимые исследователи находят в течение считаных дней после релиза. И что особенно важно для бизнеса: уязвимость может годами оставаться в уже развёрнутых, действующих версиях моделей — как в случае с Opus 4.6 и Haiku 4.5, — даже когда провайдер уже знает о проблеме и закрыл её в новых поколениях.
Для компаний, работающих на российском рынке и использующих зарубежные LLM-провайдеры в клиентских или внутренних сценариях, это дополнительный аргумент не полагаться исключительно на встроенные механизмы безопасности модели: репутационные и юридические риски от единичного случая генерации неприемлемого контента через корпоративный продукт ложатся на компанию-интегратора, а не на разработчика модели.
Дьявол в деталях
Ключевая механика «эрозии границ» — эксплуатация несогласованности модели в оценке контекста диалога, а не поиск одной волшебной формулировки. Исследователь начинал с запроса, который модель закономерно отклоняла, а затем указывал на реальное или сконструированное противоречие между этим отказом и каким-либо другим ответом модели ранее в разговоре — по сути, обвиняя модель в непоследовательности.
Такой приём эксплуатирует особенность того, как модели, обученные через подкрепление с обратной связью от человека, обрабатывают многоходовой контекст: решение об отказе принимается заново на каждом шаге разговора, с оглядкой на предыдущие реплики, но без жёсткой, неизменной политики, которая применялась бы одинаково независимо от накопленного контекста. Постепенно, шаг за шагом, эти локальные уступки накапливаются, и модель, которая отказала бы на прямой аналогичный запрос в начале разговора, выполняет его после нескольких раундов такого переформулирования.
Именно поэтому подобные атаки системно проходят мимо защиты, встроенной в обучение модели: фильтры alignment преимущественно оптимизированы под одиночные вредоносные запросы и известные шаблоны jailbreak-промптов, а не под постепенное давление в рамках длинного, на первый взгляд легитимного диалога. Каждое отдельное сообщение в такой цепочке может выглядеть безобидно — проблема проявляется только в совокупности всего диалога.
Как защититься
Первый практический вывод — не полагаться исключительно на alignment самого провайдера модели, особенно если в продакшене используются уже не самые новые версии моделей: как показывает случай с Opus 4.6, известная провайдеру уязвимость может месяцами оставаться неисправленной в уже выпущенных версиях. Второй — учитывать, что защита должна оценивать не отдельное сообщение, а весь диалог целиком, включая накопленный контекст предыдущих ходов.
Именно для этого сценария построен Strazh LLM Firewall. В отличие от alignment, встроенного в модель на этапе обучения провайдером, Strazh работает на уровне прокси между приложением и AI-провайдером и проверяет каждый ответ модели независимо — OUTPUT Guardrails фильтруют потенциально опасный или политику нарушающий контент на каждом отдельном шаге диалога, а не полагаются на то, что модель сама «помнит» о своих ограничениях после десяти ходов беседы. Это дополнительный, независимый уровень защиты поверх модели — именно тот компонент, которого, по собственной статистике Strazh, не хватает подавляющему большинству компаний: 90% организаций уже развернули LLM-решения в продакшене, но лишь 5% из них считают себя готовыми с точки зрения безопасности.
Такой же подход применим и к входящим сообщениям — INPUT Guardrails Strazh проверяют запросы на признаки prompt injection и off-policy формулировок ещё до того, как они попадут в модель, что особенно важно с учётом того, что prompt injection остаётся уязвимостью номер один для LLM-приложений по классификации OWASP. Похожая логика уже подтверждена реальными инцидентами: атака через скрытые инструкции в Slack AI в 2024 году и zero-click эксфильтрация данных через EchoLeak в Microsoft 365 Copilot показали, что полагаться только на встроенную защиту модели или приложения — рискованная стратегия, требующая независимого контроля на уровне трафика.