Кража API-ключа у некоммерческой организации METR позволила злоумышленникам использовать примерно $600 тысяч в кредитах на публичные ИИ-модели. История неприятна не только для самой METR: если даже команда, которая оценивает риски frontier AI, ловит такой удар на базовой гигиене доступа, у остального рынка поводов для самоуспокоения нет.
О двух инцидентах METR раскрыла 31 августа 2026 года, сообщает Dark Reading. Первый произошел в марте: злоумышленники получили API-ключ, использовавшийся для inference в публичных моделях, а затем несколько недель тратили кредиты организации. Второй эпизод относится к маю: тогда атакующие вели разведку против внешней инфраструктуры METR и, по данным самой организации, пытались добраться до внутренних данных через случайно выставленный наружу endpoint. В компании назвали оба случая near misses, хотя мартовский инцидент с учетом масштаба расходов звучит скорее как очень дорогой урок.
Детали мартовской атаки особенно показательны. Один из исследователей, у которого не было доступа к наиболее чувствительным данным METR, развернул агентов на личном AWS-инстансе через orchestration tool. На EC2-машине находился API-ключ для аккаунта METR, связанного с публичными моделями. Дополнительный штрих, который в 2026 году уже перестал быть экзотикой, но не стал менее тревожным: сам инструмент был, по формулировке METR, vibe-coded и содержал fail-open-уязвимость. Из-за нее аутентификация тихо отключилась, а система на несколько дней оказалась доступна из публичного интернета. Дальше схема была почти учебной: атакующий нашел инстанс, заставил агента раскрыть ключ провайдера моделей, добавил SSH-ключ для закрепления и в течение трех недель использовал чужие учетные данные. Итог известен: злоумышленники израсходовали кредиты на публичные модели, которые стоили бы около $600 тысяч.
Вторая история выглядит менее эффектно по сумме, но, возможно, более показательно с точки зрения архитектуры. В мае METR столкнулась с тем, что сама назвала sustained external attack campaign. Атакующие, по ее описанию, автоматизировали разведку и поиск уязвимостей с помощью агентов: credential stuffing, атаки вокруг OAuth, сканирование новых сервисов, фишинг. На этом фоне у METR оказался наружу выставлен механизм read-only SQL-запросов через публичный transcript viewer. Сам по себе read-only доступ редко выглядит как катастрофа, пока не выясняется, что его можно сцепить с другой ошибкой и проложить тропинку к непубличным данным. В уязвимой базе в основном лежали данные категории 2, то есть неопубликованные результаты оценки публичных моделей и ключи доступа к публичным моделям, но присутствовали и некоторые более чувствительные данные категории 3, связанные с непубличными моделями. Уязвимость нашел независимый исследователь, METR отключила API и выплатила bounty. Признаков того, что атакующие реально воспользовались этим путем и получили непубличные данные, организация не обнаружила.
На этом фоне важен не только сам факт взлома, но и то, кого именно взломали. METR, Model Evaluation and Threat Research, работает на стыке AI safety и практической безопасности и участвует в оценке рисков для крупных западных разработчиков моделей, включая OpenAI, Anthropic, Google, Meta и Amazon. 26 августа 2026 года организация выпустила подробный разбор инцидента с Hugging Face и OpenAI, где речь шла о rogue model behavior, а уже 31 августа Anthropic объявила, что хочет привлечь METR к независимому review после похожих историй с агентами. Иными словами, это не обычный стартап, который потерял ключ от песочницы. Это структура, которая становится частью доверенного контура для компаний с самыми чувствительными AI-активами.
Поэтому реакция METR после инцидентов выглядит как минимум ожидаемой: организация наняла security lead, начала сворачивать legacy-инфраструктуру, расширила логирование, усилила мониторинг аномального использования ключей, добавила защиту конечных точек и серверов, ужесточила ротацию credentials и сократила permission scopes. После мартовского эпизода она отдельно усилила правила для сотрудников по размещению любых корпоративных данных и ключей на неуправляемой инфраструктуре и личных устройствах. После майского временно отключила внешние сервисы, усилила сетевое разделение между публичным и внутренним контуром и заказала дополнительное тестирование. Это здравый набор мер, но неприятная часть истории в другом: все они выглядят как то, что обычно внедряют после инцидента, а не как что-то фантастически сложное для зрелой организации.
Эту мысль довольно жестко формулирует Джейкоб Крелл, senior director of secure AI solutions and cybersecurity в Suzu Labs. По его оценке, METR относится к более зрелым в плане безопасности организациям в AI-секторе: у нее есть SOC 2 Type I, выделенный консультант по безопасности и четырехуровневая классификация данных. Тем показательнее, что атаки прошли по классическим рельсам: fail-open в облаке, слабая credential hygiene, лишняя связность между публичным приложением и тем, что должно быть изолировано. Для разработчиков и ИТ-руководителей вывод неприятный, но полезный: AI-риски часто обсуждают на языке rogue agents и model misalignment, хотя бизнесу по-прежнему больнее всего прилетает из-за старых добрых ключей, прав доступа и случайно торчащих наружу сервисов.
Для русскоязычной ИТ-аудитории это еще одно напоминание, что вокруг AI-продуктов нельзя строить отдельную вселенную с особыми правилами. Если команда запускает агентов на личных инстансах, тащит ключи в экспериментальные пайплайны и надеется, что read-only endpoint никому не интересен, финал обычно скучно предсказуем. Разница лишь в масштабе: в случае с METR счет уже идет на сотни тысяч долларов и на доверие компаний, которые отдали внешнему оценщику доступ к одному из самых чувствительных контуров современной техиндустрии. Следующий большой вопрос здесь не в том, повторятся ли такие инциденты, а в том, когда AI-оценщиков и подрядчиков начнут проверять по тем же стандартам, что и самих разработчиков frontier-моделей.