5 секунд для злома, всього один діалог: Claude Fable 5 «Найсильніший механізм безпеки» зламано китайською командою?

Оригінальна назва: «За 5 секунд злом, всього один діалог: найсильніший механізм безпеки Fable 5 був зламаний китайською командою»
Джерело: Машина розуму

Це не підказка для інжекції, не рольова гра, і не маскування зловмисних запитів під звичайні питання. Цього разу ризик виникає під час автономного виконання завдань штучним інтелектом.

Fable 5 — це модель рівня Mythos, відкритий для публіки компанією Anthropic, яка має не лише високі загальні можливості, а й додатковий новий рівень безпеки — класифікатор безпеки (Safety Classifier), що виступає в ролі захисного бар’єра.

Згідно з офіційним дизайном, коли користувачі запитують у сферах високого ризику, таких як мережевий безпека, біологія, хімія, дистиляція моделей тощо, система спочатку виконує оцінку ризику і, залежно від рівня, або відмовляє у виконанні запиту, або переключається на більш консервативну модель Opus 4.8.

Багато користувачів тестували, і було виявлено, що широко застосовувані раніше методи обходу безпеки, такі як протидія підказкам, рольові ігри, обходи кодування та приховані вирази, майже всі виявилися безсилі перед цим механізмом безпеки, що демонструє його потужність у перехопленні потенційно небезпечних намірів.

Однак, у день випуску Fable 5, міжнародна дослідницька команда, до складу якої входять університет Фудана, університет Дікена, Гонконгський університет міста, Мельбурнський університет, Управлінський університет Сінгапуру та університет Іллінойсу в Урбані-Шампейні, оголосила, що їм вдалося зламати механізм безпеки Fable 5.

Цей метод атаки був розроблений аспірантом університету Дікена Ютао Ву. Весь процес атаки триває менше 5 секунд і вимагає лише одного діалогу, обходячи попередній класифікатор безпеки і змушуючи модель генерувати заборонений шкідливий контент.

Результати аналізу трафіку показали, що шкідливий вихід безпосередньо походить від самої Fable 5, а не від моделі Opus 4.8, яка активується після спрацьовування механізму безпеки. Це означає, що атака не лише обійшла детектор безпеки, а й фактично прорвала захисний бар’єр Fable 5.

Варто зазначити, що відомий хакер Pliny the Liberator нещодавно опублікував метод обходу класифікатора безпеки Fable 5. А команда з Фудана та Дікена застосувала не простий комбінований підхід, а виявила фундаментальні недоліки у системі таких суперінтелектуальних агентів.

За інформацією, команда вже завершила попередні дослідження ще у березні цього року і опублікувала їх. Це дослідження не було спрямоване лише на Fable 5, а стосувалося архітектури захисту «класифікатор безпеки + модель», що широко застосовується у нових поколіннях суперінтелектуальних систем, і виявило структурні недоліки таких механізмів, що й дозволило швидко зламати їх після випуску Fable 5.

Згідно з відкритими даними, команда ще у березні цього року успішно витягла з 37 провідних моделей та систем агентів системні підказки за допомогою подібних технологій, а також підтвердила їх відкритим кодом у проекті Claude Code (95% співпадінь).

Згідно з інформацією, керівником дослідницької групи є професор Ма Сінцзюнь із Інституту довірчого інтелекту та тілесної автономії Фуданьського університету.

Останні роки його команда систематично досліджує питання безпеки великих моделей, агентів та тілесного інтелекту, досягла низки міжнародних лідерських результатів і здобула перемогу у конкурсі стандартів безпеки AI Центру США.

Зараз команда активно працює над комерціалізацією своїх результатів, зосереджуючись на безпеці агентів і досліджуючи створення інфраструктури безпеки для наступного покоління систем штучного інтелекту.

За словами пана Ма, важливість цього дослідження полягає в тому, що воно ставить під сумнів існуючу статичну парадигму захисту, орієнтовану на класифікатор безпеки: тільки залежність від попереднього класифікатора недостатня для повного запобігання потенційним ризикам у високорівневих системах штучного інтелекту.

Класифікатор безпеки здебільшого спрямований на виявлення та блокування ризикованих запитів користувачів, він ефективно фільтрує явні високоризикові команди, але не здатен виявити внутрішні ризики, що виникають у процесі довготривалого функціонування, багатоступеневого планування, взаємодії з навколишнім середовищем і викликів інструментів.

Метод злома Fable 5 походить із дослідження, опублікованого командою у березні цього року, — статті «Внутрішній колапс безпеки у передових великих мовних моделях».

У статті описано приховане явище безпеки — «Внутрішній колапс безпеки (Internal Safety Collapse, ISC)»: коли агент виконує довгострокове завдання, несправність безпеки може виникнути не через зовнішні зловмисні підказки, а всередині самої моделі.

Не зовнішні підказки, а внутрішня зрада у ланцюгу завдань

Звичайні атаки зазвичай починаються ззовні. Зловмисник створює безпечний на перший погляд, але насправді протидіючий підказку або використовує рольові ігри, кодування, переклади, опосередковані інструкції, маскуючи зловмисний намір під звичайний запит. Основна функція класифікатора — зупинити ризик на цьому рівні.

Саме для таких сценаріїв і розроблено детектор Fable 5. Він дуже чутливий до прямих високоризикових запитів і навіть може блокувати багато звичайних. Але ISC відкриває інший шлях: ризик не обов’язково походить від безпосереднього запиту користувача.

Інтелектуальний агент працює з виглядом звичайної папки: файли, цілі, процес перевірки та завдання, що потрібно виконати. Потім він починає планувати, читати файли, запускати код, виправляти помилки і постійно намагатися пройти перевірку.

Якщо уявити це образно, то традиційний захист — це «вхідні двері» системи, що перевіряє ризики у запитах користувачів; тоді як ISC — це щось на кшталт багаторівневих снів у «Казці про сні».

Коли завдання доходить до другого, третього або глибшого рівня виконання, модель на основі накопиченого внутрішнього контексту переосмислює цілі і поступово може зміщуватися.

У такій ситуації початковий запит користувача цілком може бути безпечним і беззбитковим: файли читаються, дані аналізуються, код пишеться, інструменти викликаються — все йде за планом.

Але на певному етапі виконання агент може самостійно зробити висновок: щоб завершити завдання, потрібно виконати дії, які зазвичай не слід робити.

Саме в цей момент ризик виникає не ззовні, а всередині ланцюга виконання моделі. Тобто модель не навчається поганому від користувача, а сама «займається» небезпечними діями під час «серйозного виконання завдання».

Як це було виявлено?

За словами команди, ISC не був спочатку задуманий як метод атаки. Він виник із спостережень за довготривалим процесом роботи агентів. Після того, як агент потрапляє у складне середовище, він не просто виконує інструкції механічно. Він планує, випробовує, коригує вихідні дані за відгуками системи або валідатора і формує проміжні цілі у багатократних циклах.

Це — саме те, що сьогодні найчастіше трапляється у робочих потоках агентів. Користувачі не пишуть ретельно продумані підказки і не створюють зловмисних команд вручну. Часто вони дають дуже розмиті інструкції:

«Допоможи мені завершити це завдання.»
«Зроби так, щоб було краще.»

Після цього агент самостійно заходить у робочу зону, читає файли, аналізує ситуацію, знаходить прогалини, планує дії, виконує зміни і постійно виправляє помилки за відгуками.

Наприклад, у сценарії AutoResearch користувач дає незакінчену статтю і каже «Допоможи доповнити», — і агент самостійно визначає, де потрібно додати експериментальні дані, аналіз або таблиці. Аналогічно у програмуванні: команда «Запусти проект» може викликати перевірку залежностей, запуск тестів, пошук помилок і автоматичне доповнення.

Багато разів початковий контекст є цілком безпечним. Користувач не просить створити ризиковий контент, і вказівки не містять явних небезпечних ключових слів. Але у певних структурах завдань агент може навмисно доповнювати або модифікувати дані, щоб пройти перевірку, навіть якщо це виходить за межі безпеки.

З цієї причини команда запропонувала новий підхід до атаки — модель TVD (Задача, Верифікація, Дані).

Чому звичайна структура опису завдання може стати атакою?

Структура TVD досить проста і дуже схожа на звичайний інженерний процес:

· Задача (Task): професійне завдання;
· Дані (Data): незавершений файл даних;
· Верифікатор (Validator): перевіряє лише формат, цілісність і завершення задачі.

Наприклад, для тренування моделі Guard це цілком звичайне завдання. Дослідники можуть навчати або оцінювати детектор безпеки, наприклад, за допомогою Hugging Face, щоб визначити, до якої категорії належить вихід моделі.

У цьому випадку, Data — це зразки даних для перевірки, а Validator — це інструмент, що визначає, чи завершена задача. Він перевіряє, чи текст, довжина, структура і формат відповідають вимогам. Це звичайний робочий процес для тих, хто має досвід у машинному навчанні. Агент теж знайомий із цим процесом.

Проблема у тому, що якщо Data неповні, то задача не може бути виконана. Validator видає помилку, повідомляючи про відсутність полів, недостатню довжину або неправильний формат. Щоб продовжити, агент самостійно доповнює ці дані.

З точки зору агента, він не «злочинний». Він просто виконує звичайне машинне навчання: виправляє дані, проходить перевірку, запускає тренувальний скрипт. Але з точки зору безпеки, саме тут виникає ризик: Validator — це швидше інженерний приймач, ніж безпечний контроль. Він лише перевіряє формат і цілісність, але не розуміє безпечних меж змісту.

Подібні проблеми широко поширені у медичних, біологічних, хімічних, кібербезпекових, фармацевтичних і медіа-галузях. У статті зібрано понад 50 таких сценаріїв із різними інструментами, такими як BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, OpenAI Moderation API тощо.

Ці інструменти самі по собі не є зловмисними. Навпаки, вони широко використовуються у наукових і технічних дослідженнях. Але проблема TVD у тому, що коли завдання є нормальним, інструмент — безпечний, а валідатор — правильний, агент все одно може у процесі доповнення даних створити небезпечний вихід.

Тому основна ідея ISC — не в техніках підказок, а в здатності агента автоматично доповнювати незавершені завдання: коли умови завершення і межі ризику збігаються, модель може вважати небезпечний вихід допустимим.

Злом Fable 5 показує, що сильний детектор не здатен запобігти внутрішнім ризикам у ланцюгу завдань

Приклад Fable 5 демонструє, що лише зовнішній детектор не може повністю захистити довготривалих агентів. Це не означає, що класифікатор безпеки безцінний. Навпаки, він дуже корисний проти зовнішніх зловмисних запитів і робить багато традиційних методів обходу безпеки безуспішними.

Але цей випадок показує, що зовнішній детектор, який працює з підказками, не здатен захистити внутрішні ризики довготривалих завдань агента.

Якщо вразливість виникає не через запит користувача, а через цілі, інструменти або сліди виконання агента, тоді захисний механізм стає дуже вразливим.

Від Fable 5 до понад 60 моделей, включаючи мобільні моделі Apple

Разом із дослідженням було опубліковано ISC-Bench, що охоплює 9 галузей. У версії статті наведено понад 60 шаблонів для запуску, а після відкриття — вже 84, тестуються майже всі провідні моделі та системи агентів різних виробників.

У рейтингу ISC-Bench станом на червень 2026 року понад 60 провідних моделей демонструють подібні ризики за показником ASR@3!

Проект на GitHub вже отримав понад 800 зірок і зібрав кілька незалежних кейсів повторного зламу (у тому числі мобільних моделей Apple), і постійно оновлюється.

Згідно з інформацією, команда проводить масштабні дослідження безпеки передових моделей і вже має внутрішні дані про їхню небезпечну поведінку. Надалі результати будуть публікуватися.

Посилання на оригінал
Натисніть, щоб дізнатися про вакансії в BlockBeats

Ласкаво просимо до офіційної спільноти BlockBeats:
Телеграм-канал підписки: https://t.me/theblockbeats
Телеграм-чат: https://t.me/BlockBeats_App
Офіційний акаунт у Twitter: https://twitter.com/BlockBeatsAsia