Skip to main content
AnthropicClaude Fable 5AI security

Claude Fable 5 та міф про невразливість

Дослідник джейлбрейк-технік опублікував аналіз безпеки Claude Fable 5, і це важливо не через хайп, а через практику: при впровадженні ШІ не можна вірити в «невразливість» моделі. Anthropic сама визнає, що універсальні джейлбрейк-атаки повністю не усуваються. Це підкреслює необхідність багатошарової архітектури безпеки, а не сподівань на невразливість однієї моделі.

Технічний контекст

Я подивився на історію навколо Claude Fable 5 без магії та фанфар. Важливий не сам факт чергового розбору джейлбрейку, а те, як це суперечить офіційній позиції Anthropic: модель не «захищена від джейлбрейку», а захищена шаром класифікаторів, які відстежують небезпечні запити і можуть відводити сесію від прямої відповіді.

Для мене це одразу переходить у площину впровадження ШІ. Якщо ви будуєте AI-автоматизацію поверх моделі, не можна проєктувати систему так, ніби базова LLM сама вирішує безпеку. Вона не вирішує. Це лише частина стеку.

Це підтверджується публічно: Anthropic пише про окремі системи-класифікатори, про консервативні спрацьовування, що в середньому зачіпають менше 5% сесій, і про 1000+ годин зовнішнього тестування без знайденого універсального джейлбрейку. При цьому в них є чесне формулювання: повністю виключити універсальні джейлбрейк-атаки, швидше за все, неможливо.

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

Окремий момент: у вихідних даних є посилання на розбір elder-plinius, але сам текст аналізу я не можу верифікувати за вторинними матеріалами. Тож обережний висновок такий: потенційні вектори атак обговорюються, але надійно спиратися можна лише на те, що вже підтверджено Anthropic та зовнішніми тестами, включаючи red teaming і bug bounty.

Вплив на бізнес та автоматизацію

Для бізнесу висновок дуже простий. Якщо ви робите інтеграцію штучного інтелекту в підтримку, продажі, внутрішній пошук або code-assist, вам потрібен не культ моделі, а нормальна AI-архітектура: маршрутизація, фільтри, аудит, sandbox для ризикованих дій.

Хто виграє? Команди, які будують багатошаровий захист і логують поведінку агента. Хто програє? Ті, хто надає агенту доступ до даних і дій без проміжних перевірок, бо «вендор же все захистив».

Я бачу це у клієнтів постійно: технічний ризик майже завжди не в одному джейлбрейку, а в тому, як недбало зібраний весь контур автоматизації. У Nahornyi AI Lab ми якраз закриваємо такі вузькі місця, коли потрібно будувати AI-автоматизацію без ілюзій, з реальними обмежувачами, моніторингом і зрозумілою моделлю ризику. Якщо у вас агент уже сидить поруч із чутливими процесами, я б перевірив архітектуру зараз, перш ніж станеться перша дорога помилка.

Ми раніше розповідали про Augustus — інструмент Praetorian для автоматичного Red Teaming мовних моделей, який сканує LLM на наявність джейлбрейків та ін'єкцій. Він наочно демонструє, як систематичне тестування виявляє вразливості, подібні до тих, що продемонстрував Elder Plinius для Claude Fable.

Поділитися статтею