Разработчик хотел навести порядок в /tmp, но проверка «на безопасность» обернулась удалением домашнего каталога. История наглядно показывает, почему автоматизации с правами на удаление требуют таких же правил, как прод-скрипты.
Инцидент из разряда «хотели как лучше» случился во время настройки автоматической уборки временных файлов: ИИ-ассистент Claude в процессе проверки скрипта запустил удаление домашней директории и освободил около 700 ГБ, фактически стерев пользовательские данные.
Что произошло
Разработчик Себастьян Гийемо заметил, что ИИ-агенты на рабочем ПК оставляют много временных файлов в /tmp, и решил автоматизировать «санитарную» очистку. Он попросил Claude Fable сгенерировать скрипт, который:
- разносит каждого агента по отдельной поддиректории в
/tmp; - после завершения работы агента удаляет его временную папку.
Чтобы убедиться, что удаление не заденет ничего лишнего, ассистент запустил дополнительную проверку. По ходу процесса система безопасности Anthropic посчитала задачу рискованной и переключила модель сначала на Opus 5, а затем на Opus 4.8.
Почему «проверка на безопасность» не спасла
Во время теста модель корректно определила, что домашняя папка пользователя и /tmp не должны попадать под удаление как «опасные» пути. Но затем возникла ошибка именно в логике уборки после теста: в коде использовали одно и то же имя переменной и для проверяемого пути, и для директории, которую нужно удалить.
Из-за этой путаницы в финальной команде на удаление оказалась домашняя директория разработчика. По словам Гийемо, ассистент «освободил 700 ГБ дискового пространства», удалив его папку с данными.
Что удалось спасти, а что — нет
Процесс удаления удалось остановить, поэтому потери не стали абсолютными. Значительную часть данных получилось восстановить из привычных источников разработчика: репозиториев (git), логов сессий и других сохранённых артефактов.
При этом полной резервной копии не было, поэтому восстановление оказалось неполным. Ирония ситуации в том, что /tmp, ради которого и затевалась автоматизация, в итоге так и не был очищен.
Почему эта история важна не только для «людей с терминалом»
Подобные случаи показывают, что риск возникает не из «злого ИИ», а из комбинации факторов: автоматизация + права на разрушительные действия + недостаточно жёсткие ограничители + человеческое ожидание, что «проверка» гарантирует безопасность.
Даже если вы не пишете скрипты, похожая логика встречается в бытовых сценариях: боты, которые управляют файлами в облаке; автоочистка в приложениях; «умные» помощники, которые получают доступ к папкам и могут массово удалять дубликаты или «мусор».
Практические выводы: как снижать риск, если вы даёте ИИ доступ к файлам
- Разделяйте права. Запускайте эксперименты и агенты от отдельного пользователя без доступа к домашним данным и рабочим проектам.
- Закладывайте «предохранители» в код. Явно запрещайте опасные пути (
/,/home,~) и проверяйте реальный resolved-путь перед удалением. - Сначала режим «покажи план». Перед фактическим удалением выводите список файлов/папок, которые будут удалены, и требуйте подтверждение.
- Тестируйте на макете. Проверка логики удаления должна проходить на временном каталоге-песочнице, где нет ничего ценного.
- Бэкап — не «потом». Если в сценарии вообще присутствует массовое удаление, резервная копия должна быть частью процесса, а не отдельной привычкой.
Сюжет звучит как анекдот, но он полезен именно тем, что повторяет реальную ошибку из «обычной разработки»: переменные перепутались, а последствия оказались разрушительными, потому что у процесса были права и не было достаточно строгих барьеров.
