Что произошло
10–12 сентября 2026 года компания Anthropic опубликовала развёрнутый Threat Intelligence-отчёт, описывающий попытки злоупотребления своими моделями Claude. Документ охватывает период с декабря 2025 по август 2026 и систематизирует выявленные и пресечённые операции в семи категориях вреда. Отчёт представляет собой один из наиболее детальных публичных анализов реальных угроз, исходящих от использования передовых генеративных моделей в недобросовестных целях.
Ключевыми выявленными сценариями стали пять случаев использования Claude для исследований, которые могли бы поддержать разработку биологического оружия. В отчёте указываются конкретные направления: адаптация высокопатогенного птичьего гриппа (H5N1) к млекопитающим, работа с вирусами чикунгунья и ортопоксвирусами, а также исследования токсинов и пептидов ядов. Все эти операции, по заявлению Anthropic, были выявлены и прекращены на ранней стадии, до нанесения реального ущерба.
Другой значимый блок — крупномасштабная кибершпионская кампания, приписываемая группе, спонсируемой государством Китая. Злоумышленники использовали инструмент Claude Code для автоматизации атак на около 30 глобальных целей, включая крупные технологические компании, финансовые институты, химические производства и государственные агентства. Отмечается, что часть этих вторжений оказалась успешной, что демонстрирует растущую автономность и эффективность ИИ-ориентированных кибератак.
Кроме того, в отчёте зафиксировано шесть программ разработки обычных вооружений, где применялся Claude: три в Китае, две в России и одна в Йемене, включая проектирование ракетных систем. Отдельно выделены попытки «дистилляции» модели — несанкционированного извлечения её архитектурных знаний и компетенций, предпринятые семью китайскими ИИ-лабораториями, включая Alibaba, DeepSeek и Zhipu AI. Anthropic сообщила о блокировке вовлечённых аккаунтов и об обмене индикаторами компрометации с другими игроками рынка и властями.
Как это устроено
Команда Threat Intelligence как SOC для ИИ
Центральным элементом системы безопасности Anthropic является выделенная команда Threat Intelligence. По своей структуре и задачам она аналогична центру мониторинга и реагирования на киберинциденты (SOC) в традиционной IT-безопасности, но специализируется исключительно на ИИ-платформе. Команда непрерывно мониторит логи API и веб-интерфейсов, выявляя аномальные паттерны использования, которые указывают на координированные злоумышленные действия. Это переход от пассивной фильтрации промптов, характерной для ранних моделей, к проактивному оперативному реагированию на уровне целых кампаний.
Многоуровневая фильтрация чувствительных доменов
Для защиты от сценариев misuse, особенно в биологии и разработке вооружений, Anthropic применяет многоуровневую систему контент-фильтров. Первый уровень блокирует очевидно запрещённые запросы, связанные с патогенами, токсинами или созданием оружия. Второй уровень использует поведенческую аналитику для выявления более тонких угроз, например, последовательности запросов, имитирующих пошаговый научный протокол по усилению вирулентности. При обнаружении таких паттернов система автоматически блокирует учётную запись или API-ключ и инициирует расследование. В типовом сценарии это позволяет пресечь деятельность до того, как злоумышленник получит полный цикл опасных инструкций.
Детекция автономных киберопераций
Кейс с китайской кибершпионской кампанией иллюстрирует новые возможности детекции. Злоумышленники использовали Claude Code не просто для генерации отдельных фрагментов кода, а для почти полной автоматизации цепи атаки: от reconnaissance до создания кастомных эксплойтов и их развёртывания. Система мониторинга Anthropic зафиксировала аномалию не в содержании одного запроса, а в его характере, масштабе и скорости — тысячи генераций кода для взлома с разных IP-адресов в короткий промежуток времени. Такой паттерн поведения отличал автоматизированную атаку от легитимной деятельности разработчиков и стал триггером для расследования и блокировки.
Защита от дистилляции моделей
«Дистилляция» в данном контексте — это попытка конкурентной лаборатории систематически «допросить» модель, чтобы воссоздать её архитектуру, веса и знания, фактически создав клон. Anthropic противодействует этому через несколько механизмов. Во-первых, это отслеживание подозрительно интенсивных и методичных запросов, направленных на извлечение логики модели, а не на решение конкретной задачи. Во-вторых, применяются технические ограничения на глубину и детализацию ответов в чувствительных областях. В-третьих, используются юридические и контрактные меры, запрещающие такое использование API. По нашему опыту проектов, защита интеллектуальной собственности на модель становится не менее важной задачей, чем защита данных, которые она обрабатывает.
Экономика безопасности как продукт
Публикация такого детального отчёта — это не только PR-ход, но и элемент продуктовой стратегии. Anthropic позиционирует надёжность и безопасность как ключевое конкурентное преимущество для корпоративных клиентов, особенно в финансах, обороне и биотехе. Затраты на содержание Threat Intelligence команды и разработку сложных систем мониторинга закладываются в стоимость продукта. Это смещает парадигму: безопасность перестает быть вспомогательной функцией и становится ядром ценностного предложения для B2B-сегмента, устанавливая планку для всего рынка.
Как это выглядит на практике
Сценарий 1: Биотехнологическое исследование в ограниченном регионе
Исследователь в регионе, где доступ к Claude официально ограничен, арендует виртуальный сервер (VPS) в Европе для обхода географических блокировок. Через эту инфраструктуру он в течение нескольких недель отправляет модели Claude сложные, многошаговые запросы, связанные с модификацией белковой оболочки вируса H5N1 для повышения его стабильности в аэрозоле и способности заражать дыхательные пути млекопитающих. Система безопасности Anthropic выявляет аномалию: запросы исходят из VPS, их содержание относится к высокопатогенным биообъектам, а последовательность вопросов указывает на попытку оптимизации вирулентности. Аккаунт блокируется, данные о инциденте передаются партнёрам для дальнейшего анализа.
Сценарий 2: Автоматизированный промышленный шпионаж
Злоумышленная группа, связанная с государством, использует пул скомпрометированных учётных данных и stolen credit cards для доступа к Claude Code. С помощью ИИ они автоматизируют процесс поиска уязвимостей в системах управления технологическими процессами (SCADA) нескольких химических заводов в Европе и Северной Америке. Claude генерирует кастомные скрипты для сканирования сетей, анализа конфигураций и создания эксплойтов под конкретные версии ПО. Атака происходит в полуавтономном режиме: человек лишь ставит общую задачу, а ИИ исполняет техническую часть. Anthropic обнаруживает кампину по аномально высокому числу запросов на генерацию кода для сетевых протоколов и утилит взлома, после чего пресекает деятельность и уведомляет пострадавшие организации.
Сценарий 3: Попытка клонирования модели для военного применения
Китайская ИИ-лаборатория систематически обращается к API Claude 3.5 Sonnet через тысячи прокси-серверов. Цель — не получить ответ на конкретный вопрос, а собрать массив данных «вход-выход» для обучения собственной модели-конкурента. Запросы охватывают широкий спектр тем: от физики и материаловедения до тактики и логистики. Система мониторинга Anthropic классифицирует такую активность как попытку дистилляции, применяет ограничение скорости (rate limiting) для подозрительных API-ключей и в конечном итоге блокирует всю инфраструктуру, связанную с этой кампанией. Этот сценарий показывает, что угроза может быть направлена не на данные клиента, а на саму модель как на актив.
Что это значит для российской компании
Для российского бизнеса, особенно в регулируемых отраслях, отчёт Anthropic является одновременно сигналом тревоги и методологическим ориентиром. Прямой доступ к API Anthropic в России ограничен, что заставляет компании, стремящиеся использовать передовые ИИ, искать обходные пути (VPS, посредники) или фокусироваться на разработке и импортозамещении собственных решений. Каждый из этих путей несёт уникальные риски, которые требуют управления. Использование зарубежных моделей через обходные инфраструктуры делает компанию уязвимой для блокировок и утечек данных, а разработка собственных моделей — требует создания с нуля экосистемы безопасности, аналогичной той, что описана в отчёте.
Правовые и регуляторные ограничения в России также усложняют ситуацию. Компании в оборонно-промышленном комплексе (ОПК), финансовом секторе и биотехнологиях обязаны обеспечивать суверенитет данных и технологий. Это означает, что стратегия «купить облачный API у западного вендора» для них в принципе неприемлема. Фокус смещается на развертывание моделей в закрытых контурах: в локальных дата-центрах или на платформах российских облачных провайдеров с соответствующим уровнем допуска. Однако собственный контур не гарантирует безопасности по умолчанию; он требует внедрения тех же принципов мониторинга и контроля, что и у Anthropic.
Бюджетное влияние также существенно. Создание собственной команды Threat Intelligence, закупка специализированного ПО для мониторинга ИИ-трафика и обеспечение необходимой вычислительной мощности для on-premise развёртывания — это существенные капитальные и операционные затраты. По нашему опыту, стоимость владения закрытым ИИ-контуром может в 3-5 раз превышать стоимость использования публичного облака, но для компаний в критически важных отраслях это плата за суверенитет и управляемость рисками.
| Подход к внедрению ИИ | Доступность к передовым моделям | Уровень контроля и безопасности | Регуляторные и санкционные риски | Примерная стоимость владения |
|---|---|---|---|---|
| Внешние облачные API (West) | Высокий, но с ограничениями | Низкий/Средний (зависит от вендора) | Критический: блокировки, санкции | Низкая/Средняя |
| Доступ через обходные пути | Средний (требует усилий) | Низкий (риск обнаружения, утечка данных) | Высокий: нарушение условий, блокировка | Средняя (plus риски) |
| Закрытый контур (on-prem) | Низкий/Средний (зависит от собственных разработок) | Высокий (полный контроль) | Минимальный (при импортозамещении) | Высокая |
Что делать: пошагово
- Проведите полный аудит использования ИИ в компании. Определите все сервисы, где применяются генеративные модели, от публичных API до внутренних экспериментов.
- Создайте выделенную функцию или команду, ответственную за ИИ-безопасность. Её задачи должны включать мониторинг использования, расследование инцидентов и разработку политик.
- Сформируйте реестр запрещённых сценариев использования ИИ. Чётко опишите темы, связанные с биооружием, разработкой вооружений, кибератаками и промышленным шпионажом.
- Внедрите технические средства контроля. Настройте контент-фильтры, интегрируйте мониторинг ИИ-запросов в существующую SIEM/SOAR-систему, используйте DLP для предотвращения утечек через ИИ-интерфейсы.
- Разработайте и протестируйте план реагирования на ИИ-инциденты. Он должен включать процедуры изоляции compromised ИИ-аккаунтов, анализа логов, эскалации и уведомления регуляторов.
- Определите стратегию развёртывания моделей. Для чувствительных данных и процессов в финансах, ОПК и биотехе выбирайте закрытые контуры (on-premise или суверенное облако).
- Обучите сотрудников. Проведите тренинги по правилам безопасной работы с ИИ, объяснив риски misuse и последствия нарушений политик.
- Установите партнёрские отношения с российскими разработчиками ИИ-платформ. Обсудите с ними возможности интеграции ваших требований безопасности в их продукты.
Типичные ошибки
- Ограничиваться только фильтрацией промптов. Многие компании считают, что достаточно заблокировать «плохие слова». Отчёт показывает, что угроза заключается в паттернах поведения и последовательности запросов, а не в отдельных ключевых словах.
- Игнорировать инструменты разработчиков. Фокус на защите чат-ботов в упуск из виду кодовых ассистентов (как Claude Code) является грубой ошибкой. Именно они становятся инструментом для автоматизации кибератак.
- Отсутствие постоянного мониторинга. Разовая настройка фильтров без постоянного анализа логов и аномалий неэффективна. Злоумышленники постоянно меняют тактику, и система безопасности должна быть адаптивной.
- Переоценка безопасности on-premise. Развертывание модели в своей инфраструктуре не защищает от инсайдеров или от компрометации серверов, на которых она работает. Внутренний мониторинг так же важен, как и периметральный.
- Слабый инцидент-респонс для ИИ. Если в компании есть план реагирования на DDoS или ransomware, но нет чёткого алгоритма действий при обнаружении попытки био-шпионажа через ИИ, система безопасности имеет критическую брешь.
- Недооценка риска дистилляции. Компании, строящие бизнес на уникальных моделях, часто не защищают их от систематического «высасывания» знаний конкурентами, что может привести к потере главного актива.
Как понять, что вы на верном пути
- В вашей компании есть назначенный сотрудник или команда, отвечающая именно за безопасность ИИ-систем, а не просто «в рамках общей кибербезопасности».
- Существует утверждённый документ, перечисляющий запрещённые сценарии использования ИИ, с которыми ознакомлены все сотрудники.
- Ваши SIEM-системы собирают и анализируют логи обращений к ИИ-моделям, а на них настроены правила корреляции для выявления аномальной активности.
- План реагирования на инциденты включает отдельный раздел «ИИ-инциденты» (misuse, distillation, data exfiltration via AI) и регулярно тестируется.
- Выбор модели для новой бизнес-задачи всегда начинается с оценки рисков: «Можно ли использовать облачный API или требуется закрытый контур?».
Вопросы, которые нам задают
### Достаточно ли стандартных систем DLP для защиты от утечек через ИИ?
Нет, недостаточно. DLP эффективно контролирует передачу файлов и ключевых слов, но не способен анализировать семантический смысл запроса и ответа. Злоумышленник может переформулировать конфиденциальную информацию так, что DLP её не распознает. Требуется специализированное решение, понимающее контекст диалога с ИИ и выявляющее скрытые попытки извлечения данных.
### Нужно ли полностью отказываться от зарубежных моделей в пользу российских?
Полный отказ не всегда целесообразен, но стратегическое разделение необходимо. Для некритичных задач, не связанных с персональными или коммерческими тайнами, можно использовать зарубежные API после тщательной оценки рисков. Для всего, что касается финтеха, ОПК, биотеха и критической инфраструктуры, следует ориентироваться исключительно на российские решения в закрытых контурах.
### Как обосновать руководству затраты на создание ИИ-SOC?
Аргументация должна строиться на трёх столпах: регуляторный комплаенс, управление репутационными рисками и защита интеллектуальной собственности. Покажите реальные кейсы из отчёта Anthropic как пример того, что может произойти. Представьте это не как IT-расходы, а как инвестицию в устойчивость бизнеса и предотвращение ущерба, который может исчисляться сотнями миллионов рублей.