2 июля Anthropic выпустила разбор того, как устроены киберзащитные механизмы модели Claude Fable 5, — и это редкий случай, когда вендор показывает не декларацию, а рабочую классификацию. Запросы, связанные с кибербезопасностью, компания режет на четыре категории. Prohibited Use — разработка ransomware и вредоносного ПО, эксфильтрация данных, обход средств защиты; блокируется полностью. High-Risk Dual Use — пентест и разработка эксплойтов; сейчас блокируется до тех пор, пока не появятся нормальные механизмы контроля доступа. Low-Risk Dual Use — поиск уязвимостей, OSINT; чаще всего разрешено, но под мониторингом. Benign Use — безопасное кодирование, отладка, патч-менеджмент, разбор инцидентов; разрешено.
Классификаторы Fable 5 работают с расширенным «запасом прочности» по сравнению с прежними моделями: Anthropic прямым текстом пишет, что готова мириться с ложными срабатываниями, лишь бы не пропустить вредный вывод. То есть перекос в сторону отказа — сознательный инженерный компромисс, а не баг.
Вторая часть публикации — фреймворк Cyber Jailbreak Severity (CJS), шкала от 0 до 4. Каждый обнаруженный обход оценивают по четырём осям: насколько он реально расширяет возможности атакующего по сравнению с уже существующим инструментарием (capability gain), сколько разных наступательных задач открывает (breadth), сколько усилий нужно, чтобы превратить его в оружие (ease of weaponization), и насколько легко его вообще найти (discoverability). Сумма даёт уровень от CJS-0 («информационный») до CJS-4 («критический»). Сообщать о находках предлагается через HackerOne.
Что это меняет на практике. Если вы строите на API продукт, который хоть краем задевает безопасность, планируйте архитектуру с учётом отказов. Всё, что выглядит как «помоги написать эксплойт» или «просканируй вот этот хост», будет отбито — даже когда у вас есть законные основания и договор на пентест: модель не видит вашего договора. Зато защитная половина работы — ревью кода на уязвимости, разбор логов, написание патчей, помощь дежурному в инциденте — остаётся полностью рабочей. Практический вывод простой: не пытайтесь протащить наступательные сценарии через промпт-инжиниринг, а закладывайте в UX явную обработку отказа и не стройте критичный пайплайн на том, что модель обязана ответить. И держите в голове перекос в сторону ложных срабатываний: часть легитимных security-запросов будет уходить в отказ, и это надо учитывать в SLA, а не считать инцидентом.
Комментарии