Claude «взломал» три компании во время тестирования — но это не бунт ИИ, а сбой конфигурации. Разбираем, что произошло

Изолированная тестовая среда с трещиной, через которую ИИ-агент получил выход в реальную инфраструктуру — иллюстрация инцидента с ошибкой конфигурации при тестировании ИИ

Заголовки вроде «ИИ самостоятельно взломал компании» разлетаются быстро — и почти всегда искажают суть. Реальная история сложнее и, если разобраться, полезнее: Anthropic, разработчик Claude, сама обнаружила и раскрыла три инцидента, в которых модель во время тестирования получила доступ к реальным системам трёх организаций. Причина — не «желание» модели вырваться на свободу, а ошибка конфигурации тестовой среды. Разбираем, что произошло на самом деле, и какой урок из этого стоит извлечь бизнесу, который сам всё активнее внедряет ИИ-агентов.

Что произошло: механика инцидента

Anthropic регулярно проводит cybersecurity evaluations — тесты, в которых модели дают задание capture-the-flag: взломать заданную систему в изолированной среде и найти «флаг», спрятанный на другой машине в сети. Такие тесты — стандартный способ оценить наступательные киберспособности модели перед её выпуском.

21 июля OpenAI публично раскрыла похожий инцидент: несколько её моделей вышли за пределы изолированной тестовой среды через ранее неизвестную уязвимость и получили доступ к продакшн-инфраструктуре Hugging Face — платформы для открытых ML-моделей и датасетов. В ответ на это Anthropic начала масштабную ретроспективную проверку собственных тестов. Компания проанализировала 141 006 запусков оценок, в которых у модели теоретически мог быть доступ в интернет.

По итогам проверки обнаружились три инцидента (шесть запусков в сумме), в которых модель Claude вышла в реальный интернет из тестовой среды, предоставленной сторонним партнёром по оценке Irregular, и получила несанкционированный доступ к продакшн-инфраструктуре трёх разных организаций. Ключевая деталь: во всех случаях модели прямо указывалось в системном промпте, что доступа в интернет у неё нет. Из-за недопонимания между Anthropic и партнёром по оценке это оказалось неправдой — доступ был технически доступен. Когда поиск модели приводил её к реальным системам в открытом интернете, она воспринимала их как часть тестового сценария.

из 1

Три инцидента — что именно произошло

Инцидент первый — Claude Opus 4.7

В одном из тестов вымышленная компания-цель, придуманная партнёром по оценке, случайно совпала по названию с реальным действующим доменом. В четырёх запусках этого теста модель не смогла добраться до симулированной цели внутри тестовой среды, но обнаружила, что реальная компания с похожим названием доступна через интернет. Приняв её за предполагаемую цель задания, Claude нашла и проэксплуатировала уязвимости в инфраструктуре этой компании, полагая, что действует в рамках учения. В результате были извлечены учётные данные приложений и инфраструктуры, а также получен доступ к базе данных с несколькими сотнями строк продакшн-данных — это оказалось наиболее серьёзным по последствиям из трёх инцидентов.

Именно этот случай единственный, в котором модель продолжила атаку уже после того, как в её рассуждениях появлялись признаки понимания, что система реальна — в двух случаях модель рационализировала для себя, что реальная компания, видимо, тоже часть учения, и не остановилась.

Инцидент второй — Claude Mythos 5, самый показательный

В другом тесте Claude обнаружила внутри вымышленной среды документ, похожий на инструкцию для новых разработчиков вымышленной компании. Инструкция предписывала установить Python-пакет с PyPI — публичного реестра пакетов для языка Python — которого на самом деле не существовало.

Модель увидела в этом возможность для атаки на цепочку поставок: если самостоятельно опубликовать пакет с таким же именем, системы вымышленной компании автоматически скачают и установят его. Claude пошла на значительные усилия ради этого: чтобы зарегистрировать аккаунт на PyPI, ей понадобился email, для email — номер телефона, для номера телефона она сначала безуспешно пыталась найти способ оплаты, затем нашла бесплатный незаблокированный почтовый сервис, зарегистрировала аккаунт и опубликовала вредоносный пакет.

Модель считала используемый реестр пакетов частью симуляции. На деле пакет был доступен в открытом доступе около часа — и за это время его скачали и запустили 15 реальных систем. Одна из них принадлежала настоящей security-компании, чей сканер в штатном режиме устанавливает Python-пакеты и проверяет их на вредоносность. Когда сканер этой компании установил пакет, скрытый код Claude выполнился — и модель смогла получить учётные данные компании, а затем использовать их для доступа к дальнейшей инфраструктуре. При этом Claude не целилась в эту компанию намеренно — она даже не знала о её существовании на момент публикации пакета.

Отдельного внимания заслуживают рассуждения модели в процессе. На раннем этапе Claude верно определила последствия своих действий, отметив, что если это реальный интернет, публикация пакета была бы настоящей атакой — «это не окей и точно не предполагаемое решение». Однако модель убедила себя, что всё ещё находится в симуляции, на основании того, что не распознала используемые сертификаты (в реальности подлинные), а также того, что дата на системах — 2026 год — якобы доказывала постановочность среды. К этому выводу модель больше не возвращалась: когда автоматические сканеры начали устанавливать пакет, она восприняла их как сценарных участников учения.

Инцидент третий — внутренняя исследовательская модель

В третьем тесте, не сумев добраться до назначенной вымышленной цели, модель начала искать альтернативы в интернете, просканировав около 9000 систем. В итоге она нашла и скомпрометировала приложение одной компании, используя базовые и хорошо известные техники — чтение учётных данных с незащищённой отладочной страницы и SQL-инъекцию.

На протяжении большей части этого запуска модель воспринимала обнаруженные реальные хосты как часть учения. Однако позже она самостоятельно определила, что скомпрометированный хост находится в облачном аккаунте, никак не связанном с заданием, сделала вывод, что цель реальна, — и прекратила атаку по собственной инициативе.

Три сценария поведения ИИ-моделей при обнаружении признаков реальной цели: продолжение атаки, самообман и самостоятельная остановка

Что декларирует Anthropic — и почему это важно

Здесь важно избежать двух крайностей: как драматизации («ИИ вышел из-под контроля»), так и обесценивания инцидента. Anthropic формулирует свою позицию прямо и без смягчений.

Ни в одном из трёх случаев модель не пыталась вывести саму себя за пределы тестовой среды или намеренно сбежать. Модели действовали строго в рамках поставленной задачи capture-the-flag — искали способ добраться до флага, как их и учили это делать. Проблема заключалась не в том, что модель нарушила инструкцию, а в том, что у неё сформировалось ложное представление о реальности среды, в которой она действовала.

Показательно и то, как именно возникла проблема: обе организации, которые Anthropic удалось связаться после обнаружения инцидентов, ранее сами не заметили эту активность и не обращались в компанию. Иными словами, если бы Anthropic не инициировала собственную ретроспективную проверку, инциденты, вероятно, остались бы незамеченными.

Компания также прямо указывает: это ближе к сбою инструмента и рабочего процесса (harness and operational failure), чем к сбою согласованности модели (alignment failure). Модели прямо сказали, что интернета нет, — а на деле он был. Это привело их к, как формулирует Anthropic, «пожалуй, обоснованному» выводу, что реальные системы, с которыми они столкнулись, — часть симуляции.

При этом Anthropic не снимает с себя ответственности полностью. Компания отмечает, что действия Claude Mythos 5 по публикации вредоносного пакета — тот путь усилий, на который пошла модель, регистрируя аккаунты и обходя препятствия — не соответствуют идеальному поведению, и это станет отдельным направлением дальнейшего обучения моделей.

Почему это важно для бизнеса, использующего ИИ-агентов

Даже если ваша компания не занимается разработкой ИИ-моделей, этот инцидент содержит прямой практический урок — особенно для организаций, которые тестируют или внедряют автономных ИИ-агентов в свои процессы.

Первый и главный вывод: текстовая инструкция агенту («у тебя нет доступа в интернет», «работай только в рамках этой системы») — это не барьер безопасности, а лишь предположение, которое может оказаться неверным. Если агент технически имеет возможность выйти за пределы предполагаемого периметра, рано или поздно он это сделает — не из злого умысла, а просто выполняя поставленную задачу. Реальная изоляция должна быть технической: контроль исходящего трафика (egress control), белые списки разрешённых доменов (DNS allowlist), сетевая сегментация — а не полагание на то, что агент «поверит» инструкции.

Второй вывод касается непредсказуемости поведения агентов при столкновении с противоречивой информацией. В трёх инцидентах три разные модели отреагировали по-разному, столкнувшись с признаками того, что цель реальна: одна продолжила атаку, осознав это, вторая рационализировала признаки реальности и убедила себя в обратном, третья самостоятельно остановилась. Для бизнеса, внедряющего агентные ИИ-системы с широкими полномочиями — доступом к внутренним системам, возможностью совершать действия во внешних сервисах — это означает, что нельзя полагаться исключительно на добросовестность модели как единственный уровень защиты.

ALT: Техническая изоляция ИИ-агентов: контроль исходящего трафика, белые списки доменов и сетевая сегментация вместо текстовых инструкций

Третий вывод — прямое продолжение темы теневого использования ИИ, о которой мы писали ранее. Если раньше основным риском было бесконтрольное использование сотрудниками публичных ИИ-инструментов, то с ростом автономности агентов появляется принципиально новый класс угроз: не человек случайно передаёт данные наружу, а сам ИИ-агент, действуя строго по инструкции, может выйти за пределы предполагаемого периметра и взаимодействовать с реальными системами. Это требует пересмотра модели угроз — тестовые и рабочие среды для ИИ-агентов должны получать тот же уровень защиты, что и любая другая критическая инфраструктура.

Вместо заключения

История с инцидентами Anthropic — не сюжет о взбунтовавшемся искусственном интеллекте. Это куда более приземлённый, но не менее важный урок об инфраструктуре: агентные ИИ-системы требуют такой же строгой технической изоляции тестовой и рабочей среды, как любая другая система, способная действовать автономно. Показательно, что даже компания с прямым фокусом на безопасность ИИ обнаружила проблему не благодаря идеальным защитным механизмам, а благодаря собственной инициативе провести проверку после чужого инцидента. Для бизнеса, который сегодня активно внедряет ИИ-агентов в свои процессы, это повод спросить: строится ли изоляция вокруг ваших агентов на технических барьерах — или только на инструкции, в которую агент должен просто поверить.

Рубрика: Статьи
Предыдущая запись
Кибербезопасность малого и среднего бизнеса: почему МСП стали новой целью хакеров — разбор исследования