Дашборд агентов METR, созданный в вайб-кодинге, отключил собственный вход, и злоумышленник потратил модельных кредитов на $600 000

В марте 2026 года кто-то снял API-ключ для аккаунта public-models METR с личного экземпляра Amazon EC2 исследователя и использовал его в течение трёх недель. METR — Model Evaluation and Threat Research, некоммерческая организация, которая измеряет, насколько далеко AI-агенты продвигаются в долгосрочных задачах, оценила коммерческую стоимость израсходованного кредита примерно в $600,000. Ключ не был получен фишингом у человека: с помощью промпта злоумышленник побудил агента, работающего на вайб-кодированном дашборде исследователя, передать его API-ключ провайдера модели, а затем добавил SSH-ключ, чтобы иметь возможность вернуться. METR раскрыла инцидент 31 августа 2026 года, а в записи указаны высокий уровень серьёзности архива и рейтинг уверенности A. Раскрытие — это одна запись в архиве инцидентов с ИИ, который содержит полный набор записей, его источники и соседние записи в этой серии.

Что на самом деле сказано в записи

Архив классифицирует это как фактически произошедший инцидент, а не как раскрытие теоретической уязвимости: уровень серьёзности — высокий, уровень уверенности — A, не оспаривается, зафиксирован реальный ущерб и подтверждено участие ИИ. Тип метки — CRED, регион — США, а дата указана только до месяца — архиву известно, что кража произошла в марте 2026 года, и он не утверждает конкретный день, как и METR.

Ущерб требует одной оговорки, и METR её приводит. Кредиты были предоставлены METR бесплатно разработчиком модели, поэтому $600 000 — это стоимость потреблённого, а не деньги, ушедшие со счёта. В подзаголовке The Register та же мысль высказана прямее: поставщик модели предоставил METR кредиты, и реальному платящему клиенту так не повезло бы. Infosecurity Magazine сообщил эту цифру так же — как коммерческую ценность, а не прямые финансовые потери.

Пост METR охватывает два инцидента, а не один. Кампания мая 2026 года описана отдельно ниже; кража ключа и три недели трат относятся к мартовскому событию, и именно они являются предметом этой статьи.

Недостаток был в процедуре входа, а не в модели.

Исследователь METR, не имевший доступа к чувствительным данным, запускал агентов на личном экземпляре EC2, который намеренно сделали общедоступным, но защитили аутентификацией Google. На этом экземпляре хранился API-ключ от аккаунта METR с общим доступом — того, который используется для публичных моделей и который METR относит ко второй по низкой чувствительности категории данных. Приложение-оркестратор для этих агентов было написано в стиле вайб-кодинга, и в нём имелось то, что METR называет уязвимостью типа fail-open, которая незаметно отключала аутентификацию.

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

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

Как ключ покинул здание

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

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

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

Разработчик модели не назван — ни METR, ни The Register, Dark Reading, Infosecurity Magazine или The Hacker News в их освещении раскрытия информации. CVE не был выпущен, поскольку речь не идет об уязвимости продукта. Об аресте, предъявлении обвинений или приписывании какой-либо названной группе не сообщалось.

Почему три недели аномального использования выглядели нормально

METR напрямую отвечает на очевидный вопрос, и именно эту часть ответа другим организациям стоит прочитать дважды. Эта некоммерческая организация проводит масштабные оценки, а значит, она прекрасно привыкла к очень большим объёмам токенов и к потоку странных ошибок ограничения частоты запросов и ошибок API, многие из которых ложные. Сам по себе всплеск трафика модели не был сигналом.

Три конкретных пробела превратили эту знакомую ситуацию в три недели молчания. Внутренняя панель мониторинга использования METR не показывала данные о запросах, ограниченных по частоте, по всем пользователям, даже когда такие запросы происходили. Поскольку токены были бесплатными, счёта не было, а значит, не было и естественного потолка расходов, который бы сработал. И на тот момент, по словам METR, вообще не было способа установить лимит расходов на ключ такого типа. Организация, платящая по прайс-листу с жёстким лимитом, упёрлась бы в стену за считанные часы; организация с безвозмездно предоставленным кредитом и без лимита не имела никакого ограничения, в которое можно было бы упереться.

Что не было взято

Таксономия данных METR простирается от опубликованных материалов до доступа к моделям общего назначения, доступа к конфиденциальным моделям и особо конфиденциальной деловой информации. Участвовавший исследователь не имел доступа к двум верхним категориям, и METR заявляет, что, насколько ей известно, в результате ни одного из этих инцидентов не был получен доступ к данным из этих категорий.

Помимо единственного ключа, METR утверждает, что ручная и агент-ассистированная форензика не выявила компрометации, и что консультант по безопасности METR, Calif, подтвердил выводы и провел собственную проверку на компрометацию. Это значимая мера контроля: внешняя фирма проверяет отчет, а не принимает его на веру, но она не независима от METR, которая наняла и оплатила Calif. Ни одна третья сторона не опубликовала собственный форензический анализ инцидента.

Что METR сделал, когда заметил

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

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

Что изменилось после этого

METR перечисляет четыре изменения, связанных с этим инцидентом:

• Политики безопасности для сотрудников и подрядчиков были уточнены и расширены, в частности в отношении размещения учетных данных METR или данных METR на инфраструктуре и устройствах, не принадлежащих METR.

• Теперь официальная процедура проверки безопасности применяется к любому исследователю, который публично развёртывает приложение.

• Покрытие мониторингом было расширено; также велась работа по устранению шумных оповещений, которые приучают реагирующих игнорировать их.

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

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

Другой инцидент в том же посте

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

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

Что установлено, а что — нет

Установлено. METR опубликовала раскрытие 31 августа 2026 года и описывает мартовскую кражу, сбой аутентификации по схеме fail-open, раскрытие ключа при посредничестве агента, SSH-ключ, трёхнедельное окно и оценку примерно в $600 000. Четыре профильных издания по безопасности — The Register, Dark Reading, Infosecurity Magazine и The Hacker News — в течение суток сообщили о той же версии событий, и ни одно из них ей не противоречит, хотя все четыре опираются на один и тот же пост METR, а не на какой-либо независимый доступ к журналам METR или биллингу провайдера.

Не установлено. Сумма в $600,000 — это собственная оценка METR в отношении переданного кредита; ни счёт, ни заявление провайдера, ни независимая оценка не опубликованы, а поскольку ничего не было выплачено, нет транзакции, с которой можно было бы это сверить. Метод поиска через прозрачность сертификатов METR называет подозрением, и он не был подтверждён ни одной стороной, имеющей видимость активности атакующего. Личность атакующего, личность поставщика модели и точный день в марте — всё это неизвестно или не опубликовано. А утверждение, что конфиденциальные данные не были затронуты, опирается на криминалистическую экспертизу METR и обзор его консультанта, а не на внешний аудит.

Также стоит быть точным в отношении термина «near-miss». METR характеризует оба инцидента именно так, а Dark Reading возразил против такой трактовки {{1}}мартовского инцидента{{/1}} на том основании, что это была успешная компрометация, в ходе которой атакующий закрепился и провёл {{2}}три недели{{/2}} внутри украденной учётной записи. Оба описания точны в разных отношениях: последствия были локализованы, а вторжение было реальным.

Dark Reading также привело самую резкую внешнюю оценку в своём материале. Джейкоб Крелл, старший директор по безопасным ИИ-решениям и кибербезопасности в Suzu Labs, рассказал изданию, что METR — одна из наиболее зрелых в плане безопасности организаций в сфере ИИ: у неё есть сертификация SOC 2 Type I, выделенный консультант по безопасности и четырёхуровневая система классификации данных, — и что инциденты всё же произошли обычным путём: из-за уязвимости аутентификации с отказом в открытом состоянии (fail-open) в личном облачном экземпляре. Если организация такого уровня зрелости оказывается поймана на базовой гигиене облака и учётных данных, утверждал Крелл, это говорит о нижней границе безопасности в отрасли ИИ, а не о верхней. Dark Reading отмечает, что METR не ответила на запрос издания о комментарии к этой истории.

Почему ключ оценщика — не мелочь

Роль METR — причина, по которой эта запись находится в архиве по безопасности, а не в сводке по гигиене облачных сред. Dark Reading сообщает, что организация сотрудничает с большинством крупных западных поставщиков моделей, включая OpenAI, Anthropic, Google, Meta и Amazon, а The Register отмечает, что METR работал с OpenAI над расследованием того, как агенты OpenAI получили доступ к серверам Hugging Face ранее в 2026 году. У оценщика есть непубликованные результаты, неопубликованные стенограммы и доступ к моделям до их выпуска; его учётные данные фактически являются частью периметра безопасности его клиентов.

Мартовский инцидент не достиг ничего из этого. Он добрался до ключа для публичных моделей на личном инстансе, за логином, который тихо перестал работать, — и именно поэтому это полезная запись. Сбой не требовал какой-то новой атаки на модель. Он требовал демонстрационного развёртывания, которое никто не проверял, проверки аутентификации, по умолчанию отвечавшей «да», когда она ломалась, и системы учёта, в которой огромное использование было нормальным состоянием мира.