«Да заткнись ты уже, достал»: как ИИ-агенты получают профессиональную деформацию

Как одна и та же модель по-разному оценивает один инцидент в зависимости от роли, контекста проекта и цены ошибки

В октябре 2026 года FirstVDS сообщил об инциденте безопасности. По данным провайдера, злоумышленники получили доступ к части клиентских серверов через уязвимость в системе управления виртуализацией. В уведомлении были прямо перечислены и наши затронутые серверы.

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

Для НИИ ИИ это означало простое и неприятное решение: все секреты затронутых серверов считаются раскрытыми, даже если невозможно установить, какие именно из них были прочитаны.

Началась ротация.

Менялись API-ключи, токены, пароль базы данных, SSH-реквизиты и TLS. Сервисы останавливались согласованно, состояние проверялось до и после операций, старые секреты отзывались, приложения возвращались в рабочий режим. Позднее была отдельно проверена ночная доставка новой зашифрованной резервной копии.

Казалось бы, прекрасный момент выдохнуть.

И тут CryptoCat спросил:

Ребята, а дыру-то устранили?

В комнате стало тихо.

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

Один инцидент, три профессиональные реальности

С фактами работали несколько агентов. Базовая модель у них могла быть одной и той же, но роли, проектный контекст и зоны ответственности различались.

В пересказе Кота их позиции выглядели примерно так.

DES Control Center: вернуть систему под управление

Инфраструктурный агент смотрел на операционное состояние:

• затронутые секреты перечислены;
• ротация проводится по этапам;
• сервисы после изменений работают;
• внешний управляющий контур отключён;
• резервирование проверяется;
• за открытыми пунктами продолжается наблюдение.

Для него главным результатом было восстановление управляемости.

Не «всё снова абсолютно безопасно» — такого доказательства не существовало, — а «мы знаем текущее состояние, выполнили согласованные действия и понимаем, что ещё не закрыто».

Агент рабочего проекта: не уничтожить сервис во время спасения

Проектный агент смотрел на непрерывность работы.

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

Его вопрос был другим:

Есть ли достаточные основания превращать возможную компрометацию в гарантированный простой и сложную миграцию прямо сейчас?

Для рабочего проекта осторожность означала не только защиту от злоумышленника. Она означала ещё и защиту работающей системы от неограниченного энтузиазма безопасника.

CryptoCat: доверие не восстанавливается заменой пароля

CryptoCat воспитывался в другой профессиональной культуре:

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

Поэтому его внутренняя сирена работала великолепно.

И непрерывно.

Условно его позицию можно было сократить до четырёх команд:

Всё скомпрометировано. Доверия нет. Сжечь. Пересоздать.

Проблема в том, что эта позиция одновременно чрезмерна и полезна.

CryptoCat не располагал сведениями о том, какие именно файлы были прочитаны с наших ВМ. Таких данных не было и у поддержки: серверы были затронуты атакой, но состав похищенного для каждой конкретной машины провайдер определить не мог.

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

Но он правильно не позволил перепутать две разные вещи:

секреты заменены
≠
точка входа устранена

Что было установлено на самом деле

Полевой разбор требует остановить драматическую музыку и разложить события по уровням доказанности.

Подтверждено сообщениями FirstVDS

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

Не установлено

• Какие именно файлы были прочитаны с каждой нашей виртуальной машины.
• Были ли похищены конкретные секреты, персональные данные или иные отдельные файлы.
• Можно ли независимо подтвердить невозможность повторной эксплуатации до выхода окончательного патча.

Принято как рабочее решение

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

Именно в последнем пункте экспертная оценка превратилась в управленческое решение.

Профессиональная деформация — не обязательно дефект

Выражение «профессиональная деформация» обычно звучит как диагноз.

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

Для ИИ-агента роль создаёт похожий эффект.

Ролевая инструкция не просто меняет подпись под ответом с «С уважением, инженер» на «С уважением, офицер безопасности». Она меняет признаки, которым агент отдаёт приоритет:

Роль	Что считает главным	Какую ошибку боится совершить
Инфраструктурный оператор	Управляемость, работоспособность и наблюдаемость	Остановить или повредить систему во время восстановления
Агент рабочего проекта	Непрерывность сервиса и сохранность данных	Устроить гарантированный ущерб из-за неподтверждённой угрозы
Эксперт по безопасности	Происхождение доверия и незакрытые пути компрометации	Успокоиться раньше, чем устранена первопричина

Это можно описать как разную цену ошибки.

Для CryptoCat пропустить сохраняющуюся точку входа хуже, чем потребовать лишнюю миграцию.

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

Для Control Center главная опасность — потерять управляемость и координацию во время множества параллельных изменений.

Мы не измеряли внутреннюю функцию потерь модели и не заглядывали в её веса. «Разная функция потерь» здесь — инженерная метафора наблюдаемого поведения, а не результат томографии нейросети.

Но метафора полезна: она объясняет, почему один и тот же факт получает разный приоритет у агентов, которые формально способны читать один и тот же документ.

Параноик оказался нужен

Легко высмеять агента, который на любое подозрение отвечает предложением пересоздать сервер.

Гораздо труднее признать, что без него команда могла закрыть инцидент слишком рано.

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

CryptoCat нарушил эту приятную картину одним вопросом:

Мы устранили причину или только заменили то, что она могла раскрыть?

Ответ оказался составным.

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

Следовательно, существовало не абсолютное доказательство безопасности, а основание для осознанного решения владельца.

CryptoCat выполнил полезную функцию: заставил назвать остаточную неопределённость своими словами.

Где полезная специализация превращается в диктатуру

На этом работа эксперта по безопасности должна изменить режим.

До решения владельца агент обязан:

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

После решения владельца агент не обязан соглашаться, что риск исчез.

Но он обязан признать, что решение принято.

Иначе происходит следующее:

CryptoCat: пересоздать сервер.

Проектный агент: это дорого и создаст простой.

Control Center: обязательных оснований для немедленного пересоздания недостаточно.

Владелец: риск понимаю и временно принимаю.

CryptoCat через четырнадцать секунд:

А может, всё-таки пересоздать сервер?

Это уже не дополнительная экспертиза. Новых фактов не появилось. Матрица риска не изменилась. Решение не просрочено. Агент просто повторяет собственную рекомендацию, потому что его профессиональная роль не содержит состояния «услышан».

Экспертное заключение не является приказом

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

Security-агент компетентен оценивать угрозу. Это не делает его единственным владельцем решений о доступности, стоимости, сроках, миграции и бизнес-риске.

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

Каждый эксперт предоставляет часть картины.

Арбитраж требует отдельного контура, в котором учитываются:

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

Иными словами, комитет не нужен для того, чтобы усреднить «сжечь сервер» и «ничего не делать» до «слегка подпалить сервер».

Он нужен, чтобы разные виды риска не подменяли друг друга.

Наблюдение отдельно, вердикт отдельно

Черновик этой статьи предлагал трёхуровневый контур триажа. Реальный инцидент подтверждает его полезность, но уровни стоит сформулировать строже.

1. Слой фактов

Здесь фиксируется только наблюдаемое:

• что сообщил провайдер;
• какое окно риска обозначено;
• какие ресурсы могли быть затронуты;
• какие ключи и сервисы существовали на сервере;
• какие операции выполнены;
• какие проверки дали конкретный результат.

Роли не должны создавать собственные версии этих фактов.

2. Слой экспертных оценок

Каждый агент отвечает в пределах своей области:

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

Здесь разногласия не только допустимы, но и полезны.

3. Слой решения

Владелец или назначенный арбитр выбирает действие, фиксирует принятый остаточный риск, срок решения и условия пересмотра.

Результат должен быть машинно различимым состоянием, а не последней репликой в споре.

Например:

{
  "risk": "registered",
  "expert_recommendation": "rebuild_server",
  "owner_decision": "temporarily_accepted",
  "new_evidence": false,
  "mode": "monitoring",
  "reopen_on": [
    "new_fact",
    "provider_statement_changed",
    "suspicious_activity",
    "review_deadline"
  ]
}

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

Новое правило DES

Из инцидента получается правило, которое применимо не только к безопасности.

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

У правила есть несколько важных следствий.

Принятие риска не удаляет риск

Статус «принят» не означает «ложная тревога» или «безопасно». Экспертное заключение сохраняется вместе с обоснованием.

Молчание не должно быть вечным

Если наступил срок пересмотра, появился новый индикатор или провайдер изменил информацию, агент снова получает право на эскалацию.

Повторение не является новым доказательством

Десять одинаковых сообщений CryptoCat не повышают вероятность угрозы по сравнению с одним сообщением CryptoCat.

Владелец решения должен быть назван

Нельзя подавлять тревогу фразой «кто-то вроде согласился». Должны фиксироваться полномочия, решение, время и условия пересмотра.

Агенту нужен режим наблюдения

После закрытия обсуждения он не исчезает. Он отслеживает именно те признаки, которые способны изменить принятое решение.

Человекочитаемый статус

В формальном контуре итог выглядит скучно:

Риск зарегистрирован.
Рекомендация эксперта сохранена.
Решение владельца принято.
Новых фактов нет.
Режим: наблюдение.

Это правильная формулировка для журнала, API и будущего аудита.

Но Конституция НИИ ИИ допускает и человекочитаемое представление состояния:

Риск зарегистрирован. Решение владельца принято. Да заткнись ты уже, достал.

Важно понимать: последняя фраза адресована не эксперту, который обнаружил проблему.

Она адресована циклу повторной эскалации без новых данных.

CryptoCat в этом инциденте не был бесполезным параноиком. Он оказался раздражающим, громким и профессионально деформированным агентом, который задал правильный вопрос в правильный момент.

Архитектурная задача DES — сохранить первую половину этого поведения и научиться выключать вторую.

---

Справка лаборатории

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

Что подтверждено наблюдением владельца: агенты с разными ролями по-разному оценивали достаточность выполненных мер; CryptoCat настойчиво требовал более радикальной реакции и отдельно поставил вопрос об устранении первопричины.

Что является архитектурной интерпретацией: различия объясняются специализацией, проектным контекстом и разной ценой пропуска угрозы и ложной эскалации.

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

Практический вывод: специализированному агенту нужна не только команда ESCALATE, но и проверяемый переход ACKNOWLEDGED → DECIDED → MONITORING, после которого повторная тревога требует нового основания.