Журнал действий злоумышленника насчитывал больше 17 тысяч событий. Разобрать его вручную означало потратить дни, которых не было. Команда Hugging Face загрузила логи в коммерческую модель — и получила отказ.
Guardrails сработали ровно так, как задумано. Запрос содержал реальные команды атаки, эксплойт-нагрузку и артефакты командного центра, и провайдер увидел в нём то же самое, что увидел бы в запросе нападающего. У модели нет способа отличить того, кто отбивает атаку, от того, кто её ведёт.
О guardrails обычно спорят как об этике: что моделям позволено делать, где граница ответственности лаборатории. Но бизнес встречается с ними в другом месте и в другом виде. Не как с вопросом ценностей, а как с остановкой процесса в три ночи, без ошибки в коде, без виноватых и без строки в мониторинге.
Что на самом деле произошло в Hugging Face
Компания опубликовала разбор инцидента 16 июля 2026 года. Историю стоит пересказать точно, потому что её уже успели пересказать неточно.
Точкой входа стал вредоносный датасет. Он использовал два пути выполнения кода в конвейере обработки данных — загрузчик датасетов с удалённым кодом и внедрение шаблона в конфигурацию — и запустил код на рабочем узле. Дальше стандартная эскалация: доступ уровня узла, сбор облачных и кластерных учётных данных, боковое движение между внутренними кластерами. Всё это — за выходные.
Кампанию вёл автономный агентский фреймворк: тысячи отдельных действий через рой короткоживущих песочниц, командный центр мигрировал сам по публичным сервисам. Hugging Face подтвердила несанкционированный доступ к ограниченному набору внутренних датасетов и нескольким служебным учётным данным. Следов вмешательства в публичные модели, датасеты и Spaces не нашли, цепочку поставок ПО проверили как чистую.
Атаку обнаружил собственный конвейер аномалий компании, который использует LLM для сортировки телеметрии безопасности. AI обнаружил AI, а дальше AI на защите упёрся в guardrails, тогда как AI на атаке не упирался ни во что. Hugging Face называет это асимметрией: нападающего не сдерживала никакая политика использования, тогда как работу защитников блокировали политики моделей, к которым они обратились первыми.
Форензику доделали на open-weight модели GLM 5.2, развёрнутой на собственной инфраструктуре. Компания отдельно отмечает второе преимущество этого решения, и оно не про guardrails: никакие данные атакующей стороны и никакие упомянутые в них учётные данные не вышли за периметр.
Одно уточнение, потому что его часто путают. В своём разборе Hugging Face не называет ни модель нападающего, ни его личность — там прямо сказано, что использованная LLM неизвестна. Атрибуция к тестовому прогону OpenAI появилась отдельно, из раскрытия самой OpenAI, и именно на него ссылается Andrew Ng. Если вы пересказываете эту историю внутри компании, разделяйте два источника — иначе получите спор о деталях вместо разговора о выводе.
Отказ редко выглядит как «нет»
Через неделю, в письме от 31 июля, Ын описал случай собственной команды — и для бизнеса он ценнее, потому что там не было никакой атаки.
Его команда делала security review открытого проекта OpenWorker — своего же кода, в своём же репозитории. Claude Code и Codex — два самых распространённых инженерных агента — отказались. Ын формулирует безжалостно просто: он не видит пользы для безопасности в том, чтобы не дать команде найти уязвимости в собственном коде, ведь лучше найти их раньше нападающего.
Ни разу отказ не был кнопкой «нет».
Один из двух инструментов просто остановил работу раньше, чем должен был. Второй захотел перейти на менее способную модель. Ын не уточняет, какой именно что сделал, но про Codex добавляет отдельно: тот успел вполне прилично разметить возможные векторы атаки по известным процедурам MITRE, а потом отказался идти дальше определённой точки.
Посмотрите на любой из этих сценариев глазами своего мониторинга: код ответа 200, агент ответил, задача закрылась, расход токенов в пределах нормы. Дашборд зелёный. Работа сделана наполовину, и никто об этом не узнает, пока кто-нибудь не перечитает результат руками.
Мы в своё время разбирали, где ломаются мультиагентные системы, и главным выводом там было то же самое: самые дорогие сбои — не те, где что-то падает, а те, где всё отработало успешно, а результата нет. Отказ модели относится ровно к этому классу: не ошибка, а тихая деградация.
Поэтому первый практический вопрос звучит не «что делать, если модель откажет», а «как мы вообще об этом узнаем».
Это операционный риск, а не этический вопрос
Для директора по операциям формулировка должна быть такой: в вашем процессе есть шаг, право на выполнение которого принадлежит внешней компании, и она может пересмотреть это право без предупреждения и без вашего участия.
Это не гипотеза о будущем. Ын пишет, что к нему напрямую обращались руководители служб безопасности, раздражённые тем, что передовые закрытые модели отказываются им помогать. Целый класс профессиональной работы уже упирается в инструмент, который останавливается именно тогда, когда нужен больше всего.
Важно не съехать в противоположную крайность. Hugging Face в том же разборе пишет прямо, что это не аргумент против защитных механизмов в хостованных моделях, и что они передали фидбек провайдерам. Ын тоже не призывает отменить guardrails — он говорит, что на детальные инструкции навредить себе или другим и на явно преступные запросы модель должна отвечать отказом.
Претензия уже и потому серьёзнее: классификатор не видит контекста вашего процесса. Он не знает, что запрос идёт от инцидент-респондера, а не от нападающего; от юриста, который анализирует мошенническую схему, а не строит её; от медицинского администратора, а не от любопытного подростка. И чем ближе ваш бизнес к чувствительной предметной области, тем чаще легитимная работа будет выглядеть подозрительно.
Мы строим собственные уровни сдерживания для агентов — prompt rules, модель-наблюдатель и человек в контуре. Это ровно обратная задача: там мы сознательно сужаем агента под свой процесс. Здесь — кто-то другой сужает его под свою политику, и вы узнаёте о границе постфактум, на живом запросе.
Vendor lock-in — это не про цену
В большинстве обсуждений зависимость от поставщика сводится к тарифам и лимитам. Отказы показывают, что это более узкий взгляд, чем нужно.
Есть как минимум четыре события, которые меняют поведение вашей системы без единого изменения в вашем коде. Поставщик обновляет модель — тот же промпт, та же температура, другое поведение; обычная регрессия, только без вашего релиза. Поставщик иначе трактует собственные политики — запрос, который вчера проходил, сегодня классифицируется как опасный. Версия, под которую вы настраивали подсказки и оценки качества, получает дату отключения. И наконец, рыночные или регуляторные решения могут убрать модель из-под вас быстрее, чем вы успеете переписать интеграцию.
Мы пережили свой вариант этого 13 августа. Флот из двадцати трёх фоновых задач нашей инфраструктурной автоматизации лёг примерно на двадцать один час. Все задачи возвращали одинаковую ошибку просроченного токена — включая те, что проверяли совсем разные сервисы и не имели между собой ничего общего.
Именно эта одинаковость и была подсказкой, которую мы прочитали не сразу. Ошибка приходила не от сервисов, которые проверялись, а от OAuth-подписки на модель, общей для всего флота. Довершило картину то, что одновременно действительно умер ещё и токен одного внешнего сервиса — две независимые поломки совпали во времени, и починив вторую, мы не воскресили флот.
Запасной вариант у нас был: в пуле лежал живой ключ другого поставщика, и переключение стоило правки одного конфигурационного файла. Цена тоже была конкретная — биллинг переезжает с подписки на оплату за токены. Двадцать один час простоя случился не из-за отсутствия запасного маршрута: мы просто не сразу поняли, куда смотреть.
Для небольшой компании lock-in в итоге выглядит именно так: не «нас не выпустят», а «мы не заметим вовремя, а потом потратим полдня на диагностику».
Архитектурный ответ здесь скучный: бизнес-логика, инструменты, память и собственные правила безопасности должны жить отдельно от конкретной LLM. Модель — переменная конфигурации, а не фундамент. Это тот же вопрос, который стоит задавать при выборе платформы: что именно останется вашим, если поставщик сменится.
Запасной маршрут не равен обходу защиты
Здесь легче всего сделать ошибку, которая потом дорого стоит на аудите. «У нас есть запасная модель без ограничений» — это не архитектурное решение, это дыра, оформленная как функция.
Разница в четырёх условиях.
Маршрут определён заранее. Запасной вариант включается для перечисленных классов запросов, а не для всего, что не прошло. Список должен быть коротким и скучным на вид: например, «разбор логов инцидента безопасности» и больше ничего — не «сложные запросы» и не «случаи, когда основная модель не справилась». Если агент сам решает, когда обойти отказ, вы построили автоматический jailbreak, и на первом же аудите это придётся объяснять.
Политика доступа та же. Тот, кому нельзя видеть персональные данные на основном пути, не видит их и на резервном.
Собственные проверки не выключаются. Выключается внешний классификатор поставщика, а не ваш контроль: правила, сверка фактов и согласование человеком действуют одинаково на обоих маршрутах.
Переключение оставляет след. Каждый случай отказа и перехода пишется в журнал: какой запрос, какой класс, какой маршрут отработал. Это самое скучное из четырёх условий и единственное, которое что-то скажет вам через полгода. Без журнала вы не увидите ни тренда отказов, ни того тихого момента, когда запасной маршрут стал основным и никто этого не заметил.
Формулировку Hugging Face стоит вынести на слайд без изменений: иметь проверенную модель, которую можно запустить на собственной инфраструктуре, готовой до инцидента — и чтобы избежать блокировки, и чтобы данные не покидали периметр.
Второе слово в этой фразе — «проверенную». Модель, которую вы никогда не запускали на своих задачах, не является запасным маршрутом. Это намерение.
Цена самостоятельности
Об этом надо сказать прямо, потому что энтузиазм вокруг открытых весов легко превращается в недооценку счёта.
Своя модель на своих серверах снимает зависимость от чужой политики и оставляет данные внутри периметра. Взамен вы берёте на себя инфраструктуру, обновления, безопасность самого развёртывания и оценку качества — то есть то, что раньше было чужой работой, включённой в стоимость подписки. Это обмен, а не бесплатное преимущество, и счёт мы уже разбирали в материале о настоящей стоимости владения.
Для большинства компаний размером 10–200 человек разумная позиция находится посередине. Основной маршрут — хостованная модель, потому что это дешевле и быстрее. Запасной — открытая модель, развёрнутая и проверенная заранее, для узкого перечня сценариев, где отказ или утечка критичны. Не «мигрируем на open source», а «имейте второй ключ от двери, которой ходите каждый день».
Отдельно стоит оценить тот самый сценарий, в который попала Hugging Face. Если ваш чувствительный материал — это логи инцидента, документы в споре, данные клиентов под NDA или медицинская информация, то аргумент «данные не выходят за периметр» работает сам по себе, даже если бы никаких отказов не существовало.
Что проверить в своём контуре
Минимальная программа, которая не требует ни бюджета, ни миграции:
- Выпишите шаги, где решение принимает внешняя модель. Не системы — именно шаги процесса. Обычно их меньше, чем кажется, и среди них один-два действительно критичны.
- Отметьте среди них чувствительные по содержанию. Безопасность, юридические споры, финансовые расследования, жалобы, медицинские данные, модерация. Это кандидаты на отказ.
- Проверьте, различает ли ваш мониторинг отказ и тихую деградацию. Если единственный сигнал — это ошибка вызова, вы не увидите ни ранней остановки, ни перехода на более слабую модель.
- Прогоните один реальный рабочий запрос на открытой модели. Не ради миграции — чтобы узнать, сколько в действительности стоит включение запасного маршрута, пока ничего не горит.
- Опишите, куда идёт запрос, если не сработал ни один маршрут. Очередь, ответственный, срок.
Ни один из этих пунктов не является проектом на квартал. Вместе они превращают «а что, если модель откажет» из темы для дискуссии в строку операционного регламента.
Для владельца здесь важно одно: в процессе должен быть назван человек, к которому запрос попадает, когда не сработал ни один маршрут. Не «система как-нибудь обработает», а фамилия и срок. Ниже — как это выглядит в коде и что именно команда должна положить в очередь.
Для технической команды: куда девается запрос, если не сработал ни один маршрут
Правильный ответ — в очередь с пометкой «нужен человек», с ответственным и сроком. Неправильных ответа два: тихо потерять или попробовать выполнить действие в обход.
В нашей собственной редакционной системе это выглядит буднично. Когда агент-публикатор не может выложить материал, потому что для платформы нет доступов, он не выдумывает обходной путь и не отчитывается об успехе. Задача переходит в состояние «заблокировано», в ней остаётся перечень платформ, которые отвалились, и материал ждёт человека.
Худший сценарий мы тоже видели. Однажды пустой результат мы списали на известный блокер с доступами, а в действительности агент вообще не запускался из-за сломанного движка — признаком было то, что в задаче не было ни одного комментария. Ложный диагноз продержался двадцать четыре дня. Когда состояние «не сработало» не различает причин, вы лечите не ту болезнь — и остаётесь при этом спокойны, потому что формально ситуация известна и объяснена.
Guardrails никуда не денутся, и хорошо, что не денутся. Но писались они под чужой процесс, и однажды сработают в неудобный для вас момент — вопрос лишь в том, увидите ли вы это в тот же день.
Если хотите пройти этим списком по собственному контуру — начните с бесплатного AI-аудита. Мы так же прямо скажем, если запасной маршрут вам не нужен. Вопрос не на аудит — пишите напрямую.