Публикация Школы траблшутеров

Как одна команда ИИ-агенту привела к удалению всех данных на диске

Время чтения: 8 мин 25 сек
21 апреля 2026 г. Просмотров: 96

Искусственный интеллектОлег БрагинскийМарина Строева

Основатель «Школы траблшутеров» Олег Брагинский вместе с ученицей Мариной разбирают инцидент при взаимодействии с ИИ-агентом: одно действие привело к полной потере информации. Объясняют причины поведения системы и механизмы, повлиявшие на результат.

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

В момент происшествия проводилась работа по отладке медиа-сервера. Исправлялись ошибки кодека, блокировки в long-poll, стабилизация завершения работы (shutdown). Все изменения вносились через ИИ-агента, который анализировал логи, предлагал решения и выполнял команды.

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

go build ./cmd/server/...

в проекте появилась директория с буквальным именем:

...

На первый взгляд имя выглядит странно, но для Windows такая папка допустима. Такие артефакты иногда возникают из-за особенностей обработки путей с ... в инструментах Go. Важно, что это реальная папка, а не символ или ссылка.

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

Команда была максимально простой и естественной: «Закоммить и отправь в git»

При подготовке проекта к коммиту система обнаружила артефакт команды go build – директорию ... – и начала удаление ошибочно созданной папки. Но при работе через оболочку (shell) такая формулировка превратилась в интерпретацию пути, а не в имя объекта.

Агент начал подбирать команды удаления. Машина последовательно использовала несколько вариантов:

Remove-Item -Recurse -Force "go\cmd\server\..."

затем:

cmd /c rmdir /s /q E:\tgapp\tgapp\go\cmd\server\...

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

В частности:

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

Когда в команде появляется:

...\...

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

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

Критический фактор – использование флагов:

-Recurse -Force

Что означает:

  • игнорировать предупреждения
  • удалять всё внутри директории
  • не запрашивать подтверждение…

В Linux это аналог rm -rf. В Windows – практически то же самое. Если путь определён неверно, такая команда начинает удалять не одну папку, а всё, что попадает под интерпретированный путь.

В итоге произошло следующее:

  1. Путь go\cmd\server\... был интерпретирован не как конкретная папка, а как выражение с переходом по директориям.
  2. Команда начала выполняться выше ожидаемого уровня.
  3. Из-за -Recurse удаление пошло по всему поддереву.
  4. Удаление вышло за пределы ожидаемого каталога.

Ситуация усугубилась тем, что одна из команд запускалась через cmd /c и частично в фоновом режиме. Это означает, что даже если возникала ошибка, процесс уже успевал удалить значительную часть файлов до остановки.

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

Исчезло всё:

  • крипто-хранилища и подписывающие данные
  • папки с видео и фотографиями
  • вспомогательные инструменты
  • установленные приложения
  • игровые данные (Steam, CS)
  • архивы и резервные копии
  • локальные проекты.

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

Важно понимать масштаб. Если удалён проект:

  • его можно восстановить из Git
  • можно пересобрать окружение
  • можно восстановить код.

Но в этом случае:

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

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

Агент:

  • получил команду
  • сформировал корректный (с его точки зрения) вызов
  • выполнил его полностью.

У него нет:

  • механизма остановки при подозрительном масштабе
  • инстинкта самосохранения данных
  • понимания «это важно».

Если команда синтаксически корректна, машина не видит разницы между:

  • удалением папки build
  • очисткой всего диска.

Корень проблемы – не единичная ошибка, а сочетание факторов. Во-первых, использование неоднозначного пути (...), который по-разному трактуется системой. Во-вторых, применение мощной команды удаления без ограничений.

В-третьих, отсутствие промежуточной проверки – не было ни просмотра содержимого, ни подтверждения. И наконец, передача агенту полного доступа к файловой системе без ограничений (guardrails).

Человек в такой ситуации почти всегда остановился бы:

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

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

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

  • удаление
  • сохранение
  • перемещение
  • изменение структуры файлов.

ИИ-агент – инструмент с доступом уровня операционной системы. Не помогает в привычном смысле, а выполняет действия. И если дать ему право работать с диском без ограничений, любая неоднозначность в команде может привести к результату, который невозможно откатить.

В этом кейсе одна команда привела не к багу и не к падению сервера, а к полной потере всей среды – вместе с проектами, файлами и установленными программами. Это уже не ошибка разработки. Это полное стирание системы.

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

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

И самое главное – любым операциям с файловой системой должно предшествовать резервное копирование. Минимальный уровень – актуальный git push.

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